Weekly Update — Incident Response || Network Traffic Analysis
Welcome back to my weekly update. Here I talk about what I learned from my course and some online sources during the week. Last week I talked about Social Engineering, Malware, Web-based Exploits, and Threat Modelling. This week I’ll be talking about Detection and Incident Response.
Disclaimer: The information (most of the definitions) shared is based on my knowledge from the Google cybersecurity certification program on Coursera and some online articles and videos.
With the ever-evolving world of technology, there is a rise in security attacks, and new vulnerabilities are discovered and exploited every week. No matter how “prepared” an organization is or thinks they are, at some point, something might go wrong: it could be a data breach, ransomware attack, or a mistake by an employee. Incidents happen, and it’s up to the security team to effectively respond to security incidents.
It is important to note that all security incidents are events, but not all events are incidents.
An event is an observable occurrence on a network, system, or device. Example A user tries gaining access to their account but cannot remember their password, so the user requests a password reset and successfully changes their password. This is an observable event because password resets are logged in the organization’s system.
According to the National Institute of Standards and Technology, NIST, A security incident is an occurrence that actually or imminently jeopardizes, without lawful authority, the confidentiality, integrity, or availability of information or an information system; or constitutes a violation or imminent threat of violation of law, security policies, security procedures, or acceptable use policies. For example, a malicious actor trying to gain access to a user account, successfully initiated the password change request and changed the account password. This is an observable request and also a security incident because a malicious actor violated security policy to unlawfully gain access to an account that’s not theirs.
The NIST incidence response life cycle is a framework dedicated to incident response. It is a substep of the NIST CSF, which provides steps to respond to a security incident, they include
- Preparation
- Detection and analysis
- Containment, eradication, and recovery.
- Post-incident activity.
Just like detectives working on a case, security analysts are required to document their findings and evidence when investigating a security incident. This investigation reveals critical information about the 5W’s of an incident:
- Who triggered the incident?
- What happened?
- When the incident took place.
- Where the incident took place.
- Why the incident occurred.
Every security team needs an incident response plan. An Incident Response Plan outlines the procedures to take in each step of incident response, and elements of this plan include incident response procedure, system information, and other documents.
I learned about Incident Detection Systems (IDS), Incident Protection Systems (IPS), and Endpoint Detection and Response (EDR). Examples of these are Snort, Zeek, Kismet, Sagan, and Suricata. The IDS detection categories — true positive, true negative, false positive, and false negative. Alerts from these systems are sent to the SIEM (Security Information and Event Management) tool for further analysis.
Let’s talk about Network Traffic
Network traffic is the amount of data that moves across a network, while Network data is the data that is being sent across a network. Understanding how data should flow across a network, gives a better understanding of the expected network traffic at any given time. We can detect traffic abnormalities through observations to spot Indications Of Compromise (IOC) — observable evidence that suggests signs of a potential security incident. Tools like IDS and IPS are used to monitor traffic. Some network components that can be monitored include Flow analysis, Packet payload information, and Temporal patterns.
Packet sniffing is the practice of capturing and inspecting data packets that flow across a network. A packet capture, also known as a p-cap file, contains data packets intercepted from an interface or network. These packet captures can be further analyzed using network protocol analyzers such as tcpdump, Wireshark, and Tshark. By examining network traffic flows, network protocol analyzers can identify actions performed on a network. However, network protocol analyzers can also be used for malicious purposes. For example, malicious actors can use them to capture packets containing sensitive data, such as account login information.
Some of the uses of network protocol analyzers include:
1. Investigating network issues by monitoring networks.
2. Collecting network statistics such as bandwidth and speed to troubleshoot network performance issues, like slowdowns.
Tasks: I completed several tasks using Wireshark, a GUI-based tool, and tcpdump, a CLI-based tool, to inspect packets/network traffic of a network interface, applying basic filters.
As a network analyst, it is crucial to have access to reliable investigative tools that can provide insights into the activity happening on a network. Network protocol analyzers are one such tool, which can be used to view and analyze packet capture files. Through this process, you can gain a better understanding of network communications and identify potential intrusions, thus helping you defend against them. Overall, network protocol analyzers are a helpful resource for network analysts.
If you got to this point, you’re an MVP. Thanks for reading. Let’s discuss, exchange ideas, and connect in the comment section. Also looking forward to collaborations.
SEE YOU NEXT WEEK.
