Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Partner Perspectives  Connecting marketers to our tech communities.
12:10 PM
Ryan Allphin
Ryan Allphin
Partner Perspectives

Preparing for a Breach: The Charge of the Security Brigade

Automation is key to shorter response times and better containment.

Breaches to the right of you,
Breaches to the left of you,
Breaches in front of you,
Broken and plunder’d.
(With apologies to Alfred, Lord Tennyson)

Hopefully your security outlook is not as bleak as the ill-fated “Charge of the Light Brigade.” Sometimes it may seem that it is only a matter of time before there is a security breach where you work. All around you, organizations are being attacked and compromised, billions of pieces of personal or confidential data have been stolen, and it appears that no one is immune from attack. Security resources are under pressure, being asked to do more with less, while the rate of attacks increases and the amount of security data to sift through is mind-numbing.

Policy-based automation is a key security resource at hand that was not available to the Light Brigade.

“Automation Is The Answer. Given the consequences of data breaches, businesses can no longer rely on passive, manual procedures to defend against them. The only way to protect the exfiltration of our data by hackers and cybercriminals is to provide our security teams with a set of rules that will incentivize automated response.” —John Kindervag and Stephanie Balaouras, Forrester, “Rules Of Engagement: A Call to Action to Automate Breach Response.”

Normalization of security data, correlation of events, and automated remediation using security analytics can reduce the transactional workload of your security staff, freeing them to focus on the most credible and most important issues. It’s part of clearing away the clutter and noise so your experts can see the relevant signals.

Before you can automate your incident response, you need to establish a baseline of what is normal. For this, you must know your day-to-day infrastructure patterns and facts:

  • what devices should be present on which network segments
  • what software applications are approved
  • what are the valid configurations
  • what network protocols are permitted
  • where are the authorized wireless access points
  • a list of valid user accounts by segment

Armed with this baseline and corporate policies, security analytics can detect unapproved or undesired activities and tell the endpoints to automatically stop a malicious process, delete unwanted files, and create a forensic image for further investigation. If the host is too infected, it can be reimaged from a known good state. When a malicious file is confirmed, the analytics engine can mine historical data to locate any past events or related artifacts (indicators of attack or compromise), or add it to a watch list for future appearances. Humans can do all of these things, but it takes them longer to assess and take action, giving the attack more time to spread in an endless game of catch up.

At the network layer, security management-driven policies can drive automation to block unwanted traffic based on various parameters you define -- such as IP address, system name, port, protocol, or physical switch port -- and add the relevant information to a watch list. Suspicious traffic can be redirected for packet capture and later forensic analysis.

Aggregating and correlating security incidents into a centralized defensive system lessens the amount of noise in your security alerts. Automating responses to known threats, whitelist violations, unauthorized user accounts, and other clear indicators of attack or compromise reduces response time, containing the threat before it can achieve its objective. Visibility into these events and counteractions will inform the security team as potential evidence of an attack underway.

The Next Frontier: Incident Response

These host and network-based responses are all possible today, and they free up resources to tackle the next frontier: enriching and guiding incident response based on the event sequence and contents of a suspicious file. Within a malicious file, data such as related files and IP addresses contacted can drive targeted reactions. The file and its history also reveal a meaningful story for investigative tools and processes that can hunt throughout your infrastructure. Tools are becoming available that automate searches for file name, hash (MD5 or SHA-1), severity of the convicted file, the gateway or device that first detected it, the message that carried it, the source and destination systems, and the source URL. Leveraging a centralized platform, systems and traffic that share these attributes can be assessed for compromise while these things are monitored via a watch list for future events.

When events surface from historic or dynamic watch lists, the host and network-based automation options can be used again, with surgical precision.

These are some ways that automated cyberthreat response reduces the workload of your security team, freeing them to focus on improving defenses and responding to unknown incidents. These are all options today for active incident response. As we shift to adaptive security management, look to machine learning to automatically add newly identified threats to the watch list, training the system to respond to threats as they become known. The increased sharing of threat intelligence and indicators of compromise and the ability of security analytics and management systems to consume and respond to these via standardized interfaces build an additional layer of validation, credibility, and confidence. These advances will help analysts continue to focus on the unknown and suspicious -- the place where the people factor remains critical.

Things may not be as bleak as the “Charge of the Light Brigade,” but you do need to be prepared for a security incident. Challenge your security analytics and management infrastructure to be your ally in the battle by understanding your business baseline and helping you detect, deflect, and facilitate correction. Otherwise, you are just charging off:

Yours not to reason why,
Yours but to do and die.  

Ryan Allphin is responsible for defining and executing the strategic direction for the McAfee Security Management business, which includes McAfee's flagship product ePolicy Orchestrator (ePO), Enterprise Security Manager (SIEM), Data & Threat Intelligence Exchange, ... View Full Bio
Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
COVID-19: Latest Security News & Commentary
Dark Reading Staff 7/6/2020
Ripple20 Threatens Increasingly Connected Medical Devices
Kelly Sheridan, Staff Editor, Dark Reading,  6/30/2020
DDoS Attacks Jump 542% from Q4 2019 to Q1 2020
Dark Reading Staff 6/30/2020
Register for Dark Reading Newsletters
White Papers
Current Issue
How Cybersecurity Incident Response Programs Work (and Why Some Don't)
This Tech Digest takes a look at the vital role cybersecurity incident response (IR) plays in managing cyber-risk within organizations. Download the Tech Digest today to find out how well-planned IR programs can detect intrusions, contain breaches, and help an organization restore normal operations.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2020-07-07
An issue was discovered in Xen through 4.13.x, allowing Arm guest OS users to cause a hypervisor crash because of a missing alignment check in VCPUOP_register_vcpu_info. The hypercall VCPUOP_register_vcpu_info is used by a guest to register a shared region with the hypervisor. The region will be map...
PUBLISHED: 2020-07-07
An issue was discovered in Xen through 4.13.x, allowing x86 Intel HVM guest OS users to cause a host OS denial of service or possibly gain privileges because of insufficient cache write-back under VT-d. When page tables are shared between IOMMU and CPU, changes to them require flushing of both TLBs....
PUBLISHED: 2020-07-07
An issue was discovered in Xen through 4.13.x, allowing guest OS users to cause a host OS crash because of incorrect error handling in event-channel port allocation. The allocation of an event-channel port may fail for multiple reasons: (1) port is already in use, (2) the memory allocation failed, o...
PUBLISHED: 2020-07-07
An issue was discovered in Xen through 4.13.x, allowing Intel guest OS users to gain privileges or cause a denial of service because of non-atomic modification of a live EPT PTE. When mapping guest EPT (nested paging) tables, Xen would in some circumstances use a series of non-atomic bitfield writes...
PUBLISHED: 2020-07-07
An issue was discovered in Xen through 4.13.x, allowing x86 HVM guest OS users to cause a hypervisor crash. An inverted conditional in x86 HVM guests' dirty video RAM tracking code allows such guests to make Xen de-reference a pointer guaranteed to point at unmapped space. A malicious or buggy HVM g...