Time is Money, Part 3: Vulnerability Assignment

This is part three in a six-part series. You can find the previous posts below.

Time is Money, Part 1: Vulnerability Management Maturity Levels

Time is Money, Part 2: Vulnerability Analysis

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.

Avoiding Finger Pointing and Vulnerability ‘Hot Potato’

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):

  1. Maintain a searchable list of assets, accurate within one week.
  2. Maintain a searchable list of software installed and/or running on all assets, accurate within one week.
  3. Acknowledge receipt and understanding of critical vulnerabilities within 24 hours of assignment.
  4. Optionally, reprioritize assigned vulnerabilities based on asset importance.
  5. Remediate all vulnerabilities within required timeframes, unless given specific expectations.
    • Fix all critical vulnerabilities within 48 hours
    • Fix all high vulnerabilities within 7 days
    • Fix all medium vulnerabilities within 30 days
    • Fix low vulnerabilities at your discretion

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.

Email is a Terrible API

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.

Asset Groups

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.

Role-Based Access Control

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.

Automated Ticket Creation and Assignment

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.

See Less of Us, More of Your Family and Friends

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.