Vigilant Ops Wins Cybersecurity Challenge

Category

Organizational Readiness

What medical device manufacturers need to know about the Cyberspace Solarium Commission’s Final Report and the reference to Software Bill Of Materials (SBOM)

Are you prepared for US cybersecurity legislation that could result in lawsuits and fines if not implemented according to prescription? Did you know that the 2019 National Defense Authorization Act chartered the US Cyberspace Solarium Commission (CSC) to define such cybersecurity policies and legislation? As a stakeholder in the healthcare industry, you should be aware of the CSC final report and the possible implications. This overview provides a brief summary of the report’s discussion of Software Bill of Materials (SBOMs) and the specific responsibilities of medical device manufacturers.

The final report from the CSC was made publicly available on March 11, 2020. The report is 182 pages in length and offers more than 80 recommendations to implement a “…strategic approach to defending the United States in cyberspace against cyberattacks of significant consequences.”

The Cyberspace Solarium Commission was tasked by the President and Congress to answer two questions:

  1. What strategic approach will defend the United States against cyberattacks of significant consequence?
  2. What policies and legislation are required to implement that strategy?

The Cyberspace Solarium Commission advocated layered cyber deterrence to be achieved by:

  1. Working with allies and partners to promote responsible cyber behavior
  2. Working with the private sector to increase security of ecosystem
  3. Imposing costs as a deterrent and motivator

Implementation of the layered cyber deterrence strategy is built upon six (6) policy pillars and more than eighty (80) recommendations. This summary will provide in-depth analysis of the specific pillar to enhance the security in the cyber ecosystem, which calls out the work being done with the Software Bill of Materials (SBOM). Here is a list of the pillars presented in the document, but please refer to the final report for details on all pillars and recommendations.​1​

6 Pillars of the CSC final report

  1. Reform the US government’s structure and organization for cyberspace
  2. Strengthen norms and non-military tools
  3. Promote national resilience
  4. Reshape the cyber ecosystem (focus of this summary)
  5. Operationalize cybersecurity collaboration with the private sector
  6. Preserve and employ the military instrument of national power

Pillar 4 –  Reshape the Cyber Ecosystem Toward Greater Security

“This pillar attempts to drive down vulnerability across the ecosystem by shifting the burden of security away from end users to owners, developers, and manufacturers who can more efficiently implement security solutions at the appropriate scale.”

Five Strategic Objectives of Pillar 4

  1. Promote the creation of more secure technology by
    • Incentivizing product manufacturers to adopt a “secure to market” strategy
    • Ensuring product manufacturers have access to trusted suppliers
  2. Encourage more secure practices through incentives and disincentives
  3. Leverage large-scale information and communications technology
  4. Reduce key supply chain risk
  5. Protect sensitive data

Strategic Objective #1 – Incentivizing Greater Security in the Markets for Technology

Key Recommendations – 4.1, 4.2 and 4.7 are detailed below

4.1 Congress should establish and fund a National Cybersecurity Certification and Labeling Authority empowered to establish and manage a program for voluntary security certifications and labeling of information and communications technology products.

4.2 Congress should pass a law establishing that final goods assemblers of software, hardware, and firmware are liable for damages from incidents that exploit known and unpatched vulnerabilities.

4.3 Congress should establish a Bureau of Cyber Statistics charged with collecting and providing statistical data on cybersecurity and the cyber ecosystem to inform policymaking and government programs.

4.4 Congress should resource and direct the Department of Homeland Security to resource a federally funded research and development center to work with state-level regulators in developing certifications for cybersecurity insurance products.

4.5 The National Cybersecurity Certification and Labeling Authority, in consultation with the National Institute of Standards and Technology, the Office of Management and Budget, and the Department of Homeland Security, should develop a cloud security certification.

4.6 Congress should direct the US government to develop and implement an information and communications technology industrial base strategy to ensure more trusted supply chains and the availability of critical information and communications technologies.

4.7 Congress should pass a national data security and privacy protection law establishing and standardizing requirements for the collection, retention, and sharing of user data.

4.1 Congress should establish and fund a National Cybersecurity Certification and Labeling Authority empowered to establish and manage a program for voluntary security certifications and labeling of information and communications technology products.

Security standards and best practices can be employed more effectively, and certifications and labels can be used as a product differentiator for developers. The following are recommended:

  • Product Certification & Attestation – certify products meeting cybersecurity standards
  • Accredited Certifying Agents – accredit organizations to certify classes of products
  • Comparative Security Scoring – revise NIST scoring include product type, environment
  • Update Federal Procurement Regulations – require product certification and labeling
  • Integrate with Ongoing Efforts – build upon existing efforts at Department of Commerce to develop the SBOM (Software Bill of Materials)
  • Partnership on Product Labeling –  provide transparent information on the characteristics and constituent components (SBOM) of a software or hardware product, including those that contribute to the security of a product or service.

