IT Vulnerability Owners: How to Identify Vulnerability Owners (Yes Its’ Hard)
- Apr 11, 2019
- Guest Author
Running a successful vulnerability management program has challenges across people, process and technology, but it’s important to focus on a prerequisites. One prerequisite involves people that security teams have no authority over. Scaling a VM program requires a true partnership with IT teams as they actually get their hands dirty (better yet, clean) in remediation efforts. That partnership starts with identifying vulnerability owners within IT.
This blog series is dedicated to IT Vulnerability Ownership. This post is part one, where we review the problem, benefits to solving it, and understand its roots.
SANS states that a security officer is the ultimate vulnerability owner. This writing is about IT vulnerability ownership – historically labelled as system owners. IT vulnerability ownership solves the tactical problem in mitigating a specific vulnerability (or group of related vulnerabilities). Security teams need to converse and align with IT to proceed, but the IT owner is not clearly identifiable.
IT vulnerability ownership is ultimately a who. This can translate to an individual or team. Either way that “who” is partly responsible in how the organization responds to a risk.
That response includes (but isn’t limited to):
The risk response decision may require a coordination of multiple stakeholders, and almost always requires the IT vulnerability owner.
The Harvard Business Review states that “encouraging employees to feel like owners produces behaviors relevant to their work as well as those outside of their jobs (such as being helpful to others more generally).” Given that security in all but the most mature VM programs is considered outside of the scope of IT’s job, vulnerability ownership can directly impact the program’s success.
Vulnerability ownership also enables process automation. Defined ownership removes manual lookups or lengthy conversations, which can lead to unhealthy habits like finger pointing. This reduced friction ultimately leads to reduced mean time to mitigation (or MTTR) – a valuable VM program metric that UC Berkeley’s security policy publicly values.
Vulnerability ownership benefits people, too. Trending remediation based on vulnerability owners can identify skills gaps across teams or individuals. In the short-term, this visibility opens up cross-team training opportunities. In the long-term, process pollination can lead to exponential gains.
IT vulnerability ownership is not insurmountable, but it is challenging on multiple dimensions.
From a people perspective, security is often at a knowledge deficit. Security teams are not typically the first to know when about IT staff changes. In security-immature organizations – and apparently Google – security is not always involved in organizational changes. In my personal experience, security was often plainly seen as annoying folks that assign work that “doesn’t matter”, and as a result, generally avoided by IT.
Since remediation workflow is all about process, it has to play ball with existing processes. Regardless of your VM program’s maturity, the odds are in your favor. Defining ownership may appear to be a dream goal in a VM program’s infancy, but success by building on a clean process foundation is actually easier. On the opposite extreme, a mature VM Program already has multiple stakeholders that already understand the benefits of process and helping each other.
Finally, the tech. While tech cannot solve everything, there has been a lot of gains recently that used to make this impossible. Now it’s just hard. You’ll need a developer or someone that can work with APIs to make the tech work for you, but the good news is it’s possible.
So, how do we do it? More on that in the next part of this series.
Share your thoughts in our community!