Piers Wilson, Siemens: Sometimes the horse will bolt … how do you close the stable door?
Security is a risk management discipline. What that means in practice is that any level of defence is only “partial”: there is always an element of residual risk. Of course once you then introduce the human element this increases – even very strong security controls, once installed, configured and used by fallible humans can introduce weakness.
Also there is the malicious element (i.e. internal misuse of legitimate access). Finally there are those attacks which are almost impossible to prevent – targetted attacks which specify exploit your weakness, zero day attacks which are not picked up by signature based defences and blended attacks which comprise several attack vectors or which use other vulnerabilities to cause much wider impacts. There is a continuum – you apply controls and draw a line (your risk appetite), beyond that you are vulnerable. On the basis that there is always some vulnerability (whether highly complex or trivial to exploit), one can assume that at some point a breach, attack or incidence of misuse will occur. The proverbial horse will bolt – how are you going to react?
Incident response – first, DETECT it…
Do you know what is happening right now on your network? Would you know if one of your workstations were comprised? Are your users honest? Detection is an obvious prerequisite for any form of response – it’s broader than just noticing something might have happened though… its important to be able to establish what. At any rate you are going to need some of those traditional controls but also some knowledge of what “normal” behaviour looks like.
So an IDS (Intrusion Detection System) is a good idea. You may prefer an IPS (Intrusion Prevention System) which is a fairly common enhancement to find these days – but very often either system looks for attacks of a certain type in a certain place (e.g. external attacks against a web application).
An extension is to have log collection, consolidation and analysis – this will often have a wider scope – pulling in and analysing data from server systems, applications devices and even workstations around the enterprise. Either of these may not be able to detect all network or system usage anomalies – radical changes to behaviour which might indicate an something untoward was occurring.
Do you often send several Gb of data to a specific IP address at 3am? No? Well you might want to be made aware if suddenly one day that happens… One further idea, again not a silver bullet, is to outsource elements of your detection to a third party or involve your ISP – they might offer the ability to correlate attacks across several clients or around the Internet. This can give you (via them) advance warning that an attack is happening before it actually gets as far as your systems.
At any rate, spotting that you are being attacked, noticing that an employee is abusing his authority or identifying that you are a victim of a zero day or targeted attack is actually pretty hard; deciding it is an attack, initiating a response and establishing what is going on can be even harder. This leads us on to…
Incident Response – CORRECT it… find out what happened and putting it right
Diagnosing security breaches is becoming increasingly complex. Regrettably many companies make simple mistakes which can make it impossible. There are therefore many of the traditional safeguards which, if properly adopted, can still help.
Analysing an environment to find infections, malware, malicious code and the footprint of a targetted attack is not easy… many attackers, code infections or corrupt staff will aim to cover their tracks. You will probably not be looking for trojan.exe.
A simple security control that can help enormously is that of standard builds (often called “Gold Builds”) – especially at the workstation level. If you suspect a workstation has been compromised, tampered with, or subverted in some way (perhaps even root-kitted) then you may find it impossible to identify the elements of that unless you have a good static reference environment. If you have nothing to compare against, that means you cannot find out which files and executables are compromised, which means you cannot search the rest of the estate to find further infections. Also, you need to contain the infection so you have something to analyse, or reverse engineer, to find out what it does.
Without adequate logs, centrally collected and held for a period of time your ability to track activity, monitor infections or breaches and establish a timeline are going to be limited. This is another familiar topic in the security industry which is seldom comprehensively implemented.
As such, when a breach does occur you only have a vague idea of the fact that something has occurred, but no way to track when, or where, or what was affected, or who was responsible… you might not even know when the attack started or how long it has been going on!
So effective diagnosis is not only hard, but may be impossible if you don’t have the reference point, the available data or the ability to reverse engineer infections, protocols and activity. Don’t think therefore that you can put all your eggs in the “response” basket, there are controls which have to be put in place before a breach to enable the response afterwards. Understanding is key…
Incident Response – PREVENT it happening again
It’s essential that you don’t end-up being attacked twice in the same way. By building up a full understanding of the attack, what your exposures were, and how onward loss of data or breaches occurred, you can put in place preventative measures to stop it happening again. The techniques and controls that helped investigate your initial breach can be used to detect and prevent future incidences.
Organisations exist that can help you analyse the attack – these same organisations can also help you devise suitable preventative measures. Building up a full understanding of the nature of the infection is essential – this will include the initial implementation and exploitation techniques, hiding techniques, communications protocols, and techniques used to scan the network and then infect further machines. For example, bespoke IDS signatures developed to monitor the progress of an attack and identify further infections can be kept in place – they may help in detecting the next occurrence of that attack. Protect against the “class” of attack, not the specific instance, and make sure those more traditional controls such as Gold Builds, log collection systems, user access controls and alerting services are in place.
The business impact of all this is striking; recent surveys have reported that the costs of breaches and data loss can be huge –they may be a few hundred pounds per lost record, but it has also been reported that in total 162 million personal records were lost last year (some from HMRC of course). Forrester reported recently that 65% of breaches are not detected and 87% are from people misusing their own access rights.
Much enterprise level security improvement has been driven by compliance – including the Sarbanes-Oxley Act of 2002 (SOX), Payment Card Industry Data Security Standards (PCI DSS), and Health Insurance Portability and Accountability Act (HIPAA). However, the controls that you will find are necessary to give you a fighting chance of preventing a breach, and also of detecting one which you can’t prevent, and then diagnosing what the impact is to minimise losses may not be the same as those mandated by the compliance programmes.
If you are following a risk management approach, then by definition you have to plan for the worst cases which you are declining to invest in preventing. For every accepted risk, there needs to be a “what if…” conversation.
Piers Wilson has been in the security industry for over ten years and has experience of a number of different market sectors and areas of risk. He is Head of Technical Assurance at Insight Consulting which provides Security, Compliance and Continuity consultancy services to organisations. This includes network and solution design, penetration and security testing and technical incident response and incident management.