In Part 1 we defined data incident management and examined how to prepare for incidents when they occur. In this article, we continue the series by examining how to prevent data loss and network outages. The methods of detecting, analyzing, and reporting data issues to recovery teams are explained.
Types of Data and Network Security Controls
Detection of computer security incidents requires the implementation of various types of controls - physical, logical, and administrative. Each of these control areas provides layered support to the others. In other articles, I described many of these controls in detail, including,
- Motion detectors
- Smoke and fire detectors
- Security cameras
- Sensors and alarms
- Intrusion detection systems
- Intrusion prevention systems
- Rotation of duties
- Security reviews and audits
- Mandatory vacations. Mandatory vacations serve the same purpose as rotation of duties. Someone else must look at work the vacationing employee has been doing.
- Performance evaluations
- Background investigations
Analyzing Data and Network Security Issues
Once one of your controls provides evidence of a security incident, it’s important that you assess what the evidence means. Disconnecting your data center from the network because you get a couple of log entries indicating a malware attack may be OK if you’re actually under attack. But what if it was just an explainable and acceptable network anomaly? Explaining loss of data or serice delivery may be difficult if you haven’t practiced due diligence before making this kind of decision. Due diligence includes the following steps:
- Perform an initial assessment to determine the type of incident
- Develop an action plan to contain and eradicate the threat
- Document all activities associated with the incident
Notifying Network and Data Recovery Teams
Once you confirm that data loss or network outage is occurring, or has occurred, immediately notify the appropriate IRT. The team’s initial response should include a high level assessment of the following:
- Initial evidence, including logs and alerts
- The general state of the system allegedly affected
- The general state of the network overall
This is a high level assessment. Digging too deeply at this stage might result in unnecessary delays leading to increased business impact. Using personnel who are familiar with the system, facility, data, or network being assessed is critical. Individuals who are familiar with day-to-day characteristics of a potential target should be capable of quickly completing the initial assessment.
Documenting Data Security Response Activities
Along with the initiation of the initial assessment, the response team manager should begin documenting all response activities. This documentation will track details about network or data security activities that you can use in post-incident assessments. It also provides a historical record of findings and actions taken, which is often valuable when the exact nature of the attack or outage is hard to identify. The following should be included in your documentation:
- Current status of the incident – This is normally kept in a running log. The log is a valuable tool for tracking the activities of the IRT, the way in which the attack or outage evolves, and for reporting status to senior management.
- Summary of the incident
- Actions taken by all members of the IRTs
- Contact information for all involved parties
- List of evidence gathered
- General observations
- Pending activities – These should be prioritized based on the criticality of the resources affected; in other words, assess the business impact of not performing each activity on your list. For example, if you need to run payroll the day of the outage, activities surrounding recovery of the payroll system will take precedence over just about anything else.
Again, perform just enough analysis work to get a general understanding of what data issues you’re facing. There’s a balance between too much data analysis and not understanding the incident well enough to effectively contain it.
In Part 3, we continue the series with a look at data loss prevention and incident containment.