IN Black hat Europe last year I spoke 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, as well as aligning a safety culture across the organization.
John: So, Paul, in an environment where there are problems everywhere and everything needs to be fixed, we need to move beyond this. In the new architectures we now have, we need to think more intelligently about our overall risks. This is related to cost management and service management – the ability to categorize our architecture in terms of actual risk and impact from a business perspective.
So, I'm kind of talking myself into buying a tool for this because I figure that in order to get past 50 tools, I first need to have a clear understanding of our security posture. We can then decide which of the tools we have actually respond to this pose because we will have a clearer idea of how vulnerable we are.
Floor: Buying a tool brings us back to the hopes and dreams of salespeople: one tool will fix everything. But I think the reality is that it's a mixture of understanding what metrics are important. Understand the information we've collected, understand what's important, and balance it with technology risk and business impact. You already made a great point: if something is at risk but the impact is minimal, we have a limited budget to work with. So where do we spend? You want to get the most bang for your buck.
So that's understanding business risk. We've defined the risk from a technology perspective, but how significant is it to the business? And is this a priority? Once we have prioritized the risks, we can figure out how to eliminate them. There's a lot to unpack in what you're asking. For me, it's about doing the initial work to understand where our security controls are and what our risks are. What really matters to us as an organization? Get back to the metrics that matter—cutting out the noise and identifying the metrics that help us make decisions. Then see if we measure those metrics. We then assess the risks and implement the right controls to mitigate them. We do this postural control work. Do the tools we have respond to this position? This is only the internal side of the matter, but there is also an external risk, this is a completely different conversation, but it is the same process.
So, when we look at the tools we have, how effective are they in mitigating the risks we've identified? There are many risk management systems out there, so you can probably find one that works, like NIST or something else. Find the right framework and use it to evaluate how your tools manage risk. If there is a gap, look for a tool that will fill it.
John: And I was thinking about the concept because it basically says there are six areas to work on and maybe a seventh one might be important for your organization. But at least check these six areas: Am I doing risk response? Am I speaking correctly? This gives you that rather than the Pareto view, but it's about diminishing returns – learn the simplest things first. Don't try to fix everything until you fix the most common problems. This is what people are trying to do right now.
Floor: Yes, I think – let me quote another podcast I do where we do “technical insights.” Yeah, who knew? I thought I'd hook it up. But if you think about the takeaways from this conversation, I think going back to your question: What should I consider as an organization? I think the starting point is probably to take a step back. As a business, as an IT leader within that business, do I take a step back to really understand what risk looks like? What does business risk look like and what needs to be prioritized? We then need to evaluate whether we are able to measure our effectiveness against this risk. We get a lot of metrics and a lot of tools. Are these tools effective in helping us avoid the risks we consider important to our business? By answering these two questions, we can look at our posture. Do the tools we have provide the kind of control we need to combat the threats we face? The context is huge.
John: In this regard, I am reminded that organizations like Facebook, for example, had a fairly high tolerance for business risk, especially with regard to customer data. Growth was everything—just growth at any cost. Therefore, they were willing to manage risks to achieve this goal. Ultimately, it comes down to assessing and accepting those risks. At this point, it is no longer a technical conversation.
Floor: Exactly. It will probably never just be technical talk. Risk and safety projects should never be driven by purely technical aspects. This affects how the company operates and the daily workflow. Unless everyone understands why you're doing it, no security project will be successful. You'll get too much pushback from older people saying, “You're just getting in the way. Stop it.” You can't be the department that just gets in the way. But what you really need is a company culture where safety is important. If we don't prioritize security, all the hard work everyone does can be undone because we haven't done the basics to ensure there are no vulnerabilities waiting to be exploited.
John: I'm just thinking about the number of conversations we have with vendors about how to sell security products. You sold it, but then nothing gets implemented because everyone else is trying to block it – they didn’t like it. The reality is that a company needs to work on something and make sure everything is in order to achieve that goal.
Floor: One thing I've noticed in my 30+ years in this job is that suppliers often have a hard time explaining why they can be valuable to the business. Our COO Howard Holton is a big proponent of this argument: suppliers are terrible at telling people what they actually do and what the business benefits are. But yesterday he told me one thing: about their approach. A rep I know works for a vendor that offers an orchestration and automation tool, but when he starts a meeting, the first thing he does is ask why the automation didn't work for the client. Before he offers his solution, he takes the time to understand what the challenges of automation are. If most of us did this—salespeople and otherwise—if we first asked, “What’s not working for you?” maybe we'll get better at finding what works.
John: So we have two takeaways for end users: focus on risk management and simplify and clarify security metrics. And for suppliers, the key takeaway is to understand the customer's problems before offering a solution. By listening to customer problems and needs, suppliers can offer relevant and effective solutions, rather than simply selling their aspirations. Thanks Paul!
Fast Understanding cybersecurity. Part 2: Providing a Cost-Effective Response first appeared on Gigaom.
