Incident Response Use Case ExamplesIncident Response Use Case Examples
The following use cases provide examples of an analyst using NetWitness to quickly respond to incidents, identify threats, and take action to reduce or eliminate the ability of threat actors to compromise valuable information in the corporate network.
Use Case #1: UEBA Anomalous User ActivityUse Case #1: UEBA Anomalous User Activity
An analyst named Chris logs in, goes to the Incidents List view, and uses the filters on the left-hand side to look at all of the incidents assigned to her. In the list, she notices an incident that she has not yet reviewed (status is Assigned) and opens the incident.
In the Incident Details view, the analyst sees a timeline of contributing events (Indicators panel) on the left, a visualization of the entities involved in the middle, and additional panels on the right where she can keep track of notes and tasks during her review.
Chris uses the Indicators panel to get finer detail on the events that lead to this incident being created. Clicking the "User Entity Behavior Analytics" link in the Indicators panel exposes the analysis that was done and the anomaly that was detected on the user account "Jonathan Sheppard (jsheppard)." The User Entity Behavior Analytics panel below shows an overall risk score of 160, details the Windows events that contributed to the severity, and shows the actual anomaly in user account changes attributed to this user. She can explore the data in as much depth as required to help validate and understand the alert.
In the Events List, Chris can even inspect the details of the individual log events involved.
During her review and investigation, she can update the incident with her notes, as well as create and assign tasks for herself or other analysts.
To remediate the incident, Chris opens a task for the administrator (admin) to suspend the jsheppard account.
Use Case #2: Encoded Webshells DetectedUse Case #2: Encoded Webshells Detected
Analyst Chris logs in, looks at all of the new incidents that have not yet been assigned to anyone, and notices a highly critical incident "Encoded Webshells Detected."
Chris decides to assign this incident to herself and investigate it.
At first glance using the visual summary, Chris can see a couple of specific Event Stream Analysis alerts that kicked off this incident, and the entities associated with the alerts. She sees that a public IP address (xxx.xx.xxx.248) has been detected as interacting with a webshell on the internal web server 192.168.31.20. It looks like the suspicious request was made to the file email.aspx. She dives in to investigate.
By drilling into the indicator (alert) on the left-hand side, Chris can view the entire list of events associated with the incident and all of the metadata generated by the system, including details about the connections between the external and internal host. She notices that the type of data in this case is "Network," meaning that these events were generated by the full packet capture component of NetWitness.
While the metadata associated with these events does look suspicious to Chris, she wants to investigate even deeper to see what is going on. To do this she can drill into the raw packet reconstruction of the HTTP sessions simply by clicking the "Network" link in the Indicators panel on the left-hand side.
From this deep dive, Chris can examine the raw payload of the suspicious connections and can easily see the strange nature of this request. In the request payload she can see a strange looking request, but most alarmingly, once she scrolls down to the response portion she can see the information that her web server is sending back out to the suspect external IP address.
Chris sees what looks to be a directory listing in the packet data, which is not something she would expect from normal web site communications. With this information, she confirms that this is indeed a malicious webshell that has been installed on the internal web server.
From here, Chris can take a number of actions. She can journal her confirmation, assign a task to another user to handle the incident from there, or she can expand her investigation to look for any other activity that has been associated with the malicious external IP address. Chris does this by left or right click the IP address to open a context tooltip and pivoting into Investigate.
This pivot brings Chris into another part of the NetWitness interface where she can perform free-form search and analysis outside of the incident.
In this case she did not uncover anything other than the same network events that were part of the original incident, which is a good step in validating the isolated scope of the incident. If, however, she were to find other interesting events across any log, network, or endpoint data in the system, she could easily add those events into the incident to keep track.
