Stay Steps Ahead With Assumed Breach Testing

What's The Big Deal

Assumed Breach Penetration Testing is intended to emulate an attacker that has already achieved a level of access to your systems or applications. In other words, if an attacker can break through the perimeter defenses of your environment, what controls are in place to prevent them from gaining further access? By giving testers initial access, you assume your perimeter has been compromised and begin to analyze what weaknesses may be lurking inside the organization (e.g., privilege escalation, excessive file and folder permissions, etc.). Cookie environments, or environments that are "hard on the outside, soft on the inside,” are no longer able to thwart current and emerging threats on their own.

The first thought most people have at this point:

"Why would I give a tester access? Doesn't that defeat the purpose?"

NO! Assumed breach scenarios are another step in the right direction for security testing. For far too long security testing has adopted anus vs. them, adversarial approach, which is frankly: very inefficient. If testers and organizations can collaborate and coordinate together, more time can be spent identifying and then fixing issues.

We’ve lost count of the number of phishing campaigns conducted in our careers (best guess: it’s north of 200) but we can count on one hand (or probably even one finger) how many organizations have passed with a perfect score. Regardless of how many security awareness trainings employees sit through, or how many phishing campaigns they are tested by, human security fails from time to time. The fact of the matter is, we’re all prone to error and make mistakes.

Reevaluate The 'Hard on the Outside, Soft on the Inside' Approach

Weigh Your Options

The key is to not just accept perimeter security—human or otherwise—as an absolute. Testing does its best to emulate, but it can’t replicate. Testing has scope, it has time constraints, there are budgets and bureaucracy—attackers don’t care about excluding the CEO and the CFO from their phishing campaign, they won’t avoid a system because it’s ‘in production’. This is where the value of an assumed breach really shines. It’s a way to conduct thorough testing without stepping on anyone’s toes (or production systems).

When weighing your options, does it make sense to use a large portion of the testing time crafting a highly-specific phishing site and email campaign; or, can we accept the premise that an attacker, given unlimited time and scope, will likely succeed at the perimeter and then use our testing time and dollars to evaluate the impact that compromise can have? For example, if we assume at least one user will fall for phishing, can we use that inbox as a starting point for—what effectively becomes—impact analysis.

To be clear, we’re not arguing that phishing training is a waste. Quite the opposite!

In order to foster, support, and reinforce secure practices at an organizational level, security awareness training and phishing exercises are mandatory. That said, it's equally, if not more, important to leverage security testing that ensures our tools and controls are operating effectively. So let’s give our frontline users the education they need to keep the organization safe and the firewalls an appropriate configuration to do the same, but let’s also start spending quality time and effort testing and improving the rest of our information security controls.

Final Thoughts

In addition to the phishing scenario described above—especially during the COVID era—we'd challenge those (still) reading, to look at their current environment and evaluate how well they are positioned to detect and prevent the following scenarios:

  • Ransomware

  • Attacker with VPN Access

  • Attacker with Corporate Workstation Access

Assumed Breach Testing can easily be structured and conducted in a way to give you valuable insight into how your control suite and Information Security Program can handle all of the above. We’re here to help if you’d like more information on how SEVN-X conducts ‘Assumed Breach’ testing.

Previous
Previous

PCI DSS - What it is and what it isn't

Next
Next

To SAST, or to DAST, That is the Question