Definition of a Ransomware Attack on playbook

Ransomware is a type of malware that prevents or limits users from accessing their systems or files,
either by locking the system’s screen or by encrypting the files until a ransom is paid. Upon locking the
files or systems, a message (ransom note) is displayed on the screen with instructions on how users can
pay the ransom, most often in the form of cryptocurrency. In many cases, the victim must pay the
cybercriminal within a set amount of time or risk losing access forever. The most common attack
methods for ransomware attacks are silent infections from exploit kits, malicious email attachments,
and malicious email links. As malware attacks are often deployed by cyber thieves, paying the ransom
doesn’t ensure access will be restored.

How to recover from ransomware :

Recovering from ransomware can be a lengthy process and recovering your organization’s brand and
reputation can be an even longer process. Working on the assumption that your organization will
encounter some form of malware will assist you in developing your planned response and could speed
up your recovery processing time. By adhering to the guidance provided in this document, your
organization will not only reduce the time it takes to recover from an attack, but it can also reduce the
likelihood of an attack occurring or minimize the impact of an infection.

Recovery process:
As described in subsection having reliable backups that are secured and stored offline can significantly
enhance your ability to recover from a ransomware attack. If your organization has been hit with
ransomware, there are immediate steps you can take to minimize the impact of the infection.

Immediate response actions :

Threat actors can infiltrate your network and continue to have visibility into your systems, connected
devices, and communications. You should assume the threat actor has visibility into your organization
and therefore you should implement an alternative communication method (e.g. external email
accessed by a device not connected to your network) that is not accessible to them. This will also block
the threat actor from gaining insight into your intended incident response plans and recovery actions.
Below, we provide a checklist for your organization to follow when taking immediate action, ideally
within the first few hours, against a ransomware attack

Health Sector Cybersecurity Framework Implementation:

While the generic cybersecurity framework implementation approach outlined in Appendix C – NIST CsF
Basics—and used by other critical infrastructure sectors such as the Department of Energy—works well
for organizations that design or specify their own controls, it does not work as well (i.e., most efficiently)
for those organizations that leverage a framework-based risk analysis to select and modify a control
baseline (or overlay). Fortunately, this generic implementation approach can be modified to
accommodate a control framework-based approach in the same way the basic risk analysis process
advocated by DHHS can be modified.

The primary reason for the modification is that, for those organizations that leverage the HITRUST RMF,
Target Profiles are easily obtained once organizations are able to scope their organization and systems,
tailor the HITRUST CsF controls based on their organizational, system and regulatory risk factors, and
then further tailor the overlay to address any unique threats. There is no need to develop a Current
Profile beforehand. Placement of the Current and Target Profiles can subsequently be reversed,
although some basic information about the state of the organization’s cybersecurity program will
necessarily be ascertained before the Target Profile is complete.

Implementation Process:
Healthcare Sector organizations leveraging the HITRUST RMF should use the following sevenstep
process for implementation.

 Step 1: Prioritize and scope organizational components for framework adoption .

 Step 2: Identify systems and existing risk management approaches within the scope .

 Step 3: Create a desired risk management profile based on the organization’s risk factors (Target
Profile)

 Step 4: Conduct a risk assessment.

 Step 5: Create a current risk management profile based on assessment results (Current Profile)

 Step 6: Develop a prioritized action plan of controls and mitigations (Action Plan).

 Step 7: Implement the Action Plan.

As with the generic process, implementation should include a plan to communicate progress to
appropriate stakeholders, such as senior management, as part of its risk management program. In
addition, each step of the process should provide feedback and validation to previous steps.
 Fig4: Healthcare Implementation Process.

Each step is now discussed in more detail, first introduced by a table describing the step’s inputs,
activities, and outputs followed by additional explanation.21 A table of the inputs, activities, and outputs
for all seven steps is also included in Appendix F – NIST CsF and HIPAA Security Rule Mapping.

Step 1: Prioritize and Scope:

Step 1: Prioritize and Scope

