There are many things to consider when thinking about information security testing, what is the goal of the test, what scope limitations (if any) should we put in place, what approaches should we allow, what is the best starting point for the test, what evidence do we need to provide to stakeholders? The list goes on.
When it comes to red teaming there’s a further consideration to add, who within the company really needs to know about the test?
All security testing is designed to simulate threats in some way, but red teaming is slightly different. It’s designed to simulate a likely real-world attack within live/operational systems, showing how it would be possible for an attacker to gain access to an organisation and assess the damage they could do once inside, typically without being detected.
Going undetected is often a key goal with this type of engagement and a level of confidentiality is therefore needed. But what are the broad approaches available in terms of confidentiality and what are the pros & cons for each?
Open approach – security teams know about test
Having an open approach may seem counterproductive for a live test, after all, the more people who know about a test, the more likely they are to change their behaviour and the less accurate the results could therefore be.
But in some cases, an open approach may be beneficial. One such example is when testing specific defences or a specific area of concern. By working in collaboration with the internal blue/security teams, it allows testers to run a range of attack scenarios one after the other, from basic attacks (which would hopefully be picked up) through to more sophisticated & stealthy approaches.
Internal teams would be made aware when a simulation was taking place and would be asked to flag if activity was picked up by internal defences. If activity was picked up, then the test would reset and a new approach would be attempted, decreasing in ‘noise’ each time.
If an attack simulation was successful, then testers can work directly with the internal team to quickly fix the issue and run the test again. Ensuring the attack can now be identified before moving on to the next attack route.
Need to know basis – key security people know of the test
This is the most common approach we find when it comes to red team confidentiality and is an approach where only key security/technical individuals are privy to the test. Security and technical teams are usually kept in the dark during the activity, therefore providing a more realistic attack simulation than what you get with a more open approach.
As well as providing a more realistic test scenario, you can leverage technical information from your key contacts (making scoping, next steps and approvals much easier) and the potential danger of a test being mistaken for a real attack, and therefore escalated to outside authorities (Police, NCSC, ICO etc), is greatly reduced.
On the downside, the realism of the test depends on the key individuals in charge. Internal politics may be at play and there is always a chance contacts could leak information to ensure their teams/departments perform as well as possible. Therefore, skewing the effectiveness of the test.
Ultimate confidentiality – only one or two people know the full extent of the test
The most realistic red team engagement is one where only one or two people within the organisation know the full details of the test.
As information security has moved up the agenda at board level, this approach has started to gain traction amongst the c-suite and red team engagements are seen as an ideal opportunity to independently assess security posture. In some cases, nobody is given details of the test, just the person running the testing, in other cases, key individuals are made aware that testing will be happening at some point (over the next 3/6/12 months for example), but are not given any details of when or what testing may include.
It’s down to the individual organisation which approach they wish to choose; however, we would recommend making key individuals/teams aware that testing will happen. This is for a few reasons.
Firstly, being open and honest about your testing approach helps promote a positive culture around security within your organisation, people will be less defensive in providing technical information that may be used in scoping a test, results will more likely be seen as a chance to improve rather than a chance to apportion blame and there’s always the added benefit that the knowledge that testing might be underway at any time will keep the blue team alert to potential dangers.
Secondly, the risk of potential escalation is greatly reduced. For example, if red team activity was to be picked up by the security team, and they had no knowledge of testing, then that activity could easily be seen as a legitimate threat and could be escalated to external authorities, all without the knowledge of the person running the test. When teams are aware that testing may be taking place, it is likely threats would be passed up to senior management and the c-suite to confirm if activity flagged was part of the test before any escalation.
Getting the right level for you
The level of confidentiality needed during a red team engagement depends on the goal of the engagement, the areas under investigation and the organisation itself. In fact, it’s not unrealistic to say that all three approaches could be utilised at some point during an engagement.
As an information security testing provider, it’s our job to understand all considerations before we engage in any testing and can confirm, or advise where necessary, on the level of confidentiality we feel is needed to get the best possible results.
