Force Multiplying Security

I started thinking about this idea in 2010. At that time, most people weren't focused on security, but after years of red teaming (since the late 1990s), it made sense to approach security this way.

In 2012 I wrote the draft of a post entitled “Deploying Security The Special Operations Way”. The post never saw the light of the day because, at the time, the concept was rather hard to implement. However, I encoded some of the concepts in the Security Operating Model, The Recipes Of Security, The Art Of Adversarial Simulation, and The Principles Of Security.

It makes sense to write about this now. Security is pervasive in everything we do, and, well, things need to be simplified; we are drowning in complexity.

So, I took some original content from "Deploying..." and updated it to make it more relevant to today's world. The result is a rough, evolving post that I’ll clean up as I refine my ideas. This isn’t a step-by-step guide—it’s more of a "how to start thinking about the problem" resource. To make it work for you, you’ll need common sense and a good understanding of your own environment.

This is a work in progress and will continue to be...

Intro

Modern security is often complex and seen as a blocker, especially in big companies. Security professionals need to look at a myriad of different technologies brought by developers seeking the cutting edge of current offerings, or by older processes left behind by past products. At best the different approaches to technology work together, but a lot of times they do not. Add to this the complex environment that needs to be defended, assessed, threat modeled, and defended again, and it’s easy to see how big companies - and some smaller ones as well - would try to grow their security organizations. More people, more vendors, more “managed”, more...

In general, most people don’t want to think about security, they just want it to happen, adding to the difficulty of security teams trying to make people abide by policies and standards.

What can we do, then, to help move security to a better place?

We must remove complexity out of security by providing simpler processes and an automated choice that best serves the person using it. The effort we must focus on needs to solve the following:

• Most of the time, people don’t want to make decisions. They want us to do it for them and not think about security. We need to give them a pre-packaged solution
• Enable the autonomy of not having to think about security by giving them a gentle push in the right direction, and enable the users to take their own actions, knowing where to go if they need a bigger push

Our intent should be to simplify the security processes, automate them when possible, and add them as capabilities in other teams’ processes. Remove their need to have to make decisions, or have to think about whether something is secure or not.

Simplify and automate.

We need to force multiply: we need to make security improve other teams’ work and enhance their probability of success.

First Things First

We need to understand first what good looks like in the place we are working on. We need to think of the basics first, the minimum viable security standard we need to achieve in order to build from there.

First of all we need to build a baseline.

This baseline can be a collection of simple but easy to follow policies that dictate the basic do’s and don’ts, it could be a set of guidelines that give people in the company a good common sense direction (e.g. always use your password manager to store your passwords and generate single use passwords), or it could be a prebuilt collection of vendors that the company can choose from which will provide a more secure experience from the very beginning.

Whatever the initial point is, it should be easier to implement and should remove a lot of the classic security problems already.

Rules

In general, security serves a purpose. We are not a silo and we don’t develop in a vacuum. We are service providers with the ultimate goal of enabling the business by helping to understand risk. Anything we do must serve that purpose, and if it doesn’t, then we shouldn’t spend the effort on it.

Listed below are a few rules that would help you understand whether a security solution is worth pursuing and simplifying.

A security solution or policy should:

1. Mitigate or reduce a specific risk
2. Push secure-by-default configurations forward
3. Enable the security team to get more situational awareness
4. Improve a process’ chance of success

Keep in mind these rules as you begin to work in building the baseline, assessing the current security processes and vendors, and working on simplifying security.

The Focus

There are two main areas of effort: the culture of a company and the guardrails we, as security professionals, can provide to make our processes simpler and more efficient, and easier for people to adopt and follow.

What I’ve seen in the past 25+ years leads me to believe that, unless a company was planned from the ground up to be a single unit, with a single tech stack and approach to technology, chances are things are chaotic, with different and segregated systems not talking to each other, acquisitions that were never integrated properly brining more ways of doing things, and a general culture that is adverse to doing things in any new way.

For security and compliance to be simplified, we need to start first with the culture, where we can work towards having one unified approach to security, IT, networking, development, and other technical efforts. A culture where simpler policies and standards can be applied and enforced, and when needed updated to keep with the change pace.

Next we need to focus on creating a culture of security. One that thinks about applying the basic principles of security to everything they do. And for this we need to simplify what we do and create guardrails to help steer people and their processes. Guardrails provide the gentle push of security towards the baseline we want to enforce, where it can be “deployed” and by doing so, create a secure-by-default starting point, with the ability for security to gain more situational awareness.

Teams and businesses get better products and we get the ability to detect bad things.

Go one step further and identify the processes that can be automated, enabling more to be done faster, and those guardrails now get a boost of energy.

A collection of guardrails and automation leads to a paved road approach. This approach ensures that whatever the teams chose to do is the most secure. It provides them with autonomy and removes possible bottlenecks created by security.

Notes:

