As a developer turned security person, I’ve learnt first-hand how important it is for all teams to work together, more than just DevSecOps.
It’s time to include and blend developers into our Infosec circle.
Current state of Information Security
Red and Blue Teams
In the realm of information security, there tend to be two main groups:
The Red Team, employees or contractors hired to be Attackers, ethical hackers that work for an organisation finding security holes that a malicious individual could exploit.
The Blue Team, the organisation’s Defenders, who are responsible for protective measures within an organisation.
While it is good to have people dedicated to secure an organisation through defence or attack methods, organisations and their systems do not stay static.
Additional processes, automations, products and being built constantly — with the potential attack surface area growing with each new change or integration.
Only having Red and Blue Security Teams is not enough. The people building what must be defended need to be included.
Introducing Yellow Team — The Builders
These are the people that build and design software, systems, and integrations that make businesses more efficient.
Application developers, software engineers and architects fall into this category.
Their focus is usually on requirements, functionality, user experience and back-end performance.
If we want to have applications, automations and processes designed and implemented securely, Red Team and Blue Team need to work with the Builders.
Builders need to be included as a part of Information Security.
(Yellow need to be part of the team. We can only do this by working together)
Last year, April Wright proposed a solution in her BlackHat talk titled “Orange is the new Purple” (DefCamp Recorded Version) and she shows how builders/attackers/defenders are all one InfoSec team. Some of the content below is directly from her paper.
We need to make Builders “The Yellow Team” and gives them the capacity to make their applications more secure.
A developer’s focus is on functionality, and making it as functional as quickly as possible. Once an application’s functionality works for all users and stakeholders, its developers will sleep easy because they’ve done their job perfectly.
Developers never know, or really think about, if they’ve done something insecurely — until it’s pointed out to them as part of a penetration test conducted by Red Team, or as part of a breach discovered by Blue Team (keeping in mind that two thirds of breaches take months or longer to discover).
But, we are building software faster than it can be security tested and defended.
We place the security responsibility on programmers, who don’t have the security experience.
Our security industry and organisations are plagued with vulnerabilities and misconfigurations and they all have the same source. The person or group who built it. As the saying goes:
If debugging is the process of removing bugs, then programming is the process of putting bugs into the application. Testing only proves the presence of bugs, not the absence of them.
To help solve this, organisations currently have a cycle:
Yellow Builds it. Red Breaks it. Blue Defends it. Yellow Fixes it.
Well, that’s the theory. In reality it’s:
Yellow Builds it. Red Breaks it. Blue Complains about it. Yellow ignores it. Management hides it
That’s what our current Security / Development culture tends to encourage.
However, our ideal cycle will work best when
Yellow are educated with Red and work hand-in-hand with Blue.
Yellow need to be involved to secure an organisation.
How to help Yellow Team become more secure
The solution is educating the Yellow Team with attack techniques, and using the Yellow Team’s strengths to make defence easier and more visible.
I’ve spent the last five years working with Blue Teams programming security automation solutions and optimising how to improve their monitoring and defence capabilities. If I had to label myself at the moment, I’m probably what the industry is trying to classify as DevSecOps. But more Dev and Sec than Ops.
Over the past five years, I’ve also dedicated many training sessions and ethical hacking courses for developers, and other technical staff. I teach them how attackers break into networks, infrastructure and applications — and how to mitigate it with good coding practices and other defence techniques.
How do we bridge the gap between developers and security?
We’ve now introduced our Yellow Team. We already have our Red Team and Blue Team.
Red. Blue. Yellow. These are our Primary Colours.
These three teams are needed to keep an organisation secure from threats, making them all responsible for the security of an organisation.
Attack and Defence cannot do it alone. Coders can’t do it alone. They all need to work together.
Individually, they don’t have the skills or visibility to protect an organisation.
Introducing the InfoSec Colour Wheel
If Red, Blue and Yellow are our Primary Colours, we can blend their skills together to create secondary teams that combine the skills and strengths of two primary teams.
This InfoSec Colour Wheel expands on April Wright’s amazing work of bringing builders into the security team by putting it into a single infographic. (Image zip at the bottom of the article)
How does it work?
Red, Blue and Yellow are our Primary Colours.
Combine two of them and you get Secondary Colours.
We have our Red and Blue Teams just as we always have, but now with the introduction of a Yellow Team, we can have secondary coloured teams (Orange, Green and Purple) dedicated to mixing skills between attackers, defenders and coders — making code more secure and the organisation more secure.
Let's see how we can combine these skill sets to make our organisations more secure.
Secondary Colours of InfoSec
Security cannot and should not be siloed, but in many cases, software developers and security are currently segregated from each other and from the rest of the organisation.
People tend to specialise in a primary colour, but for an organisation to be secure, all colours must be strong, but they must work together and blend.
As we blend, these teams will combine their knowledge and capability to enhance and improve the other teams to make an organisation more secure.
Do not think of these “Secondary colour” teams as dedicated full-time roles — these secondary colours are a concept and function of existing members.
It is more likely there will be regular and scheduled secondary team “meetings/exercises/engagements” and an open-door policy between groups.
The goal is to have these usually-opposing primary teams work together to achieve a common goal.
Think of Purple Team as a marriage counsellor. It’s fine to have someone act in that role in order to fix communication, but under no circumstances should you decide that the new, permanent way for both partners to communicate is through a mediator.
Purple Team — Maximise Red. Enhance Blue.
The primary goal of a Purple Team is to maximise the results of Red Team engagements and improve Blue Team capability.
This is actually an already established, or easily spun up, team within many security mature organisations. We’ve learned from experience that the business works best when Red and Blue Teams work together to improve the security posture of the organisation. There are many Purple Teams already in existence and people happily declaring their solidarity to Purple Team.
Because knowing both attack and defence is a huge asset to any organisation, team and individual.
Orange Team — Inspiring coders with attackers
The reason for many security bugs within software is not malicious programmers, but a lack of security awareness within software development teams and architects.
The purpose of the Orange Team is to inspire Yellow Team to be more security conscious, increasing their security awareness by providing education to benefit software code and design implementation. There should be structured and ongoing engagements between Red and Yellow Team for the benefit of Yellow.
You want your Orange Team to teach your developers to think like attackers
I joined the security industry as a “Developer Security Trainer Guy”, teaching coders how attackers break into networks and apps. In my experience running ethical hacking courses and secure coding courses, developers don’t respond positively to a list of vulnerabilities, but they LOVE to learn how to think like an attacker.
Yellow Team want to see and understand how the attack tool/automation works, and they love how clever an attack can be. The techniques they learn tend to be more clever, insidious or easily available than they initially realised.
A developer will then, in their brain, begin to internalise how to make their apps resistant to these types of attacks. They begin to understand not just “use cases”, but “mis-use cases” and “abuse cases”.
They develop and inspire offensive critical thinking in Yellow Team and in themselves which is the goal — this helps prevent security bugs being introduced in the first place since it becomes an intrinsic part of how they develop and design solutions.
How are Yellow Team learning security without the help of an Orange Team?
Good question. They’re certainly not reading about it. Yellow Team are too busy keeping up with their own software tooling updates. Their first experience is usually, one day, they receive a penetration testing report with a list of vulnerabilities, then Google what they are, change a line or two of code or configuration, and go back to their actual job (which isn’t security).
Getting Builders to understand how attacks work, and why they want to code securely is significantly more effective than giving them a spreadsheet of vulnerability findings from a penetration test.
When giving a developer a checklist of security bugs to fix, you are basically telling them their work is wrong, after being told that it was right. No one likes to be told their art is wrong, giving them more work to do and having everyone resent security for ruining schedules and pushing back timelines. This only creates conflict.
Traditionally, we exclude builders from Information Security, but scold them after a penetration test or breach for not knowing stuff that changes constantly and is hard to keep up even for seasoned InfoSec professionals!
Everything is always on fire in InfoSec, it can be quite overwhleming for someone not familiar to the field.
Some thoughts on creating an Orange Team
As mentioned previously, I don’t think there will be a full-time Orange Team, although it may depend on the size of an organisation. Some organisations already have “Security Awareness Champions”, and I feel like Orange Team is similar to that role.
Since Orange Team’s goal is to make developers think more like attackers, it will most likely start with certain Red Team members being available to Yellow Team. Working with developers to understand how attackers work will be the first step.
Orange Team members are highly technical and ‘in-the-weeds’. Someone who can speak code, and speak attack methods and understand this fundamentally and from an implementation perspective.
Bringing in a Red or Orange Team member at the beginning of a software sprint allows for additional “Abuser Stories” and “Mis-use cases” to be developed alongside the team’s usual “User Stories” and “use cases” that Yellow Team would typically rely upon to make features. Probably by using some sort of Risk/Threat Model like STRIDE
This gives Yellow Team immediate feedback on areas they need to secure before they write a single line of code.
Time dedicated to training Yellow how the Red Team operate, or even just lunch-time learning sessions to help encourage conversations is also a great way to engage Yellow Team into thinking more securely. Encouraging an open-door, or specific point of contact is also a great way to bridge the gap between Yellow and Red.
If a developer can understand a security flaw, they may recognise the same security flaw they programmed into a separate project that wasn’t tested by attackers — and security flaws start to become fixed proactively.
(Pictured above ^^ Me. So many times.)
Once Orange start having more software builders in their team, they may also be in positions for code-reviews to check on other Yellow Team members code updates catching flaws before they’re committed, or in architecture design positions to ensure that the right decisions are made at the beginning of the project, and not at the end after testing.
The end result should hopefully be better coders trained by attackers, who then train each other to encourage a culture of security amongst developers.
Green Team — Enhance defence with coders
Blue Team are not always aware of all the frameworks, libraries, third-party systems, network calls and functionality added by Yellow Team. Yellow Team may be barely aware of some of the dependencies behind their own code.
Ask any coder using Node what their 80+ dependencies do. Stealthily, it might “heart” a random HotPockets tweet. It might steal bitcoin or developer passwords. And more. These are real cases in very popular libraries!
In the event of an incident, Blue Team may not have the data needed to investigate or defend breached systems and no one wants to test or touch the production environment for fear of it breaking.
Green Team consists of ongoing structured interactions between the Blue Team and members of the software team (Yellow Team). The ultimate goal is to improve code-based and design-based defence capability for detection, incident response and data forensics.
Yellow Team know how to set up systems and code. Green Team will work together with Blue Team or Purple Team and discuss solutions and improvements for:
- DFIR Output
- Logging improvements
- Log content / events
- Log generation standardising
- Change Management
- Integrity Monitoring
- Anti-Virus / End Point Protection
- Full coverage monitoring
With Yellow Team working with Blue Team, catching an event before it becomes an incident, before it becomes a breach, is essential to the defence of any organisation.
How are Blue Team currently doing this without the help of a Green Team?
With great difficulty (or a mandate from management). They inject security and monitoring requirements into projects, however, that in turn increases timeframes and budgets, which tend to become categorised as non-essential requirements for launch.
Alternatively, they have to ask and beg and push for monitoring improvements once a production system is live, forcing double the amount of work to add in improvements at the end of the development lifecycle.
Ignoring monitoring is a medium to high risk practice that companies are doing every day and is now considered one of the most common web app vulnerabilities by OWASP.
I constantly talk about bringing security in at the beginning of the Software Development Life Cycle (SDLC) and having a Green Team would help fulfil this requirement. Making the case at the beginning of a project, and during development for monitoring improvements, logging improvements, integrity monitoring that integrate with Blue Team systems is vital for the security visibility of an organisation.
As shown in the above diagram, a bug found in requirements is significantly cheaper than a breach in production.
Source: Defense Systems Management College, 1993.
Still very relevant today.
Still very relevant today.
Some thoughts on creating a Green Team
I think having a Blue Team member, hopefully with some scripting ability, present at the beginning of the SDLC or Sprint process is a good first step. This new Green member will get to hear the use cases of the Sprint, understand the infrastructure being used, different integrations that might be required, hear potential misuse cases from Orange Team — and understand if there is anything that can should be monitored from a defence perspective.
They can also give early tips for how to best protect or detect a threat or vulnerability that the Yellow Team might not need to worry about.
(Blue tend to know the better and quicker way to secure something)
The other side of Green Team is helping Blue with automation; have a Yellow Team member shadow Blue operations, understand how they work, and where they might have some challenges that can be fixed with automated processes.
A Yellow or Green Team member might be able to improve Blue’s defences through a relatively simple code additions or helping mandate logging standards within a project.
It can be much easier to determine what is easy or difficult to automate if someone is a developer and has visibility within the code of a project.
Green Team might be able to integrate Automated Security Testing (one of my specialties!) into a normal code testing workflow. So when Yellow Team commits code, and runs automated test cases, they also run automated security test cases too, making Blue and Yellow’s job easier.
The two sides of Green Team is enhancing Blue’s abilities to perform monitoring and forensics, while also encouraging Yellow to consider the long-term defence maintenance of the application.
The end result has many benefits that help the organisation as a whole.
The first is a culture of developers who want to integrate their work into the security fabric of an organisation and understand how they can benefit from the intrinsic protections of those defenders.
The second is a health check of Blue operations and saving hours, days, weeks, months of time through simple automation, reporting and standardisations only doable by a Yellow Team.
White Team — bringing all colours together.
At the end of the day, Information Security is dictated by p̶e̶r̶f̶e̶c̶t̶ ̶s̶e̶c̶u̶r̶i̶t̶y̶ ̶r̶e̶q̶u̶i̶r̶e̶m̶e̶n̶t̶s̶ governance, compliance, policy and business requirements.
White Team members include elements of Compliance, Management, Analysts, Logistics and more. These are all-knowing, neutral, third-party individuals who set the rules of engagement, organise teams, set strategy, perform risk assessments and sets plans and monitors progress.
They’re essential for every organisation, but they’re seen as “too corporate” for the developers, “too demanding” for the defenders and “too much of a killjoy” for the attackers.
Since White Team don’t tend to be technical in the same way as our primary coloured teams, conversations between these two groups tend to be more adversarial, each side trying to get across the other’s point of view and requirements heard.
^^ Trying to get everyone on the same high-level page can be difficult for White Team.
White Team are just as essential as builders, attackers and defenders. White Team encompass, and manage all of the colours, without directly being one of them.
So, although they have to be across a lot of organisational areas at a high level, they tend to conflict when directly interacting with a primary colour.
Having White Team interact with a secondary colour team will decrease conflict since secondary colours understand the language of the primary colours they come from, but they are “closer to white” and understand multiple pieces of the security puzzle.
Rainbow Team — All of the above
So I put this Colour Wheel concept to some of my security rockstar friends (people far smarter than me with minimum 10 years security experience, run events, communities etc) and many identified with all of the colours and declared themselves as a Rainbow Team.
They’ve done coding, they’ve done training, they’ve performed attacks, they’ve implemented defensive systems, and they’ve audited and designed for compliance and regulation.
Having a full spectrum understanding might be the ultimate path or goal for a passionate security person.
Or maybe some people will prefer to specialise. I think we’ll find out over the next few decades how this plays out. I do see some people preferring to specialise, but at some point all teams have a hard limit for what they can achieve alone.
One of my best pieces of feedback so far suggests that System Engineers are supposed to be the glue between all colours and white — and that problems Red and Blue are facing are because of a lack of System Engineers.
Tracking, documenting, verifying and managing the various interactions between red, blue and yellow. Systems engineers are technical integrators who are multi disciplined.
While I don’t disagree and I’m not suggesting this model is a replacement for System Engineers, I believe this is a great way to see how we can include Software Builders to work with security to help keep the organisation secure. Very happy for System Engineers to be the glue, but would also like have developers trained by Red and have developers help Blue.
What to do next?
I really like the Infosec Colour Wheel, and early feedback has shown that it’s already helping security teams understand how to interact with development teams, and where certain security professionals now sit within their own organisation as one of the new Orange / Green colours.
Got some thoughts? Did I miss something? Feedback is very welcome 😊. I like improving articles, so this one may change slightly once I receive some additional feedback.
Hope you enjoyed the article. Clap the article if you liked it. You can clap it 50 times if you really like it. I’ve also included links to the pictures used at the bottom of the page. DM me if you want access to PSDs.
For more reading on this topic, I recommend April Wright’s paper as she goes into more details and talks about how to implement this concept. Check out her Youtube video and Podcast on the topic. You should follow her on Twitter too — she’s pretty rad.
While you’re on twitter, follow me @proxyblue. I tweet InfoSec stuff.
For myself, I’ve been a security person for 5+ years, but never fit the Blue/Red/Purple mould. As an #orangeTeam #greenTeam person, now I can see where my skills fit in an organisation, rather than just being brought in as a contractor from time to time.
Also, it’s always nice to be included and have a team 😊🧡💚
Also, it’s always nice to be included and have a team 😊🧡💚
If you want to discuss and learn more, I regularly hang out at The Many Hats Club on Discord, the best InfoSec Discord. We have podcasts and lots of channels for discussion and questions. We’re also currently the only one with Discord Partner Status. https://discord.gg/infosec
As I continue my InfoSec journey, I’m learning more Blue and Red skills, so hopefully I’m on my way to being Rainbow Team too. 🌈
Check out my other popular posts. They’re actually all very Orange Team, it’s nice to finally be included in the InfoSec colour circle 🧡💚
Useful Links to Colour Wheel Graphics
Thanks for reading the word “team” 120 times
Thanks to all my proof readers. This article would not be the same without you amazing people.