Clues to identifying IT vulnerability owners
IT Vulnerability Ownership, Part 2: Find early adopters
Telling people what to do gets nowhere fast. I even have to justify my suggestions to my grade school daughter. Partnering with stakeholders removes the friction of creating a new process. The key is finding the right partners to jointly create that process of vulnerability ownership–the goal being able to assign a vulnerability to the appropriate IT individual automatically. That partnership starts with identifying vulnerability owners within IT that are able and willing.
This blog series is dedicated to IT Vulnerability Ownership. This post is part two, where we identify the right IT staff to partner with to start the vulnerability ownership process.
Why partnering with IT is necessary
The ultimate goal is to increase the health of your vulnerability management program. After vulnerabilities mitigation has been approved, the infosec team alone lacks permission (e.g., write-access) to make the necessary changes. The IT team has these technical privileges. So easy solution, right? Just assign tickets to the generic IT email address, right? While team accountability is possible, it’s rare and typically leads to no accountability. Fortunately, individual ownership resolves this.
Finding the right individual is the challenge. Most organizations will separate their IT team from their infosec team, and will go as far as having separate management. IT’s charter is typically to build the things that make money, and often sees infosec as slowing them down. This separation and perception of conflicting goals does not foster an open and trusting channel for infosec to correctly identify IT vulnerability owners.
It’s important to note that assigning work to the wrong IT teammate is seen as noise by IT and over time discredits the infosec team–I have personally seen this lead to hasty generalizations by IT claiming “false positive” for any infosec assignments.
Benefits of partnering with early adopters from IT
Taking the time and energy to identify the right vulnerability owners has direct benefits for reducing the risk of your organization. It creates accountability to jumpstart the vulnerability mitigation process, reducing the risk of your organization.
This effort will not go unnoticed and will lead to indirect benefits. Demonstrating a proactive attitude to meet IT halfway will increase the infosec team’s reputation in the eyes of IT. This will accelerate the long-term benefits, IT engagement leading to self-serve ownership decisions on their own.
Invite IT early adopters, but gently
If this approach is new to your organization (or has a lower CMMI), it’s best to be as inclusive as possible. Assume everyone is interested and make it easy for IT owners to find you. I suggest not being too noisy (avoid spamming colleagues) and find a way informally make it a positive experience. When I was VM owner, I found that IT colleagues were generally willing to help if they clearly understand the parameters and problem that needs to be solved.
If you already have a relationship with IT, it’s likely you already have a decent set of early adopters in mind. I suggest keeping ownership informal until you and IT are comfortable drafting a process together–more on this in the next blog post. This way your early adopters are not scared off from starting on this journey with you, and also feel more comfortable in contributing.
Clues to find mystery IT owners
When starting out, don’t worry if the number of volunteer vulnerability owners isn’t enough. This is to be expected. After all, you are creating accountability for a team that is already understaffed and overworked. The good news is there are ways to find more vulnerability owners using tools you likely already have access to.
Follow the data
System logs are the standard way to identify who did what on IT systems. This correlation of who and what system will enable a fact-based conversation with infosec and potential IT vulnerability owners–e.g., “The logs showed that you patched 10.10.10.10, are you the system owner?”. There are several sources of logs that infosec can investigate:
- Patch management tools (e.g., SCCM) to identify which IT personnel applied security patches in the past.
- System logs (e.g., auditd on Linux) to identify who ran commands relevant to patching (e.g., yum or apt-get).
- System owners identified in CMDBs (e.g., ServiceNow).
- Ticketing systems (e.g., Jira) to correlate owners to applications or systems. If ITIL is used in your organization, this is a good bet.
Sweeten the offer
HBR states that recognizing employees is the simplest way to improve morale. Celebrating early adopters publicly within the organization brings two major benefits:
- Showcase infosec’s commitment to a positive partnership with IT.
- Create IT rockstars that will inspire fellow teammates.
I personally can attest to the success of this methodology. I used an internal blog to interview early adopters and celebrated their success to the whole company.
Find security-minded IT teammates
If you are unsure of who would be interested in kick starting this partnership, look for IT teammates that already have security interests. The following are great starting places:
- DevOps team–technically own security but often outsource specialized tasks to infosec.
- Search your company’s employees on LinkedIn for infosec keywords.
- Search Github for infosec related open-source contributions by your colleagues.
I have early adopters! What’s next?
How exciting! Finding the right people to start this partnership is the hardest part, in my experience. The next steps in formalizing vulnerability ownership are all about process and execution. Since this can be fairly new to both the infosec and IT, it’s important to phase process in.
So, how do we do it? More on that in the next part of this series.
- Invite and incentivize vulnerability owners to find you.
- Find vulnerability owners by using technology like system logs, or CMDBs.
- Find early adopters that already show an interest in infosec through tools like LinkedIn, or Github.