There are two broad goals when it comes to an organisation’s information security, ensure specific systems/operations are as secure as possible and ensure the wider organisation is protected against likely attacks. Penetration testing used to cover both angles, investigating specific systems/operations to uncover the vulnerabilities within, then exploiting these vulnerabilities to assess the wider business impact of such a compromise. Somewhere along the line, things changed, a marketing department probably got involved and decided penetration testing wasn’t ‘cool’ enough, the service split in two and red teams were born.
Whilst red teaming undoubtedly sounds cooler, its introduction has led to confusion on how it differs from penetration testing and many misconceptions have been formed over time.
So, what’s the difference between a red team and penetration testing?
In essence:
Penetration testing looks to uncover as many vulnerabilities as possible within a set scope (usually a specific system or operation), all issues will be reported whether they are likely to be attacked by a realistic threat or not. Risk scores are assigned based on the potential consequences of compromise, but the outcome of such exploitation typically isn’t verified for all issues identified.
Red teaming simulates a realistic attack against your organisation, helping understand the likely routes a threat actor would take, demonstrating how vulnerabilities could be exploited and then chained together to reach a set goal. Goals typically focus on gaining access to critical business assets, or a level of privilege that would be highly impactful to an organisation, without being detected.
To use the well-trodden, but not quite accurate analogy, it’s a pirate approach (get as much as you can within a set target, whilst making a lot of noise) vs a Ninja approach (stealth operation that uses all available routes to achieve a set goal).
Misconceptions
Over the years, a lot of misconceptions have formed around red teaming and to many, it is still seen as an ‘elite’ form of security testing. One that requires months of work, a large team of highly trained testers, advanced levels of security maturity and ultimately, a large security budget. It’s no wonder many organisations don’t see it as a realistic testing option.
The truth is that red teams are highly flexible and can be tailored to most requirements. Yes, they can be complex, lengthy, and costly, but only when they need to be. They can also be short, simple and cost effective. It all depends on what you are looking for.
Tailoring a red team to suit your needs
One way of tailoring a red team to suit requirements/budget is to vary the starting point. There are two broad options, a black box approach and an assumed compromise approach.
> Black box approach
This approach mimics a real-life attack scenario, where consultants (and therefore attackers) have basic knowledge of the organisation but have no prior access. This is typically used by clients who wish to find out how a malicious threat could gain access to the organisation from the outside.
> Assumed compromise approach
Attackers don’t have a scope when it comes to breaching an organisation’s perimeter and all routes are available to them, including unethical and illegal ones. With enough skill, determination, and time, it’s reasonable to assume that a dedicated attacker will likely breach the perimeter at some point.
An assumed compromise approach starts from this position and will provide consultants with an existing level of access from which to start their investigations. Clients utilising this approach typically want to spend their time and budget understanding the impact an attacker can make once they have a presence inside the organisation.
Examples that defy the stereotype
Below are some examples of the red team engagements we’ve conducted over the years that don’t fit the traditional complex or ‘full scope’ stereotype.
> Phishing – incorporating a red team to go beyond the click
Many organisations undertake phishing simulations, checking to see if staff education has worked and to understand how many people click on potentially malicious links. The problem is, when done well, phishing is almost guaranteed to catch out at least one person. It’s therefore important to think beyond the click, to assess the damage that the click could potentially do, and a red team engagement is the perfect way to find this out.
Scenario: A software development firm wanted to run a phishing exercise to test their developers. We worked with them to extend this test to a small red team, not just running the phishing exercise but seeing what the potential fallout could be if an unsuspecting employee were to click.
Goal: Attempt to gain access to the latest software in development
Test: We ran a phishing simulation, targeting developers and QAs, who potentially had access to source code or internal servers. Out of 31 employees targeted, 3 clicked the link. One was a QA, whose account provided access to all the systems used by developers, including the source code repository for their latest product under development.
> Are reused passwords a potential way in for attackers?
Staff typically use a host of remote access services to obtain entry to internal networks and with multiple logins, there is always the chance users are reusing passwords across many services. Password dumps can help attackers uncover these passwords, using them in an attempt to gain access through known services.
Scenario: A global technology firm wanted to know if it was possible for an outsider to gain access to the internal networks.
Test: Using the LinkedIn password dump, we were able to identify several user accounts which had been set up using the target companies email addresses, and the passwords of those users at the time of the breach. Attempts were made to log in to several the company’s remote access services (such as office365) using these credentials and we successfully gained access to the company’s VPN via five separate accounts due to password reuse.
> Are your defences truly effective?
There are a host of defensive solutions available to organisations and many don’t come cheap. But how do you know if the defences you’ve implemented can really detect a real-world attack? You can simulate one.
Scenario: A payment solution provider wanted to see if their internal defences could successfully detect known and likely cyber-attacks.
Test: Using the tactics and techniques utilised by the companies most likely threat actors, we were able to simulate specific attacks within the company’s network, working with their internal teams to fully assess whether they were able to detect our activity. Where activity was not detected, we worked with the internal security teams to reconfigure defensive measures and rerun the attacks to ensure activity was now being successfully picked up.
> Understanding the business impact of an attack to obtain management buy in
Information security is quickly moving up the agenda at board level, but for many, obtaining security buy in from senior management can be difficult, especially when the consequences of an attack are unknown, or underestimated. Red teaming can help demonstrate the true business impact of a breach, helping educate senior management and obtain security buy in.
Scenario: A Telecommunications company had made significant investment into their perimeter defences; however, the IT Director was also concerned about the security of the internal network. Obtaining board level support for this work was proving difficult, with the board believing existing defences would be adequate. The IT Director wanted to demonstrate the full impact of an internal threat through a red team engagement, helping support their requests.
Test: Using an assumed compromise approach – to mimic a malicious insider or a threat actor that had gained access through a phishing campaign, we were able to work our way through the company’s internal network and show how we would be able to gain access to business sensitive information. This provided the IT Director with the evidence they needed to present to the board and ultimately gain buy in for their security improvement work.
Ready to take a different approach to testing?
As you can see from the examples above, red teaming really doesn’t have to be complex, it can be tailored to your goals and can be adapted to your suit your needs, whatever your size and whatever your budget. It’s a different approach, with a different set of goals that can truly enhance your existing testing strategy.
