A Mature Security Program at Any Size

Security processes your program must absolutely have. How to implement them correctly and how to scale them as your team grows.

A lot has been discussed about building security program, but somehow still so many things are commonly missed.

Justin Berman, CISO of Zenefits says, “Security is a process not a solution.”

In this post, I will describe the processes that exist within the most effective security programs and how they can scale to any size of organization or security team.

I’m not here to tell you how to hire or what parts of your security team you need to build first, because those things are going to change depending on industry and company size. But there’s one thing that isn’t going to change: These four workflows your security team needs to perform in order to be effective.

Threat Intelligence

Identifying and understanding attacker targeting, capabilities, infrastructure, and cost. Understanding and predicting likely attacker activity.

The intelligence you collect about your attackers will inform every other aspect of your security program. Attackers consistently win because of information asymmetry. Understanding their motivations, strategies, tactics, and economics is necessary to being an effective defender.

Your threat intelligence process can scale from ingesting free indicator feeds or doing a yearly threat modeling exercise to having a whole team collaborating with industry peers, hunting for new threats, and gathering intelligence. Do not naively pull a threat feed into your SIEM, make sure you also gather and interpret data about your attackers.

While this may be an unpopular opinion, I recommend that you do not collect attack surface in this process. You should only be using modern models like intrusion kill chain, factor analysis, and attacker cost.

At any stage, your threat intelligence process should be able receive a list of assets and a list of potential breaches and return a list of attackers (coarse generalizations are okay) and tactics.

Situational Awareness

Identifying and cataloging known assets. Discovering new assets and organizational risk.

asset (n): Any system, component, process, project, initiative, or person that exists within an organization.

You can’t apply your threat intelligence if you don’t know what your protecting. This is the only process where it’s okay to enumerate before you prioritize, because if you’re missing situational awareness your priorities will be wrong. However, you should be able to differentiate assets by value based on your situational awareness and likelihood (to be targeted) based on your threat intelligence. Do not waste time organizing assets that your attackers are not interested in, know that they exist and move on.

Your situational awareness collection methods will change a lot as your organization grows. At smaller organizations, it often makes sense to meet with many teams often to get higher fidelity information. This often doesn’t scale to larger organizations where you might be using automation to discover most assets and only meeting with senior staff once a quarter.

At any stage, your situational awareness process should be able to return a list of prioritized assets and a list of potential assets not yet discovered or organized.

Security Controls

Build effective prevention, detection, and monitoring based on testing and threat intelligence.

Your red team — whether it’s in house or third-party, whether it’s specialized or standard penetration testing — should yield a list of security issues or gaps in your defense strategy that your existing controls do not address. Your security controls process should collate these findings with threat intelligence and situational awareness to prioritize the most relevant controls. Then, this process is responsible for building those controls in order to be effective against attackers. Do not build any controls that you don’t have evidence for or data supporting their existence.

Building, buying, or tuning security controls can look very different at different organizations. At smaller or more engineering-focused organizations, you might be building a lot of things from scratch to satisfy specific requirements. At larger or more traditional organizations, you might be putting together requirements matrices, calling vendors, and testing products to determine the best thing available to buy.

At any stage, your security controls process should be building at least one high-priority control and return a list of existing controls and their effectiveness.

Red Team

Challenge all assumptions and conclusions. Test efficacy of intelligence, awareness, and controls.

In order to fully qualify your risk profile, you must be constantly testing your environment. Your attackers are definitely doing it, whether or not you are.

Your red team can be a vulnerability scanner (not recommended), a team of experts, a yearly or quarterly third-party penetration test, or a mix of all of the above and more.

Do not rely on open source tools or dumb scanners to give you quality results here. Your red team should understand the status quo very well and be able to dispute it in many ways.

At any stage, your red team process should be able to return a list of your most likely and most impactful risks.

Collaboration

Finally, whether all four of these processes are being done by one person, or you have four distinct process teams, or you have a unique organizational structure and all of our teams are doing all of these processes, it is imperative that information is shared between throughout the whole team. Your red team cannot be effective without threat intelligence. Your threat intelligence is not going to be accurate without a list of valuable assets. Your security controls aren’t going to work unless they are informed by intelligence, awareness, and testing. Spend time to disseminate information throughout your security team and constantly improve workflows.

Appendix

• In addition to scalability, maturity implies repeatability. You want to make sure that you can run each process over and over again as necessary.
• Don’t forget your other obligations to your organization, including compliance. Even if you have model your auditor as an attacker.

These ideas were developed with Justin Berman and Adam Zollman at Flatiron Health. These ideas were directly influenced by everyone who worked with us at Flatiron, including Nicholas Arvanitis, Chris Sandulow, Marc Budofsky, Shane Pusz, Kelly Lum, Peter Teoh, and James Chiappetta.