Inputs Activities Outputs

1. Risk management strategy 2. 1. Organization determines where it 1. Usage scope
Organizational objectives and priorities wants to apply the HITRUST RMF to 2. Unique
3. Asset inventory evaluate and potentially guide the threats
4. HITRUST RMF improvement of the organization’s
capabilities
2. Threat analysis
3. Business impact analysis
4. System categorization (based on
sensitivity & criticality)
 Table 4: Prioritize and Scope

The risk management process should begin with a strategy addressing how to frame, assess, respond to,
and monitor risk. For healthcare organizations, leveraging the HITRUST RMF is a central component of
that strategy as it forms the basis of their HIPAA-required risk analysis, informs the organization on the
minimum level of due care and due diligence required to meet its multiple compliance obligations,
provides for the adequate protection of PHI and other sensitive information, and provides a
comprehensive and rigorous methodology for control assessment, scoring, and reporting. The
organization’s risk strategy is also used to inform investment and operational decisions for improving or
otherwise remediating gaps in their cybersecurity and information protection program.

In this step, the organization decides how and where it wants to apply the HITRUST RMF (its usage
scope)—whether in a subset of its operations, in multiple subsets of its operations, or for the entire
organization. This decision should be based on risk management considerations, organizational and
critical infrastructure objectives and priorities, availability of resources, and other internal and external
factors. Current threat and vulnerability information from HITRUST or other nationally recognized ISAO
may also help inform scoping decisions.

Note, this step includes the following elements of the DHS risk analysis process as modified to
accommodate use of a control framework:

 Conduct a complete inventory of where electronic PHI (ePHI) lives (if not already performed)

 Perform a Business Impact Analysis (BIA) on all systems with ePHI (criticality)

 Categorize & evaluate these systems based on sensitivity and criticality.

Step 2: Orient:

Step 2: Orient
Inputs Activities Outputs
1. Usage scope 1. Organization identifies in- 1. In-scope systems and assets
scope systems and assets (e.g., 2. In-scope requirements (e.g.,
2. Risk management people, information, organizational, system,
strategy technology and facilities) and regulatory)
the appropriate regulatory and
3. HITRUST RMF other authoritative sources
(e.g., cybersecurity and risk
management standards, tools,
methods and guidelines)
Table 5: Orient

The organization identifies the systems, assets, compliance and best practice requirements, and any
additional cybersecurity and risk management approaches that are in scope. This includes standards and
practices the organization already uses, and could include additional standards and practices that the
organization believes would help achieve its critical infrastructure and business objectives for
cybersecurity risk management. The organization’s risk management program may already have
identified and documented much of this information, or the program can help identify individual
outputs. A good general rule is to initially focus on critical systems and assets and then expand the focus
to less critical systems and assets as resources permit.

Note that this step includes the following element of the DHS risk analysis process as modified to
accommodate use of a control framework: Conduct a complete inventory of where ePHI lives. (Note a
HIPAA-compliant risk analysis generally considers all systems, devices, locations, etc., where ePHI “lives”
to be in scope.)

Step 3: Create a Target Profile:

Step 3: Create a Target Profile

Inputs Activities Outputs
1. Organizational objectives 1. Organization selects a 1. Target Profile (Tailored
HITRUST CSF control overlay HITRUST CSF control overlay)
2. Risk management strategy and tailors the overlay based
on unique threats identified in 2. Target Tier
2. Detailed usage scope the prioritization and scoping
phase
3. Unique threats
2. Organization determines
5. HITRUST RMF level of maturity desired in the
selected controls
Table6 : Create a Target Profile

The organization applies its specific risk factors as determined during the first two steps to create an
overlay of the CSF for its particular subclass of healthcare entity and then tailors the overlay to account
for any unique threats (as compared to other, similar organizations in its subclass). The Target Profile
should include these practices as well.

