By Mat Clarke, Information Security Analyst
Whilst guarding against a security breach is often high on the agenda for businesses and security professionals alike, making preparations for the worst-case scenario actually occurring can easily be overlooked.
Unfortunately, as a number of recent high-profile security breaches have demonstrated, no set of defences is infallible and no business is too big to fail. This means that putting measures in place that will help your business to detect, neutralise and recover from a security incident is extremely important.
How should I prepare?
The Incident Response Plan
One of the most important steps you should consider is creating, maintaining and distributing a detailed Incident Response (IR) plan. This is a formal document, which should contain the following important information:
- Definition of the parties within your organisation who are responsible for security and the maintenance of the IR plan
- Breakdown of potential breach scenarios that are relevant to your business
- Description of the specific actions that need to be taken in the event of a potential breach. This should include clear definition of responsibilities for those taking specific actions
- Complete list of parties who need to be contacted and importantly, how they can be contacted. This should include information related to whether out-of-hours cover exists and if not, what actions should be taken in the event of a security incident occurring at these times
- Definition of any third-parties who may be relied upon, contacted or otherwise involved following a breach, for example managed service providers of network/security systems
Care should be taken, throughout the creation of the IR plan, to make sure that the material contained within it is relevant and specific to the business(es) it will be supporting. In many cases, a poorly thought out IR plan can be more of a hindrance than a help, especially at a time when clear-thinking and the speed of response to a breach can be critical.
It’s also important that the IR plan isn’t created within an IT or Information Security vacuum, as receiving the buy-in and support of all areas of the business helps to ensure that everyone gets a chance to help define and evaluate the plan from their own perspective within the business. Not only does this help in the creation of an inclusive document, but also means that it’s much more likely that in the event of a breach, solid communication lines between departments already exist and the level of overall understanding of the expected response is much higher.
Sysnet Global Solutions have developed a template IR plan document, which you may find useful in helping to build a plan specific to your business. The document can be downloaded here.
Once created, it’s important to implement the following:
- Ensuring that personnel with designated responsibilities have read and understood the content of the IR plan
- Ensuring the availability of the document, in order to ensure that if a breach is suspected, staff can easily access it
- Maintaining the document by reviewing on a regular basis (e.g. at least annually) or following any major change to systems, people or processes
- Regular testing of the plan is absolutely vital to ensure that it works (and continues to work) as planned. This step is explained in more depth below
Testing the IR plan
Routinely testing the IR plan is extremely important and can often reveal gaps in the plan, such as breach scenarios which hadn’t been considered, changes to the environment (including systems, people and processes) which weren’t originally accounted for or even specific processes which aren’t being (or can’t be) followed by personnel.
Testing of the plan should be carried out regularly (at least annually) or following any major change to physical sites, systems, processes or people. To get the best value from your testing, full breach simulations (where possible) are highly recommended. These should be designed to include as many identified breach scenarios as possible and multiple people; especially those with defined responsibilities within the IR plan.
Where full simulations are not possible, or as a secondary testing mechanism following a full simulation, a paper-based walkthrough may be useful. This technique typically involves bringing personnel with designated responsibilities within the IR plan together and going through the document and expected responses step-by-step, to ensure that the plan is fit for purpose.
Recognising a Breach
A breach can be characterised as any unauthorised access, disclosure, modification or destruction of data. This could be an attack against your computer systems or network, but could also include physical premises or property.
The key word here is unauthorised, as the attack could potentially be carried out by an external third-party with little or no legitimate access, or by an insider with some or even full access to systems and sites.
Recognising a breach can be difficult, as attacks can be carried out in many ways. The breach may even resemble typical, unsuspicious business/system activity if the attacker is effective at covering their tracks.
As one system or process will not be enough to detect all potential breaches or instances of suspicious activity, it is recommended to maintain a range of tools, processes or systems configured in a fashion that monitor the data most important to your business.
For example, ensuring that important systems are creating and storing event/activity logs is vital, as is the continuous review (whether by manual or automated means) of the log material. Based on certain criteria, for example multiple failed login attempts to an admin portal, alerts can be created to bring suspicious behaviour to the attention of concerned individuals or teams.
Alongside this, software which monitors changes made to key files could be considered. So-called “change detection mechanisms” are usually configured so that alerts are created whenever key files, for example files containing cardholder data, log files or configuration files are altered.
Intrusion detection or prevention systems (IDS/IPS) are often used to monitor traffic at key areas of a computer network and either create alerts or block the traffic based on key criteria, such as attempted access to sensitive files contained on a web server. Intrusion detection and/or intrusion prevention can be implemented in a number of different ways in your cardholder data environment, including:
- As network-based devices or systems that monitor traffic on the network
- As host-based systems installed on your servers that monitor traffic to and from the specific hosts
- As application-based software that monitors traffic to and from specific applications
Additionally, Security Information and Event Management (SIEM) solutions are routinely used by organisations in order to detect threats, usually by correlating data collected from your network, systems and applications against specific rules or known threats. Based on the data, alerts are created and incidents are ranked based on how serious they are perceived to be.
Whichever tools are used, it’s important to understand that configuration and building business processes around them are equally important – if a tool isn’t setup in the right way, or no-one is looking at its output, then the chances of it helping to detect a breach are extremely slim.
Here are a number of common “suspicious” events which you may wish to look-out for. Please note that this is intended to give you an idea of the type of activity you need to be aware of and shouldn’t be viewed as an exhaustive list:
- Unauthorised or unusual user-account activity on your computer systems or network. This could include the granting of increased user privileges, attempted access to key files/systems by unauthorised users, use of emergency (sometimes called “break glass”) accounts etc.
- Excessive or unusual remote access activity into your business. In particular, watch out for suspicious activities linked to third-party vendors or service provider accounts used for remote access into your business systems, such as access outside of agreed/regular hours, attempted access to systems which the third party does not have legitimate access to etc.
- The presence of new or unauthorised wireless networks (Wi-Fi) accessible from or otherwise connected to your business network
- Detection of malware (viruses, Trojans or other unauthorised executables or programs) on your network or systems
- The presence of, or unusual activity in relation to, new/unapproved software and programs on your business systems
- Critical alerts from your firewall, intrusion detection systems, web application firewall or other security monitoring and protection systems
- Malicious attacks against your internet-facing computer systems as well as suspicious or unusual activity on, or behaviour of, your internet-facing systems
- Evidence of tampering with Point-of-Sale (POS) payment devices, payment terminals, chip & PIN/signature devices or dip/swipe card readers, as well as of your computer and networking equipment
- Any physical card-skimming devices found in your business
- Hardware or software key-loggers found connected to or installed on your systems
- Accidental or deliberate contravention of policies or processes relating to the handling of cardholder data, e.g. mistakenly including card data in an external communication, misplaced hard copy reports containing card data;
- Lost or stolen merchant receipts or any other records that display the full payment card number or card security code (the 3- or 4-digit number printed on the card) or other evidence of unauthorised physical intrusion
- Lost or stolen computer equipment and media (computers, laptops, mobile devices, removable media, etc.) which may have had access to or contained payment card data
If a breach occurs
If you detect that a breach has occurred, then the processes and procedures set out in the formal IR plan should immediately be enacted. These will vary from business to business and will also depend on the perceived scale and nature of the suspected breach.
Dependent on the circumstances, contacting specialist teams or individuals may be necessary. For example, forensic, breach recovery or even public relations specialists are often called in following a breach. Where possible, these teams/individuals should be detailed within the IR plan, including any potential third-parties who may be required.
For further information on what to do if a forensic investigation is required, please see the following article: