Making Sense of Cybersecurity – Part 2: Delivering a Cost-effective Response

At Black Hat Europe last year, I sat down with one of our senior security analysts, Paul Stringfellow. In this section of our conversation (you can find the first part here), we discuss balancing cost and efficiency, and aligning security culture across the organization.

Jon: So, Paul, in an environment with problems everywhere, and you’ve got to fix everything, we need to move beyond that. In the new architectures we now have, we need to be thinking smarter about our overall risk. This ties into cost management and service management—being able to grade our architecture in terms of actual risk and exposure from a business perspective.

So, I’m kind of talking myself into needing to buy a tool for this because I think that in order to cut through the 50 tools, I first need a clear view of our security posture. Then, we can decide which of the tools we have actually respond to that posture because we’ll have a clearer picture of how exposed we are.

Paul: Buying a tool goes back to vendors’ hopes and dreams—that one tool will fix everything. But I think the reality is that it’s a mix of understanding what metrics are important. Understanding the information we’ve gathered, what’s important, and balancing that with the technology risk and the business impact. You made a great point before: if something’s at risk but the impact is minimal, we have limited budgets to work with. So where do we spend? You want the most “bang for your buck.”

So, it’s understanding the risk to the business. We’ve identified the risk from a technology point of view, but how significant is it to the business? And is it a priority? Once we’ve prioritized the risks, we can figure out how to address them. There’s a lot to unpack in what you’re asking. For me, it’s about doing that initial work to understand where our security controls are and where our risks lie. What really matters to us as an organization? Go back to the important metrics—eliminating the noise and identifying metrics that help us make decisions. Then, look at whether we’re measuring those metrics. From there, we assess the risks and put the right controls in place to mitigate them. We do that posture management work. Are the tools we have in place responding to that posture? This is just the internal side of things, but there’s also external risk, which is a whole other conversation, but it’s the same process.

So, looking at the tools we have, how effective are they in mitigating the risks we’ve identified? There are lots of risk management frameworks, so you can probably find a good fit, like NIST or something else. Find a framework that works for you, and use that to evaluate how your tools are managing risk. If there’s a gap, look for a tool that fills that gap.

Jon: And I was thinking about the framework because it essentially says there are six areas to address, and maybe a seventh could be important to your organization. But at least having the six areas as a checkbox: Am I dealing with risk response? Am I addressing the right things? It gives you that, not Pareto view, but it’s about diminishing returns—cover the easiest stuff first. Don’t try to fix everything until you’ve fixed the most common issues. That’s what people are trying to do right now.

Paul: Yeah, I think—let me quote another podcast I do, where we do “tech takeaways.” Yeah, who knew? I thought I’d plug it. But if you think about the takeaways from this conversation, I think, you know, going back to your question—what should I be considering as an organization? I think the starting point is probably to take a step back. As a business, as an IT leader inside that business, am I taking a step back to really understand what risk looks like? What does risk look like to the business, and what needs to be prioritized? Then, we need to assess whether we’re capable of measuring our efficacy against that risk. We’re getting lots of metrics and lots of tools. Are those tools effective in helping us avoid the risks we deem important for the business? Once we’ve answered those two questions, we can then look at our posture. Are the tools in place giving us the kind of controls we need to deal with the threats we face? Context is huge.

Jon: On that note, I’m reminded of how organizations like Facebook, for example, had a pretty high tolerance for business risk, especially around customer data. Growth was everything—just growth at all costs. So, they were prepared to manage the risks to achieve that. It ultimately boils down to assessing and taking those risks. At that point, it’s no longer a technical conversation.

Paul: Exactly. It probably never is just a technical conversation. To deliver projects that address risk and security, it should never be purely technical-led. It impacts how the company operates and the daily workflow. If everyone doesn’t buy into why you’re doing it, no security project is going to succeed. You’ll get too much pushback from senior people saying, “You’re just getting in the way. Stop it.” You can’t be the department that just gets in the way. But you do need that culture across the company that security is important. If we don’t prioritize security, all the hard work everyone’s doing could be undone because we haven’t done the basics to ensure there aren’t vulnerabilities waiting to be exploited.

Jon: I’m just thinking about the number of conversations I’ve had with vendors on how to sell security products. You’ve sold it, but then nothing gets deployed because everyone else tries to block it—they didn’t like it. The reality is that the company needs to work towards something and make sure everything aligns to deliver it.

Paul: One thing I’ve noticed over my 30-plus years in this job is how vendors often struggle to explain why they might be valuable to a business. Our COO, Howard Holton, is a big advocate of this argument—that vendors are terrible at telling people what they actually do and where the benefit lies for a business. But one thing he said to me yesterday was about their approach. One representative I know works for a vendor offering an orchestration and automation tool, but when he starts a meeting, the first thing he does is ask why automation hasn’t worked for the customer. Before he pitches his solution, he takes the time to understand where their automation problems are. If more of us did that—vendors and others alike—if we first asked, “What’s not working for you?” maybe we’d get better at finding the things that will work.

Jon: So we have two takeaways for end users – to focus on risk management, and to simplify and refine security metrics. And for vendors, the takeaway is to understand the customer’s challenges before pitching a solution. By listening to the customer’s problems and needs, vendors can provide relevant and effective solutions, rather than simply selling their aspirations. Thanks, Paul!