In my most recent post, I wrote about the important role proactive threat hunting plays in a mature security program. Equally important to a well-designed program and closely related to hunting for threats is having a robust red team testing plan. Having a creative and dynamic red team in place helps to “sharpen the knife” and ensure that your security tools are correctly configured to do what they are supposed to do — which is to detect malicious activity before it has advanced too far in your environment.
Red teams and blue teams
A red team’s mandate can range from assessing the security of either an application, an IT infrastructure or even a physical environment. For this post, I am referring specifically to general infrastructure testing, where the goal is to gain access to sensitive data by (almost) any means necessary, evaluate how far an attacker can go, and determine whether your security tools can detect or protect against the malicious actions. The red team attackers will approach the environment as if they are an outside attacker.
While your red team assumes the role of the attacker, your blue team acts the defender. It’s the blue team that deploys and manages the enterprise’s defenses. While the red team performs their “attack” exercises, there are many things your blue team can learn about the effectiveness of your company’s defenses — where the shortfalls are and where the most important changes need to be made.
Defining success
Before conducting a red team test, it helps to decide on a few definitions:
1. Define your targets: Without specifying what the critical assets are in your environment — and therefore what actual data an actual attacker would try to steal — your testing efforts will not be as valuable as they could be. Time and resources are always limited, so make sure your red team attempts to gain access to the most valuable data in your organization. This will provide you the greatest insights and biggest benefits when it comes to increasing defensive capabilities.
2. Define the scope: Along with identifying the data targets, it is essential to define the scope of the test. Are production systems fair game or will testing only be done against non-production systems? Is the social engineering of employees allowed? Are real-world malware, rootkits or remote access trojans permitted? Clearly specifying the scope is always important so that there aren’t misunderstandings later on.
How tightly you scope the exercise includes tradeoffs. Looser restrictions make for a more realistic test. No attacker will play by rules. They will try to breach your data using any means necessary. However, opening up production systems to the red team exercise could interrupt key business processes. Every organization has a different risk tolerance for these tests. I believe that the more realistic the red team test is, the more valuable the findings will be for your company.
Once you define your scope, make sure the appropriate stakeholders are notified, but not everybody! Telegraphing the test ahead of time won’t lead to realistic results.
3. Define the rules of engagement: With the scope of the test and data targets well defined, both the red team and the blue team should have a clear understanding of the rules for the exercise. For example, if production systems are in scope, should the defenders treat alarms differently if they positively identify an activity as part of the test? What are the criteria for containment, isolation and remediation for red team actions? As with scope, the more realistic you can make the rules, the more accurate the test will be, but at the potential cost of increased business interruption.
Making final preparations
Don’t end the test too quickly. A real attacker who targets your organization may spend weeks or even months performing reconnaissance, testing your systems and gathering information about your environment before they strike. A one-day red team engagement won’t be able to replicate such a determined attacker. Giving the red team the time and resources to mount a realistic attack will make for more meaningful results.
It’s also important to precisely define what success means. Often a red team attacker will gain access to targeted resources. This should not be seen as a failure on the part of the blue team. Instead, success should be defined as the red team identifying gaps and areas where the organization can improve security defenses and response processes — ultimately removing unneeded access to systems that attackers could abuse. A test that ends too early because the attacker was “caught,” doesn’t provide much in the way of meaningful insights into your security posture. An excellent red team test is a test that is comprehensive.
It’s important to note that defenders have the harder job, as the countless daily news stories about breaches illustrate. It is much more challenging to build and maintain defensible systems than infiltrate them. This is one of the reasons why red team exercises are so important.
Completing the test
Once the test is complete, the red team should share the strategies they used to compromise systems, and gain access or evade detection with the blue team. Of course, the red team should be documenting all of this during the test. Armed with this information, the blue team can determine how to harden the environment and create a bigger challenge for the red team during the next exercise.
We have a fantastic red team here at Code42. The team has conducted multiple tests of our infrastructure, and we have always found the results to be incredibly valuable. Any organization, no matter the size, can gain much more than they risk by performing red team testing.
As always, happy threat hunting! And if you’re interested in more tips from the trenches from our red and blue teams, check out this webinar.