Maturity, Effectiveness, and Risk - Security Program Building and Business Resilience
One of the most common questions asked by business leadership is also one of the most challenging to answer:
“How secure are we?”
Now, some of you reading this may already be cringing or yelling at your screen that this question on its own shouldn't have a simple answer with little actionable value. However, when these questions get asked by leadership, it is important to be able to reply with a concise and easy to digest answer. It is the responsibility of the organization’s Security leadership to be able to answer this question. It is also their responsibility to translate technical information related to the organization’s Security program into clear priorities without techno-babble and in a language the business can understand.
And that’s complicated.
There are three challenges associated with achieving this goal.
- Describing the Security Program Components
- Defining the Target Audience
- Prioritizing Efforts That Lead Towards a Complete Security Program
Describing the Security Program Components
There are many angles we can look at a Security program from that may all result in differing assessments of the program. Penetration testing will provide one set of results on the in-scope targets. A PCI-DSS Report on Compliance (ROC) will provide another set of data. As will a NIST Cybersecurity Framework program maturity assessment, and so on. All different angles resulting in different data sets.
Unfortunately, most of these angles also fall short of answering the original question in a manner that leadership can wrap their heads around before making the appropriate business decisions with.
The TrustedSec Advisory group tends to nerd out on topics like this and has tried to uncomplicate the process of answering this question. So, to address the first challenge of describing the Security program components as simply as possible, the team first looked at what we would consider as the primary “buckets” that a program should be addressing. After many lengthy discussions, the team landed on these three components that a Security program should be able to address: Validate, Improve, and Educate. Each of these three components can represent vastly different activities:
Validate
- Compliance to a framework such as PCI
- The existence of exploitable vulnerabilities through Penetration Testing
- The security of system configurations such as backup solutions
- The effectiveness of tools through controls and organizational effectiveness testing
Improve
- The maturity of program domains and processes such as Security Architecture and Threat Management
- The organization’s incident preparedness through Incident Response Tabletop Exercises
- The organization’s detective capabilities through Purple and Blue Team testing and workshops
Educate
- Technical teams with specific vendor or secure coding training
- General user or specific role Security Awareness training
- Leadership knowledge transfer and Risk communication
Definingthe Target Audience
The second challenge is defining the different layers of an organization that have differing priorities and find value in different testing and analysis results. The team landed on the following groups (which tend to be consistent with other "Three Lines" business-structure models): Leadership, Oversight, and Execution. These groups are straight-forward:
Leadership
- Boards
- Executive Leadership
- Line of Business Leadership
Oversight
- Audit and Risk Groups
- Security Steering Committees
- Technical Team Management
Execution
- System, Network, and Security Architecture and Administration
- Monitoring and Detection Teams
- Security Testing and Response Teams
Prioritizing Efforts That Lead Towards a Complete Security Program
The last challenge in our attempts to answer the original question is in prioritizing the applicable efforts required to ensure that the Security program has functional solutions in each of the program components (Validate/Improve/Educate) and that the right layers of the organization (Leadership/Oversight/Execution) are getting the data and metrics that provide the most value. This can take time, given the needs, directives, and priorities of each of the three audiences. Every organization is going to be different, but we should be able to better express our current Security program requirements as well as future program needs by using a grid like this:
Validate | Improve | Educate | |
Leadership | |||
Oversight | |||
Education |
Organically grown Security programs tend to be underfunded and rarely result in Security being aligned with the business, which is a necessity for the further advancement of any Security program. Our Advisory teams use a similar framework to the one above when assisting clients develop their Security program beyond the limits of organic growth.
From my own perspective as a vCISO, I specifically help security teams align with business needs and requirements by helping organizations focus on Maturity (Improve), Organizational Effectiveness (Validate), and Risk (Educate), and assist all three layers of the organization in determining what resulting data they need from these areas.
Answering the Wrong Question
"How secure are we?" may not be the best question to ask, but the reality is that failure to protect business-critical data directly leads to potentially dramatic financial ramifications in the form of fines, productivity losses, and reputation hits that may result in the loss of a client-base. Better leadership communication (Educate) should be able to pivot from an answer framed by the wrong question to something like "We need to prioritize budget to separate authentication to our backup systems away from our primary mode of user authentication. As our testing has shown, we are susceptible to a ransomware attack that could result in three to four weeks of production being disrupted, and therefore revenue generation being shut down if we do not have access to backups."
We may not be able to answer the “How secure are we?” question with a binary answer like “very” or “somewhat” but using a framework similar to the one presented above as part of our process can help us achieve our goals of moving beyond organic Security program growth and help to align Security with the Business. Additionally, we can succinctly describe a variety of Security solutions, where those solutions can improve our Program, where those solutions provide the most value, and what gaps our program may have at this high level that should be addressed.