Why not start with red teaming?

We have a number of articles already describing our approach to red teaming, but we also want to explain why we do it in the first place. Contrary to the belief we sometimes see, red teaming will not and should not provide a full insight into the security posture of a company. In essence, evaluating how secure an organization is comes down to answering three broad questions:

– How hardened is the infrastructure?

– What are the detection and monitoring capabilities?

– What are the processes to utilize those capabilities and react to incidents, and how well do they work?

Standard external black-box red teaming focuses on answering the last one, and this is where its value lies. In our opinion, it is impossible to know how a security team will react to an incident without causing one, and even the most advanced security solutions and custom detection rules cannot replace real people operating them and calling the shots. However, the test only briefly touches the first two, and only in the capacity sufficient to achieve the engagement objective. For example, it is impossible to list all undetected lateral movement methods, since we usually only need to use one or two, and it’s left unknown if there are any more vulnerabilities than in the report, since the team did not have to find them all. Another interesting issue is with vulnerabilities that are way too noisy to even try exploiting during an engagement. While it may be too loud for us, it might not be for an attacker, especially the “smash-and-grab” type.

In defence of vulnerability assessments

This is why we propose a proper vulnerability assessment first for about 30% of our customers. This allows our team to methodically go through the entire scope first, both internally and externally, and help fix vulnerabilities without worrying about the engagement ending because we have used a noisy and quick approach. We find that all internal security processes work much better when built on top of the hardened and predictable infrastructure, so it is much easier and more valuable to start with that first. It’s cheaper, as well, since we cover much more ground in way less time due to taking evasion temporarily out of the question. Also, a VA allows us to conduct attacks that may be way too easy to detect for us to use on attack simulations, but that may be exploited by someone else with speed over sophistication in mind.

Taking the next step; detection and monitoring

Either after a vulnerability assessment or for more mature organizations, we start to include detection and monitoring evaluations in our offers. 

We almost always propose purple teaming first. This is for the same reason: covering more ground in less time. Since during a purple team engagement, our testers do not worry about the integrity of the full attack chain, we can focus on atomic tests of various techniques, collaborating with the security team to cover the full surface of their detection capabilities. Collaboration also allows us to find gaps in detection coverage, since we can, for example, immediately find out that telemetry for particular types of attacks isn’t even ingested. We can also test detection rules and solutions themselves, making sure they stop attacks as advertised.

This is also where we can start conducting dechained tests: only focus on phishing and initial access, for example, or only on cloud post-exploitation. Dechaining allows us to ensure that all attack stages will get tested irregardless of the success of the previous ones and allows the customer to focus on remediation in one area at a time. There are also benefits for companies with several branches here since we can only test the shared infrastructure once and then separately work on the regional differences.

The time for real attacks

And now, when the customer has confidence in their security posture across the entire attack chain, comes the time for us to try and test the security team itself:

– We know that simple attacks will not work anymore, so we can test how the organization would fare against advanced ones

– We know that detection rules are present and working, so we can test the response of the team if we manage to trigger some of them

– We know that technical countermeasures to phishing or network filtering solutions are in place and work, so we can test how they can be evaded

– We know that monitoring covers all attack steps, so we can test whether the security team manages to recreate a full timeline of the incident we caused

This is the only time where a full-scope red team is unavoidable: since we are evaluating the response to a security incident, we need to create one and be as realistic as possible in the process. Only about 20% of our customers can get the full value of a test like this outright. Usually, at least some of the previous steps are performed first to ensure the technical capabilities are there.