What’s surprising then is that even in today’s increased regulatory environment, there are still healthcare organizations large and small that take the other route--reacting to each event with untrained staff and undocumented, ad hoc procedures, which ultimately waste both time and money. That’s a missed opportunity when you take into account that these programs allow organizations to apply consistency and efficiency to the chaos associated with security incidents as well as streamline responsiveness and cut costs by ensuring the basics are addressed in their incident response program.
In order to ensure your incident response program is effective, it’s important to assess your current capabilities, identify gaps and opportunities for improvement, and execute a mitigation plan.
There is ample literature and documentation available which provides guidance in building and managing an incident response program. The National Institute of Standards and Technology’s (NIST) SP 800-61 Rev. 2 Computer Security Incident Handling Guide is an excellent benchmark to measure against because it is an up-to-date, relevant best practice reference.
Here are a few basic elements you should look for in your gap assessment:
- Incident Response Policy: Ensure an incident response policy has been developed and documented that includes the overall objectives and scope as well as a section that assigns responsibility for identifying, documenting and ensuring compliance with the relevant regulations and legal requirements. The policy should set clear direction and demonstrate executive management’s support. The policy should also define the term “incident” and establish definitions that are usable at your organization. It should also reference the establishment of an incident response team that effectively and consistently responds to such events as personnel actions, lawsuits, security incidents and regulatory issues impact the organization.
- Incident Response Procedures: Ensure procedures are implemented, supported by technology and based on the incident response policy. Incident escalation triggers need to be defined and based on asset prioritization, data, system or application type or by the results of an incident analysis. The procedures should specify the types of responses and techniques used, such as:
- Acquisition and analysis of data
- Referral to law enforcement
- Escalation of incidents
- Reporting of findings
Incident identification and prioritization needs to be defined as well. This would include incident alerts from systems such as IDS/IPS and firewalls as well as confirmation that there are appropriate routing procedures for evaluation and validation. Specifically verify that procedures exist for:
- Who needs to be notified when an incident occurs
- Forensic acquisition, analysis and handling of data, including the platforms in your IT environment such as Windows, Unix and Linux
- The review and analysis of physical security logs to detect violations that correspond with the incidents
- Corrective action and remediation that determine the actions required for compromised systems. This includes patching, reconfiguring of settings, reloading data from backup media and complete system restores
- Establishing agreements with outside organizations, business partners and associates using Service Level Agreement (SLA)-type language that addresses such issues as how incidents are handled, the notification and required response times, designated contacts and communications with the public
- The development of an executive report of the investigation and its findings
- Incident Response Roles and Responsibilities - One of the primary elements of an effectively managed Computer Security Incident Response Team (CSIRT) is the definition of their roles and responsibilities. Confirm incident response roles and responsibilities are identified and documented. This should include assigning the level of authority for lead and supporting roles to make critical decisions such as shutting down network connections, acquiring additional resources and taking systems offline or wiping them.
Healthcare organizations often lack the understanding of who should lead an incident response investigation, who should be involved, who has decision-making authority and what roles should be played. By documenting and verifying that staff members understand their roles and responsibilities, the organization can gain confidence that investigative issues are being addressed appropriately by the CSIRT.
- Incident Response Training: Ensure CSIRT members are properly trained in incident response competencies by reviewing the results of your skills assessment and addressing any gap areas that are identified. Often, healthcare organizations designate personnel to lead an incident response who have no previous investigative experience. Defining and developing training plans would improve CSIRT member knowledge regarding proper principles and techniques. Enhancing the skills and knowledge of the staff will provide improvements to the organization’s incident response approach through better execution and decision-making. Training course examples include tools for incident response, threat analysis, forensic techniques, chain-of-custody processes and legal standards.
- Incident Response Metrics Reporting: Ensure the implementation of a process for collecting, maintainingand reporting incident response metrics and trend analysis. Healthcare organizations typically lack an effective way to capture and track accurate incident metrics. If they do have one in place, it is usually a subset of all the incidents occurring within the organization.
An Incident Response Tracking database should be created and maintained in order to track all identified incidents. By centralizing all the incident response data collection and management, the resulting metrics and trending provide a more accurate picture of your organization’s risk landscape. It also allows you to more effectively identify the need for preventive and detective security controls and countermeasures. The security metrics should be designed so you can easily determine whether or not the program was meeting your organization’s objectives. Security metrics can be developed based on a range of attributes including quantifiable, qualitative, tangible and intangible.
- Incident Response Awareness Training - Confirm there is an awareness program in place for management, IT staff and the general user population. Users need to know how to identify an incident and where to report it so create a training and awareness that addresses the varying needs and sensitivities for all users, with focused sessions for specific audiences. Management has a tendency to get anxious once informed about certain incidents. By developing and implementing an awareness training program, the organization increases the knowledge of every member, which allows them to more fully understand the importance of incident response, their individual responsibilities and how they can act accordingly.
- Periodic Risk Assessments - Risk assessments are an integral component of any incident response program do make sure these are conducted periodically. This is crucial for three reasons:
- Threats are constantly evolving that can impact your organization’s information assets.
- Systems and applications are being introduced or continually changing with some lacking proper security controls.
- Then, there is the ever present and fallible nature of humans.
All of this adds up to a dynamic security environment that requires periodic and consistent revisiting to ensure threats and vulnerabilities are identified as early as possible and appropriate mitigation measures can be taken immediately. The risk assessment should include such areas as an incident’s potential impact on the organization, liability from business associates and legal compliance with regulatory requirements and standards.
Security incidents can be costly to any business. A gap assessment can determine if your organization has the marks of an effective incident response program to help prevent losses, prepare you for the next incident and ultimately save your organization from taking a massive hit in its wallet.