As we explored in the article titled “The Importance of an Incident Response Plan”, one of the most cost- effective mitigation tools against cybersecurity breaches is the incident response (IR) plan. In addition to the IR plan, having a formal IR team periodically testing the developed IR plan was shown to boost this effectiveness, providing medical device manufacturers with solid footing for an effective response to an incident.
According to the National Institute of Standards and Technology (NIST)1, establishing an incident response policy should include the following actions:
- Creating an incident response plan
- Developing procedures for performing incident handling and reporting
- Setting guidelines for communicating with outside parties regarding incidents
- Selecting a team structure and staffing model
- Establishing relationships and lines of communication between the incident response team and other groups, both internal (e.g., legal department) and external (e.g., law enforcement agencies)
- Determining which services the incident response team should provide
- Staffing and training the incident response team
In this article, we will outline an incident response plan development methodology to provide a solid starting point for crafting a plan that fits your specific organizational need. With proper scoping, a well-developed incident response plan can start small and scale as required. So, no matter where you are in your risk mitigation journey, the important thing is to start. By taking a small first step, you will be on your way. “Well begun is half done”, according to Aristotle. Our mission is to help you begin well. Let’s get started.
What Does an Incident Response Plan Look Like?
Well, not all the same. Each organization should develop an IR plan that fits their needs and is based on the size and structure of their organization. An additional consideration is the resource availability to develop and maintain the plan. Given the evergreen nature of the IR plan, the initial development cost is only part of the overall resource budget required. In any case, all functional IR plans do share some common characteristics, and we’ll explore those next.
Elements of an Incident Response Plan
Team
- A cross-functional group that is aligned with the organization and mission
- Clear roles and responsibilities – during a crisis and in peacetime
Communication
- Processes and procedures that support information sharing with internal and external parties
Visibility
- Tools and technology that enables the team to monitor threats and vulnerabilities
Intelligence
- Information and knowledge that informs security planning and vulnerability management
Response
- Identification, investigation and remediation of incidents
Metrics
- Objectively measuring response effectiveness and efficiency
- Tied to desired organizational security goals and easily measured
Team
The IR team should include representatives of the various device security stakeholders in your organization. Depending on the size and structure of the organization, the composition of this team will vary. In large organizations, the team might consist of the following functions – Device Cybersecurity, IT Security, Legal, Corporate Communications, Customer Support, Compliance, Regulatory. In smaller organizations, there might only be a handful of resources available to respond to incidents. In either case, it has been shown conclusively that organizations with an IR team following an IR plan are the most efficient and effective in responding to security incidents. NOTE: if possible, identify backup individuals for key roles on the team.
Communication
Internal communication should be straightforward once the stakeholders are identified. This can be accomplished in a group setting, via email, individually or any combination. However, the plan should contain sufficient details regarding communication (who, what, how) so that it can be followed easily with little opportunity for error.
External communications are a little more convoluted. Understanding the rules, such as the HIPAA Breach Notification Rule, is not always straightforward. It is highly recommended that you review the applicable rules and integrate those requirements into your communication plan, ahead of an incident. Putting this formal procedure in place will save a tremendous amount of response time, in the event of an incident. A couple of recommended resources:
HIPAA Breach Notification Rule, 45 CFR 164.400-414, https://www.hhs.gov/hipaa/for-professionals/breach-notification/index.html
What are the HIPAA Breach Notification Requirements?, HIPAA Journal, https://www.hipaajournal.com/hipaa-breach-notification-requirements/
Visibility
Does your organization actively monitor threats and vulnerabilities associated with your devices? Is your organization investigating methods for generating device software bills of materials or device SBOMs? By generating component lists for your devices, you will have the advantage of visibility when vulnerabilities are announced. Using the lists of components, you will be able to assess the impact of a vulnerability, in any given component, much more quickly. Automated generation and maintenance tools can be utilized here to provide that much needed visibility across multiple product lines and versions.
Intelligence
Do you subscribe to any vulnerability data feeds, such as those offered by National Institute of Standards and Technology (NIST)? They offer various feeds including JSON Vulnerability Feeds and Vulnerability Vendor Comments. Find out more by visiting – https://nvd.nist.gov/vuln/data-feeds
Response
These are the processes and procedures that enable your organization to effectively recover from an incident. This requires the processes and technology to fully investigate incidents. Understanding of root cause is necessary so that mitigation techniques can be developed and applied to prevent similar future incidents. Surviving a security incident is not enough if your organization does not develop a risk infrastructure that prevents repeat exposure to the same vulnerability. Again, thorough understanding of the security incident and associated details is required for this analysis. For a bit more discussion of the eradication and recovery process, see the NIST Guide mentioned on page one of this document, which can be found at – https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r2.pdf
Metrics
Objective measurements of the organization’s handling of a security incident should be developed and reviewed. The metrics should align with organizational objectives and goals, with respect to handling security incidents. There are various metrics that can be utilized, and here are a few examples:
- Time to discover security incident
- Time to react to security incident (first gathering of IR team)
- Time to remediate
- Time to communicate (external and internal)
Summary
Medical device manufacturers must have an IR plan in place in order to respond effectively to security incidents. There are specific components of an IR plan that facilitate the end goal of effective response, and the undertaking of developing these components is a worthy investment of resources. Organizations that respond effectively and efficiently to security incidents consistently earn praise from customers and regulators, in addition to fostering an internal, proactive culture.
Ken Zalevsky
CEO, Vigilant Ops
Former Head of Medical Device Cybersecurity, Bayer
- Computer Security Incident Handling Guide. NIST. http://dx.doi.org/10.6028/NIST.SP.800-61r2.
