In 2008, no one was offering full-scope Red Teaming to commercial organizations. The only people doing real adversarial simulation were in the military. Penetration testing was the standard, and even then, it was shallow. Most testing was limited to technical scans, quick reports, and canned results that barely touched real risk.

Lares was built to change that.

From the start, our goal was to go beyond checklist assessments and deliver real-world attack simulation. Not just network probing, but the full spectrum of threat activity. We tested electronic, physical, and social exposure. We wanted to operate like real attackers and see how well companies could detect, respond, and recover.

That model became the foundation for what many now treat as standard practice. It came from necessity. You cannot defend against what you do not test. And you cannot improve what you do not measure.

We helped define how Red, Blue, and Purple functions operate during engagements. We also helped create the Penetration Testing Execution Standard, which remains a benchmark for structured security testing.

Most organizations still only see part of the picture.

This blog will walk you through the full model.

Red: Simulating Threats with Real Objectives

Red is not about finding every vulnerability. It is about proving what an attacker can do with one. The Red role simulates adversarial behavior. It begins with reconnaissance and ends with a meaningful objective being completed. The goal could be access to customer data, full domain control, or code execution in a production pipeline.

A real Red engagement typically includes:

• Mapping external infrastructure and collecting OSINT
• Phishing, vishing, or impersonation
• Credential abuse or social engineering
• Physical entry or device drops
• Initial compromise, enumeration and lateral movement across internal network or cloud
• Abusing misconfigurations in object relationships (e.g., excessive user privileges in on-prem Active Directory environments or Microsoft Entra ID)
• Establishing persistence and avoiding detection
• Achieving the defined business-impact goal

At Lares, we treat Red as a full-scope operation. We do not stop at phishing or shell access. We clone badges, test camera coverage, tailgate into secure spaces, and exfiltrate data to simulate the outcome of a real compromise. We test people, process, and technology at the same time

Blue: Defending Against What You Can See

Blue represents the defensive function. This includes managing telemetry, writing detection rules, triaging alerts, and performing incident response. Many organizations have these functions split across tools, service providers, or internal engineers.

Blue should focus on:

• Logging and telemetry from endpoints, networks, and cloud services
• Correlation of unusual behavior into alerts that matter
• Investigation of access patterns, lateral movement, and persistence
• Execution of containment or response actions
• Root cause analysis and detection refinement

The challenge for Blue is not just identifying alerts. The challenge is knowing which ones are real, how they connect, and what to do next. In most engagements we run, the detection stack can see the signal, but no one is watching the right place. Logs exist but do not reach the SIEM. Alerts trigger but are buried in noise.

Good Blue work starts with visibility. Great Blue work connects that visibility to action.

Purple: The Process That Makes Testing Useful

Purple is not a team. It is the process that links Red and Blue. It creates structure around execution and learning. It is how you make every test result count.

The Purple function includes:

• Planning scenarios that reflect real threats
• Executing attacks while the defensive team observes
• Mapping each tactic and checking for telemetry coverage
• Reviewing gaps in visibility, correlation, or alert response
• Tuning detections and re-running tests to confirm improvements

At Lares, we do this live. Our engineers simulate attacks and work alongside your detection owners to improve coverage in real time. You do not need to wait for a final report. You will know what is working and what is not as the test is happening.

No Formal Teams? No Problem

Most organizations do not have a Red Team. Many do not have a full SOC. Some have neither. That is fine. The model still works.

You can apply Red, Blue, and Purple functions using the people and partners you already have.

For example:

• A consultant or security engineer simulates attacker behavior
• A cloud or systems administrator reviews logs and investigates alerts
• Both collaborate during the test to measure gaps and fix what is broken

The point is not to meet a headcount. The point is to run structured testing with built-in feedback. One side attacks, one side defends, and both improve the outcome together.

Frameworks Can Help, But Structure Is What Matters

You can align these roles and activities to established frameworks like MITRE ATT&CK for visibility and coverage tracking. You can also follow assessment procedures based on NIST 800-115. These standards help create consistency, especially when reporting outcomes to leadership.

The critical point is to focus on how work gets done. Frameworks can provide structure, but structure without feedback does not improve anything.

You still need to simulate, observe, measure, and adapt. That loop matters more than labels or documents.

What This Looks Like in Practice

We do not hand over a report and leave. Our tests simulate threat behavior across digital, physical, and human layers. We interact with the people responsible for detection. We find what works, fix what fails, and validate every step before we are done.

If you cannot detect lateral movement or data staging, we will show you where the blind spots are. If your EDR does not “see” persistence, we will help you tune the rules. If your alert logic misses real indicators, we will rerun the attack until it does not.

Red shows you what an attacker can do. Blue tells you what was visible and how fast it was handled. Purple connects the two and turns the test into progress.

Final Thought

Red, Blue, and Purple are not titles. They are roles within a process. You do not need a formal team for each. You need structure, coordination, and intent.

You need to test the threats that matter. You need to measure what you can see. You need to improve what you cannot.

This is not about maturity models or industry labels. It is about whether your organization can respond to a real threat in time to matter.

If you can answer that, the colors do not matter. If you cannot, it is time to run the test.