In the IT security space, we have to worry about everything. Any problem, no matter how small, can become the vehicle for remote code execution or, at the very least, a landing point for threat actors who want to live off the land and turn our tools against us. It’s no surprise that IT security staff face burnout and stress. Second research conducted by the Enterprise Strategy Group and ISSA, about half of IT security professionals think they will leave their current job in the next 12 months.
Security teams are professionally accountable and now, for Chief Information Security Officers (CISOs), personally responsible – for the security of their organizations. Yet in other IT and technology sectors there is a completely different mentality. From Mark Zuckerberg’s mantra “move fast and break things‘Until Eric Ries’ Lean startup and the Minimum Viable Product (MVP) model, the idea in these areas is to move quickly but also provide just enough for the organization to move forward and improve.
Now, IT security teams cannot embrace this model. There are too many regulations to consider. But what can we learn from a thought exercise about minimum viable compliance (MVC), and how can we use that information to help us in our approach?
What would MVC entail?
MVC involves covering what is needed to actually be secure. To achieve this, you need to understand what you have in place and what is critical to keep safe, and what rules or regulations you need to demonstrate compliance with.
For resource management, ideally you should know all the resources you have installed. Without this level of oversight, how can you call yourself safe? For an MVC approach, would you need 100% in-depth insight into what you have?
In fact, resource management projects like configuration management databases (CMDBs) aim to provide full visibility of IT resources, but they are never 100% accurate. In the past, asset accuracy hovered around 70-80%, and even today’s best implementations are unable to achieve full visibility and keep it that way. So, should we spend our MVC budget in this area? Yes, but not quite in the way we might traditionally think.
One deputy CISO told me he understands the ideal of full coverage, but that it’s not possible; instead it is concerned with complete and continuous visibility of the organization’s critical infrastructure (about 2.5% of total resources), while other workloads are monitored as frequently as possible. Therefore, while visibility is still a necessary element of IT security programs, the effort should be directed first at protecting the highest risk assets. However, this is a short-term goal, as only one vulnerability disclosure is needed to transform a low-risk asset into a high-risk one. During this process, don’t confuse compliance with security – they are not the same thing. A compliant company may not be safe.
Regulatory planning
As part of MVC, we need to think about regulations and how to comply with them. The challenge for security teams is how to think ahead around these rules. The typical approach is to introduce legislation, then see where it applies to our applications, and then make changes to the systems as needed. However, this can be a very stop-start approach involving changes – and therefore expense – every time a new regulation is introduced or a significant change occurs.
How can we make this process easier for our teams? Instead of looking at each regulation separately, can we consider what is common to the applicable regulations and then use that to reduce the amount of work required to comply with them all? Instead of putting the team through massive exercises to bring systems into compliance, what can we instead take out of scope or use as a service to deliver infrastructure securely? Likewise, can we use common best practices like cloud audits to remove entire sets of issues, rather than looking at each issue individually?
At the heart of this approach, we need to reduce security overhead and focus on what poses the greatest risks to our operations. Instead of thinking about specific technologies, we can look at these issues as process and people issues, because regulations will always evolve and change as the market evolves. Adopting this mindset simplifies security planning because it doesn’t get bogged down in some of the details that can plague our teams when processes are built to review CVEs and threat data rather than in practical risk terms about what really is an issue.
The idea of doing the minimum required to meet market demands or pass a set of rules might be appealing at first glance. But the MVP mentality isn’t just about reaching a specific level and then settling there. Instead, it is about reaching the minimum standard and then acting as quickly as possible to improve the situation further. For security teams, this mindset of continuously improving and finding ways to reduce risk can be a useful alternative to the traditional IT security model. By focusing on which improvements would have the greatest impact on risk in the shortest time possible, you can increase your effectiveness and reduce risk overall.