Vulnerability Management: An essential tactic for zero trust from the Rick the Toolman Series.

Rick Howard: I know that the phrase zero trust causes a sour taste in the mouth of most network defenders these days. The main cause, I think, is that the bulk of security vendors have incorporated the buzzword phrase into their marketing material by now.

(SOUNDBITE OF MUSIC) 

Rick Howard: (Imitating radio announcer) The Galactic Zelarayan paper clip. It slices. It dices. It collects all those naughty runaway zeroes scampering around your house into trusted piles of paper and all for the minimum price of just $19.95. The Galactic... 

Rick Howard: If I saw that ad on late night TV, I'd buy it in a heartbeat. I don't know what it does, but clearly, I need to get all of my zeroes into paper piles right now. But I would say that the capabilities these zero trust products offer generally land in the bucket of restricting access to resources based on need-to-know, and that's a good thing. But I want to elevate this conversation a bit and consider zero trust as a first-principle strategy, not as a feature to a security product. Specifically, I want to talk about how we can indirectly all use vulnerability management as a tactical tool to improve our zero-trust posture, and that sounds to me like a perfect Rick the Tool Man episode. 

(SOUNDBITE OF MUSIC) 

Rick Howard: My name is Rick Howard, and I'm broadcasting from the CyberWire's secret sanctum sanctorum studios located underwater somewhere along the Patapsco River near Baltimore Harbor. And you're listening to "CSO Perspectives," my podcast about the ideas, strategies and technologies that senior security executives wrestle with on a daily basis. 

Rick Howard: The network defender eventual dissatisfaction with an initial good idea seems to be the way for all potential trends in the tech security space. It starts by somebody having a good idea, like John Kindervag back in 2010 with his original zero-trust white paper, "No More Chewy Centers: Introducing the Zero Trust Model on Information Security." And if you haven't read this by now... 

(SOUNDBITE OF ARCHIVED RECORDING) 

Tim Allen: Oh, no. 

(LAUGHTER) 

Rick Howard: ...Shame on you. You should definitely read the original source of what all this zero trust kerfluffle is all about. Slowly but surely, though, everybody in the space starts to get excited about how it will solve all the world's problems, to include world peace. 

(SOUNDBITE OF FILM, "MISS CONGENIALITY") 

Sandra Bullock: (As Gracie Hart) I really do want world peace. 

Rick Howard: At some point, though, the crowd turns on the idea because it dawns on them that a practical solution to deploy this fantastic idea is exceptionally hard to do. And the commercial offerings that claim they've solved it fall a bit short. These changes to expectations are captured beautifully by the famous Gartner hype cycle. According to the Challenger coder website, Gartner's Jackie Fenn created the concept in 1995. She noticed a repeated pattern of expectation attitudes from consumers of tech and security goods and services as new and innovative products emerged in the marketplace. The expectation starts with a product announcement and then rises through the... 

Rick Howard: (Imitating radio announcer) ...Peak of inflated expectations... 

Rick Howard: ...As consumers realize the potential of the new idea. From there, expectations begin to diminish through the... 

Rick Howard: (Imitating radio announcer) ...Trough of disillusionment... 

Rick Howard: ...As these same people begin to realize that the new tech is not quite ready for prime time. From there, expectation rises again through the much gentler... 

Rick Howard: (Imitating radio announcer) ...Slope of enlightenment... 

Rick Howard: ...And finally, once the product has matured, reaches the... 

Rick Howard: (Imitating radio announcer) ...Plateau of productivity. 

Rick Howard: Fenn published a book on the concept in 2008. Note, don't you just love that phrase - trough of disillusionment? That captures exactly the right sentiment, end quote. Even though network defenders have put the idea of zero trust squarely in the trough of disillusionment today, Gartner analysts see a change. According to the September 2021 hype cycle, products that promise zero-trust features have just moved out of the trough and have begun their slow climb up the slope of enlightenment. But as the zero-trust strategy, we want to reduce the attack servers of everything in our digital space by limiting access to workloads - services and data - for people, devices and applications on all of our data islands - mobile devices, data centers, SaaS applications and cloud deployments. 

Rick Howard: This is 180 degrees opposite of what we used to do from the 1990s until just recently. Back then, we created an electronic perimeter around all of our digital assets. Once you got into the perimeter, though, you had access to everything. Today, the perimeter has disappeared in the traditional sense, and zero-trust solutions give us the ability to reduce access permissions wherever the data or servers may reside. Tactically, we directly pursue this zero-trust strategy with robust identity and authorization tools and maybe couple them with an easy-to-use software-defined perimeter product. These are the things that Gartner's talking about on their hype chart. But indirectly, one of the ways we reduce the attack servers and reduce access to workloads is by closing the doors and windows to our digital house that we have inadvertently left open. These metaphorical portals manifest in the real world as software vulnerabilities and misconfigurations in commercial and open-source software, as well as the code that we develop in-house. The indirect tactic that we use to pursue this strategy is a collection of people, process and technology lumped under the banner of vulnerability management. 