Product component lists, like the SBOM mentioned above, are being adopted as an industry security document in healthcare because they provide transparency into deployed device risk. For a more detailed discussion of Software Bill Of Materials, and how they support responsive patching programs, please see our article – The Impact of COVID-19 on Medical Device Cybersecurity.

4.1.1 Enabling Recommendation – Create or Designate Critical Technology Security Centers

Provide the US government with the capacity to test the security of critical technologies and, when appropriate, assist in identifying vulnerabilities, developing mitigation techniques with relevant original equipment manufacturers

4.1.2 Enabling Recommendation – Expand and Support the National Institute of Standards and Technology (NIST) Security Work

Congress should increase funding in support of NIST’s work on cybersecurity. Specifically, NIST should be appropriately resourced to:

  • Maintain cybersecurity frameworks and standards
  • Develop technology development standards
  • Develop standards for vulnerability and patch management
  • Support National Vulnerability Database (NVD)
  • Support Common Vulnerabilities and Exposures (CVE) program
  • Support Cybersecurity and Infrastructure Security Agency (CISA)

4.2 Congress should pass a law establishing that final goods assemblers of software, hardware, and firmware are liable for damages from incidents that exploit known and unpatched vulnerabilities.

Definitions

Final Goods Assembler – the entity that is most responsible for the placement of a product or service into the stream of commerce. In the case of medical devices, this could be assumed to be the medical device manufacturer.

Known Vulnerability – vulnerabilities disclosed through public sources such as the National Vulnerability Database (NVD) and Common Vulnerabilities and Exposures (CVE) program, reported to the hardware/software developer by a third party, and discovered by the hardware/software developer themselves.

Vulnerability Disclosure and Retention – final goods assemblers, as well as software and hardware component developers, establish a process for vulnerability reporting, retain records documenting when a vulnerability was made known or discovered by the company, and maintain a vulnerability disclosure and patching policy that conforms to the requirements set out under this regulation.

4.2.1 Establish Liability for Final Goods Assemblers – Legislative Summary

Private Right of Action

  • End users may bring action against final goods assemblers not meeting standard of care
  • Damages up to 15% of annual revenue of preceding year of final goods assemblers

Standard of Care – final goods assembler

  • Meet the standard of care if, within 18 months of the enactment of this Act
    • Makes security patches available within 90 days of a vulnerability 

4.7 Congress should pass a national data security and privacy protection law establishing and standardizing requirements for the collection, retention, and sharing of user data.

  • Preempts the existing state, district, and territorial data breach notification laws
  • Establishes threshold for a covered breach
  • Requires notification and transmission of forensic data to cyber authorities
  • Sets standards and timelines for notifying victims
  • Sets criteria that determine when victims should receive free credit monitoring
  • Deconflicts with existing federal regulation for private-sector and other non-federal entities

Conclusion

The CSC final report is a call to action to the US government. Through the various strategic recommendations, the Commission is urging the United States Congress to act quickly and pass supportive legislative measures enabling private rights of action by end users harmed in cyber incidents. For medical device manufacturers, the CSC final report is also a call to action. It’s clear that the demands to provide concise, transparent information and timely responses to cyber incidents will continue to increase. Providing security documentation such as the SBOM (Software Bill of Materials) will be an expectation, and product insecurity will not be tolerated. Medical device manufacturers would be wise to begin preparing now for these sweeping reforms.

The InSight Platform uses advanced techniques to interrogate medical devices and automatically generate bills of materials. Using artificial intelligence and machine learning, the InSight Platform continuously monitors for vulnerabilities in discovered device components, enabling device manufacturers to respond proactively to the latest discovered threats.

Ken Zalevsky
CEO, Vigilant Ops
Former Head of Medical Device Cybersecurity, Bayer

Founded in 2019, Vigilant Ops is an innovator in the medical device cybersecurity industry. Led by seasoned medical device cybersecurity experts with more than forty years of combined experience, Vigilant Ops provides medical device manufacturers and hospitals with unprecedented insight into device risk profiles, enabling proactive management of threats before they impact the quality of patient care.

For more information about Vigilant Ops or the InSight Platform, please visit our website at www.vigilant-ops.com
Or drop us an email at: inquiries@vigilant-ops.com

  1. 1.
    The final report, along with additional information about the CSC can be found at . Cyberspace Solarium Commission. https://www.solarium.gov