However, information protection cannot be a “one size fits all” approach. For example, organizations,
more often as not, have different information systems (or different implementations of similar systems),
different business and compliance requirements, different cultures, and different risk appetites. Even
the HITRUST CSF cannot account for all these differences through the tailoring of controls based on
specific organizational, system, and regulatory risk factors.

So for whatever reason an organization cannot implement a required control, one or more
compensating controls should be selected to address the risks posed by the threats the originally
specified control was meant to address. But while compensating controls are well-known and
extensively employed by such compliance frameworks such as the Payment Card Industry Digital
Security Standard (PCI-DSS), the term compensating control has often been used to describe everything
from a legitimate work-around to a mere shortcut to compliance that fails to address the intended risk.
As a result, organizations should be able to demonstrate the validity of a compensating control by way
of a legitimate risk analysis that shows the control has the same level of rigor and addresses a similar
type and level of risk as the original. Additionally, the compensating control must be something other
than what may be required by other, existing controls. For more information on how compensating
controls can be used to support HITRUST CSF validated or certified assessments and reporting, refer to
the HITRUST Risk Analysis Guide

The organization should also determine the evaluation approach it will use to identify its current
cybersecurity and risk management posture. Organizations can use any of a number of evaluation
methods to identify their current cybersecurity posture and create a Current Profile. These include self-
evaluations, where an organization may leverage its own resources and expertise; facilitated
approaches, where the evaluation is assisted by a third party; or completely independent evaluations,
such as those used to support a HITRUST validated or certified report or American Institute of Certified
Public Accountants (AICPA) Service Organization Control (SOC 2) for HITRUST report.

The organization should also determine its goals for the Target Tier from the NIST CsF and identify the
equivalent levels of control maturity required to achieve those goals. For example, an organization may
be satisfied with a Tier 1, Risk-Informed level of organizational maturity, which would translate to an
overall 3- to 3+ maturity rating. However, an organization with less risk tolerance may select a Tier 3,
Repeatable level and subsequently strive for an overall control maturity rating of 4- to 5-. Refer to Table
13 and Table 14 in Appendix D – Healthcare’s Implementation of the NIST CsF for more information on
the HITRUST maturity ratings and how they map to the NIST CsF Implementation Tiers.

Note, this step includes the following elements of the DHS risk analysis process as modified to
accommodate use of a control framework:

 Select an appropriate framework baseline set of controls .

 Apply an overlay based on a targeted assessment of threats unique to the organization.

Step 4: Conduct a Risk Assessment:

Step 4: Conduct a Risk Assessment

Inputs Activities Outputs
3. Detailed usage scope 1. Perform a risk assessment for 1. Risk assessment reports
in-scope systems and
2. Risk management strategy organizational elements

4. Target Profile

4. HITRUST RMF
Table7: Conduct a Risk Assessment

Evaluation of the maturity of the organization’s control implementation—often colloquially referred to

as a risk assessment (even though NIST considers the terms synonymous)—is performed in this step.
Organizations perform cybersecurity risk assessments to identify and evaluate cybersecurity risks and
determine which are outside of current tolerances. The outputs of cybersecurity risk assessment
activities assist the organization in developing its Current Profile and Implementation Tier based on
control maturity, which occurs in Step 5. For organizations that have a risk management program in
place, this activity will be part of regular business practice, and necessary records and information to
make this determination may already exist. For example, many organizations perform regular
evaluations of their programs through internal audits or other activities, which may describe the
controls as implemented within the defined scope of the risk assessment.

Note, this step includes the following elements of the DHS risk analysis process as modified to
accommodate the use of a control framework:

 Evaluate residual risk

 Likelihood based on an assessment of control maturity.

 Impact based on relative (non-contextual) ratings.

Step 5: Create a Current Profile :

Step 5: Create a Current Profile
Inputs Activities Outputs
1. Risk assessment reports 1. Organization identifies its 1. Current Profile
current cybersecurity and risk (Implementation status of
2. HITRUST RMF management state selected controls)

2. Current Tier (Implementation

maturity of selected controls,
mapped to NIST CsF
Implementation Tier model)
Table8: Create a Current Profile

A Current Profile is created from the evaluation of the organization’s cybersecurity and risk management
practices against the Target Profile created in Step 4. The organization may represent the results using
the HITRUST CSF control structure, or if a report is generated using HITRUST’s online assessment support
tool, the results can be presented as a scorecard for the HITRUST assessment domains and/or the NIST
CsF subcategories. To manually generate a scorecard for a NIST CsF Target Profile, refer to Appendix E –
NIST CsF and HITRUST CSF Mapping. In fact, scorecards against any of the CSF’s authoritative sources,
including the NIST CsF, may be manually generated using the mappings contained in the HITRUST CSF
crossreference document.26 The maturity scores generated during the assessment will also inform the
current Implementation Tier as described earlier in this document.

Note, this step includes the following elements of the DHS risk analysis process as modified to
accommodate use of a control framework:

 Evaluate residual risk

 Likelihood based on an assessment of control maturity

 Impact based on relative (non-contextual) ratings
Step 6: Perform Gap Analysis :

Step 6: Perform Gap Analysis

Inputs Activities Outputs
2. Current Profile 1. Analyze gaps between 1. Prioritized gaps and
Current and Target Profiles in potential consequences
2. Target Profile organization’s context
2. Prioritized implementation
2. Organizational 2. Evaluate potential plan
objectives consequences from
gaps
4. Impact to critical
infrastructure 2. Determine which gaps
need attention
2. Gaps and potential
consequences 4. Identify actions to address
gaps
2. Organizational
constraints 2. Perform cost-benefit
analysis (CBA) or
2. Risk management similar analysis on
strategy actions

8. Risk assessment/analysis 2. Prioritize actions (CBA

reports or similar analysis) and
consequences
9. HITRUST RMF
7. Plan to implement
prioritized actions
Table 9 : Perform Gap Analysis

The organization evaluates its Current Profile and Implementation Tier against its Target Profile and
Target Implementation Tier and identifies any gaps. When mapping back to the NIST CsF, a gap exists
when there is a desired Category or Subcategory outcome in the Target Profile or program characteristic
in the Target Implementation Tier that is not currently achieved by the organization’s existing
cybersecurity and risk management approach, and when current practices do not achieve the outcome
to the degree of satisfaction required by the organization’s risk management strategy. When using the
HITRUST CSF controls as the evaluation and reporting mechanism, gaps are identified by a level of
control maturity that does not meet or exceed the levels specified by the Target Implementation Tier. (A
control maturity score of zero is a valid measure of a control that is not implemented as required by the
Target Profile.)

After controls are specified by an organization to ensure risk is controlled to a level formally deemed
acceptable by executive leadership, the most common way of dealing with deficiencies observed with
the implementation and management of those controls is to remediate them. This reduces risk to an
acceptable level, a process referred to as mitigation.
HITRUST requires assessed entities requesting a validated or certified report to prepare Corrective
Action Plans (CAPs) for identified deficiencies. Self- or third-party assessors, as applicable, must describe
the specific measures intended to remediate (correct) deficiencies identified during an assessment for
validation or certification. HITRUST understands that most organizations have more vulnerabilities than
they have resources to address, so organizations should prioritize corrective actions based on the
sensitivity and criticality of the information systems or assets affected, the direct effect the vulnerability
has on the overall security posture of the information systems or assets, and the requirements for CSF
certification. Note, third party assessors must review the CAP to evaluate the effectiveness of the
remediation strategy, provide recommendations or feedback as needed, and document any findings for
submission to HITRUST if the organization wishes to receive a HITRUST validated or certified report.

Non-contextual Impact and Relative Risk:

Although HITRUST organizations and CSF Assessors typically have no problem with identifying the
corrective actions needed to address specific deficiencies, some have difficulty rating the risks
associated with these deficiencies and subsequently prioritizing the work. To help with CAP
prioritization, HITRUST provides non-contextual impact ratings for each CSF control, which allows the
computation of relative risk for each deficiency identified in an assessment. The ratings are non-
contextual in that they assume the probable impact should the control fail— assuming all other controls
are in place.

