Time is Money, Part 3: Vulnerability Assignment
- Jan 30, 2019
- Steve Finegan
This is part three in a six-part series. You can find the previous posts below.
In our previous post, we covered proven and effective strategies used by NopSec to prioritize vulnerabilities. Once vulnerabilities are prioritized, they must be fixed! The first step in this process is determining who to assign the vulnerability to. This assignee will most often ‘own’ the system or application that the issue was discovered in.
For example – a critical vulnerability in the Linux Kernel will require an operating system patch to fix. This vulnerability would be assigned to a Linux system administrator. However, if a vulnerability was discovered in a proprietary corporate application that runs on that same Linux server, it wouldn’t do much good to assign this vulnerability to the same sysadmin that would handle the kernel vulnerability. Instead, the issue would likely go to a developer or someone that specifically supports internally-developed web applications.
This raises an important point – it is critical to assign responsibility for all corporate-owned assets and applications. This should be done down to every datacenter cooling system, laptop and wireless access point. Next, clearly communicate security responsibilities to each owner. Here’s an example list of responsibilities (note: you don’t have to use this list, we just want to get you started):
The idea is to set expectations for asset and application owners so that there are no surprises. Ideally, these expectations should come from IT and owner leadership – not directly from the security team. This can help avoid friction, finger pointing and alleviate adversarial interactions between IT and security teams.
So how does NopSec save time when it comes to vulnerability assignment? You may have already noticed mention of some activities that are easy to automate. Most of these tasks are currently managed manually, typically using email. A spreadsheet is exported from the vulnerability management system, attached to an email and sent to the asset owner. Unified VRM has several features that streamline the assignment process.
The ability to create logical groups of assets and applications is essential when a system is designed for use by IT practitioners in addition to the security team. An IT manager might be interested in the progress of a single Windows domain, for example. In another example, Unified VRM could be used to address step 1 in the list of responsibilities above.
Access control is also essential for effective visibility and usability. Role-based access control (RBAC) makes it possible to grant users either full control or read-only access to either all data within a customer’s account, or selected asset groups. This is a huge time-saver for asset/application owners, as they never need to see or sort through vulnerabilities that aren’t theirs.
When owners are assigned to assets and applications, vulnerabilities can be automatically assigned to these owners as soon as vulnerabilities are ingested into Unified VRM, deduplicated and prioritized. Once assigned within our system, tickets can manually or automatically be generated in external systems like Jira and ServiceNow. Duplication and consolidation is critical here – when automating any process that will likely generate email to someone’s inbox, we want to minimize the volume. For example, it makes more sense to generate a single ticket for a critical vulnerability affecting 2000 assets instead of creating a ticket for every asset.
Our customers’ time is valuable. Securing and managing systems is hard enough without products adding additional consoles with additional credentials and additional steps and procedures. These features are designed to reduce how long existing workflows take on top of making our customers more secure through better prioritization.
We think you’ll love and enjoy our new world-class user interface, but our goal is for most employees to see as little of it as possible. I’ll explain.
We understand the amount of effort that goes into making workflows efficient. We want to integrate into it – not disrupt it. Most of the employees that will benefit from our product – the asset owners, patch management staff, developers – won’t ever see or use our product directly. They’ll just notice that their daily security workflows suddenly take significantly less time and include significantly less false positives.
The next in this series, part four, will cover how we can save time when fixing vulnerabilities. As with vulnerability assignment, the next installment will cover how automating manual tasks can save significant time when patching systems.