In my previous blogs ‘data breaches are inevitable’ and ‘the rise of the OODA’, I discussed the need for an effective incident response plan, and introduced the idea of using the Observe, Orientate, Decide & Act loop for dealing with a data breach. In this first of a series of blogs I’ll be dealing with the actual practicalities of building your incident response capability, but in doing so I’ll also be using the OODA loop as the framework for each element of the plan.
Both the SANS Institute and NIST [NIST SP 800-61] define six main elements of an incident response capability, and the first one being preparation – not only the establishment of an incident response capability [so that the business is ready to respond to incidents], but also in some cases the prevention of incidents [ensuring that systems, networks, and applications are sufficiently secure]. In an ideal world, the individual charged with dealing with a data breach should be separate for those charged with preventing a data breach occurring in the first place. However, we don’t live in an ideal world, and it would normally be same individual. Whatever the situation, preparation is fundamental to the success of any incident response. It is a recurring process, ensuring each new or additional system or device is prepared for incident response, and uses the OODA loop as the driver.
Before start lets have a look at a definition of the preparation.
preparation | noun [to describe or identify] | the action or process of making ready or being made ready for use
In this blog, we will focus on the process of making ready; the key active here is pre-incident planning, and uses the following steps:
It is vital that the Network Time Protocol [NTP] has been enabled, and that all devices on the network are synchronized using a consistent time zone across the business [e.g., Greenwich Mean Time]. tech speak alert: The NTP is a networking protocol for clock synchronization between computer systems over packet-switched data networks. I know I said having a synchronized network time across the business was vital, and it is, especially when identifying a timeline for the data breach – this is important when looking to bring a criminal prosecution or a disciplinary action.
Next identify necessary Incident Responses Policies. This should include a device login warning banner. Login banners provide a definitive warning to any possible intruders that may want to access your system that certain types of activity are illegal, but at the same time, it also advises the authorized and legitimate users of their obligations relating to acceptable use of the computerized or networked environment[s]. A warning banner displayed at all access points is an essential element for a successful prosecution of any unauthorized users who improperly use any feature of your digital infrastructure. The technical details for implementing banners is dependent on the particular operating system and access point, and is outside the scope of this blog, as is the legal and HR considerations when drafting such a banner.
You should also determine how the business communicates notification of the data breach, in particular when interacting with any necessary law enforcement process [i.e., who, how & when]. This is especially important if you are going to use some form of digital media to communicate how you are dealing with the breach, implications/advice you are giving your customers. In addition, those individuals charged with investigating the data breach, must be able to access and monitor the network; this would require administrator access accounts.
The bulk of any incident response investigation is the analysis of system/network logs, so it is essential that a protected central logging capability be established. However, be warned Windows servers and systems will record many events that can be discarded, so a large protected central logging capability will be required, possibly many terabytes in size. It is also vitally important that the server logging capability is set-up to capture appropriate and useful events [e.g., while successfully logins are useful, the number/time of unsuccessful logins is more useful].
The ability to identify network/system users is another essential element of any successful prosecution. Again in an ideal world you should follow the ‘one user, one account rule’, however most businesses don’t live in an ideal world, and while a standardized user account policy implemented across an business is extremely helpful, it is rarely put into practice. However, again for any successful prosecution, you must be able to identify which user accessed which device, and when. Which leads us to identifying service and system accounts – the business should have in place a method of establishing who owns which service and systems accounts. tech speak alert: In Windows operating systems, a Windows service is a computer program that operates in the background. These services can start when the operating system starts, or they can be started by an event; they have three accounts: System, Network Service and Local Service, and hence can operate when a user is not logged on. Consequently, if for example a Network Service is started, then the owner of that service [i.e., the user account that started it] must be established.
You may also think about building what I like to call ‘take it apart kit’. This bag of goodies, includes sanitized portable drives [min 3TB], some Linux distributions [e.g., Kali, SANS SIFT], bootable USBs [e.g., Microsoft Network Monitor, Mandiant Memoryze], disk imaging tools [e.g., FTK Imager], incident forms, notebooks, pens, camera, LAN cables, a mixture of screwdrivers, evidence bags & tags, plus a mini voice activated recorder. You will also need a lockable cabinet to secure the evidence and your tools [i.e., to stop people borrowing them].
So there we have it, the preparation phase. However, before I leave, lets just have a look at some key decisions you may have to make during the incident.
do you watch and learn or pull the plug? If you are in the fortunate position of catching the data breach in the act, do you let things take their course, or do you shut done the device. Well the answer to that is – it depends. It depends on the data assets under threat, and you need some criteria to aid in that decision; how valuable is the data, what loses [financial/reputational] will the business incur, are there compliance/regulatory implications, could you bring a prosecution? Unfortunately, in the majority cases, the business finds about the data breach long after it has occurred, and by majority I mean 74% of the time.
do you really understand your data breach requirements? In particular, what are your regulatory and legal requirements?
do you have a process for handling and reporting criminal activity? Can you ensure that any evidence of criminal activity that you collect is fit for submission to a criminal court – in the UK the Association of Chief Police Officers Good Practice Guide for Digital Evidence is a good starting point.
do really understand the expectations of the businesses’ stakeholders? This requires that you can actually identify the stakeholders of the business.
Lastly, have you practiced the incident response plan? As they say ‘practice makes perfect’.
Al last, the end – sorry it is so long, but if you managed to get here, then thank you. Remember preparation is a continuous process, as your network grows, so your preparation will need to be reviewed and refined to include those new devices.
In the next blog, I’ll be looking at dealing with a data breach.