Incident Response Plan Cyber Simulation Exercise

Executing effective simulation exercises and rigorously testing the organization’s incident response capability has been proven to positively impact the organization’s ability to recover. There is sufficient evidence to show that organizations can reduce the cost of a breach by more than 30%​1​ simply by having an Incident Response (IR) team following a thoroughly tested IR plan. In this document, we will explore the fundamentals of testing an organization’s IR plan using cyber simulation exercise.

The planning of cyber simulation exercises is fundamentally the same across all organizations, with the organizational objectives driving the details of scenario development and execution. Before getting into the details of the exercise, we’ll do some necessary preparation and define some important parameters for the exercise in order to maximize benefits.

Exercise Objective

To prepare for the undertaking of an effective cyber simulation exercise, there are several considerations necessary. The most important is the objective of the exercise. At a high level, the objective should convey the definition of a successful simulation. What does the organization want to accomplish through the exercise?

In this case, we are planning to test our IR plan, but our ultimate objective is to improve our organization’s ability to respond to a cyber incident by improving our IR plan. This improvement to our IR plan encompasses several lower-level objectives including identifying gaps in current policies and procedures, ensuring that team members are familiar with their particular role in the case of an incident, optimizing response processes for efficiencies, and others. But for clarity, the objective should be set at a level that enables crisp communication across the organization, so words like “improve” need to be quantified. We’ll attach our success to specific improvement in our customer communication of an incident. So, the final objective could look like this – Improve security incident response, as measured by the cycle time needed for the first external communication of security-related incidents, by 15%.

Exercise Lead/Planner

As part of exercise preparation, it’s also advisable to assign an exercise lead or planner role that will be responsible to implement and facilitate the exercise planning, execution and follow-up/reporting. This is usually an individual but can also be assigned to a team with various leadership responsibilities split among the team members. This depends on the size and complexity of the organization and the intended size and complexity of the cyber simulation exercise. In any case, the exercise planner will have the largest time commitment to the exercise, so should be prepared to devote the necessary time in order to make the exercise successful.

Exercise Team

Depending on the size and scope of the cyber simulation exercise and the objective set by the organization, it may be necessary to form an exercise team consisting of those in the organization in roles directly responsible for action in the case of an incident. The team size will vary depending on the size and complexity of the organization, but usually ranges from about 4 to 10 people. Some functional groups with members that might be considered for inclusion on the team could be:

  • Product Development
  • Product Security
  • Information Technology (IT)
  • Customer Support/Complaint Handling
  • Legal
  • Compliance/Regulatory
  • Human Resources
  • Senior Management/Executives

Exercise Scenario

The exercise scenario describes the scope and details of the exercise in a manner sufficient to communicate objectives and expectations. In other words, the scenario actually sets up the exercise and drives the associated exercise activity and planned events. For example, an exercise scenario could be that a former, disgruntled employee secretly modified commercial product source code, prior to leaving the organization. The modified source code that was injected with malware was being shipped to customers as new installations or upgrades, for several months prior to the malware being discovered.

Master Scenario Events List (MSEL)

The Master Scenario Events List (MSEL) is the list of planned exercise events, sometimes referred to as injects. The injects should be easily understood by exercise participants, so that they can respond appropriately. They should be defined sequentially with the timing of the injects simulating a real-world scenario as much as possible, providing the IR team with ample opportunity for realistic testing.

General Format of the MSEL

The MSEL should list the exercise injects in chronological order, for ease of tracking as the exercise progresses.

The MSEL could include the following details for each of the injects:

  • Date and time of occurrence (within the exercise)
  • Synopsis or description of the event
  • Responsible personnel
  • Expected action from responsible personnel
  • Attachments (for example, an email received from a customer)
  • And other details of the injects

NOTE: We have developed a Master Scenario Events List (MSEL) template available for you to download. Just click to download your MSEL template.

Execute

After developing the MSEL, reviewing the plan with the exercise team, clarifying roles and responsibilities, and making sure internal systems are ready to support, it’s time to execute the exercise! Be sure your team planner(s) monitor the exercise properly and record activity detail will be used to develop the Exercise Simulation Report (ESR). The ESR will summarize the exercise and provide details of identified gaps in processes/policies/procedures.

NOTE: We have developed a sample Exercise Simulation Report (ESR) available for you to download. Just click to download your sample ESR.

Report the Results

