I’ve been doing internal network security, (traditional Active Directory environments), for 15 years. The difference between a mature security program and those who get breached, is how well they detect threats.
One of the best ways to improve at this is by doing Purple Teaming.
Purple Teaming can mean different things for different people. To me it’s to answer the question, “if something goes bump on my network, will I know about it.”
If you’ve never done a Purple Team, here’s my framework for getting started.
1-Start with goals
What do you want to accomplish by purple teaming?
What attack techniques do you want to test?
Are there specific attack techniques you’re concerned about?
The most important thing is to have a plan and have goals in mind that you want to work towards.
For example, maybe you had a recent incident and the lateral movement done by the threat actor was not alerted on. It would be a great idea to run those techniques in your environment again. Then build new detections for the things you missed.
2-Identify TTPs
Next is to look at your business, verticals, industry, where you do business, with who. All that stuff. Then compare it to the threat groups that may likely target you.
Then you look up their playbooks and TTPs, and document the stuff they do. Then you can replicate them in your next purple team.
If you still can’t find much or don’t know where to start, I encourage you to check out Atomic Red Team. It’s an open source (free) library of tests designed to test your organization's security controls.
For example, on a recent purple team engagement I did, the client wanted to see TTPs from INC ransomware. So we researched that group, identified their common tactics and integrated them into the purple team engagement. This was a huge success for the client.
3-Run them in your environment
This should go without saying but you of course want to know what it is you’re running. That’s why test frameworks like Atomic Red Team are so nice. They are pre-vetted by some great security researchers. And there are hundreds upon hundreds of techniques pre-built for you to test.
In order to generate traffic and telemetry and potentially alerts, you need to run these techniques in your environment.
Run them on a typical end-user endpoint, where all your typical security products are installed.
Take your time here. Don’t rush through this process.
It takes time for logs and events to make it to your EDR and SIEM.
The last thing you want to do is blow through a bunch of techniques and not know exactly what is what on the backend in your monitoring systems.
4-Document!
Make sure to keep good notes of what techniques you ran, capturing specific commands. This is important for reproducing them later once you’ve created alerts.
You should also document:
the time you ran the thing
the time it finished
if it was blocked
if there was an alert
which security product alerted on it
what the severity was when the alert was generated
This is super important for tracking progress. Ideally, as you mature and improve you want to be alerting on a higher percentage of techniques, faster.
5-Don’t stop after you’re done
What I mean by that is, after you’ve run all your tests you should have a bunch of data.
Some techniques will have been blocked and alerted on.
Some techniques will not.
The next step is to identify what techniques should have been blocked and/or alerted on.
Your task now is to develop rules for those in your EDR/SIEM. Then re-test those techniques.
Purple team engagements can and should be something you do on a recurring basis. There’s always things to test. Once is never done.
We only do a few purple team engagements per quarter, to keep the value high. If you’re curious if they can help you, I’d love to chat.
PS - Organizations who do purple team engagements, catch threat actors more than those who don’t. Do a purple team.