Part 2: Frameworks in Context: The Business-Aligned Information Security Program and Control Frameworks
March 08, 2018
In part 1 of this series, we provided insights responding to the frequent question regarding control frameworks and their place in the security strategy. During hundreds of strategy, risk and compliance engagements, we have seen that security programs (of different levels of maturity) are most successful when they participate in regular tune-ups to keep up with the business.
In this installment, we will discuss the “how”—understanding the business, the role of the threat, current steps and the best way to approach the gaps, which doesn’t necessarily mean filling them.
The Business Side
Understanding how a business operates is the first critical element of the business-aligned program. In healthy programs we see business-alignment manifest itself when the security team has a clear understanding of what’s critical to success operation of the business and how the business makes money. Is confidentiality of information critical to the business? What about availability for certain systems or applications? What are the most important information assets that need to be defended? Where is the business going? What’s the IT strategy of the organization? Understanding the answers to these questions creates the heart of the program’s alignment to business objectives.
The Role of Threat
Once the key objectives of a business are understood, the next fundamental building block to the business-aligned program is understanding what the actual threats are that would cause harm to the organization. More succinctly, asking the question, “What are the actual threats relevant to this organization?” For some organizations, confidentiality is paramount and threats come by way of intellectual property theft and espionage. Some organizations have availability as a primary concern and threats come by way of ransomware and distributed-denial-of-service (DDoS) attacks. For most organizations different business systems have different threat concerns across a wide variety of vectors. Regulatory compliance is another example of a threat to a business, and when considered as such, it’s kept in context with other non-regulatory threats.
What Do We Have in Place Today?
This is where the frameworks shine: Understanding the state of controls, and the maturity of those controls in the context of the business and the threats are at the heart of why we should use control frameworks to organize our program. Assessing current state in a repeatable way against a well-organized bucket of controls is the only practical way to answer the question, “What do I have in place?” Perhaps what’s more important than asking the question about what controls exist is understanding at a deeper level how effectively those controls are employed—this is where maturity comes into the mix. As an example, putting a checking the box for having patch management is different in substance from documenting that an organization’s patch management program patches only critical vulnerabilities every 30 days and medium vulnerabilities every six months. Intrusion prevention is another example. Putting a check in the box for the controls is different than being able to articulate what percentage of network ingress/egress points are covered by this control. Assessing maturity against controls gives us the greatest insight into the state of the program.
Where are There Gaps?
Once we understand the business, the threat landscape and the implemented controls, we can now begin to look for gaps. Does our business have components which require constant availability (like a factory floor), yet we have limited maturity in preventing DDoS attacks or ransomware? Do we have multi-factor authentication deployed for administrators who are logging in to administer our cardholder data environment for payment? These are all considerations which begin to inform where gaps exist. Again, the frameworks have immense value here.
The Risk Conversation
A key part of business-alignment is the risk management aspect. Considering the cost to implement a control, the risk of something bad happening, and the consequence of that bad event, what should be done? This is where the rubber meets the road in business-aligned security programs. If an information security team understands the business, the threats, the current state and where gaps exist, it can facilitate a true risk-based conversation with the organization. Determining whether or not an organization should pursue greater maturity in an existing control or deploy a new control now becomes a risk management exercise that considers all sides of the equation.
In our experience in the field, most organizations have the resources to be at high maturity in no more than about ten controls. Mileage here does vary by industry (for instance, the financial services sector tends to be mature in far more controls than other sectors), but in general it’s rare for an information security program to have highly mature, continuously improving, well monitored controls beyond ten or so. We often find a moderate level of maturity across another 20-30 controls. Taking ISO 27002 as an example, this leaves us with 74-84 controls without much maturity in an organization. These remaining controls are often those that just barely “have a check in the box” or controls that simply aren’t implemented.
Armed with this reality, the question and the spirit by which we consult with our clients regarding program strategy is this, “Based upon this business, which ten controls should this organization deploy with excellence?” Followed by, “Which 20 or so controls can this organization handle deploying with average maturity?”
Perfect is the Enemy of Good
The recognition that organizations simply aren’t going to effectively deploy the universe of controls in the various frameworks has come about over hundreds of engagements and has provoked those of us who deliver strategy services for a living to seek out a better way. Guiding our industry towards building effective and business-aligned security programs has required us to put the frameworks into context: They’re a guide and a fantastic way to organize controls, but pursuing high maturity across the entirety of these frameworks is not a realistic or achievable way of building solid, threat-aware, risk-based and business-aligned programs. We’re much better off dissecting a business, understanding the threat landscape, and choosing controls as a function of sound risk management.
In this two-part series, we’ve dissected some of Optiv’s field observations regarding successful security programs and where the frameworks play a role. Our work in building successful security strategies over the years has been extremely enlightening with regards to what works and what doesn’t. It’s our sincere hope that sharing our experience will help organizations keep control frameworks in the proper context and enable a true business-aligned security program.