After developing the ESR, schedule a series of review meetings to discuss the results of the exercise. Schedule the initial meeting with the exercise team, review the ESR, develop exercise communication to be shared with the rest of the organization. Depending on the size and complexity of the organization, it could take several meetings to communicate to all stakeholders. Be consistent by sharing the same basic communication with all stakeholders, slightly modified for specific functions and responsibilities. For example, it would be beneficial to include some treatment of compliance effectiveness when meeting with your Regulatory team.

Cyber Simulation Exercise Summary

To summarize what we have done in our testing exercise, here are the ordered steps that we followed:

  1. Develop a clear, concise objective for the exercise that can be easily communicated
  2. Identify exercise lead(s) with the responsibility to manage the exercise
  3. Assemble the exercise team – usually cross-functional representatives from the organization
  4. Develop the exercise scenario – have fun with it, but make it realistic for believability
  5. Based on the exercise scenario, develop the exercise activities, known as events or injects
  6. Compile developed events into the MSEL (Master Simulation Events List)
  7. Distribute and review the MSEL with the team, make sure everyone understands their roles!
  8. EXECUTE THE EXERCISE
  9. Develop the Exercise Simulation Report
  10. Share the results of the exercise with the organization

Ken Zalevsky
CEO, Vigilant Ops
Former Head of Medical Device Cybersecurity, Bayer

Founded in 2019, Vigilant Ops is an innovator in the medical device cybersecurity industry. Led by seasoned medical device cybersecurity experts with more than forty years of combined experience, Vigilant Ops provides medical device manufacturers and hospitals with unprecedented insight into device risk profiles, enabling proactive management of threats before they impact the quality of patient care.

For more information about Vigilant Ops or the InSight Platform, please visit our website at www.vigilant-ops.com
Or drop us an email at: inquiries@vigilant-ops.com

  1. 1.
    2019 Cost of a Data Breach Report. Ponemon Institute. IBM Security

Three Reasons You Need to Use AI Software for Generating and Maintaining Medical Device SBOMs/CBOMs

What if you found out there was a way to interrogate medical devices and automatically generate cybersecurity bill of materials (CBOM)? Although you may initially miss the manual effort, you and fellow MDMs can now use artificial intelligence to begin automatically generating, maintaining, and monitoring medical device SBOMs/CBOMs.

The Solution

Utilizing the cloud, the Vigilant Ops InSight platform introduces a solution for generating, updating, and monitoring device software bills of materials. The InSight CBOM Generator automatically detects the Operating System of the medical device and executes the appropriate commands to interrogate the device and inventory all of the software components.

How It Works

  • The generated cybersecurity bill of materials is uploaded to the InSight Platform, where it can be reviewed and approved before publication.
  • An approved CBOM is automatically sent for certification by Vigilant Ops trained security specialists.
  • Once certified, the cybersecurity bill of materials (CBOM) can be published and shared with confidence.

Your Biggest Pain Points Solved

The general consensus is that the Cybersecurity Bill of Materials (CBOM) is a valuable document that can help improve healthcare security, but it comes at a cost. And, if you are not utilizing a tool to help automate the CBOM generation process, then that cost is substantially higher.

  • Manually generating and maintaining a single medical device SBOM takes hours of effort plus hardware and software tools.
  • If your organization is on a quarterly release cycle, you will have to generate four cybersecurity bill of materials annually per device, in addition to continuously monitoring sources for vulnerability updates.
  • Every cybersecurity bill of materials is a snapshot in time, so manually generating a CBOM is taking the risk that the information is not already obsolete.
  • Manual generation and maintenance of medical device CBOMs is not practical or scalable, and is possibly misleading, in that it could contain outdated information.

The Stats

As a medical device manufacturer, the FDA is clear that you “are responsible for remaining vigilant about identifying risks and hazards associated with your medical devices, including risks related to cybersecurity.”

According to Health IT Security, 70% of medical devices have vulnerable software components, and with an average of 40 new CVEs being received daily at the National Vulnerability Database, disaster is looming. It is evident that the manual CBOM process can’t keep up, challenging even the most tenured security experts, without the introduction of CBOM monitoring and automation.

Why You Cannot Afford To Go Without The Vigilant Ops CBOM Generator

  1. Using manual effort to generate a medical device CBOM always leaves you asking – “Did I get all of the components?”
  2. Monitoring CBOM component vulnerabilities using public data sources requires time and patience. Do you really have hours to spend trying to match components to CPEs just so you can try to find them in the NVD?
  3. How are you planning to respond to your sales team’s onslaught of emails asking for CBOM documentation to send to their demanding hot prospect who happens to be contemplating a million-dollar deal?

