kevinlmclaughlin

When first arriving at an organization that has not invested in a major cybersecurity program and then looking at the sheer number of computer vulnerabilities in the environment a sense of feeling overwhelmed is a common initial response. In many cases the numbers can be upwards of one million vulnerabilities that need to be remediated. My advice is to keep a couple of concepts in mind, kaizen or continuous improvement over time and the old saying that you eat an elephant one bite at a time. As a practitioner who has faced this task many times over the past 30 years, I can tell you that it is not as daunting to complete or to get alignment and buy-in from your Information Technology (IT) colleagues to complete as it first appears.
The National Vulnerability Database (NVD) is part of US government repository of standard-based vulnerability data and is part of the National Institute of Standards and Technology (NIST). This vulnerability database enables automation of vulnerability management, security measurement, and ensures standard compliance. (Wang 2009) NVD contains a list of vulnerabilities, exposures, and an associated risk score for each vulnerability. This risk score is known as a CVE score is an integral part of the NVD and Common Vulnerability Scoring System. Most commonly used vulnerability scanning tools and services make use of this CVE scoring system to assign a risk number or indicator to the vulnerabilities it finds. The higher the CVE score the greater the risk and in general the more urgent it is for you to remediate.
I recall arriving at one company in an operational IT security role and during my first morning one of the cybersecurity team members came by with a cart, in the cart was an extremely large number of papers, about 10,000 pages to be exact. The guy looked at me, said good morning and then started to leave without taking the cart, I asked him why he was leaving the cart and he said “oh, those are all the vulnerabilities you need to tell IT to fix”. I did take a quick look and there were about 30 per page of all criticalities. I took the cart to the loading dock, found a dumpster, and dumped the pages into the dumpster. I then scheduled a meeting with the cybersecurity vulnerability team to talk about a process for handling vulnerabilities that would actually work. The process we aligned on looked something like this, and it is one that has proven effective across multiple companies. As the ultimate goal is to reduce overall risk, we started by agreeing that the risk listed in our current tool as Catastrophic would be the most important ones to fix first as they would reduce the highest level of risk in the shortest amount of time. As a bonus, many of the patches that resolved those types of risk overlapped in resolving some of the lower-level risk as well. At first there were always a staggering number of catastrophic risks to resolve, though not as staggering as a 10,000-page hardcopy PDF manual. We then agreed that the patches which needed deployed would be deployed in the order that hit the greatest number of systems versus those a patch that only impacted one or two; in many cases a patch to resolve a vulnerability is needed across all the Windows servers for example vs only one older version of the Server Operating System. Once the Catastrophic vulnerabilities were eliminated, we agreed that we would move to Critical, then high, then medium and eventually low. As our tool provided an executive summary of the vulnerability and a recommended patching solution along with a breadth of details that were very interesting but not relevant to the IT patching team, we further aligned that the electronic report the vulnerability remediation team received would show: System name, IP Address, MAC Address, OS Level, Vulnerability, and the recommended patch to be deployed along with a status and comment column. Lastly, we aligned the number of patches that IT was willing to deploy during their weekly or monthly maintenance window. Following this approach, in all the cases that I participated in, the number of Catastrophic vulnerabilities across the infrastructure was reduced to near zero within 12 months. Some of you may question if that is good or not or if that took too long but keep in mind that also in every case these same patches had been left, in general, unattended and unpatched for years as the sheer volume of patching that IT was being asked to do was just overwhelming.
Some readers are most likely questioning why IT would not just patch systems regularly and are most likely wondering why systems would be left unpatched and be left in states of vulnerability. Yes, automatic patching should be highly encouraged and should be used across the majority of organizational systems, but the simple truth is that system patching can and does break an IT system, not as much in modern days as in the past but I can recall reading recently where this OS patch, or that Application patch needed to be pulled back because it caused a major system failure. ITs job is to keep their Organization up and running so they are hesitant to complete broad based patching for every issue on a weekly basis. By taking and aligning on a risk-based approach that provides a manageable and workable solution for the IT patching team / support staff we are more likely to get the cooperation needed to drive vulnerabilities downwards and reduce overall risk. IT leaders in the organization are very security conscious and they really do want to be great security stewards, but they also are driven to keep the business systems up and running and therefore making money for the organization. To simply dictate an unreasonable course of action and then throw our hands up in disgust when they don’t engage and do what we ask is not being a trusted and helpful cybersecurity partner to IT or to the business. As Stephen Covey said in his book The Seven Habits of Highly Effective People, if we want to reduce risk (Vildal 2012)we need to work towards the win-win solution (Covey 1989) and then aggressively drive that forward while monitoring and adjusting the results as needed. By driving this one-team, one-goal approach to reducing risk through reduction of cybersecurity vulnerabilities the chances of a successful outcome are maximized. Do this work right and you end up with a metric that looks like the one below, which is a great story to share with your executive leadership team.





Covey (1989). The Seven Habits of Highly Effective People.

Vildal, M. (2012). “A systems thinking approach for project vulnerability managment.” Kybernetes Emerald.

Wang (2009). OVM: An Ontology for Vulnerability Management. Marietta, GA, Southern Polytech State University.