Breach and Attack Simulation: Hack Yourself to a More Secure Future

November 10, 2021
| |
4 min read

Getting breached is the surest way to learn your organization’s cybersecurity vulnerabilities. And that’s why you need to hack yourself before threat actors do. A cyber breach and attack simulation, also called red teaming, is best to understand vulnerabilities in practice, rather than just theory. What can you do before, during and after a simulated attack to boost your defenses?

Types of Simulations

Some methods for finding vulnerabilities are easily confused with each other. Here are three basic approaches:

Vulnerability assessment: This is a routine semi- or fully-automated scan for publicly known vulnerabilities. The system harvests data from the network and connected devices and compares this to a database of known vulnerabilities. This is not a simulation exercise.

Penetration testing: An example of how security systems could be breached. It shows how a threat actor could gain access somewhere in your IT infrastructure and make their way to sensitive data or systems. This is mostly manual and applies the skills of the pen tester to find a way in.

Red teaming: Also known as red team versus blue team exercises, these simulate a sustained attack (by the red team) to test the way your defenders (the blue team) detect and respond to an attack. The idea is to test systems, processes and people all at once.

The last two are sometimes confused with each other. What is pen testing compared to red team testing, exactly? The main difference is that pen testing tests specific systems (hardware and software). It’s human versus machine. Meanwhile, red team versus blue team exercises test your digital defenses as a whole — hardware, software, people, policies, procedures and more. It’s one team of humans against another, each with its respective tools and processes.

Before the Breach and Attack Simulation

The pre-simulation phase of red team security is often the lengthiest and most important part. Firstly, consider how often you should run red team versus blue team tests. They can take place once a year, every six months, quarterly, monthly or some other frequency.

Determine whether you’ll hire internal red teams or use internal staff. Each approach has merit, but decide in advance.

Gather threat intelligence before the faux attack. Research threat actors most likely to target your industry and deploy their aims and methods in the attack plan.

Establish the scope and purpose of your exercise. Make sure you identify targets and also non-targets — resources that are off-limits. Form, clearly articulate and document your objectives. One isolated red team objective might look like this: infiltrate a specific network segment, steal the credentials of a leader (C-level or an IT administrator) and exfiltrate financial data.

Get approval and buy-in from all leaders and stakeholders. One challenge is that offensive cybersecurity tools tend to be harder to justify on a budget than defensive ones. So take some care in making the return on investment case for the power of effective red team exercises and the importance of using the right red team tools in conducting them.

Define a starting point for the breach and attack simulation. This should be based on the assumed knowledge of the attacker. Are they getting their information only from public sources? Or do they have inside knowledge? Define what the simulated attacker knows and plan to begin the attack based only on that knowledge.

Plan communication. One option is for the red team to tell the blue team nothing about targets, methods and approaches. The other is a “purple team” approach, with open communication. Both work. But decide in advance and stick to it during the exercise.

Review the last exercise you conducted to refresh memories of how that went and how the next exercise might be improved over the last one.

During the Breach and Attack Simulation

At this stage, you’ll launch the attack. This often begins with a phishing attack to get a victim to install malware, depending on planning.

From here, focus on internal threats and openings for breaching security, stealing credentials, gaining access and stealing data. Attack simulation is a great training exercise, so make sure to include all who might benefit from it. Make sure all team members feel free to contribute and add their observations and opinions.

The red team should monitor both physical and digital access points. Focus not just on systems, but physical security, social engineering and the use of public data to gain access. Be aware of the staff most likely to be targeted in an attack — the C-suite, board members, accounting staff and others.

After the Breach and Attack Simulation

Afterward, judge the degree of success based on your stated goals and objectives. Do that formally, but capture everything.

Was the red team able to get anyone to open an attachment? Were they able to gain access to an area they shouldn’t have been in? Did an alarm fail to go off? Were they able to convince an employee to let them in, or slide through security with a group of employees without swiping their badge? Record everything.

Vulnerabilities and other problems should point the way to changes in tools, policies, practices and training. Craft a full report describing in detail the method and steps in the attack, conclusions and detailed recommendations to prevent that kind of attack in the future. This should focus on ranking findings based on the risk and value of the target to the organization. The report should clearly rank vulnerabilities and weak spots in order of which need to be fixed first.

After remediation, test the remedy by repeating the attack to see if the problem has really been solved.

Take notes as well to guide the next red team exercise. The idea is to improve not only cybersecurity each time, but the simulated attacks as well. Better, more careful red team attacks lead to better blue team security.

You will likely face a threat actor at some point. It is better to attack yourself first, find out the problems that would enable their success and fix them.

Mike Elgan

I write a popular weekly column for Computerworld, contribute news analysis pieces for Fast Company, and also write special features, columns and think piece...
read more