Join Mike Chapple for an in-depth discussion in this video Network symptoms, part of CISM Cert Prep: 4 Information Security Incident Management.
- [Instructor] As a cyber security analyst, you need to be familiar with many of the signs and symptoms of a security incident. This information can help you identify that an incident is taking place, and also point you down the right avenues of investigation during incident analysis. Just like a physician takes a patient's vital signs and asks about physical symptoms when trying to diagnose a disease, security professionals must look at the signs and symptoms on their networks, when diagnosing a security incident.
Network traffic is a common source of valuable information about security incidents. Firewall logs, NetFlow records, and data from network-performance monitoring tools may play a valuable role in diagnosing security incidents. As a cyber security analyst, you should practice reviewing these logs. Make sure that you don't only look at automated summaries of logs. You should also be capable of digging into the records produced by the systems on your network and performing manual log reviews.
Let's talk about a few of the specific, network-related symptoms of a security incident. Bandwidth consumption is one of the most valuable data sources that you'll have, when performing network traffic analysis. NetFlow records will tell you which systems communicated with each other, and how much information they exchanged. You might notice unusual traffic spikes that correspond to a denial of service attack, or the exfiltration of sensitive information. You might also notice that bandwidth consumption by servers or clients is abnormally high or low.
Bandwidth data alone can't diagnose what is happening, but it can be very helpful in identifying a potential incident, as well as identifying the systems involved in an incident. Bandwidth consumption can also help you reach conclusions about what happens during an incident. For example, you might have a file server that contains proprietary software stored in a one gigabyte executable file. If an attacker accesses that system, and you're concerned that the software was stolen, you can look at the bandwidth consumption records for that system.
If there were no flows of information exceeding one gigabyte from that server, the software is probably safe. You can't tell what information was stolen from a system just by looking at bandwidth records, but you can use this information to rule out some possibilities. You also might uncover unusual activity by endpoint systems on your network. Client systems usually have a fairly typical network traffic pattern that involves accessing servers on the internal network and the Internet. If you see a lot of irregular peer-to-peer communication on your network, where two client systems are talking to each other, that might be a sign of a compromised system.
An attacker or malware may have gained access to one system and is using it to try to compromise other systems on the network. Cybersecurity analysts often use the term lateral traffic to refer to this peer-to-peer activity. Many types of malware establish a connection back to a command-and-control server on the Internet, so that the attacker can send commands to the system. Once malware establishes itself on a system, it performs an action known as beaconing where it begins sending messages back to the command-and-control server, announcing its presence.
You can use intrusion detection systems and other controls to watch for beaconing traffic. This traffic may be recognizable because of the content of the traffic or because it's using IP addresses known to be associated with malware. Finally, client systems may begin aggressively scanning other systems on the network, when they are compromised. If you see a system begin to scan many IP addresses and ports on other systems, that's a good sign that a compromise took place, and you should investigate further.
Network traffic provides many important clues for cybersecurity analysts, and you should carefully monitor it for symptoms of security incidents.
- Creating an incident response team
- Classifying incidents
- Building an incident response program
- Identifying symptoms of incidents
- Conducting forensic investigations
- Logging and monitoring