What do you think?
Rate this book
Applied Network Security Monitoring: Collection, Detection, and Analysis
Applied Network Security Monitoring is the essential guide to becoming an NSM analyst from the ground up. This book takes a fundamental approach to NSM, complete with dozens of real-world examples that teach you the key concepts of NSM. Network security monitoring is based on the principle that prevention eventually fails. In the current threat landscape, no matter how much you try, motivated attackers will eventually find their way into your network. At that point, it is your ability to detect and respond to that intrusion that can be the difference between a small incident and a major disaster. The book follows the three stages of the NSM collection, detection, and analysis. As you progress through each section, you will have access to insights from seasoned NSM professionals while being introduced to relevant, practical scenarios complete with sample data. If you've never performed NSM analysis, Applied Network Security Monitoring will give you an adequate grasp on the core concepts needed to become an effective analyst. If you are already a practicing analyst, this book will allow you to grow your analytic technique to make you more effective at your job.
496 pages, Paperback
First published January 1, 2013
32 people are currently reading
286 people want to read
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 4 of 4 reviews
December 21, 2013
Update: I was contacted by the authors who were very kind and receptive to my review.
Mistakes and all will be documented at http://www.appliednsm.com/errata/.
Also, note that 100% of author royalties will go to charity.
--
I'm dividing this review into sections which focus on the good, bad, and the potential improvements.
For brevity and time I will comment with a simple sentence or two and then provide examples to justify my claims.
I will preface my review by saying that I've read just about all, if not all,
NSM books on the market, and I work with many of these tools daily.
The Good:
1. Easy to read and clear
2. Many tools are covered here that are rarely mentioned at all in other NSM books e.g. CIF, SiLK, Bro, Justniffer, Netsniff-NG
3. Section on writing Snort rules was very good w/ detailed examples of keywords and modifiers
4. At the time of writing, the best coverage on Bro available in a book. Highlights,
- Adding fields to logs
- Taking advantage of intelligence data with the Intel Framework
- Using the File Analysis framework e.g. extracting and writing files to disk
- Working with the Notice framework, including an explaination of hooks
5. The SiLK chapter was very good because it provides a large number of useful
query examples that can be applied to your network with little modification. Also,
the addition of a few graphing and plotting examples was novel.
6. The packet math section in the Packet Analysis chapter is something every
good introductory NSM book should have and most, if not all, are lacking.
7. Easy to follow along with SecurityOnion, and where the tools are not included
in the distribution e.g. SiLK, a how-to for installing them is given.
The Bad:
Some grammar mistakes and typos.
Pg. 55 - Last paragraph, comma aligned incorrectly,
The three most common vendors ,from most to least expensive, are...
Pg. 71 - First paragraph typo,
"In most instances, your sensor should not have unfettered Interner access"
Pg. 105 - First paragraph, "utilities" should be singular.
"In our testing, Netsniff-NG is the best
performing FPC utilities in this book when it comes to high throughput links."
Inadequate:
In Chapter 5 (FPC), I felt that there was too much of listing usage
options for each tool. Nearly half a page was given to these sections which
closely resemble the usage output of ``-h'', ``--help'', or the tool's manual
page. They were not identical because the author added an annotation here or there are
shortened the usage statement.
Technical errors
Pg. 94 - Second paragraph says that argus' ra uses BPF.
"...you'll probably find yourself making basic queries using only a read option
with a Berkeley Packet Filter (BPF) at the end."
The argus daemon uses the high-level BPF expressions available from libpcap but ra
(Read Argus) uses its own filter expressions *based* on libpcap's high-level BPF syntax.
This adaptation provide primitives for flow based expressions rather than packet
based expressions. It is also not the same thing as libpcap's high level syntax, and this point
is especially important for the book because more advanced BPF expressions like those
explained in the Packet Analysis chapter will not produce the desired results with ra e.g. 'tcp[13] = 2'.
Pg. 101 - Third paragraph,
"This command will begin capturing packets and writing them to a randomly named file in the current working directory,..."
Command given,
"dumpcap -i eth1".
In Linux, dumpcap writes to /tmp if the ``-w'' option is not used. On OSX,
it will write to /var/folders. The filename, on Linux, for the example given
by the author, is not random but of the format wireshark_$int_$timestamp_$uuid.
Since tshark and wireshark call dumpcap to perform packet capture on their
behalf, the unique file names dumpcap creates are used by the calling program.
Pg. 115 - Last paragraph, incorrect explanation of find command.
Command given,
"find /data/pcap -type f -mtime +60"
Quote,
"...in order to find files older than 60 minutes within the /data/pcap directory,
simply run the following command;"
The command given by the author will find on days, the default for -mtime, not minutes.
The -mmin option is used to work on minutes e.g. "find /data/pcap -type f -mtime +60"
Pg. 165 - Third paragraph, awk is not given an argument to its -F option, this command will err.
"grep 7100031 master_ioc_list.csv | grep sid | awk -F '{ print $11 }'"
Pg. 187 - Output file should be mdl.domainlist.set, not mdl.iplist.set. The name doesn't match command.
"Here, we provide rwsetbuild with the name of the input file, and the name of the output file, which is mdl.domainlist.set:"
Command text given,
"rwsetbuild mdl.iplist mdl.iplist.set"
Pg. 187 - Inconistent and incorrect usage of SiLK options --start-date and --end-date.
"rwfilter -start-date=$start -end-date=$end ..."
In the command text above the two options are missing the second dash (--start-date)
In other examples, the double dashed GNU long options form are used, this example deviates.
Pg. 380 - Fourth paragraph, incorrect explanation of BPF filter.
"This expression will match any packet with only the TCP RST bit set"
Expression given,
"tcp[13] & 0x04 = 4"
Because the binary AND (&) is introduced, the BPF expression will match any TCP segment who's code flags have at *least* the RST bit set e.g. it will match an odd packet with both the SYN and RST bit set.
Command typesetting
Note: This is a problem with the publisher.
At times it not easily discernable whether a command, option, or argument is seperated by a space.
Two other examples: the pipe character is much larger than any of the other command text and makes,
in my opinion, the command text look uneven and visually odd, the same reasoning can be applied to the hash character, or pound, which also looks alien and out of place.
Clarifications, Improvements, and Misc:
Pg. 56 - Performance unclear, depends on how much data e.g. 1Gb and 10Gb can be done.
"The traditional Linux network socket buffer is not suited to high performance
traffic analysis".
The mmap'd PF_PACKET kernel sockets are comparable in performance to PF_RING in transparent mode 0
which is what SecurityOnion uses. The Linux kernel also offers a socket option called PACKET_FANOUT
that allows the distribution of flows across sockets like PF_RING does for load balancing. I don't
know of any NSM tool that is taking advantage of it yet. This was only recently documented.
Pg. 104 - One of the things that sets netsniff-ng apart from other sniffers is its
offering of multiple I/O methods i.e. write, scatter-gather, and mmap.
Pg. 194 - Possibly unclear,
"This is done by editing /etc/nsm/sensor_name/snort.conf and uncommenting this line:"
I can see where this may be unclear to a new SecurityOnion user that they must replace sensor_name with $HOSTNAME-$INT.
Pg. 217 - Suricata is not covered in Port Variables section, only snort.
Suricata is covered in the IP Variables section before and in the subsection of
Defining Rule Sets along with Snort. Why the absence in Port Variables? I feel
that leaving this out makes the section incomplete.
Would I recommend this book to others? Yes.
Mistakes and all will be documented at http://www.appliednsm.com/errata/.
Also, note that 100% of author royalties will go to charity.
--
I'm dividing this review into sections which focus on the good, bad, and the potential improvements.
For brevity and time I will comment with a simple sentence or two and then provide examples to justify my claims.
I will preface my review by saying that I've read just about all, if not all,
NSM books on the market, and I work with many of these tools daily.
The Good:
1. Easy to read and clear
2. Many tools are covered here that are rarely mentioned at all in other NSM books e.g. CIF, SiLK, Bro, Justniffer, Netsniff-NG
3. Section on writing Snort rules was very good w/ detailed examples of keywords and modifiers
4. At the time of writing, the best coverage on Bro available in a book. Highlights,
- Adding fields to logs
- Taking advantage of intelligence data with the Intel Framework
- Using the File Analysis framework e.g. extracting and writing files to disk
- Working with the Notice framework, including an explaination of hooks
5. The SiLK chapter was very good because it provides a large number of useful
query examples that can be applied to your network with little modification. Also,
the addition of a few graphing and plotting examples was novel.
6. The packet math section in the Packet Analysis chapter is something every
good introductory NSM book should have and most, if not all, are lacking.
7. Easy to follow along with SecurityOnion, and where the tools are not included
in the distribution e.g. SiLK, a how-to for installing them is given.
The Bad:
Some grammar mistakes and typos.
Pg. 55 - Last paragraph, comma aligned incorrectly,
The three most common vendors ,from most to least expensive, are...
Pg. 71 - First paragraph typo,
"In most instances, your sensor should not have unfettered Interner access"
Pg. 105 - First paragraph, "utilities" should be singular.
"In our testing, Netsniff-NG is the best
performing FPC utilities in this book when it comes to high throughput links."
Inadequate:
In Chapter 5 (FPC), I felt that there was too much of listing usage
options for each tool. Nearly half a page was given to these sections which
closely resemble the usage output of ``-h'', ``--help'', or the tool's manual
page. They were not identical because the author added an annotation here or there are
shortened the usage statement.
Technical errors
Pg. 94 - Second paragraph says that argus' ra uses BPF.
"...you'll probably find yourself making basic queries using only a read option
with a Berkeley Packet Filter (BPF) at the end."
The argus daemon uses the high-level BPF expressions available from libpcap but ra
(Read Argus) uses its own filter expressions *based* on libpcap's high-level BPF syntax.
This adaptation provide primitives for flow based expressions rather than packet
based expressions. It is also not the same thing as libpcap's high level syntax, and this point
is especially important for the book because more advanced BPF expressions like those
explained in the Packet Analysis chapter will not produce the desired results with ra e.g. 'tcp[13] = 2'.
Pg. 101 - Third paragraph,
"This command will begin capturing packets and writing them to a randomly named file in the current working directory,..."
Command given,
"dumpcap -i eth1".
In Linux, dumpcap writes to /tmp if the ``-w'' option is not used. On OSX,
it will write to /var/folders. The filename, on Linux, for the example given
by the author, is not random but of the format wireshark_$int_$timestamp_$uuid.
Since tshark and wireshark call dumpcap to perform packet capture on their
behalf, the unique file names dumpcap creates are used by the calling program.
Pg. 115 - Last paragraph, incorrect explanation of find command.
Command given,
"find /data/pcap -type f -mtime +60"
Quote,
"...in order to find files older than 60 minutes within the /data/pcap directory,
simply run the following command;"
The command given by the author will find on days, the default for -mtime, not minutes.
The -mmin option is used to work on minutes e.g. "find /data/pcap -type f -mtime +60"
Pg. 165 - Third paragraph, awk is not given an argument to its -F option, this command will err.
"grep 7100031 master_ioc_list.csv | grep sid | awk -F '{ print $11 }'"
Pg. 187 - Output file should be mdl.domainlist.set, not mdl.iplist.set. The name doesn't match command.
"Here, we provide rwsetbuild with the name of the input file, and the name of the output file, which is mdl.domainlist.set:"
Command text given,
"rwsetbuild mdl.iplist mdl.iplist.set"
Pg. 187 - Inconistent and incorrect usage of SiLK options --start-date and --end-date.
"rwfilter -start-date=$start -end-date=$end ..."
In the command text above the two options are missing the second dash (--start-date)
In other examples, the double dashed GNU long options form are used, this example deviates.
Pg. 380 - Fourth paragraph, incorrect explanation of BPF filter.
"This expression will match any packet with only the TCP RST bit set"
Expression given,
"tcp[13] & 0x04 = 4"
Because the binary AND (&) is introduced, the BPF expression will match any TCP segment who's code flags have at *least* the RST bit set e.g. it will match an odd packet with both the SYN and RST bit set.
Command typesetting
Note: This is a problem with the publisher.
At times it not easily discernable whether a command, option, or argument is seperated by a space.
Two other examples: the pipe character is much larger than any of the other command text and makes,
in my opinion, the command text look uneven and visually odd, the same reasoning can be applied to the hash character, or pound, which also looks alien and out of place.
Clarifications, Improvements, and Misc:
Pg. 56 - Performance unclear, depends on how much data e.g. 1Gb and 10Gb can be done.
"The traditional Linux network socket buffer is not suited to high performance
traffic analysis".
The mmap'd PF_PACKET kernel sockets are comparable in performance to PF_RING in transparent mode 0
which is what SecurityOnion uses. The Linux kernel also offers a socket option called PACKET_FANOUT
that allows the distribution of flows across sockets like PF_RING does for load balancing. I don't
know of any NSM tool that is taking advantage of it yet. This was only recently documented.
Pg. 104 - One of the things that sets netsniff-ng apart from other sniffers is its
offering of multiple I/O methods i.e. write, scatter-gather, and mmap.
Pg. 194 - Possibly unclear,
"This is done by editing /etc/nsm/sensor_name/snort.conf and uncommenting this line:"
I can see where this may be unclear to a new SecurityOnion user that they must replace sensor_name with $HOSTNAME-$INT.
Pg. 217 - Suricata is not covered in Port Variables section, only snort.
Suricata is covered in the IP Variables section before and in the subsection of
Defining Rule Sets along with Snort. Why the absence in Port Variables? I feel
that leaving this out makes the section incomplete.
Would I recommend this book to others? Yes.
September 17, 2018
Amazing framework for going from 0 to an enterprise ready monitoring solution and team philosophy. This book might not be the most useful guide for an enterprise whose infrastructure is mostly in the cloud, but the ideas here I believe are fundamental to any strategy mimicked in the cloud.
November 15, 2017
Adds little to the classic book on this subject from TaoSecurity
November 30, 2014
Great book! If you do or interested in Incident Response and general Blue Team kind of work it is a must read.
Displaying 1 - 4 of 4 reviews