Communicating with Teams the Way they Want to be Communicated With
…it can be tough to do. The problem with vulnerability management is so many people need to look at the data in order to act on it, but all of them look at it very differently. Security Analysts think in terms of CVEs. Remediation teams think in terms of patches. CISOs think in terms of risk. And perhaps the biggest problem in vulnerability management programs is the presentation of that data. The teams that need to work together end up talking past each other, and as a result, nothing gets done.
To compound the issue, security teams often have different tools than the teams they communicate with — so not only do they want other teams to look at strange data, they want to force others to log into security tools they aren’t used to working with in order to see the data. This interrupts their workflow. Nucleus takes the approach of putting the data where the users live, so they are able to find it quickly and act on it. Rather than hoard all of the valuable correlated and enriched data, Nucleus shares the wealth.
Nucleus is the only tool I have found in my professional career that works past this problem. I liked it so much I didn’t buy the tool, I applied for a job.
It’s Not Right or Wrong, Just Different
We learn early in life to treat other people the way we want to be treated – and then we spend the rest of our lives warning the exceptions to that rule, to which there are many. Every child has picked out a gift for another child that was much more appropriate for them than it was for the intended recipient. But they were following the rule. They would like that gift, so why wouldn’t the recipient?
The challenges in professional relationships are similar. I can recognize the difference because I used to be a System Administrator. I patched 800,000 vulnerabilities. I’ve also been a Security Analyst. I coached System Admins through patching millions of vulnerabilities when others had failed.
When I have given data intended for a System Admin to a CISO (or vice versa), they generally haven’t understood it and on occasion have even gotten angry. Creating a monthly deliverable that caters to both audiences, plus Security Analysts, presents another challenge – because anyone reading it is going to be confused by 2/3 of it.
You need to give people the data they need to do their jobs in a way they understand it. So, let’s talk about some audiences.
The Security Analyst
Security Analysts run scans against corporate assets using a variety of tools – some of which is pretty straightforward data. Some of it is less so. Pulling that data together and making something consumable from it can take weeks, and most of us don’t have weeks to dedicate to that task.
Security Analysts tend to think in terms of vulnerabilities and controls. Many of them have names, and many of them have industry standard tracking numbers. Nucleus makes it easy to pull all that scan data together and track progress to quantify what work has been done and what work remains. It also adds context, making it easier to prioritize the work. Probably the most common complaint I’ve heard from Security Analysts while working in vendor-land is that they don’t know where to start. Give Nucleus some data and it will tell you exactly where to start – and the more data you throw at it, the better its advice will be.
The System Administrator
System Administrators think in terms of software versions and hotfixes. When a vendor releases an update, they usually document what vulnerabilities it fixes… somewhere. But that information isn’t necessarily easy to find, especially once that update is more than a month or two old and isn’t something everyone is talking about anymore.
You can hand scan results to a System Admin and they can analyze it to figure out what patches to download and deploy them. It’s absolutely work that they are capable of doing – but the problem is most of them don’t have time to do it, and they may or may not enjoy that kind of analysis. We tend to put off the work we don’t enjoy doing. As understaffed as most security departments are, System Admins tend to be even more overworked as well – so when we want them to do something, the less they have to hunt around, the more likely they are to do the work.
Nucleus helps by rolling each of those vulnerabilities for configuration items up into a fix, telling how many systems that fix applies to, and opening a single ticket for that item. We don’t flood an inbox or a ticketing queue. More importantly, since the fix data that comes from the scanner vendors can vary, we allow you to edit the fix however you want.
For example, you can add company-specific information to it, including any pitfalls or anything else someone might need to know. That way, when the issue comes up again (which it probably will), all of the lessons learned from the last go-round are available in the new ticket.
We also reduce the paper pushing – when a fix is completely deployed, Nucleus closes the ticket automatically.
The Developer or Product Owner
Developers and Product Owners think in terms of bugs. Closing vulnerabilities for a developer tends to be more work than it is for a System Administrator, because they need to fix the bug in their code before they can deploy it. They can also have the shared challenge of not knowing where to start, but the need for prioritization can be even more acute because of the time required to develop the fix before deploying it. While the Nucleus Risk Score probably won’t look like anything they are used to seeing, they will understand the concept, and can certainly understand the nuance of low, medium, high, and critical.
If a critical vulnerability takes the same amount of time and effort to fix as a low vulnerability, there is a much greater return on effort from fixing the critical.
Rolling up each instance is helpful, because they will need to deploy their fix to every system in production – and missing one will lead to bad things. The roll ups that Nucleus does can help tremendously with determining level of effort, but keep in mind internal development teams will generally not be able to fix vulnerabilities as quickly as System Admins can, so use that when setting your own expectations.
The other difference between a development team and other teams is the tool set. While your other teams may use ServiceNow, your developers are likely to prefer Jira. Nucleus was designed to accommodate such scenarios, so you don’t have to make one team use alien tools designed for a different team.
CISOs think in terms of risk. They like to have a score. The industry has generally settled on a score of zero to 1000, kind of like a credit score. Not everyone does a good job of explaining what the numbers mean, and we think that’s pretty important. The Nucleus Risk Score tells you what your typical vulnerability in a given population looks like – and then you can compare scores across populations, or your entire enterprise, and see which populations are making things better and which ones are making things worse. They may or may not want a few other KPIs, but generally speaking, these guys and gals are all about the stats.
It’s very high level, and not very actionable, but this audience usually doesn’t want the details. We have them if they do, but in my experience, it’s more likely that they want the Risk Score and a chart that shows a trend. As long as the other teams know what they need to do to make the trend go in the right direction, they’re happy.
Granted, these are generalities. Sometimes a System Administrator or a Security Analyst will enjoy looking at the statistics and try to turn it into a game. And I know one CISO who loved digging into actionable data – looking at that stuff seemed like the best part of his day sometimes.
That’s why we don’t hide any data from anyone. You can look at the data anywhere in the Nucleus UI and see the various views. But we certainly have customized views recommended for certain roles. As our founders frequently point out, Nucleus is the result of 15 years of pain. Hopefully by learning from our pain, we can reduce yours.