Essentials of Incident Response: 01. Preparation – Technology

23 Feb Essentials of Incident Response: 01. Preparation – Technology

This blog series has been updated here.

This is the last of a 3-part series on the role of Preparation in the Incident Response process. The first two parts covered People [1] and Process [2]; this part addresses the role of Technology in Preparation. Further posts will cover the remaining 5 steps of the Incident Response process.



At the most basic level, preparation requires knowledge of the normal static and dynamic states of your network – i.e., knowing what normally *exists* on your network, and what normally *happens* on your network. Once you have the baseline, it is possible to monitor for deviations from that baseline.

Hardware inventory

The most fundamental preparation is simply to have an accurate inventory of hardware on the network, including the logical and physical location of each device. This is also the first item on the list of Critical Security Controls for Effective Cyber Defense [3]. Organizations can implement this control using a combination of an automated asset inventory discovery tool and passive tools that identify devices by their traffic. The inventory should include every device that has an IP address on the network – desktops, laptops, servers, printers, routers, switches, firewalls, NAS, VoIP devices, BYO devices, virtual addresses, etc. Some enterprise-level systems will maintain the inventory in an integrated database; smaller enterprises may maintain the database of devices separately.

Network populations are not static; devices come and go during normal operation as well as during malicious activity. For this reason, it’s important to update the inventory as part of normal business changes. For instance, procurement processes should include updates to the inventory. DHCP logging, Network Access Control (NAC), and 802.1x authentication can be useful as well. Like all controls, this one should be tested periodically, for instance by connecting a new device to the network, and assessing how long it takes to identify and quarantine the unknown device.

Software Inventory

In addition to an actively managed hardware inventory, it is critical to maintaining an actively updated inventory of authorized software on the network. Beyond the obvious role in software license and patch management, properly managed control of software can substantially reduce the attack surface for the environment. Indeed, application whitelisting is one of the 4 most effective steps to reducing cyber intrusions, as determined by the Australian Signals Directorate [4]. This control can be implemented using technical means such as a whitelisting technology, or by restricting users’ ability to install software, and restricting allowed software to a specific list of applications required for each type of system.

Network Monitoring

Once you have established a reliable list of your network components, it is critical to creating a baseline of what those components are doing. In keeping with a “defense in depth” approach, most networks will be architected to permit monitoring both at endpoints and chokepoints within the network. Endpoint devices will likely have a host firewall/IDS, antivirus, and perhaps application control such as whitelisting. Network devices may also have a local protective capability, as well as logging and alerting functionality. Firewalls and various proxies are also capable of producing logs and alerts. All these logs and alerts should be collected and maintained according to a formal retention schedule.

The sheer volume of log data available can be overwhelming, resulting in a situation that former NSA official Tony Sager calls “The Fog of More” [5]. Logging policies should address both the retention schedule, and whether to collect and store full packet capture or some subset of information such as NetFlow data. A full discussion of Network Monitoring for Security is far beyond the scope of this post; see the reading list below for more information.

Responder Tools

Lastly, it is critical that incident responders have a collection of tools, and the training to use them. Depending on the expectations of the internal team, this could include tools such as dcfldd and Volatility for acquiring and processing disk and memory, or commercial tools such as X-Ways Forensics, EnCase, F-Response, FTK, etc. Workflow and task management should be considered as well; in a compromise situation, normal communications channels should be avoided, and management will need regular reports on current status.

The next entry in the series will cover step 2 in the process – Identification. Your comments and suggestions are welcome; feel free to email me at rdavidson AT syncurity dot net.

1.  Syncurity Networks, “Essentials of Incident Response: 01. Preparation” []

2. Syncurity Networks, “Essentials of Incident Response: 01. Preparation – Process” []

3. Council on CyberSecurity, “Critical Security Controls for Effective Cyber Defense”, v5.0 []

4. Australian Government, Department of Defense, “Top 4 Strategies to Mitigate Targeted Cyber Intrusions”, []

5. Sager, Tony, “The ‘Fog of More’ – A Cybersecurity Community Challenge”, delivered at RSA 2014, San Francisco CA, []

For further reading and information on network monitoring, see:

NIST Special Publication 800-137, “Information Security Continuous Monitoring (ISCM) for Federal Information Systems and Organizations” []

Sanders, Chris and Jason Smith, “Applied Network Security Monitoring: Collection, Detection, and Analysis”, Syngress 2013. []

Bejtlich, Richard, “The Practice of Network Security Monitoring: Understanding Incident Detection and Response”, NoStarch Press, 2013. []

SANS Course SEC511, “Continuous Monitoring and Security Operations”, []

Copyright 2015, Ray Davidson and Syncurity Networks

No Comments