XDR: telling a complete story
When it comes to threat detection, the job of the security operations centre (SOC) analyst is to put together the story from initial infiltration, through lateral movement, to any exfiltration in order to quickly understand the impact and the response actions needed.
The more data sources and security vectors you bring into the single, integrated XDR platform will present greater correlation opportunities and will result in a more comprehensive investigation and response.
For example, today an analyst might use an EDR tool to get detailed visibility for suspicious activity on managed endpoints but then have a separate siloed view of network security alerts and traffic analysis. As for the cloud workloads, they likely have limited visibility to suspicious activity (perhaps using tools like EDR that aren’t tailored to this different environment).
All parts of the environment generate many noisy alerts that are likely sent to a SIEM. The analyst can see the alerts but not a detailed record of all the activity between alerts, so they miss important attack details and are left buried in alerts without context or way to connect related events.
XDR brings the layers together so security analysts can see the bigger picture and quickly explain what may be happening in the enterprise.
Efficient endpoint activity recording is necessary to analyse how a threat might have arrived, changed, and spread across endpoints. Using XDR, you can sweep for indicators of compromise (IOCs) and hunt based on indicators of attack (IOAs).
Detect: Endpoint events
Investigate: What happened on the endpoint? Where did it come from? How did it propagate across other endpoints?
Respond: Isolate, stop process, delete/restore files
Many organisations may start with endpoint, via EDR tools. While that is a good first step, it can miss the beginning and end of the attack story. What occurred before it landed on the endpoint? Did it come in through email, and did others receive that same email? What happened after it landed on an endpoint? Was there lateral movement to a server or container? Did it spread to an unmanaged device?
Given that 94% of breaches begin through email, having the ability to identify compromised accounts and detect malicious email threats is a critical piece of an organisation’s broader threat detection capability.
Detect: Email threats, compromised accounts, highly attacked users, and email attack patterns
Investigate: Who enacted the infiltration, and who else received the malicious email?
Respond: Quarantine email, block email senders, reset accounts
Email as the No. 1 attack vector should be a priority expansion point towards cross-layered detection and response. Email threats often don’t impact endpoints until a user clicks on an attachment or a link embedded in the email. An undetonated threat could be sitting in multiple inboxes undetected. Connecting an endpoint detection with the originating email means you can automatically search inboxes to find who else received the malicious email and if the malicious attachment or URL is also in other users’ mailboxes. You can then subsequently quarantine the emails and remove the threat to prevent any additional spread and damage.
Network analytics is a great way to find targeted attacks as they spread laterally or communicate with command and control (C&C) servers. Network analytics can help filter the events from the noise and help see into what can be blind spots, such as IoT and unmanaged devices.
Detect: Anomalous behavior as threats spread
Investigate: How does a threat communicate? How does it move across the organisation?
Respond: Outline scope of attack.
Network logs provide a comprehensive source of data to help you understand the scope of an attack, but without correlating those logs with other security alerts, it’s hard to get the context you need to assess what’s related and important. Network and endpoint, for example, is a powerful combination, and by correlating the data, suddenly something that might have seemed benign at just the endpoint layer, such as suspicious PowerShell activity, becomes a high priority alert when it is considered alongside associated command and control (C&C) communication with a server.
Servers and cloud workloads
Much like endpoints, this involves efficient activity recording to analyse how a threat might have arrived and spread across servers and cloud workloads. You can sweep for indicators of compromise (IOCs) and hunt based on indicators of attack (IOAs).
Detect: Threats specifically targeting servers, cloud workloads, and containers
Investigate: What happened within the workload? How did it propagate?
Respond: Isolate server, stop processes
Many may use EDR tools for their servers and cloud workloads; however for most, EDR does not do a good job of addressing new cloud models nor provide the needed type of data and visibility. As with any vector, correlating information from server environments can validate suspicious activity—such as servers that communicate with an IP address in a country they’ve never communicated with before—as malicious by linking it with activity data from other layers, be it endpoint and/or network.