Detecting an attack

- [Instructor] Let's look at the operational response phases of incident response. In the NIST model of incident response these are detection and analysis, containment, eradication, and recovery, and post-incident activities. Detection and analysis is the non-stop process of monitoring for evidence of a cyber attack, and this is the job of the SOC analyst. During the detection phase, the SOC analyst is looking for evidence of malware or intrusive behavior coming into the organization from external sources. This will usually involve watching real-time alerting screens, which run 24-by-7. The analyst is also looking for evidence of malware that has succeeded in penetrating the organization by running file scans and monitoring for signals going out to the malware's command and control servers. A further requirement is to monitor for lateral malicious movement between systems inside the organization to detect malware or an intruder that's penetrating deeper into our networks. Here's an example of the monitoring screen which SOC analysts use. This is the Splunk system, but there are others, such as Graylog and ELK Stack, each with its own pros and cons. All of them, however, digest log records and raise alerts when certain conditions are met. Life in the operations room monitoring for attack isn't easy. It involves many hours of staring at screens of scrolling log records and alerts for candidate incidents which are relevant to pull out and investigate further. Even when there's real evidence of an incident, such as a crashed server, it's often difficult to determine whether the incident is just an IT issue or whether it really is security related, and if so the type, extent, and magnitude of the problem. Picking cyber attacks often requires as much intuition as intelligence. Another challenge is that many alert sources such as IDS have a high rate of false positives. Being under-responsive will let the attack in, but being over-responsive means there's a risk of crying wolf. When an incident is confirmed as being security-related, incident responders will often be asked to analyze ambiguous, contradictory, and incomplete symptoms to determine what's happened. This is where an analyst's skill really becomes important. Signs of an incident fall into one of two categories. A precursor is a sign that an incident may occur in the future. A port scan may be a precursor to an attack, as an adversary would likely do surveillance before launching a hard attack. Similarly, the release of an exploit in the wild to attack a known vulnerability in the organization would be a precursor to an attack. An indicator is a sign that an incident may have occurred or may be occurring now. A beaconing connection back to an unusual IP address may be an indicator that malware is attempting to make a command and control connection. Many of the alerts which are raised in the operations room will be false positives, and it's important to validate any detection before raising alarms. Understanding normal behavior is one of the best ways of discriminating between false precursors and indicators and real ones. Having a knowledge base helps, as this can be used to quickly determine whether the same anomaly has been seen before. Here's what a traffic flow monitoring screen looks like. With this, a SOC analyst can check for unusual flows of information such as might occur in a major data breach. And here's another showing unusually large amounts of traffic going to a port which normally has minimal traffic flows. Detection may involve correlating information over a period of time. Today's analytical tools tend to use big data analytics as a key strategy to detect long and slow APT infections. Deep packet inspection can be used to provide a detailed snapshot of activity on a particular part of the network, and this may give more context to the precursor or indicator. Host-based packet capture tools such as Wireshark can be used, as can network-based devices such as FireEye and NetWitness. Once an indicator is turned into an incident, prioritization is perhaps the most critical decision point in the incident handling process. Incidents shouldn't be handled on a first come, first serve basis, but should be prioritized based on the criticality to the business.