11.8 STANDARD: SECURITY INCIDENT PROCEDURES

The Security Incident Procedures Standard has as single implementation specification, Response and Reporting, which is a required standard.

This standard requires a covered entity to create policies and procedures for reporting and responding to security incidents. Responding to and dealing with security incidents is generally referred to as 'Incident Handling' in the Information Security (InfoSec) industry. Some of the following information was taken from the SANS 'Incident Handling Foundations' course outline:

An 'Incident' is an adverse event in an information system, and/or network, or the threat of the occurrence of such event. An incident implies harm or the intent to do harm. Examples of an 'incident' include: unauthorized use of another user 's account, unauthorized use of system privileges, and execution of malicious code that destroys data, to name a few.

There is a difference between an 'incident and an 'event'. An ˜event' is any observable occurrence in a system or network, such as system boot sequence, a system crash, packet flooding, etc. All 'incidents' are composed of 'events' but not all events are incidents.

A covered entity needs to have proper procedures in place to know what to do when an incident occurs. Incidents will happen, it is just a matter of when. An incident handler reduces or minimizes harm.

'Incident Handling' then is an action plan for dealing with intrusions, cyber-theft, fires, floods, denial of service and other security related events. The covered entity must identify and respond to suspected or known security incidents, and mitigate (if possible) the harmful effects of known security incidents. In all cases, the incident handler must document security incidents and their outcomes .

Incident Handling is a security function all to its own. There are training classes that can be taken for those who want to be a 'Certified Incident Handler' and the art of handling an incident is well defined by InfoSec industry 'best practices'.

11.8.1 There are 6 steps in the Incident Handling process:

Preparation
Identification
Containment
Eradication
Recovery
Lessons learned

11.8.1.1 Preparation

The first step of Preparation is to develop a Plan. The Plan needs to include a policy of what to do when an Incident occurs, such as to notify police or watch the attackers , etc.

This Plan must receive management support because it will entail staff, tools, overtime, and other financial costs.

Team members need to be selected. In smaller hospitals and medical centers, the same IS/IT staff that runs the daily operations may be the Incident Team members . In other larger organizations, where incidents are a constant part of doing business, there may be a dedicated team of full-time staff to perform these functions.

The Team should identify specific contacts in senior management and the legal department, as well as law enforcement in advance, should an attack be severe. The Team should have an updated copy of the covered entity's disaster recovery plan, including checklists and procedures, and emergency communication.

Because anyone working under pressure in likely to make mistakes and forget even the simplest things, the Team should keep a written list of passwords and encryption keys in a safe place for use under the pressure of an incident.

11.8.1.2 Identification

Once an event happens, it is not an Incident until someone recognizes and identifies it. An alarm must be sounded, the Team called together to assess the situation and take the proper steps or give the all clear. Even when an event could be an incident, the Team member must be willing to alert the rest of the Team early enough to act in time, but not too early and sound a false alarm.

Some of the ways a IS/IT staff can begin to identify Incidents is by tracking trouble tickets at the helpdesk. Many Incidents affect many people, so multiple calls about the same subject from different people can point to a possible Incident.

Other sign of an Incident can include alerts by an Intrusion Detection System, unexplained entries in a log file, failed or unexplained events, system reboots or crashes, poor system or network performance, etc.

Once an event is identified, a primary handler should be assigned (unless there is only of you) to determine whether an event is an Incident. For legal purpose the Team must maintain a provable chain of custody of all evidence in case the matter goes to court . To do this, make a clean backup of the system and save the original hard drive.

11.8.1.3 Containment

Once of the statements in the Hippocratic Oath that physicians take is, 'Above all, do no harm.' The same could be said for an Incident Handler, they should not make things worse . The area and/or equipment should be made secure and a copy of all evidence should be made as well. The system should be pulled off the network if at all possible, to prevent a spread of the problem. Passwords should also be changed immediately, if the Incident involved unauthorized access and password compromise was possibly.

11.8.1.4 Eradication

The problem must be fixed before putting the system back on line. This does not mean simply reinstalling the Operating System. The Incident handler must determine cause and symptom of the attack in order to improve defenses in the future. If the vulnerability was previously unknown, it should be recorded and analyzed sufficiently to prevent a reoccurrence.

11.8.1.5 Recovery

The Incident Team or Handler must determine if there are the corrupted and compromised files and where these files are. Each potentially compromised machine must be tested and the regular user should give their approval that the machine is working correctly before putting it back on-line. Each of these systems should be monitored for possible re-infection. The entire Team should hold a follow-up meeting after every incident to review how the process worked.

11.8.1.6 Lessons Learned

The Team should make appropriate recommendations to management on how to better prevent future similar incidents, if possible. It is very important for a report to be written that shows a factual complete consensus amongst the Team in case the matter goes to court. The report should focus on improvements that can be made, any suggested change to Incident Handling plan, processes and procedures.