mpact is described using five rating levels: Very Low (1), Low (2), Moderate (3), High (4) and Very High
(5). For the purpose of computing risk, ratings may be assigned specific values such as those prescribed
by NIST: Very Low (1) = 0, Low (2) = 2, Moderate (3) = 5, High (4) = 8, and Very High (5) = 10. HITRUST
uses a similar approach and computes impact (I) as a function of the impact rating (IR):

Impact = I = (IR - 1) x (25),

which equates to Very Low (1) = 0, Low (2) = 25, Moderate (3) = 50, High (4) = 75, and Very High (5) =
100. When converted to a 10-point scale and rounded up, the values are identical to the NIST model.

HITRUST impact ratings for all 135 CSF controls directly related to cybersecurity.
 Table10formula’s table

The numbers are intended to provide a starting point for assignment of relative risk to CAPs based on
relative maturity of the controls as determined by a HITRUST CSF assessment. For internal remediation
planning purposes, organizations may adjust the impact ratings based on the status of other controls in
the environment or the sensitivity and/or criticality of the information assets in scope. However, these
non-contextual impact ratings may not be adjusted for validation and certification reporting to ensure
consistency across the industry.

Note, the formula for computing risk using the HITRUST CSF control maturity score may be written as:

R = L x I = [(100 – MS) / 100] x [(IR – 1) x 25]

where, R = risk, L = likelihood, I = impact, MS = HITRUST CSF control maturity score, and IR = impact
rating

For example, suppose an organization obtains a maturity score of 75 for CSF control 01.a. Since this is a
very high impact control, the risk would be computed as [(100 – 75) / 100] x [(5 – 1) x 25) = .25 x 100 =
25, which is a moderate risk.

HITRUST recognizes two types of risk scales, a traditional bell-shaped model and a left-skewed bell-
shaped “academic” model. Although the traditional model is best used for communicating risk to
external stakeholders, the academic model provides a very intuitive approach to understanding risk
when presented as risk grades, reminiscent of the model used by the federal government to report
security compliance for federal agencies.

The following table provides the intervals for both models:

Risk Level Range (Traditional Model) Range (Academic Model)

Very High (Severe) 96-100 41-100
High 80-95 31-40
Moderate 21-79 21-30
Low 5-20 11-20
Very Low (Minimal) 0-4 0-10
Table 11: intervals of traditional and academic models

There are many ways in which the resulting information can be presented. One way is to show relative
residual risk at the control objective level of the HITRUST CSF using an academic scoring model. An
example of such a “scorecard” that can be manually generated using standard office productivity
software is presented.
 Fig5: Example HITRUST CSF Residual Risk Scorecard (Academic Model)

A similar, manually constructed view based on the NIST CSF functions and categories using a traditional
scoring model is provided in Figure 3. Example NIST CsF Residual Risk Scorecard (Traditional Model).

Fig6 : Example NIST CsF Residual Risk Scorecard (Traditional Model)

Prioritization:

HITRUST also provides implementation dependencies amongst CSF controls based on priority codes for
federal controls28 contained in NIST SP 800-53 r4. The priority codes indicate relative order of priority
(sequencing) for implementation, which helps provide a more structured, phased approach by ensuring
controls upon which other controls depend are implemented first.

Priority code sequencing, consistent with NIST SP 800-53 r4, is as follows:

 P1 – First (Control contains significant number of foundational requirements)

 P2 – Next (Control contains requirements that depend on the successful implementation of one
or more foundational control requirements)
 P3 – Last (Control contains requirements that generally depend on the successful
implementation of one or more priority 2 requirements)

The following table provides the HITRUST priority codes for all 135 CSF controls directly related to
cybersecurity:

Table12: HITRUST priority codes

