In this short article, you'll learn a few key team definitions for any organizations trying to implement a proper security practice.

Blue Team

When you implement a Blue Team within your organization, it’s all about defense. This is the typical team that organizations will start out with. If you see a SOC within an environment or an organization hiring for SOC Analysts, think Blue Team.

The whole goal of Blue Teams is:

1. Protect the organization against cyber threats.
2. Plan proper defense mechanisms for an organization's data, systems, and network.
3. Threat analysis.
4. System hardening.
5. Use outcomes of Red Teams and penetration tests to harden the defenses for the organization.

Compliance can also fall under Blue Teams. Typically they will work with either a Compliance Officer (someone who isn’t technical), the legal team, or both to understand exactly what’s needed from a Compliance perspective. It could be anything from SOC2 to PII to HIPPA and anything in between.

The gist is that anything that falls under the defense of an organization's data, systems, networks, and applications (sometimes this is AppSec, depending on the org) falls under the Blue Team.

Red Team

Engineers on the Red Team:

1. Emulates Techniques, Attacks, and Procedures (TTP).
2. Shows the organization from a real-world perspective where they’re falling short with security.
3. Increases security posture.

Red Teamers can do anything that “hackers” do from running Payloads to performing DDoS attempts. They use “hacking” (I use that term loosely) tools like Metasploit, vulnerability scanners, and all of the software suites that come on distros like Kali Linux.

Intel about the environment is gathered, data/system/network infiltration is conducted, and then reports are created to show the current state of the environment.

Red Team vs Penetration Testers

Penetration Testing (pentest), is all methodical. Typically, pentesters are an outside party (otherwise, they would probably be on the Red Team) and their goal is to attack a network (ethically and with permission) to see how vulnerable an environment is. They either have zero information about the network (Black Hat), some information (Gray Hat), or a lot of information (White Hat).

The Red Team emulates (TTP). The goal is to have real-world simulations on an organization that the Red Teamer is working for. They will then find gaps and help implement a better security posture.

They’re both using the same tools, just in a different way.

Another thing to keep in mind is Pentesters usually have very limited time (like 1-3 days) to do the testing (because they’re actually attacking the environment), but Red Teamers could have weeks to months.

Purple Team

If you miss blue and red, you get purple, so it only makes sense that the Purple Team consists of implementing best practices and methods from both Blue and Red teams.

Think about Purple Teams like DevOps. DevOps mixes both Operations and Development work. Purple Teams mix Red Teaming and Blue Teaming.

The goal of a Purple Team is to use skills that were obtained from both an offensive (Red) and defensive (Blue) to enhance an organization's security posture. It’s essentially the best of both worlds if you like offensive security and defensive security.

You’ll use all of the tools that Red and Blue teams use and if there are Red and Blue teams within the organization you’re working in, you’ll work with both.

You may also see Purple Teams (probably not called Purple Teams) within startups and small organizations that may not have the bandwidth to hire both teams and instead, for the time being, combine the two.

What About AppSec?

Although this blog post is more about Red, Blue, and Purple Teams, I wanted to give a high level of what Application Security (AppSec) does.

AppSec is everything at the Software Development Lifecycle (SDLC) level, from the code that’s being written to how it’s deployed. Once it hits the system, chances are that it’ll fall under the Blue Team and Red Team, but that doesn’t mean the AppSec team can’t have a good understanding of the system. For example, Kubernetes is made up of several APIs, which could very much fall under AppSec.

Another good example of where AppSec comes in at the container (Docker, LXC, Cloud Native Buildpacks) layer and the CICD (pipelines) layer. For example, if an artifact/binary is being built via Continuous Integration (CI), AppSec should be part of that process.

One key thing to keep in mind is any good AppSec Engineer has the pentesting knowledge. The pentesting knowledge helps them know holes within code and create security implementations and fixes around those holes.

There are a lot of vulnerabilities in Software. AppSec plays a crucial role.