Ultimately, the goal is to avoid a breach and keep our company off the news headlines. That’s a given for every CISO. But we also have business availability goals that are typically defined by service-level agreements (SLAs).
"A tool by itself doesn’t do anything. It’s the intelligence that you personally put behind it in being able to use it very thoughtfully"
Most companies, unless they are just starting out, are dealing with some sort of legacy application or software that the business cannot thrive without. And maybe that application is driving some significant portion of the company’s revenue. That ties the hands of the CISO very quickly because, even though we might know that there’s a patch that we want to apply to the system, if applying the patch means the system then can’t operate as intended, we could end up costing the company a set amount of revenue. Yes, the patch might mean that bad guys can’t get in, but if data doesn’t flow, then we can’t get money into the company. As a result, most times companies are carrying some risk along those lines. The fact is, you can’t always patch everything as you would like. That’s why vulnerability management really has to look at things in a business context, not just a technical context.
I believe that every CISO has this issue, and it’s hard. You will never have 100 percent coverage of the recommended patches at any point in time while also being able to meet your service level agreements. There’s a little bit of give and take in that area.
Key Factors to Consider
The way I see it, there are two sides to the coin of what to consider in a vulnerability management solution. The first side of the coin is actually from your service management, or perhaps you call it infrastructure management, inside the company. I think of this group as the strict IT side of the house, which doesn’t include security. They are focused on availability and how quickly they can patch something, how quickly they can get up, how less intrusive they can be to the user using the piece of equipment, be it a server, laptop, desktop or tablet.
What to consider in a solution is a different question for them from what a security team would consider. When they evaluate vulnerability management software, they must make sure that they can see the entire enterprise and all the systems that are under their control, as well as what needs to be applied as a patch, and then how quickly they can get it patched. That’s usually what they see from that side of the house.
As the head of information security, my side of the house is all about confidentiality, integrity and risk to the organization, and mitigation of that risk. The tools I use will take the results of scans into a unified security management system that allows me to look at the risk. What I do—and this might be rather unique—is look at every one of my systems, be it a user system like a workstation, laptop, desktop, et cetera, or a server, and I look to see every single piece of data that’s running through that system. Then I will categorize it. Is it a production system? Is it a development system? Is it a test system? Is it a print server system? And then, what applications are running in it? Is that my application group A, B, C, D, E, etc? Then I can monitor the risk for that system.
The reason that’s important from my side of the house is that I really think that security and CISOs should help drive what systems are patched by the infrastructure or service or networking team or whoever you have in your organization doing that—and do it in an order that reduces the risk overall to the company. A lot of people don’t take it that extra step, but it’s what I personally do.
I need to be able to determine what systems need to be patched and in what order, and then go ahead and let the IT side of the house know that so then they can patch that. That will also help me with my remediation plans and a corrective action plan that I might need.
I believe that looking at vulnerability management from these two sides is something new. I’ve been speaking to other people about it and the approach is new to them, too. They haven’t really thought of that. They’ve allowed IT to drive what patching software they’re going to use. So, can I see the machine, and can I push a patch, versus me looking at which systems are involved and thinking about the overall risk to the organization of that patch. That is a new way of thinking for most people in the industry
Impact on Staffing
Many people might assume that this level of risk assessment and prioritization of vulnerabilities and systems would increase my staffing levels. However, with the machine learning and the intelligence that we’re able to get with our vulnerability management tool, it can reduce the number of staff needed for patching on the strict IT side of the house, and also on the security risk side of the house. The reason is that we’re more able to quickly look and see what the risk is of applying the patch to which systems.
A lot of the newer systems now will go out and call into the threat intelligence for you. So right there, for example, I can see the patch, I can see what the CVE says the risk of the patch is, but I can see what it would be on my system. Then also, I can immediately go ahead from there and see, this is what we need to do: fix it, and if we can’t fix it directly by the patch, here’s the mitigations we can put in place. We can manually go ahead and then even upload all that intelligence right into a help desk ticketing system.
This saves a lot of time. Where analysts would have to go out and grab all that by hand, we now have it as a click of a button. This allows us to have “skinny” teams because the system we use has a lot of automation. It helps us document what we are implementing, what we aren’t implementing, why we aren’t implementing, and what the risk is to the organization. It gives us that information quicker, in one spot, so we can make those determinations, and write up a great risk strategy for the company. As a result, we really do need fewer people for this effort, and it gives us cost savings even after we buy the tools.
Selling to the Board of Directors
The patch management, pushing patches, intelligence software on the IT side of the house—that’s an expense. Some people might be able to do it on that side of the house initially as a capital expense and then do it as a yearly service, similar to how they do their Data Loss/Leakage Protection (DLP) solution. For the risk management side of the house, that was a straight expense and then an ongoing annual service fee. Purchasing this solution was really easy on both sides of house, and we didn’t have to go to the executive board. We just put it in as part of our regular budget.
I think we have to get away from buying shelfware. A tool by itself doesn’t do anything. It’s the intelligence that you personally put behind it in being able to use it very thoughtfully. You need to buy what you’re going to use and what you can manage, and buy what you can intelligently put into the organization. We, as IT and security, need to be good fiduciaries with our budget to show the executives that we’re being thoughtful that way.
Recommendations and Advice
I think you have to consider who the people are that are going to work with the vulnerability management system. What I mean by that is, you need to see how long they’ve been in the industry. In my experience, I have observed that people who’ve been in the industry for a very long period of time generally has a certain way of seeing things, a certain way that they can implement very quickly. I guess you can call this being set in their ways. Generally, I find the people who have been in the industry for fewer years tend to be more up for different technologies. They’re more up on the newer ways to visualize things, or they’re more quickly able to adapt. So, your approach to choosing a product might depend on who will ultimately be using that product, and whether they are able to adapt to the tool. If they don’t adapt, then you won’t get the most out of the tool.
I call it “old school” versus “new school” thinking. One’s not right over the other, but one of the things that people forget when we buy anything in IT is that there’s the business case for it, there’s the IT case for it, but then there’s also the training of your staff to use it—and then any changes and tweaks that have to be done in it, which leads to a lot bigger of a cost. What we want is the quickest deployment, shorter time frame to deployment, because if we can’t deploy it, can’t use it, if it’s just going to sit around for nine months, that’s nine months that we are carrying that risk. Sometimes you might need to go with a product that costs more, but your adaptation cost will be less, meaning overall your cost will be less. And people really don’t look at the cost from A to Z as well.
On another note, I believe that, as a whole, Gartner does a good job of reviewing products, but I don’t think that that should be your stopping point for selecting a product—I think that should only be your starting point. The reason I say that is because a lot of the times, those reports might come out many, many months after the analysts started to do the review. There are so many new players in the game who are doing quick adaptations. A lot of times they are quicker to adapt to what the market needs are. So, when you read those Gartner reports, sometimes they can be deceiving.
Do not rule out a vendor who has only been in the field for a few years, because a lot of times they will listen to you as a customer, and discover what you want, and actually put that in play. That’s important for today’s world. I think that any vendor who’s been in the field for a very long time—say a decade or longer—really has to be cautious that it isn’t slow to adapt to a world that is moving so quickly. CISOs shouldn’t rule out a vendor just because they’re not on Gartner’s radar yet, because they might be the forward thinkers of the industry. And I think you need to be as forward as you possibly can be in this field.