Whether or not these priority codes will be useful to an organization will depend on the specific
deficiencies requiring CAPs. Self- and third-party assessors must also fully understand the requirements
in order to understand their dependencies.

An organization should understand that CAP prioritization will depend on other factors unique to the
organization, which cannot be addressed by an RMF like HITRUST or NIST. Examples include available
operational and capital budget, budget planning processes, architecture and infrastructure constraints,
and even organizational culture and politics.

For the purposes of certification, HITRUST generally requires CAPs for all CSF requirements that score a 3
or below and for any requirement that is not fully implemented (i.e., not fully compliant for maturity
level 3, Implemented).
To illustrate how risk and priority codes can be applied to CAP prioritization, consider a scenario in which
an organization has an immature business continuity program and received the following HITRUST
maturity scores for controls 12.a thru 12.e.

 12.a, Including Info. Security in the Business Continuity Mgmt. Process: 50

 12.b, Business Continuity and Risk Assessment: 75
 12.c, Developing and Implementing Continuity Plans Including Info. Security: 50
 12.d, Business Continuity Planning Framework: 50
 12.e, Testing, Maintaining, Reassessing Business Continuity Plans: 38

CAPs would likely be required to address deficiencies with one or more requirement statements for
controls 12.a, 12.c, 12.d and 12.e; however, for the sake of simplicity, assume one requirement
specification for each control.

Risk and priority information for these four controls are provided in the next table.

CSF Control Maturity Impact Rating Raw Risk Priority Code Assigned
Score (MS) (IR) Score (R) Priority
12.a 50 3 25 P1 2
12.c 50 3 25 P2 3
12.d 38 3 31 P1 1
12.e 50 3 25 P3 4
Table 13: Risk and priority

The highest risk gap has a priority code of 1, so this CAP is assigned the highest priority. The three
remaining controls have similar excessive residual risk, and so they may be ordered according to their
priority codes: 12.a (P1), 12.c (P2) and 12.e (P3).

For more information on alternate risk treatments (i.e., transference, avoidance, and acceptance), refer
to the HITRUST Risk Analysis Guide.

Note, this step includes the following elements of the DHS risk analysis process as modified to
accommodate use of a control framework:

 Rank risks and determine risk treatments

 Make contextual adjustments to likelihood & impact, if needed, as part of the corrective action
planning process

Step 7: Implement Action Plan :

Step 7: Implement Action Plan

Inputs Activities Outputs
[Link] implementation 1. Implement actions by 1. Project tracking data
plan priority
2. New security measures
2. HITRUST RMF [Link] progress against plan implemented
 3. Monitor and evaluate
progress against key risks using
metrics or other suitable
performance indicators
Table 14: : Implement Action Plan

The organization executes the CAP and tracks its progress over time, ensuring that gaps are closed and
risks are monitored. CAPs can be used as the overarching document to track all capital (project) and
operational work performed by the organization to address gaps in its Target Profile.

A complete CAP should include, at a minimum, a control gap identifier, description of the control gap,
CSF control mapping, point of contact, resources required (dollars, time, and/or personnel), scheduled
completion date, corrective actions, how the weakness was identified (assessment, CSF Assessor, date),
date identified, and current status.

Note, this step includes the following element of the DHS risk analysis process as modified to
accommodate use of a control framework: Implement corrective actions and monitor the threat
environment.

Fig7:Ransomware attacks on healthcare organizations and patient records

After the attack: Ransomware response actions:

When facing a ransomware attack, it’s best to have a playbook of what to do. The majority of
ransomware attacks are still initially spawned by malicious documents or malware. We recommend
ensuring your team takes the below prescribed actions to stop ransomware attackers early

Remediation steps:

• rebuilding systems from known-good baseline images to counter undetected threats.

• scanning systems with an up-to-date anti-malware solution to remove malware and related artifacts.

• blocking malicious domain(s) and IP addresses. This should be performed at all appropriate network
filtering and domain name server devices such as firewalls, web proxies, switches, and DNS servers.

