Attacks/Breaches

11/5/2018
10:30 AM
Jackson Shaw
Jackson Shaw
Commentary
Connect Directly
Twitter
LinkedIn
RSS
E-Mail vvv
50%
50%

After the Breach: Tracing the 'Smoking Gun'

Systems, technology, and threats change, and your response plan should, too. Here are three steps to turn your post-breach assessment into a set of workable best practices.

Many times, organizations become so wrapped up in taking steps to avoid becoming the next breach headline that they neglect arguably one of the most important steps: understanding exactly what happened after a breach occurs. But prevention is only part of the equation. Businesses are beginning to see the benefits of analyzing breaches after an event — among them, lowering forensics costs to improving the efficiency of incident management. But, as with any security practice, there is still much room for improvement.

Here are three important steps that can turn an organization’s post-breach assessment into workable best practices that will protect their enterprise from future attacks.

Step 1: Identify Potential Sources of Data
Following an incident, the simple question of "who did what?" is one of the most critical — yet most difficult — to answer. When an incident occurs, organizations want to discover the root cause as soon as possible to determine if other data is actively at risk and avoid additional compromise.

A full examination of security, operations, and access logs can help determine the initial cause and piece together a sequence of events. Typical resources usually start with security logs, operations logs, and remote access logs created on servers, clients, operating systems, databases, networks, and security devices. But even logs have their limitations.

For example, organizations that rely solely on logs run the risk of not detecting advanced attacks stemming from privileged user activities. In addition, a skillful attacker (or a rogue system administrator) can easily erase or alter relevant logs to cover his/her tracks. The loss of this information can lead to a faulty and costly investigation, followed by a delayed response or even an undetected breach — any organization's worst nightmare.

As a countermeasure, security can teams can turn to resources, such as session audits (leveraging session recordings and replayable audit trails) and behavioral analytics (detecting anomalous activity based on deviations from established norms) that show the full context of suspicious user activity and can also provide alerts if suspicious activity is detected.

Biometric and session data — such as mouse movement, logins, previously issued commands, viewed windows, and keystrokes during a session — provide tamper-proof audit trails that allow an analyst to replay or rebuild a user's action. When supplemented with log data, this type of monitoring gives analysts the tools to building a timeline of events, which is invaluable for both real-time and post-breach investigations.

Step 2: Acquire, Verify & Extract Breach Data
After identifying potential data sources, the analyst will need to acquire the data from the identified sources and — perhaps most importantly — verify its integrity before analyzing it.

Log management tools can help here by centrally collecting, filtering, normalizing, and storing log data from a wide range of sources. In a privilege misuse investigation scenario, it's recommended that analysts include audit trails stored by privileged session recording tools in their data acquisition plan.

After the data has been acquired, it's essential to verify its legitimacy, to prove that the data has not been tampered with, especially if it's needed as legal evidence in building an incident response plan.

Advanced forensic tools can protect against tampering by providing encrypted, time-stamped and digitally signed data. In addition, they can secure sensitive information with granular access policies.

After the data has been collected and verified, analysts will need to examine the data by assessing and extracting the relevant pieces of information. The use of forensics tools can provide quick navigation to the point in time where the suspicious event occurred. Combining log data with session metadata can accelerate examination of privileged account-related incidents.

Step 3: Conduct a Full Analysis
Once the relevant information has been extracted, the team should analyze the data to draw conclusions that help answer the who, what, where, when, why, and how of a breach. The foundation of good forensics is using a methodical approach to reach appropriate conclusions based on the available data or determine that no other conclusion can be drawn.

Third-party services can assist with conducting assessments ranging from information technology risk and network vulnerability assessments to penetration testing and many other types of assessments that determine if there is a weakness that can be targeted and eradicated. These risk evaluations allow an organization to establish an appropriate protocol and response process to protect it from future incidents.

As long as data is at risk, a breach or accidental loss can — and will — occur. But by conducting a thorough post-breach assessment, a company can craft a thoughtful response plan that prioritizes mitigation of risk, security of critical assets, and effective crisis execution.

Systems, technology, and threats change, so your response plan should, too. Security teams should conduct an audit at least once a year and conduct incident response plan "fire drills" to ensure the plan is still relevant, minimizes the possibility of future recurrences, and can be fine-tuned to establish accountability on an ongoing basis.

Related Content:

 

Black Hat Europe returns to London Dec. 3-6, 2018, with hands-on technical Trainings, cutting-edge Briefings, Arsenal open-source tool demonstrations, top-tier security solutions, and service providers in the Business Hall. Click for information on the conference and to register.

Jackson Shaw is vice president of product management for One Identity, the identity & access management (IAM) business of Quest Software. Prior to Quest, Jackson was an integral member of Microsoft's IAM product management team within the Windows server marketing group at ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
'PowerSnitch' Hacks Androids via Power Banks
Kelly Jackson Higgins, Executive Editor at Dark Reading,  12/8/2018
Windows 10 Security Questions Prove Easy for Attackers to Exploit
Kelly Sheridan, Staff Editor, Dark Reading,  12/5/2018
Starwood Breach Reaction Focuses on 4-Year Dwell
Curtis Franklin Jr., Senior Editor at Dark Reading,  12/5/2018
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: New camera 2FA closed loop!
Current Issue
10 Best Practices That Could Reshape Your IT Security Department
This Dark Reading Tech Digest, explores ten best practices that could reshape IT security departments.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2018-20059
PUBLISHED: 2018-12-11
jaxb/JaxbEngine.java in Pippo 1.11.0 allows XXE.
CVE-2018-20056
PUBLISHED: 2018-12-11
An issue was discovered in /bin/boa on D-Link DIR-619L Rev.B 2.06B1 and DIR-605L Rev.B 2.12B1 devices. There is a stack-based buffer overflow allowing remote attackers to execute arbitrary code without authentication via the goform/formLanguageChange currTime parameter.
CVE-2018-20057
PUBLISHED: 2018-12-11
An issue was discovered in /bin/boa on D-Link DIR-619L Rev.B 2.06B1 and DIR-605L Rev.B 2.12B1 devices. goform/formSysCmd allows remote authenticated users to execute arbitrary OS commands via the sysCmd POST parameter.
CVE-2018-20058
PUBLISHED: 2018-12-11
In Evernote before 7.6 on macOS, there is a local file path traversal issue in attachment previewing, aka MACOSNOTE-28634.
CVE-2018-20050
PUBLISHED: 2018-12-10
Mishandling of an empty string on the Jooan JA-Q1H Wi-Fi camera with firmware 21.0.0.91 allows remote attackers to cause a denial of service (crash and reboot) via the ONVIF GetStreamUri method and GetVideoEncoderConfigurationOptions method.