Minimum Viable Compliance: What You Should Care About and Why

In the IT security space, we have to care about everything. Any issue, no matter how small, can become the vehicle for remote code execution or, at the very least, a landing point for threat actors to live off the land and turn our own tools against us. It's not surprising that IT security staff face burnout and stress. According to research by Enterprise Strategy Group and ISSA, around half of IT security professionals think they will leave their current job in the next 12 months.

Security teams are professionally responsible — and now, for chief information security officers (CISOs), personally liable — for the security of their organizations. Yet in other areas of IT and technology, there is a completely different mindset. From Mark Zuckerberg's mantra of "move fast and break things" through to Eric Ries' Lean Startup and the minimum viable product (MVP) model, the thought in these areas is to move quickly but also to deliver just enough so the organization can move forward and improve.

Now, IT security teams can't embrace this model. There are too many regulations to consider. But what can we learn from a mental exercise around minimum viable compliance (MVC), and how can we use that information to help us in our approach?

What Would MVC Involve?

MVC involves covering off what's needed in order to be effectively secure. To achieve this, you have to understand what you have in place and what is critical to keep secure, and what rules or regulations you have to demonstrate that you are compliant with.

For asset management, ideally you have to know all of the assets that you have installed. Without that level of oversight, how can you call yourself secure? For a MVC approach, would you need 100% insight into what you have?

In reality, asset management projects like configuration management databases (CMDBs) aim to provide full visibility into IT assets, but they are never 100% accurate. In the past, asset accuracy hovered around the 70% to 80% mark, and even the best deployments today are not able to achieve full visibility and keep it there. So, should we spend our MVC budget on this area? Yes, but not quite in the way that we might traditionally think.

One deputy CISO told me that he understands the ideal of full coverage, but that it was not possible; instead, he cares about full and continuous visibility for the organization's critical infrastructure — about 2.5% of the total assets — while the other workloads were tracked as frequently as possible. So, while visibility is still a necessary element for IT security programs, the effort should go into protecting the highest-risk assets first. However, this is a short-term goal, as you are only a single vulnerability disclosure away from a low-risk asset becoming a high risk one. While going through this process, do not mix up compliance with security — they are not the same thing. A compliant business may not be a secure one.

Regulation Planning

As part of MVC, we have 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 get the legislation in, 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 that involves change — and therefore expense — each and every time a new regulation is brought in or a significant change takes place.

How can we make this process easier for our teams? Rather than looking at each regulation separately, can we look at what is common to the applicable regulations, and then use that to reduce the amount of work required in compliance with them all? Rather than putting the team through huge exercises to bring systems into compliance, what can we either take out of scope or use as a service to provide the infrastructure in a secure way instead? Similarly, can we use common best practices like cloud controls to remove whole sets of problems, rather than looking at each issue individually?

At the heart of this approach, we have to reduce the overhead around security and concentrate on what represents the biggest risks to our businesses. Rather than thinking about specific technologies, we can examine these problems as processes and people issues, because regulations will always evolve and change as the market goes on. Taking this mindset makes security planning easier, because it does not get bogged down in some of the details that can plague our teams when processes have been built to look at CVEs and threat data rather than in practical risk terms around what is really an issue.

The idea of doing the minimum required to meet market demands or pass a set of rules might be appealing at face value. But the mindset of MVP is not just about getting to a specific level and then settling there. Instead, it is about getting to that minimum standard and then iterating as fast as possible to improve the situation further. For security teams, this mindset of continuous improvement and looking out for ways to reduce risk can be a useful alternative to the traditional IT security model. By focusing on what improvements would have the most risk impact in the shortest timeframe, you can increase your effectiveness and reduce risk in general.