• terminating malicious processes on the compromised endpoint(s) identified.

• quarantining affected endpoints from the network.

• locking affected compromised account(s) until the credentials can be rotated.

• changing affected account(s) password(s) as soon as possible to prevent an attacker from leveraging
the credentials to access services.

• determining whether other users received malicious communications and removing them from all
mailboxes.

• blocking the sender’s email address (if applicable).

Mitigation steps:

• removing a user’s domain account from the local administrator group. User accounts with
administrator rights allow for automated and targeted attacks to interact with system-level privileges,
including dumping credentials, modifying firewall rules, disabling security controls, and deploying
malware. If you need some direction, Microsoft’s LAPS is a great tool to manage local administrator
passwords.

• conducting phishing-based user awareness training and know how to forward suspicious links to the IT
security group for analysis.

• disabling execution of macros in the Microsoft Office suite from untrusted locations via Group Policy.
Office macros account for approximately 98% of Office malware; disabling macros significantly
decreases the attack surface of user workstations.

• ensuring unique passwords for local administrator accounts (if applicable). Local administrator account
passwords should be unique per system to prevent lateral movement due to local credential
compromise.

• implementing application whitelisting for critical systems, such as domain controllers and Exchange
servers. Application whitelisting reduces the likelihood that attackers could execute malware or
unapproved utilities, and is less labor-intensive to implement on systems with static configurations.

• creating separate user accounts for privileged and non-privileged domain activities. Privileged domain
accounts should only be used when required to perform maintenance or other system administration
activities, and non-privileged user accounts should be used for normal daily activities.

• reviewing URL and firewall outbound access policies and blocking high-risk categories (adult material,
games, gambling, advertisements, peer-to-peer file sharing, Dynamic DNS, as well as categories such as
spyware, phishing, keylogging, and malicious mobile code).
• following vendor-recommended guidelines for security settings on Windows, Mac, and Linux
platforms.

• preventing activation of OLE packages in Microsoft Word to prevent users from launching malicious
packages.

Process Summary :
This implementation approach can help organizations leverage the HITRUST RMF to establish a strong
cybersecurity program or validate the effectiveness of an existing program. It enables organizations to
map their existing program to the NIST CsF, identify improvements, and communicate results. It can
incorporate and align with processes and tools the organization is already using or plans to use.

The process is intended to be continuous, repeated according to organization-defined criteria (such as a

specific period of time or a specific type of event) to address the evolving risk environment.
Implementation of this process should include a plan to communicate progress to appropriate
stakeholders, such as senior management, as part of its overall risk management program. In addition,
each step of the process should provide feedback and validation to previous steps. Validation and
feedback provide a mechanism for process improvement and can increase the overall effectiveness and
efficiency of the process. Comprehensive and wellstructured feedback and communication plans are a
critical part of any cybersecurity risk management approach.

Additional Resources to Support Framework Use Goals :

The use of the HITRUST RMF along with other tools and approaches discussed above is an important
step Healthcare Sector organizations can take to align their cybersecurity programs with existing sector-
level goals and guidelines. The approaches below can also be used to increase knowledge and enhance
cybersecurity practices.

 Council on CyberSecurity (CsC) Critical Security Controls for Effective Cyber Defense:30 The Critical
Controls for Effective Cyber Defense (the Controls) are a recommended set of actions for cyber defense
that provide specific and actionable ways to stop today's most pervasive attacks. They were developed
and are maintained by a consortium of hundreds of security experts from across the public and private
sectors. An underlying theme of the Controls is support for large-scale, standards-based security
automation for the management of cyber defenses.

 DHS Cyber Resilience Review (CRR):31 The CRR is a no-cost, voluntary, non-technical assessment to
