When you Can’t Stop a Breach, you Should Still be Able to Spot it

Retailers have had an Annus Horribilis to quote Queen Elizabeth II. Target, Home Depot, Michael’s, Dairy Queen, Sony – the list is endless. What is going wrong?

Mark Kedgley notes that the truth is that there is never going to be a 100 percent guarantee of security: and with today’s carefully focused zero day attacks, the continued reliance on prevention rather than cure is obviously not working. Organizations are blithely continuing day-to-day operations while an attack is in progress because they are simply not spotting the breaches as they occur.

If an organization wants to maintain security and minimize the financial fall out of these attacks, the emphasis has to change. Accept it: the chances of stopping all breaches are unlikely at best with a prevention only strategy. Instead, with non-stop, continuous visibility of what is going on in the IT estate, an organization can at least spot in real-time the unusual changes that may represent a breach, and take action before it is too late.

The bottom line is that these breaches could, and should, have been detected in near real-time. Post-event analysis reveals that these Trojan attacks leave plenty of clues, with the creation of new system files, services and registry changes. And yet the attacks continued unnoticed for weeks: two and half weeks in the case of Target.

AV is helpless; vulnerability scanning of the entire infrastructure is resource intensive and over a nationwide chain can happen at best every month; network monitoring will not reveal much as traffic is likely to conform to the restrictions (e.g. internal only).

Duo Security RSAC 2015 – Register to win a free Quadcopter

What is needed is a lightweight process that acts in real-time, is inexpensive to implement, does not depend on an ever-expanding list of malware signatures, has a low false positive rate and is easily tunable.

All this is possible with new process detection with comparison to an internal whitelist of known/good processes. Here is how it works:

• Every process launch is noted and compared against a list of previously seen processes
• Exact matches (e.g. the same process launching again) are ignored
• Anything different about the process (name, property, checksum) triggers a comparison against an internal whitelist; if it matches, it is ignored; if not it is flagged for review.  Analysts can very quickly tune the list (much like spam filters). In a buttoned down environment (such as at a nationwide retailer), unknown processes rarely happen.

While it is true that you cannot always stop a breach, you should be able to spot one.