CBOMs are all about managing medical device cybersecurity risk and providing actionable insight in order to create a safer, more secure healthcare environment. The use of a cloud-based platform to securely generate and maintain CBOMs is a vigilant and efficient way to enable compliance, improve organizational awareness, and implement a proactive approach to medical device security within your organization.

Ken Zalevsky
CEO, Vigilant Ops
Former Head of Medical Device Cybersecurity, Bayer

Founded in 2019, Vigilant Ops is an innovator in the medical device cybersecurity industry. Led by seasoned medical device cybersecurity experts with more than forty years of combined experience, Vigilant Ops provides medical device manufacturers and hospitals with unprecedented insight into device risk profiles, enabling proactive management of threats before they impact the quality of patient care.

For more information about Vigilant Ops or the InSight Platform, please visit our website at www.vigilant-ops.com
Or drop us an email at: inquiries@vigilant-ops.com

The Importance of an Incident Response Plan

Medical device manufacturers must follow various regulations for their fielded devices, generally referred to as postmarket requirements, which include tracking and reporting malfunctions and injuries. Most have formal procedures and processes in place to satisfy these requirements. However, security incidents impact medical device manufacturers, and their customers, in ways that go beyond the requirements satisfied by existing procedures.

Effective response to security incidents requires preparedness. Attempting to pull together a team of responders and weave together disparate processes under the extreme pressure of a security breach is nearly impossible. An organization might be successful using ad-hoc methods, but it’s not a sustainable strategy as threat vectors continue to grow with every newly discovered exploitable vulnerability. In times of extreme crises, having a planned response can mean the difference between life and death. In terms of security incidents in healthcare, having a planned response can reduce the overall cost to medical device manufacturers. “An organization’s ability to respond effectively after a data breach is strengthened by the presence of an incident response (IR) team that follows and incident response plan…the formation of an IR team and testing the IR plan mitigate data breach costs more than any single security process.​1​

The development of an incident response (IR) plan should be a top priority for medical device manufacturers. Equally important, however, is the continuous maintenance of the developed plan. This is just the nature of the continuous evolution of medical device cybersecurity and typical organizational change. Threats evolve, bad actors discover new exploits, product profiles change, people leave and join the organization, and before you know it, the original incident response plan is woefully out of date.

One of the most effective methods of maintaining an IR plan is periodic testing by a formal IR team. In the Ponemon study referenced above, the mean cost of a breach was $3.92 million US dollars. Organizations with formal IR teams following extensive testing of IR plans effectively reduced that mean cost to around $2.69 million US dollars, saving $1.23 million US dollars. This is significant, especially when considering the fairly modest cost of developing of an incident response plan.

Reduction in cost of breach

Of course, all medical device manufacturers have financial and resource constraints, and in some cases, it might be difficult to carve out the money or the time to develop an IR plan, form an IR team and apply resources to continuous testing. There are several IR plan templates available, some freely downloadable and others with some restrictions, however, the process does not need to be overly complex or overly expensive. As a matter of fact, with proper scoping, medical device manufacturers can get started quickly, develop a plan, form a team and put some tabletop exercises in place.

For specifics on developing and maintaining an IR plan, see our article titled “Developing an Incident Response Plan for Medical Device Manufacturers”.

Ken Zalevsky
CEO, Vigilant Ops
Former Head of Medical Device Cybersecurity, Bayer

Founded in 2019, Vigilant Ops is an innovator in the medical device cybersecurity industry. Led by seasoned medical device cybersecurity experts with more than forty years of combined experience, Vigilant Ops provides medical device manufacturers and hospitals with unprecedented insight into device risk profiles, enabling proactive management of threats before they impact the quality of patient care.

For more information about Vigilant Ops or the InSight Platform, please visit our website at www.vigilant-ops.com
Or drop us an email at: inquiries@vigilant-ops.com


  1. 1.
    2019 Cost of a Data Breach Report. Ponemon Institute. IBM Security.

Developing an Incident Response Plan for Medical Device Manufacturers

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

Founded in 2019, Vigilant Ops is an innovator in the medical device cybersecurity industry. Led by seasoned medical device cybersecurity experts with more than forty years of combined experience, Vigilant Ops provides medical device manufacturers and hospitals with unprecedented insight into device risk profiles, enabling proactive management of threats before they impact the quality of patient care.

For more information about Vigilant Ops or the InSight Platform, please visit our website at www.vigilant-ops.com
Or drop us an email at: inquiries@vigilant-ops.com


  1. 1.
    Computer Security Incident Handling Guide. NIST. http://dx.doi.org/10.6028/NIST.SP.800-61r2.