Just as I did with SIEM and DLP, I wanted to explore the process (practice, procedure, workflow) side of network forensics tooling. So, my question is the same: what processes/practices are absolutely essential for an effective use of a network forensics tool?
I can think of a few off the top of my head:
- incident response process (and, yes, I cringe as I am writing this as it is so painfully obvious)
- indicator analysis process which essentially means investigating a clue reported by a 3rd party, logs, NIPS alerts, etc
- process for defining and refining capture policies
- process for defining and refining detection alerts (if the tools is utilized for monitoring)
- data exploration process aimed at understanding what is going on, was going on, which may be based on a threat hypothesis or other suspicions (see additional details on this here)
Other ideas!? Do you think #5 is the same as #2 perhaps?
P.S. BTW, check out this great piece called “The Security Processes You Must Get Right.”
P.P.S. While we are on the subject of network forensics, check out this excellent piece by a true network forensics literati.
Related posts:
The Gartner Blog Network provides an opportunity for Gartner analysts to test ideas and move research forward. Because the content posted by Gartner analysts on this site does not undergo our standard editorial review, all comments or opinions expressed hereunder are those of the individual contributors and do not represent the views of Gartner, Inc. or its management.
Comments are closed
3 Comments
Probably part of nbr 5 but look at the outliers. What is an outlier in your company? The 1%?
Hi,
I believe this would also come along with other processes, or may be included in some of the above mentioned processes.
a. Process/Policies for retention
– retention of data captured (logs/packets)
– retention of evidence
b. Process/Policies for retrieval
I also think below mentioned points would be required, possibly these may be included in above mentioned process.
– Defining/Applying context to the captured data (i.e. either business context, technical context, or anything useful) – Possibly this is covered in #5
– Process for defining a baseline for security alerts (#4, #2)
With Regards,
Nrupak D Shah
@steve That’s a good point – whatever outliers you define (rare, first-time-seen, occurring in unique combinations,etc) are likely to be reviewed in #2, but what is an outlier defined in #5 based on explorations.
@nrupak Thanks for a great comment. I like a separate process for *evidence* retention. Will check whether any NTF users have that separated as such.