Rick Howard: In the early days, circa 1990s, vulnerability management was more about understanding the bugs and exploits discovered and eventually getting around to patching the issue. Exploits didn't happen that often, and we didn't have armies of nation-states, criminals and hacktivists attacking us around the clock like we do today. We would patch the issue when it was convenient. Back then, most of us were running some version of Windows on the desktop and some flavor of Unix on the servers. When issues popped up, we were more concerned with how to decide about the prioritization of all the things. Do I install the new printer in the lab today, or do I roll out the newest version of the VI text editor to fix that new vulnerability? We didn't even have a common language around vulnerabilities and exploits to compare notes with peers and pundits. According to Tripwire, back then, every software vendor had their proprietary method of tracking vulnerabilities in their own products. Security professionals had no way to know if vendor A's vulnerability was the same as vendor B's or if they were two separate issues. We were kind of on our own. That would be phase one of vulnerability management - confusion. That started to change in 1999, when MITRE's David Mann and Steven Christey wrote the white paper "Towards a Common Enumeration of Vulnerabilities." But hold on to your butts... 

(SOUNDBITE OF FILM, "JURASSIC PARK") 

Samuel L Jackson: (As Arnold) Hold on to your butts. 

Rick Howard: There are more acronyms involved in this story than you can shake a stick at - NIST, CVE, CISA, NVD, CVSS, SCAP and E-I-E-I-O. OK, OK. I made that last one up, but it feels like, after reading that list of acronyms, you should sing the E-I-E-I-O part in the classic "Old MacDonald Had a Farm" song just to finish it off. And that, ladies and gentlemen, is how my weird brain thinks. Mann and Christey proposed creating a common vulnerabilities and exposures list, CVE for short, that the entire community could use, and the idea quickly gained traction. The very first CVE list they published contained 321 vulnerabilities, chosen after careful deliberation and consideration of duplicates. By 2002, the CVE list contained over 2,000 software vulnerabilities, and the National Institute of Standards and Technology, NIST, recommended that the U.S. government only use software that used CVE identifiers. By 2005, the Cybersecurity and Infrastructure Agency, CISA, built the National Vulnerability Database, NVD, designed to enrich the CVE list with risk and impact scoring using the Common Vulnerability Scoring System, or CVSS, and provided other references like patch information, affected products and security content automation protocol mappings, SCAP for short. A SCAP scanner compares a target computer or application's configuration and/or patch level against that of the SCAP content baseline. Both CISA and NIST sponsor the NVD. 

Rick Howard: I know all of this sounds complicated, but this was just phase two, the relatively easy phase compared to phase three. It was easier because, for the most part, not many of us were using their personal laptops and mobile devices for official work, and cloud deployments hadn't transformed the industry yet. Vulnerability management was still relatively contained to devices residing behind the perimeter. That started to change sometime around 2014. Now, that's not a precise date. Some organizations were doing it sooner, and others did later. Governments did it much later, and some are still not there. But the complexity of vulnerability management in phase three is exponential compared to phase two. For example, NIST last year, 2021, tabulated a record fifth straight year of newly discovered vulnerabilities - 18,378. 

(SOUNDBITE OF ARCHIVED RECORDING) 

Tim Allen: Oh, no. 

(LAUGHTER) 

Rick Howard: And when you consider that these vulnerabilities are scattered across multiple data islands, it's no wonder that a young Cecil looks like he's 107 years old. It ages you. As the complexity skyrocketed, as with most things in the security space, network defenders reached a point where they couldn't manage organizational software vulnerabilities with a spreadsheet anymore. We needed a more strategic view. 

Rick Howard: According to the Cybersecurity Canon Hall of Fame candidate book "Practical Vulnerability Management" by Andrew Magnusson, vulnerability management is not simply patch management. Managing patches within an organization is a subset, a key and essential piece, but not the entire thing. There is another set of activities that must happen before we can even think about applying patches. No. 1 - continuously monitor all of the software assets running on the network in terms of version control, nested libraries for open-source packages, current configuration - meaning who and what can access the asset and what can the asset access itself - the history of who and what have accessed the asset in the past, and any exposure to newly discovered vulnerabilities and exploits. No. 2 - using the zero-trust strategy as a guide, regularly check and recheck that all of the software assets only have access to what they absolutely need to get the job done. And finally, No. 3 - prioritize the most material software assets, meaning the software that would cripple the business if it stopped functioning for even a second or if customer data is exposed because of it. And then when new vulnerabilities and exploits pop up, you go into this risk-forecasting checklist. No. 1 - determine if the organization was exposed. No. 2 - forecast the probability that some bad guy will leverage it. No. 3 - forecast the probability that, if it's leveraged, that it will be material to the business. No. 4 - determine if there is a reliable patch or other workaround that will mitigate it. No. 5 - decide which actions to take to mitigate the risk - and this could be many things or nothing, depending on the risk forecast. And finally, No. 6 - once all of that is done, then you have to implement whatever you decided to do - the risk mitigation plan. 

