An introduction to purple operations

What are blue and red teams operations

Almost everyone who deals with cybersecurity has heard about red and blue teams. Simplifying, a blue team stands for defence, so SOC engineers, security focused Dev(Ops), Incident response engineers, and all the people who fix and maintain security stuff are the blue team.

A red team, on the other hand, stands for offence, threat intelligence. These are white hats, pen testers, social engineering experts, physical break-in testers, and other people who like to break things.

Both types of operations are essential for maintaining a healthy level of security in the company. In many cases, companies have the blue team in house and hire a red team to test their perimeter and scope. Often the life cycle of the security teams without much details looks like this:

1. The security management determines the scope
2. Blue team strengthens security for the scope
3. (The hired) red team tests the scope and shares the recommendations
4. Blue team fix problems
5. Go to step 1

It works, but there are a few flaws in this cycle. Firstly, it is sometimes the security management whose view on the organisation (people, process, technology) can be limited to a fairly high level and very often depends on the budget, which can lead to the situation where some parts of the organisation are protected like a fortress and others are an open highway. This is often the case for OT and IOT industries unfortunately.

Another problem is the long cycle itself. It is rather a waterfall method of working for security, which has all the advantages and disadvantages of the waterfall methodology from the development world. This is actually fine, but in this case the security of the organisation often lags behind the actual development of the world’s security knowledge since the process can take sometimes months until fully resolved. This is especially a pain in IOT industry.

Furthermore, there is often a lack of cooperation due to a difference in KPIs for red and blue teams. Red teams focus on getting the job done any possible way. They are praised for achieving goals and this is often the only metric they have. Blue teams focus on preventing and mitigating problems and dealing with great uncertainty because their area of responsibility is much broader. Both teams work against each other and in the worst cases the blue team might be punished for the success of the red team. It is therefore normal that the blue team will not reveal many details about the system and may not be open to an honest assessment. And this is when the idea of purple teams came up.

Purple operations

The purple colour appears when you mix blue and red, the same applies to purple teams. It is a team that stands between blue and red teams and glues them together. Well I said a team, but it is not necessarily to be a dedicated team, it is more of a framework, so I prefer to call it purple operations.

Purple operations are a joint approach for blue and red teams, and a shift in their traditional operations. But first and foremost it is a shift in the top/mid management mentality. Within purple operations, security management is no longer scoping but prioritising using a security architecture view on attack vectors entry points and a feedback from the purple team. This means that for the red team, there are no longer boundaries, but a priority direction.

Purple operations life cycle

While in principle purple operations can fit into any company’s way of working, they really shine when they are more like agile from the development world with short and intense cycles. Quite simplifying it looks like this:

1. The security management defines priorities.
2. Red and blue teams creates the attack plan with priorities in mind and define the scope for the test using knowledge and inputs from both worlds.
3. The red team runs tests while the blue team monitors and learns.
4. The blue team fixes things with the help of the red team while the red team also learns from the blue team’s solutions and trying to detect further gaps.
5. The blue and red teams improves the scope with any new potential gaps and shares a feedback with the security management
6. Go to step 1.

The red team act differently within purple operations. Instead of the narrow approach to the target, the red team work broadly. They test as many attack vectors as possible, involving the blue team and their data and help to bypass already secured areas. In essence, they lead the blue team to the areas they need to focus on.

Even being guided the blue team have a huge impact on the red team test scopes during planning, but also when things are more or less matured by actually helping them and providing all the information they need about the areas they are working on.

Collaborative work

Red and blue teams are both responsible for planning and running tests in purple operations. The blue team shares openly and in detail what they have in their domain, what worries them most and what their backlog is. The red team, on the other hand, adjusts its plans based on the blue team’s input and also shares its own plans. The red team also helps to draw up monitoring and protection rules, so that the blue team can learn from a practical example what the attack looks like.

The red team constantly keeps its counterpart informed of the activities it is carrying out. But the blue team acts to be as non-intrusive as possible and only guide the red team in such a way that it does not accidentally hit badly something sensitive, for example very sensitive and old parts of the critical infrastructure.

These plans are also an essential part of the continuous security architecture. It helps security management to set priorities, analyse the current status and maintain an improvement plan, thus closing the continuous security improvement cycle.

Why it works

Blue teams with the support of the security architects have very deep knowledge about their systems and operations in general. Thus, purple operations allows them to shape tactics more effective than the security management.

At the same time shorter cycles with the intense involvement of both teams improves the blue team’s ability to spot and solve potential problems, sometimes as early as during the development phase. Blue teams are usually much more relaxed, cooperative and open to improvements when they are in the purple team.

This approach helps security architects and security management to structure, document and get the most value out of the activities of the red team.

And of course, the specific knowledge of the red teams translates more quickly and accurately into actions and improvements when the blue team is involved.