Assume Breach: Building Resilient Systems in an Era of Constant Threats

It's not just large organizations that should be concerned they will be attacked either as smaller organizations can be a tempting and sometimes softer target for adversaries. For example, an attacker may want to make use of free computing resources that a poorly protected VM can provide to launch an attack or perhaps use a smaller company as a steppingstone to gain entry to a connected organization.

When developing solutions, a software development team can do everything right from a security perspective, but the application can still end up getting breached. This is because software doesn’t exist in a vacuum and is dependent on many other items.  

Even a theoretically 100% secure application (which does not exist!) can end up getting breached as:

• The underlying operating system the solution is running on may contain security issues
• Third-party libraries referenced are later found to contain security issues
• A third-party service used by the application could end up getting breached
• Protocols used by the application are found to contain flaws
• A user or administrator could be tricked or forced into providing access
• Bob wont stop opening attachments that are sent to him offering tempting business opportunities from Yahoo email addresses  
• And a billion other ways..

By taking the assume breach perspective we ask questions such as:

“If an attacker was able to circumvent protections such as firewall rules what they could do?”

“What if an attacker gained database access could they read the sensitive information?”

We can then look at the defenses (controls) we can put in place to prevent or limit the damage that can be done.

Additional protections provide value outside of security and can protect us from mistakes such as accidental deletion or corruption of data.  

Of course, adding additional defenses can be expensive and have other implications so it’s important to balance these with the value of assets they are protecting.

Defenses take many forms from restrictive firewall rules to providing minimal database permissions limiting an attacker's options if a SQL injection issue was discovered to key system functions requiring multiple approvers to making sure data is encrypted at rest.  

Adding multiple protections provides defense in depth if one defense was to fail.

By assuming the worst, we can put in place additional defenses to prevent or mitigate the damage attackers can do and create more secure and resilient applications.

‍