This is a two part questions. First I will need the discussion question answer which will be below in bold, 300 words APA format. After that is completed I will extend the time and will need the discussion responses answered. For those response I will need three responses of at least 175 words each.
Describe and interpret the deployment considerations involved with using network security monitoring products to obtain full content data.
I hope you are all having a great start to your week two of this course. This week we are talking about a really important topic such as deployment considerations when it comes to network security monitoring. As I much experience with network forensics and tools such as WireShark, the seer amount of data that can be captured can be very overwhelming.
The first consideration that I would take into account would be the location of which the network security monitoring begins. As we place it outside on the network boundary, companies will be capturing all data that is coming into and out of its network. As we can have more than one network security monitoring tool, there can be different rules that can placed on the networking tools to ensure the proper secure monitoring of the network. As we work in from the firewall, we are able to implement stricter controls to ensure that the more sensitive information systems are properly secure but also being properly monitored. There are many devices out there from different vendors that will allow the organization to fully meet the needs they are looking for.
Once we have a placement planned out, we are able to determine what type of network data that we are wanting to capture. We have the options of full content data, session data, and statistical data. Full Content Data is the form that is most flexible when it comes with monitoring network security. It offers full detailed captures of the network. Once a full content data capture is done, it can be separated into session, alert, and statistical data. Another consideration to keep in mind is the amount of space that you have available for when doing a full content data capture. Even a small organization can produce a large amount of network traffic that is being captured. Being able to have the ability to categorize what is captured in network full content data capture will allow for the best results to be recorded and analyzed.
Bejtlich, R. (2004). The Tao of Network Security Monitoring: Beyond intrusion detection. Boston, MA: Addison-Wesley.
Phatak, P. (2011, June 1). Best Practices in Network Security Monitoring. Retrieved March 9, 2020, from https://opensourceforu.com/2011/06/best-practices-…
From a tool agnostic perspective, the deployment considerations include the perimeter, wireless zone, demilitarized zone, and intranet (Bejtlich, 2005). Of the tools mentioned in this week’s reading, I am only familiar with the Snort and Wireshark network security monitoring products. I have some limited experience with Suricata too. Of all of these tools, Snort is the only one that I have any extensive experience with. Snort is a free, open source network intrusion system, which is one of the primary reasons I am more familiar with this tool than with other tools (Snort, 2020). Snort uses a rules structure to look for patterns within the network traffic. I would consider this tool as being able to examine full content data as it examines the raw traffic data.
There are a couple of deployment considerations for Snort. Most of these deployment considerations relate to implementing its rules. Enabling all rules will almost certainly kill system performance, and probably is not needed (Rapid7, 2016). For example, if you are working with Windows systems, then you would only need to enable to Windows-based rules. Similarly, if you have a network backup server, if you have rules enabled on the network backup server, you are again going to kill system performance. Some other Snort considerations; albeit slightly minor, include that it is still a single-threaded application and it requires root privileges in order to open the network interface (Ghafir, Svoboda, Hammoudeh, & Prenosil, 2016). After Snort opens the network interface though, it is possible to configure it to revert to a non-root user; however, this is not an out-of-the-box function. Additionally, this week’s reading discussed that with a poorly written rule, you have the possibility of having normal network activity be flagged as suspect or malicious (Bejtlich, 2005). If this happens, then one would need a large number of analysts to determine whether the network traffic is indeed malicious, or whether it has been inaccurately flagged. Since I have never deployed this technology on a large, or even a small network, I do not have much expertise in this area. However, I would assume that there is a middle ground here between flagging too much and requiring additional manpower to manually review, and not flagging enough and risking malicious traffic entering the network.
While this week’s assignment is specific to computer networks, I would also like to try and fit this into my everyday job of microelectronics/hardware assurance. With that said, it is not necessarily a one for one translation. If I were to answer this question to microelectronics, I would relate it to device using a co-EMIB technology, which uses two Embedded Multi-die Interconnect Bridge links, or another type of multi-chip module device. Co-EMIB is easier to speak against though as it allows for some extraordinary large heterogeneous packages that could include a dozen chiplets that will serve as our ‘network’ in this example (Verheyde, 2019). Much like securing a larger network, one would need to secure and authenticate the individual chiplets in the co-EMIB device. If I was designing a device, I would design so one chiplet’s function is to verify the other chiplets (e.g., handshake), as well as ensuring that secure boot has been enabled on the programmable logic chiplet. From a perimeter standpoint, there would be two primary considerations. Firstly, one would need to consider the possibility of an antenna that has been malicious inserted into the interconnect that transmits outside of the device. There are not any easy ways to do this post-fabrication in a non-destructive manner. Examining the interconnect substrate prior to device customization and testing would probably be the best mitigation as this can still be performed in a non-destructive manner at this stage. Side-channel vulnerabilities would be the second perimeter consideration. Enabling secure boot is only a partial fix to the problem, and for most situations, you are left original equipment manufacturer’s anti-side channel mitigations. The good news is that leading-edge devices have some fairly good anti-side channel mitigations, at least for now (Lu, Kenny, & Atsatt, 2019) (Peterson, 2018). Altering the chiplet configuration or the type of chiplets used could also aid in this; however, that seems like a bit of a drastic approach to take.
Bejtlich, R. (2005). The Tao of Network Security Monitoring. Boston: Addison-Wesley.
Ghafir, I., Svoboda, J., Hammoudeh, M., & Prenosil, V. (2016). A Survey on Network Security Monitoring Implementations. 4th International Conference on Future Internet of Things and Cloud Workshops (pp. 77-82). Vienna, Austria: IEEE.
Lu, T., Kenny, R., & Atsatt, S. (2019, May 10). Secure Device Manager for Intel® Stratix® 10 Devices Provides FPGA and SoC Security. Retrieved from Intel Corporation: https://www.intel.com/content/dam/www/programmable…
Peterson, E. (2018, September 14). Developing Tamper-Resistant Designs with UltraScale and UltraScale+ FPGAs. Retrieved from Xilinx: https://www.xilinx.com/support/documentation/appli…
Rapid7. (2016, December 9). Understanding and Configuring Snort Rules. Retrieved from Rapid7 Blog: https://blog.rapid7.com/2016/12/09/understanding-a…
Snort. (2020). Snort FAQ. Retrieved from Snort: https://www.snort.org/faq/what-is-snort
Verheyde, A. (2019, July 11). Intel Reveals Three new Cutting-Edge Packaging Technologies. Retrieved from Tom’s Hardware: https://www.tomshardware.com/news/intel-packaging-…
Our textbook’s first few chapters covered very basics of network security monitoring (NSM): the “collection, analysis, and escalation of indications and warnings to detect and respond to intrusions (Bejtlich, 2004).” Intrusion Detection & Prevention Systems (IDS/IPS) play a key part in overall NSM. With IDSs, we general focus on monitoring real-time events for unusual/abnormal activity i.e. a possible unwanted intrusion. These intrusions can be detected by referencing databases of commonly known attacks (aka signatures) or behaviors (e.g. network activity beyond a normal baseline of operations). IPSs go one step further and typically block intrusions based on said signatures (Chapple, Stewart & Gibson, 2018). In the reading, Bejtilch (2004) specifically refers to NSM being more than simply an IDS/IPS – NSM expands itself to the collection of tools and products (in various deployments) to adequately leverage indications and warnings (I&W) and counter intrusions.
Basic deployment considerations include a Perimeter, Wireless Zone, Demilitarized Zone and Intranet – all of which generally rely on switch utilization and one or more firewalls for a particular zone (Bejtilch, 2004). Firewalls are cornerstones of network defense – you can set rules to limit inbound and outbound traffic. In the case of the basic zones/deployments, you can also control traffic flow between said zones via firewall. Perimeter zones are the least secure and in closest proximity to the wild west which is the Internet. DMZs (in a sense) prepare and quarantine parts of your network you most expect to be attacked the most (e.g. e-mail, web servers, DNS, etc.). At the time of writing, the reading suggested Virtual Private Networks (VPNs) to add extra security layers to wireless hosts, although wireless encryption standards have made strides since 2004. Logically, Intranet deployments are encouraged for protecting and monitoring your most trusted assets, especially from insider threats (Bejtilch, 2004).
Bejtilch (2004) explicitly reminds us in the reading that NSM is more about monitoring than it is access control – although the deployments and tools available allow us plenty of flexibility with the latter. NSM relies on tools to collect and analyze I&Ws in the form of data. This data can be described as alert data, session data, statistical data and full content data (FCD). FCD is considered ‘the most flexible form of network-based information,’ because (as the name implies) every aspect of data in captured network packet is available for collection and analysis (Bejtilch, 2004). Utilizing tools that can capture FCD allows NSM analysist to draw different types of relevant data categories such as session data, ‘a summary of a packet exchange between two systems (Bejtilch, 2004).’ Some NSM products that can capture FCD include tcpdump and Snort – these tools I have had personal experience working with in my Air Force Career. Utilizing tcpdump in a DMZ for example can capture large amounts of network packet data – data a skilled analyst may need to filter through with customized scripts. One of the downsides of FCD capture is cost – drives capable of large amounts of data storage can run companies dry. A company or business may tailor only certain parts of the NSM deployments to capture FCD to save costs (Sanders, 2011).
During research, I found a blog from our reading’s author where he commented on FCD considerations. Bejtilch (2012) encourages users to be deliberate when utilizing full packet capture, aiming to ‘collect where you can see the true Internet destination IP address for traffic of interest, and where you can see the true internal source IP address for traffic of interest.’ Based on this advice, I’d assume it’d be wise to choose FCD capture for somewhere other than perimeter zone if you had limited storage resources…it’s pretty easy to mask your IP on the Internet!
Thanks for reading and good luck in the coming weeks. I look forward to reading everyone’s posts.
Bejtlich, R. (2004). The Tao of Network Security Monitoring. Boston: Addison-Wesley.
Bejtlich, R. (2012). Why collect full content data? TaoSecurity: Richard Bejtlich’s blog on digital security, strategic thought, and military history. Retrieved at https://taosecurity.blogspot.com/2012/11/why-colle…
Chapple, M., Stewart, J. M., & Gibson, D. (2018). (ISC)² CISSP Certified information systems security professional: Official study guide. Indianapolis, IN: John Wiley & Sons.
Sanders, C. (2011). Using application layer metadata for network security monitoring. Chris Sanders. Retrieved at https://chrissanders.org/2011/09/using-application…