evaluate an organization’s operational resilience and cybersecurity practices. The CRR may be conducted
as a self-assessment or as an on-site assessment facilitated by DHS cybersecurity professionals. The CRR
assesses enterprise programs and practices across a range of ten domains including risk management,
incident management, service continuity, and others. The assessment is designed to measure existing
organizational resilience and provide a gap analysis for improvement based on recognized best
practices.
  HHS Security Risk Assessment (SRA) Tool:32 ONC, in collaboration with the HHS Office for Civil Rights
(OCR) and the HHS Office of the General Counsel (OGC), developed a downloadable tool to help guide
organizations through the HIPAA risk assessment/analysis process. The SRA Tool presents a question
about your organization’s activities for each HIPAA standard and implementation specification, and then
identifies what is needed to take corrective action for that particular item. Resources for each question
help assessors understand the context of the question, consider the potential impacts to PHI if the
requirement is not met, and provide the actual safeguard language of the HIPAA Security Rule.
DISCLAIMER: The SRA Tool is provided for informational purposes only. Use of this tool is neither
required by, nor guarantees, compliance with federal, state, or local laws. Please note that the
information presented may not be applicable or appropriate for all healthcare providers and
organizations. The Security Risk Assessment Tool is not intended to be an exhaustive or definitive source
on safeguarding health information from privacy and security risks.

 ISO 27799:33 ISO 27799:2008 specifies a set of detailed controls for managing health information
security and provides health information security best practice guidelines. By implementing this
International Standard, healthcare organizations and other custodians of health information will be able
to ensure a minimum requisite level of security that is appropriate to their organization's circumstances
and maintain the confidentiality, integrity, and availability of personal health information.

 NIST HSR Toolkit:34 The NIST HIPAA Security Toolkit Application is intended to help organizations
better understand the requirements of the HIPAA Security Rule, implement those requirements, and
assess those implementations in their operational environment Target users include, but are not limited
to, HIPAA covered entities, business associates, and other organizations such as those providing HIPAA
Security Rule implementation, assessment, and compliance services. Target user organizations can range
in size from large nationwide health plans with vast information technology (IT) resources to small
healthcare providers with limited access to IT expertise.

 NIST SP 800-66:35 Federal guidance intended to help educate readers about information security
terms used in the HIPAA Security Rule and improve understanding of the meaning of the security
standards set out in the Security Rule; direct readers to helpful information in other NIST publications on
individual topics addressed by the HIPAA Security Rule; and aid readers in understanding the security
concepts discussed in the HIPAA Security Rule.

DISCLAIMER: This publication does not supplement, replace, or supersede the HIPAA Security Rule itself.

Final recommendation:
If this all sounds complicated, that’s because it is. Ransomware continues to evolve to evade the
technological solutions we have in place; it is time that all of our security programs rise to support the
tools.

The best solutions in security always involve people, process, and technology. Yet, our security programs
consistently favor the technology, leaving the people to struggle with overwhelming data and
inconsistent processes.

Encourages all security teams to build a ransomware defense plan with proper security hygiene,
defensive tactics, and a continuity plan to better prepare and respond to ransomware attacks.
Finally, a ransomware plan is useless unless it is practiced and kept up to date. All security staff should
rehearse what to do when responding to a ransomware scenario and be prepared to act if a
ransomware attack was successful

Conclusion :

Cybersecurity governance in healthcare is critical to safeguarding sensitive data, ensuring regulatory compliance,
and maintaining patient trust. By adopting a comprehensive cybersecurity framework, conducting regular risk
assessments, investing in advanced security technologies, and fostering a culture of security awareness, healthcare
organizations can effectively manage cyber risks. Collaboration and information sharing among stakeholders
further enhance the overall security posture of the healthcare sector. As the threat landscape continues to evolve,
ongoing vigilance and adaptation of cybersecurity strategies will be essential to protect healthcare systems and
patient information.

This paper provides an overview of the critical aspects of cybersecurity governance in the healthcare sector, from
the importance of protecting sensitive data to recommended strategies for robust security measures. The dynamic
nature of cyber threats necessitates continual improvement and adaptation of governance practices to safeguard
valuable healthcare information.