Inside the castle: Intrusion detection

When designing application security it is no longer appropriate to focus solely on the perimeter of the application.

This is not to say that this is not crucial, merely insufficient.  Best practices such as having anti-malware installed, using least privilege accounts, disabling 'default' admin accounts, using multi-factor authentication and countermeasures for common attack vectors such as SQLi, CSRF, XSS are the bare minimum.

The assumption should be that these techniques are the beginning, not the end, and that these will be breached.

  

The emphasis should be:

1. Have a strong perimeter by adopting application security best practices.

2. Expecting that there will be a breach, being able to identify that a breach has occurred, so the 'hole' can be 'plugged'.

3. Mitigating the likely impact of a breach. 

While many attackers favour a "slow and stealthy" approach, creeping through your system bit by bit, gradually increasing their rights, control and access to data, siphoning it off at a rate low enough to escape detection (they hope).

Some prefer to use a "smash and grab" approach.  Whereby using a pre-discovered vulnerability and unsubtle techniques, they will attack your system to either take it offline by causing as much damage as possible, or, steal as much data as they can before they are discovered and ousted.

To defend against these, it is best to use a "scatter-gun" of different technologies, tools and techniques.  This ensures that even if one is identified and compromised, the others will continue to work (until they are also discovered and compromised).

Strategies to consider

• Encrypt data at rest, and while in transit.  While we should expect this to be able to be "brute-forced", slowing the attacker down can reduce the value of the data (due to timeliness).  There is no need to make things easy.
• Use "canary" accounts.  Create fake users. You can monitor if these accounts are accessed, and if so, you know your security has been compromised.
• Intermingle real data with fake data to obfuscate and confuse, and identify if your system was the source of the leak.
• Put file watchers on "bait" files with tantalising and tempting names, raising notifications if they are accessed.
• Put file watchers on directories whose contents should not be modified at runtime, raising notifications if they are interfered with.
• Create logs of user activity (e.g. logins, the URIs they visit), feeding the data into machine learning algorithms to spot fraudulent activity (e.g. when a user accesses part of the system they have not visited before - perhaps due to privilege escalation).  Machine learning built into the major cloud platforms (e.g. Azure & AWS) makes this a much simpler and cheaper proposition than in the past.
• Monitor and log incoming and outgoing connections.  Once again, this can be fed into the a machine learning algorithm to identify unusual/unexpected connections.

This is just scratching the surface. What detection measures do you think could be put in place?  Please let me know in the comments.