VP, Product Management
J.R. Cunningham is an accomplished innovator and premier thinker in cyber security and risk management. As vice president of product management, Cunningham is responsible for maintaining Optiv’s industry leading advisory services offerings and developing innovative and practical solutions that solve real-world security challenges.
Part 1: Frameworks in Context: The Business-Aligned Information Security Program and Control Frameworks
During hundreds of strategy, risk and compliance engagements, Optiv’s consultants often have been asked very thoughtful and deep questions about control frameworks and standards by our clients. Such topics often center on which of these frameworks and standards are most appropriate for a particular organization, which specific controls are most important, and in what order and to what depth an organization should pursue maturity with a particular set of controls. In this two-part blog series, I’d like to share some field observations on this topic gathered by Optiv’s strategy, risk and compliance teams.
Excellence Requires Discipline, and Frameworks are Useful Here
When your security team constantly puts out fires and incidents seem to be never-ending, it is a sure sign of an ad-hoc security program that responds to issues rather than attacking root cause. Without fail, clients in this position have no effective method in place (perhaps outside of personal heroics) of tracking the state of the program and which controls are in place. Instead, organizations should focus on putting the right program elements in place to begin proactively managing the security posture of the business.
Keeping track of the security program is essential for an organization to escape the daily fire-fighting method of security management. Control frameworks are an essential and effective way to accomplish this. One interesting paradigm here is the improvement in security programs that we’ve seen occur when clients begin to face more arduous compliance requirements due to growth. A great example is the improvement in information security posture when an organization moves from a PCI level 2 merchant to a PCI level 1 merchant. On the surface it would seem that the existence of an external QSA holding the organization accountable would be the cause of this improvement, but perhaps a more subtle paradigm is in play: The organization now has a list of controls and a checklist to follow in managing their program. We’ve seen many programs run by leveraging PCI as the control framework of choice, even though it’s not even a control framework, rather an industry standard.
Having something to measure against is key to making decisions on what to do next with an information security program. There are many great control frameworks available for this purpose such as ISO 27001/27002, NIST SP800, NIST CSF, CIS Top20, COBIT, ITIL, PCI-DSS, and the list goes on and on. Each of these frameworks is well designed, expertly constructed and thoughtfully organized.
“A Check in Every Box”
The downside to the above-mentioned frameworks is that we in the information security industry have adopted the notion over the decades that we have to “put a check in every box.” This is where it all goes sideways for us. Organizations simply do not have the money, information security or IT resources to put a check in every box. The business stakeholders and end users don’t have tolerance for the restrictive security that checking every box entails.
Take ISO 27002, for instance. This framework contains 114 controls very well organized into 14 chapters. NIST 800-35 can have up to 170 controls. These controls taken individually all appear to be reasonable and practical, but taken in totality they represent a challenge to implement at a moderate degree of maturity, let alone a high degree of well monitored and continuously improving maturity.
The truth of our industry is that 100 percent maturity in 100 percent of the controls in any of these frameworks is not only impossible, it’s impractical and unnecessary. We’ve spent years in our industry trying to pursue such an objective, and we have little to show for it if metrics such as breach frequency, breach cost and threat emergence are any indication. As an example, look at healthcare. HIPAA was passed in 1996, HITECH in 2009. Did healthcare breaches decrease in frequency or cost? Quite the contrary. Why is this the case especially given the specificity with which some of these control frameworks provide guidance on what to do to protect information and what can we do to leverage the frameworks most effectively?
On the other end of the spectrum from the “fire-of-the-day” security program are those programs connected to the operation of the business in a meaningful and effective way. We generally run into these types of security programs as a result of regular strategy tune-ups and recurring risk assessments. These are programs which have a plan, adjust the plan regularly, and have a genuine pulse for where they have maturity and where they don’t. What’s striking about such programs is that where we find areas of immaturity, it’s usually intentional. This is a departure from the concept of “a check in every box,” and it requires a level of acumen in business and technology in order to succeed. We call these “business-aligned programs,” and they are rare and fantastically effective when done properly. They also have figured out how to effectively leverage control frameworks to facilitate this alignment.
In summary, frameworks and standards are necessary as long as the ultimate goal is business alignment and not putting checks in boxes for the sake of it. In the second part of this blog series I will discuss the “how” of driving toward a business-aligned security program where frameworks fit into this process.