Security Program Pyramid

I created this about 8 years ago to help my clients think about resource allocation and prioritization. It could use some updates but I think it's still relevant and useful so I decided to share it.

Ray Dalio, the founder of Bridgewater Associates and someone whose ideas I find useful, talks frequently about creating a machine in your organization to manage how it functions and is measured. I took that concept and adapted it to infosec programs in the form of a pyramid.

The foundation of the pyramid is basic IT operations. Without this, the remaining bricks cannot stand. I've seen many organization purchase expensive threat intelligence or exploitation platforms when they only had 1.5 IT staff and their systems were in disarray. This approach will not improve your security posture, just reduce your ROI.

The next layer to the pyramid is Log Retention & Monitoring. Decisions need to be made as to what data is collected, how long it is retained for, and who has the job of reviewing it, maintaining it, backing it up. If the logs are never viewed or processed, they have low utility. I've done Incident Response for organizations that only had 2 weeks of data and an intrusion that began 2 months previous. There was no way to determine the initial entry vector. However, I've been in organizations that generate 100s of GB per day and in that case, retention becomes a challenge.

The organizations where I was most effective at helping them investigate incidents were the ones who had sufficient network data sources and retention time. Mining a months worth of full packet capture and netflow is priceless when trying to determine what an attacker did. Similar issues to logs above.

This next layer has many names but the essential idea is to have the capability to search across all of the above data sources for known or potential bad activity. If your IT operations aren't in order, you have no logs, and no network data, this layer isn't possible. These days I might add sandboxes and artifact reverse engineering to this layer to have some ability to test and classify potentially malicious files. This is also where I would stick Threat Intelligence for what its worth.

In addition to incident response and reverse engineering, this next layer is one of my favorites. If you have the previous levels in place, you need to test them, train the staff that manages them, validate their efficacy, and improve them as threats evolve. I've seen a lot of organizations try to start here with bad outcomes. I often provide new clients with a questionnaire to determine what layers and bricks they have in place and if it even makes sense to do APT simulation or other testing yet.

Once your program is very mature and the management and exercise of it has become routine, then it may be time to consider leveling up and developing internal Offensive Capabilities. This might not be the right fit for all organizations, some might do better to engage a 3rd party to provide this for them, but the components are the same. The idea here is to be extremely proactive and make attacking you a pain for the bad actors that want your data or to disrupt your organization.

As an add-on to the Security Pyramid, I created a cycle that visualizes how offensive and defensive components can feed into and evolve each other:

The idea here is that as new attack tools and techniques become known, they can be reverse engineered and then tools simulating them can be built. These tools can then be incorporated into the testing program to train and exercise detection capabilities and staff. That staff can then begin to look for those classes of IOCs and find new previously unknown threats which share some characteristics with the simulation tools. Once those are found they can be handed off to the reversing team to repeat the cycle.

This can evolve a security program to a very high level of effectiveness.

I welcome any additions or gaps as this is a pretty old process and it would be great to update it.

Thanks for reading!

A.