Retailers are facing a significant threat from cyber criminals following the spate of major Point-of-Sale data breaches that we’ve seen over the past year, affecting businesses as large as Target and Home Depot in the US and mass transportation ticketing systems across Europe, writes Ben Densham. As a result, mindsets need to change and businesses should now expect their systems to be breached.
It then becomes a necessity to implement effective detection and mitigation mechanisms that will allow retailers to respond effectively when an incident does inevitably occur. Understanding how breaches are taking place and what the Indicators of Compromise (IoC) are is essential in order to ensure a robust security posture.
Being breached does not need to be ‘game over’. If organisations like Target can detect and respond when they are first under reconnaissance, prior to any PoS malware entering networks, when the malware is first delivered or when it starts to export card holder data then matters can be very different indeed.
We now know that some elements of detection were in place within Target, but the response wasn’t delivered. If an organisation can identify via threat intelligence – or other external sources – that it is being (or is going to be) targeted then the appropriate action may be taken. If it can detect when payloads are delivered into a network, something can be put in place to stop the Command and Control functions starting up and so on.
Finding and applying the right technologies, logging capabilities and monitoring solutions is therefore critical. They should be in place to give advance warning such that there’s time to act before hackers reach the point of data extraction. In parallel, a solid approach to the process of gathering alerts, determining actions and responding effectively is also critical.
Implementing a Response in Depth (RID) plan will enable retailers to mitigate the potentially disastrous fall-out from a data breach.
What is the RID model?
The six steps that follow describe the actions needed to implement a Response in Depth (RID) Plan. These may be automated activities, manual investigations or, most probably, a combination of the two.
An effective response mechanism means that organisations are given the required actions and can carry them out in a timely manner. Tools and systems may be used to deliver this but, even at its most basic, affording an administrator an Action Plan can dramatically reduce the impact of a breach.
The use and development of automation is ideal for log analysis and alerting on IoC. It’s almost impossible to manually review this amount of data. However, the remediation and response actions will often require more manual action as the disparity in tools, interfaces, protocols and platforms remains.
RID Step 1: Detect
Detection can come from a number of bases and touch points, but inevitably encompasses the collection and retention of source data. This includes technical log sources (such as servers and databases), as well as threat intelligence and proactive internal investigations.
Threat intelligence data enables the analysis of this data from multiple feeds via defined messages and services, such as TAXI (Trusted Automated eXchange of Indicator Information). Threat data can be represented through the use of a standard, structured language like STIX (Structured Threat Information eXpression) and all events and statuses represented within a standardised schema, for instance the CybOX (Cyber Observable eXpression) model.
Proactively seeking suspected breaches, investigating process failures and monitoring third party activity can all generate useful batches of information.
The first step is to ensure the right logs are being captured. Knowing why log data is being collected is also important. Often, the logs required for detection of malicious or unwanted events are different to those needed for forensic analysis and investigation. On that basis, a detailed ongoing record must be kept.
RID Step 2: Aggregate
Log data should be collected at source and then collated. The conventional way to do this is through a form of centralised log collection system which can correlate and normalise the data into a format that may be standardised.
Once completed, the aggregation of data from logs, threat intelligence sources and other systems can be evaluated. This data will highlight IoC for further investigation and analysis.
Data from all sources should be aggregated in order to determine if events affecting one system are linked to those on another. Logs are then sent to a centralised platform where they may be standardised and correlated.
RID Step 3: Analyse
Collecting log data, threat intelligence data and other information is one challenge but, in order to make use of it, detailed analysis needs to be conducted that takes into account the value of the data.
The environmental factors surrounding the situation where the data is collected – or the system to which it relates – will also need to be factored in.
What are the areas of risk or concern for the environment? What type of behaviour warrants investigation?
However, log data at this stage may not have significant value until it’s merged with other correlated events. The purpose of the analysis stage is to investigate trends, baselines and behaviours from the environment.
Multiple sources of information will be correlated and a common timeline of actions built up to show the root cause as well as the final effect of activity and actions within the environment. An analysis of trends and behaviours can then be completed and any anonymities indicated.
RID Step 4: Identify
The IoC generated from the aggregated data will facilitate the identification of breach events, malicious activity and security breaches. From this, actionable events will be determined which then allows for an effective response to take place.
IoC will be determined showing potential system settings that changed, applications that were installed, beacons that left the environment, data that was being exported and so on. These events can then be fully investigated and duly escalated as required.
RID Step 5: Respond
The actual response can be broken down into three further sub-steps as follows…
RID Step 5.1: Contain
The initial actions will be designed to contain the breach. These actions must identify affected systems, confirm the extent to which the environment has been affected and isolate (or prevent) the breach from delivering on its intended goal. It may not be possible to fully understand the breach intent at this stage, but the focus is to contain the affected systems until this can be determined.
An investigation into the purpose and operation of any malware, compromise or change in settings and process must be understood in order to move on to the next step. For example, if a phishing e-mail delivers a PDF payload that’s forwarded to three internal staff, e-mails and end points would need to be isolated until the investigation has been completed.
RID Step 5.2: Remediate
Once the purpose and actions of the compromise have been determined, remediation procedures then need to be conducted. These may include patching any exploited vulnerabilities, the reversing of any changed settings, the removal of any rootkits, malware or Trojans and the updating of security signatures or configurations.
A method of preventing the compromise from re-occurring, the ability to detect if any other system has been compromised and the ability to return to a secure, uncompromised state all require to be generated.
RID Step 5.3: Recover
The next stage is to recover any services that have been affected. This process may well involve rebuilding systems and testing operational systems’ security.
Indeed, recovering operational applications and system access – and determining the larger organisational effect of any compromised systems or data – will inevitably form an essential part of this stage.
RID Step 6: Improve
Once the incident is complete and the systems are recovered, governance and security teams should then meet to review the impact of the compromise. This procedure should identify any lessons to be learned, processes to be adapted and areas where improvements are needed to ensure the right level of assurance is being maintained.
With the stakes higher than ever for retailers, proactive steps must be taken as a matter of urgency in order to mitigate the risks. These days, it’s a case of ‘When’ rather than ‘If’ a breach will occur. That being so, retailers must focus on ensuring full network visibility and that incident response teams are able to detect, contain and remediate an attack when situations inevitably arise.
After all, attackers are adept at exploiting any gap that may exist in security defences. Remember… It only takes one successful attempt for a disastrous data breach to occur.
Ben Densham is CTO at Nettitude