Rick Howard: Every single item I mention here is a critical information requirement to aid in that decision for a newly discovered vulnerability or exploit. Over time, that collection of intelligence will enable you to achieve some success in a vulnerability management program. And I refer to intelligence collection on purpose - this is a perfect task for your intelligence team to own, regardless of whether you have a robust team or just two guys and a dog in the broom closet who only do this part time - or, you know, everything in between. The task lends itself to the intelligence lifecycle. You start with creating critical intelligence requirements, or CIRs. For you military types out there, they're called commander's intelligence requirements. That's just a fancy name that really just means big-picture intelligence questions that the boss wants front and center all the time. For vulnerability management, they're all the items we just went through. 

Rick Howard: Once you get that done, the next step is data collection - in other words, decide if the data you have on hand will answer all the CIRs. If not, go get the data you need. The next step in the cycle is intelligence production. Convert the collected raw data into something useful. Next in the cycle is building intelligence products designed to convey the essence of the transformed intelligence, complete with recommended courses of action. And then disseminate the intelligence products to the decision-maker and all interested parties and get their feedback. Finally, go to the top and do it all over again - or as I like to call it, the intelligence do loop. 

Rick Howard: A short while ago, I got a question from one of our "CSO Perspectives" listeners, Raffi Jamgotchian - and Raffi, I apologize if I screwed up that pronunciation of your name. He was wondering about small- and medium-sized businesses - SMBs - trying to follow the first-principle strategy of DevSecOps when they barely had the resources to keep the printers working and the coffee brewing. Raffi asked this question - my paraphrase - if there is no dev to speak of, how do you do DevSecOps? That's a great question. I hate to admit this, but for startups and very small businesses, this might be a bridge too far. 

(SOUNDBITE OF TV SHOW, "(SOUNDBITE OF ARCHIVED RECORDING)") 

Tim Allen: Oh, no. 

(LAUGHTER) 

Rick Howard: But as you grow and start to edge towards the medium-sized business with a few more resources, automating big chunks of the vulnerability management program will save you in the long run. The automation requirements are, for the most part, stated in the CIRs I just went through. Keep in mind, though, that DevSecOps is infrastructure as code, not utility scripts written by our brand-new tier 1 SOC analyst, Kevin. I'm not saying Kevin can't write the code. I'm just saying that whatever Kevin writes needs to fit into the mindset as being part of the security understructure and not running as a cron job on an experimental Raspberry Pi computer sitting under Kevin's desk in the SOC. The code needs to be as stable as the power coming into the data center - flexible enough to accommodate change and improvement and resilient enough to survive when Kevin gets promoted to that cushy management job over at headquarters. Thanks, Kevin. This is a commitment to the DevSecOps philosophy. 

(SOUNDBITE OF ARCHIVED RECORDING) 

Tim Allen: Oh, yeah (laughter). 

(LAUGHTER) 

Rick Howard: And to answer Raffi's question, this is a DevSecOps project that the security team and specifically the intel team can own and manage. 

Rick Howard: I often talk about risk forecasting in these shows. I've said over and over again that calculating probabilities is much bigger than many security professionals think it is. In our mandatory Stats 101 course that most of us took in college, we learned to count colored marbles falling out of urns and use crazy hard math to predict what the next color would be with some accuracy. Well, the math was crazy hard for me. 

(SOUNDBITE OF ARCHIVED RECORDING) 

Tim Allen: Oh, no. 

(LAUGHTER) 

Rick Howard: Calculating these kinds of problems with known quantities - the number of colored marbles hiding in urns - is definitely part of probability understanding, but it's just a small part. And network defenders have been befuddled with trying to forecast cyber events with this small subset view because there are way too many variables to contend with within the cybersecurity space - too many different-colored marbles falling out of our cybersecurity urn, and we're not even sure how many marbles are in the urn. 

Rick Howard: But there is a bigger and more useful way to think about this. According to Dr. Ron Howard - no relation to me, by the way, and not related to the actor/director - who created decision analysis theory back in the 1960s, he said, quote, "a probability reflects a person's knowledge or, equivalently, ignorance about some uncertain distinction. Therefore, probability is nothing more than our degree of belief that a certain event or statement is true," end quote. Dr. Howard says that probability doesn't come from data. Quote, "it represents a person's state of information about an uncertainty," end quote. Framing probability that way expands our view of how to think about forecasting risk in our own cybersecurity problem domain and specifically how to apply new evidence to the forecast in terms of vulnerability management. The CIRs I listed here specifically ask questions about what we know and what we don't know about the impact of a newly discovered vulnerability or exploit. From an infosec program viewpoint, the atomic first principle we are all trying to answer is what is the probability of material impact due to a cyber event in the next three years? We do that by asking questions about our uncertainties regarding our environment and collecting new evidence as it manifests. 

Rick Howard: If, in November 2021, we forecasted a 20% chance that the organization will be materially impacted in the next three years and then in December, the Log4j vulnerability popped up, how does that change our forecast? What did we know and what didn't we know at that moment? The CIRs I've talked about are the right questions to ask. Were we exposed? Well, with the ubiquity of the software module, chances are that we were. What was the probability that some bad guy would leverage it on our systems? Well, since exploiting the code was and remains almost trivial, the chances were high that some bad guy would at least try. By leveraging the Log4j vulnerability, could the bad guy get access to or cause damage to anything that's material to the business? Well, we didn't know for sure. It would take us a few days to determine that. There's that uncertainty again. 

Rick Howard: But let's assume that at least some material data was exposed. In that case, how does it affect our risk forecast? In the early days of the Log4j vulnerability crisis, we hadn't yet developed any mitigation strategies other than finding all instances of Log4j running and patching it, and most of us didn't know where it was running. Just with a back-of-the-envelope calculation, all of that evidence had to at least raise our risk forecast to above 90% that we would get hit by a material event not in three years but in the next 90 days. The only thing we had going for us was that all of our peers were in the same boat. Unless the bad guys were specifically targeting us, it might be a while before they find us. Then again, we might be first in the barrel. 

Unidentified Person: Boo-la-la. 

Rick Howard: I hate uncertainty. But as Dr. Howard might say, that's the way of the world in most organizations and specifically in the cybersecurity field. If this gives you the heebie-jeebies, maybe cybersecurity isn't the field you should be working in. You might be better suited to sorting apples coming off an assembly line. There's more certainty there. 

Rick Howard: Contrast Log4j with CVE-2021-46608 that NIST published in February of 2022. The CVSS score for the Bentley MicroStation software categorizes the vulnerability as low. Even if we had the Bentley software in our environment, which most of us don't, how would that change our risk forecast that we made in November last year? Going through the same CIR logic that we did for Log4j, we are most likely not exposed. The odds that some bad guy will leverage it, even if we were, are low. And if we were running it, the chances that the Bentley software is connected to something material in our business is extremely low. This vulnerability doesn't impact our risk forecast in the least. We should shove the mitigation plans so far down the priority queue that it's likely that we will never get around to fixing it because we don't have to. The odds are so low that it will impact us that this vulnerability is not an issue at all. 

Rick Howard: In order to reduce the probability of material impact, zero trust is a key strategy to pursue, along with intrusion kill chain prevention, resilience and risk forecasting. Tactically, there are many direct ways that will improve the zero trust posture, and they mostly deal with identity and authorization. Indirectly, the tactic that most have not associated with zero trust is vulnerability management, but that's where it sits in my mind. Vulnerability management isn't some independent set of activity that exists by itself in a vacuum that all network defenders need to do because of - why? Don't get me wrong - it's important. But where does it fit in our first principle thinking? I don't consider it as a first principle strategy. It's not atomic enough. That said, it's an important first principle tactic that we can use to improve our zero trust posture. Vulnerability management helps us close those doors and windows to our digital house that we may have inadvertently left open. And that's a good thing. 

Rick Howard: And that's a wrap. As always, if you agree or disagree with anything I've said, hit me up on LinkedIn or Twitter, and we can continue the conversation there. Or if you prefer email, drop a line to csop@thecyberwire.com. That C-S-O-P, the at sign, the CyberWire - all one word - dot.com And if you have any questions you would like us to answer here at "CSO Perspectives," send a note to the same email address, and we will try to address them in the show. 

Rick Howard: The CyberWire "CSO Perspectives" is edited by John Petrik and executive produced by Peter Kilpe. Our theme song is by Blue Dot Sessions, remixed by the insanely talented Elliott Peltzman who also does the show's mixing, sound design and original score. And I am Rick Howard. Thanks for listening.