A Framework for Maturing Security

This year I’ve had the good fortune of spending quality time with customer security teams. Over the last few days, I’ve been thinking about a recent meeting where we discussed how the flood of cloud technology is changing the role of a central security team. At one point, a person in the meeting challenged the need for a centralized security team. That idea caught me off-guard and caused me to re-examine some of my long-held assumptions.

This re-examination led me to a simple framework for describing security investments. This post summarizes my current perspective on the mission, structure, outcomes, and competencies of an enterprise security team that’s fully bought into the cloud.

I’m writing this post on a plane, hopefully it flows.

Mission

Enterprise security exists to empower the rest of the organization by optimizing risk.

Cyber risk is inherently probabilistic and very hard to conceptualize, so managing it (or optimizing it) is more like a social science than physics.

For the sake of this post, let’s accept this mission at face-value.

Group Structure

Enterprise cybersecurity has several disciplines, and their structure can vary from one enterprise to the next. The following diagram describes what I’ve found to be a reasonable way to structure these disciplines.

The following offers a glimpse of the scope of each of these disciplines. By no means is it complete or universal, and an organization could easily choose to structure disciplines differently.

Application & Platform: Application architecture, all types of scanning, controlling how software is built and verified as “safe”, controlled service consumption, CI/CD, HA, logging, patching, credentialing, etc.

Security Operations: Penetration testing, network configuration, log and event collection/correlation/monitoring/analytics, intrusion detection, forensics, incident response, threat hunting, cyber intelligence, fraud detection, detecting compromised accounts, etc.

Data Protection: Definition and implementation of data classification and controls, tokenization / data encryption / DLP, device management, data retention, data disposal, etc.

Identity and Access Management: Employee, partner, customer, and system authentication, directory services, multi-factor authentication, identity lifecycle, PKI services, SSO, RBAC management, etc.

What’s the security team gotta do?

It may seem obvious, but these disciplines need to be defined, scoped, managed and matured somewhere in the organization. It’s also true that the tsunami of cloud technologies hitting the enterprise must be mapped into these disciplines. It seems like these are among the principal tasks for a central security team.

Outcomes

I’ve yet to encounter a company that’s achieved security nirvana. There’s always room to improve, there’s always another summit to achieve, there’s always a new bit of shiny technology, and there’s always another threat to mitigate. This reality creates some gnarly challenges. Namely, it’s often hard to set meaningful goals and to communicate intent across the organization (“why” are we doing something). It’s in this context that I think maturity models shine. Others have come to the same conclusion.

Maturity is the right outcome.

For some readers, maturity models imply complexity. This doesn’t have to be the case. Let’s say we have a simple scale of 1–4:

1. Compliance Minimum

2. Industry Baseline

3. Best Practice

4. Market Leader

What’s the security team gotta do?

4 levels of maturity in the 4 cyber security disciplines yields 16 possible sets of maturity criteria. A more advanced and organized audience might want to include sub-disciplines in maturity models. Either way, it seems like defining the maturity criteria for each of the cyber disciplines is a principal task for the security team. By itself, defining this matrix of maturity criteria is a mountain of work that regularly evolves.

There’s another aspect to maturity that’s extremely powerful yet often overlooked.

Synaptic Structures

Cyber disciplines aren’t stove-pipes. Information must flow between them. Let’s call these channels of information synapses.

Security organizations that strengthen synaptic structures are more resilient than stove-piped ones, and this usually requires intentional investment.

If we represent our cyber disciplines as vertices in a graph, then a fully-connected cyber team is a complete graph. Each vertex in the graph is connected to every other vertex with an edge. If there are N vertices, then there are (N*(N-1))/2 edges. I’m calling an edge a synapse because I think it sounds better.

I believe a good security maturity model includes the synaptic investment.

Previously we saw how 4 maturity levels across 4 cyber disciplines result in 16 sets of criteria. If we have 6 synapses and 4 maturity levels, we end up with 24 sets of synaptic criteria.

I don’t know about you, but I’m not terribly excited about creating ~40 sets of criteria and keeping them current over any extended period of time.

I don’t think success requires fully fleshed out criteria.

This structure is really just an organizational framework that’s useful as a way to target investment, track maturity, and communicate intent.

Synaptic Outcomes

Let’s take a few examples of information flow and see concrete opportunities for maturity. For the sake of this post, let’s assume Controls, Tests, and Monitoring (CTM) are part of the fully mature state.

The Application & Platform <=> Security Operations Synapse

In the simplest case, we know that applications and platforms emit log data, and the Security Operations team needs to make sense of that data. The following are a few examples of targeted investment to improve this information flow:

1. CTM to ensure application and platform logs are ‘always on’ and always forwarded to security operations.
2. CTM to ensure logs are always complete and in the correct format.
3. CTM to ensure logs don’t contain sensitive information.
4. CTM to ensure FIM and HIDS are installed on every node, enabled, and emitting events.
5. CTM to ensure all systems are scanned for vulnerabilities.
6. …

It’s easy to expand, prioritize, and categorize this list into a maturity model. Let’s say our groups collaborate and expand the list to 30 items. This list, whatever the size, is a contract between groups and an opportunity for shared execution.

The act of shared execution is itself an opportunity for maturity and cohesion. In this case, perhaps members of the Security Operations group write automated tests with members of the Application & Platform group. Maybe there’s a quarterly schedule for regular and trackable cross-team rotations.

In general, a synapse is an opportunity for cross-team execution to create stuff that matters to both groups.

Let’s look at another example.

Application & Platform <=> Identity & Access Management

In the most obvious case, applications consume user identity. This consumption represents another synapse. Like the prior example, a synapse is an opportunity to create stuff that matters to both groups. Here are some specific examples:

1. CTM to ensure applications consume Single Sign On Identity services.
2. CTM to ensure applications properly implement token validation.
3. CTM to ensure applications properly implement the user session lifecycle (session state synchronize with logout and credential changes).
4. CTM to ensure applications describe their authorization strategy and implement RBAC in approved ways.
5. CTM to ensure correct provisioning for applications and platform instances.
6. …

Like the prior example, the list is easy to expand, prioritize, and categorize into a maturity model. I’ll leave that to an exercise for the reader.

Competencies

If there’s one thing I’ve learned about hiring, it’s:

You gotta be able to code and continuously deliver code.

As we’ve described, this body of code is most effective when it includes strengthening the synaptic structures in the organization. I don’t see any way a large organization can SaaS and outsource their way out of this reality. Maybe I’m wrong, but I think this reality survives past the adoption of technology in the private, public and multi-cloud arenas.

As I’ve shown in the Synaptic Outcomes section, most of the work isn’t rocket surgery. Sure, there’s always a place for those with a special talent for reverse engineering malware, but I find this to be the exception rather than the rule. The reality is that good security talent is hard to find at scale and can be extremely difficult to retain. However, an organization can mature quickly with a combination of a) generalist developers that have a product mindset, and b) experienced mentoring and leadership.