Guardrails are security tools in the pipeline that help ensure the software doesn’t drift too far from established standards. These guardrails allow developers to maintain their creativity and flexibility while building features that ultimately go to the customer. Guardrails do not dictate precisely how something is done but instead provide a container around the solution and ensure that the finished feature doesn’t stray into the land of insecurity.

Paved roads are platforms that developers can build on top of without having to worry about aspects like identity and access management.

Source

Paved roads and guardrails help make their products better.

General Thought Process

When you begin working on simplifying security, focus on understanding the priorities a business has, and its biggest risks. Work backward from the core risks and select the efforts that best help lower that risk, focusing next on simplifying it for the teams. In short: understand the risks, assign criticality, and begin to work from there.

Always think about how to make security simpler, lighter, and faster for the teams. You want to get to the point where you can create guardrails and automations, so you can give the tools for people to implement security themselves, freeing you to go tackle the bigger issues.

The Process

First, identify the processes that the security team already have and ask:

• Are people using our processes at all?
• Why not?
• Are they efficient?
• Are we doing it right?
• Can we remove steps?
• Can we explain it simply to non-technical people?
• Can we create automation so people can use it without worrying?
• Do we need to replace it with something better?
• Can we make the process part of developers’ CI/CD without them having to change many things?

As you do this, make sure you add a way to monitor any automation you create to make sure it works. A key aspect of this activity should be the ability for us to understand when something is not working and change it.

Then, focus the effort in the following actions:

• Create a collection of minimal security activities that need to happen. This is the baseline we must enforce
• Give all business units a list of processes, policies and standards they need to follow, no exceptions, no special cases
• Build guardrails to help them follow the process. Make them simple and easy to automate. Teach people how to do security so they can help change the culture
• Aggregate all security documentation, guides, guardrails, technical tools, policies and standards, and the intake of security requests in one place, where people can easily find them
• Create a paved road where security is a simple “lego” piece in the developers toolset. Make their products and code better
• Create a central place for the paved road, where people can select the right configuration needed and begin a deployment of the secure baselines that best suits their needs

Remember: Always revisit your processes and check whether they can be made simpler. It’s incremental improvements towards the simpler and more efficient way of doing things that will make this happen, with each iteration better and more useful than the previous one. Just start and deliver one feature, then the next one, and then the next one...

Start small, then iterate as needed. Work from the outside in. From the 10,000 ft how-to-solve-the-issue to the actual one inch altitude with the detailed list of things to do.

Important: limit optionality. Enforce critical security controls.

When you give too many options to people, those people might have a hard time choosing, leading to poorer solutions and higher risk. Focus on creating shared accountability and governing mechanisms to enable the autonomy we need for a paved road.

Remember: If something isn’t actually optional, giving an option is confusing.

Treat each security solution as a product: create it, document it, take it to market. Then iterate. Remove the unnecessary and leave the features that work.

The intended outcome should be:

• Simplified security
• Secure-by-default configurations and actions
• Developer autonomy

The Work

Start where you are, and look at what you have.

Shrink the tech. Limit new investment in niche, shiny, and new solutions that only address single security and risk use cases. Focus on unifying the solutions.

Questions to ask first:

• What do we have that we can use?
• How can we get more done with what we have?

Then:

• How do we “force multiply”? How do we expand the security capabilities by giving technical teams and business units automated security processes and tools so they can do security?
• How do we teach them that by doing security, their products and services become better?
• How do we “improve” their stuff so they would like to continue doing security going forward?

Remember: people, clear processes and simple solutions that just work are key for reducing and managing security risks.

Ask:

• How risky are our IT and business legacy processes?
• How should we prioritize investments to secure, simplify, and transform them to achieve a better culture where security is part of what everyone does? Then make a plan, prioritizing by criticality, as in risk reduction, and set to work.

Recommended Initial Baseline

• Create a list of the basic security processes that people must follow. Processes that make security to be stronger by default. Create policies to enforce them. Here's an example
• Policy and standard-based enforcement: consistency in security policies is essential for good security. Create centralized policies that are simple, easy to understand and can be adjusted when needed. Examples of key policies: Secrets Management Policy, Access Control, IAM, and Zero Trust Policy, Vulnerability Management Policy.
• Clearly document the penalties for not following security best practices or policies
• Prioritize employees security training
• Adopt a Zero Trust architecture
• Automate and simplify patch management, no exceptions
• Incident response automation. Identify routine tasks so we can respond to incidents quickly
• Consolidating vulnerability, threat, and asset data sources for risk assessment and prioritization in one single source of truth
• Create simple performance metrics to see how you and the teams are doing

Closing

Security begins with people. We need to enable people to do security. Each and every person at the organization and team levels need to be ready, trained, and understand the issues we face.

Security is a force multiplier, and as such there is a real need to focus on having the right people, the right processes, and the right tools. A small team of highly capable security professionals can achieve a lot. By “exporting” security to others, the nimbler security teams can go focus on the bigger issues. Automation and guardrails are the answer here.

Priorities are needed, along with clear communication and simple standard operating procedures that both security and non-security people can understand.

Create that paved road and set security free.