Last year, the Department of Health and Human Services’ (HHS) Office for Civil Rights (OCR) filed 22 HIPAA resolution agreements totaling over $1.12 million in settlement fines. In just the past two months, financial penalties have already surpassed that number, with two settlements totaling $1.27 million. This trend points to HHS becoming more stringent with its enforcement of HIPAA, a trend that could be driven by the increase in healthcare ransomware attacks and opportunistic nation state adversaries eyeing the industry as a key target. 

In my 25+ years working in cybersecurity, the majority of my time was spent in the healthcare industry, where I held roles such as HIPAA security officer, information security manager, health information technology director, and security auditor for several large health systems. 

In these roles, and still today, the HIPAA Security Rule has left me wanting more.  

The vague nature of the Rule leaves much of the compliance requirements up for interpretation. The Rule was written to ensure that healthcare organizations are doing what is necessary to protect ePHI – yet there is no explicit mention of penetration testing. 

HIPAA is notorious for telling security leaders what needs to be done to achieve compliance, without explaining best practices to get there. Let’s eliminate the gray area and examine penetration testing’s critical role in HIPAA compliance. 

What is HIPAA Penetration Testing? 

I will start this section off with a harsh truth: There is no such thing as a “HIPAA Penetration Test”. Though we often see the term used in marketing, pentesting has long been an unwritten component within the Security Rule. You can review the full Rule online here.  

The following items within the administrative safeguards section touch on security testing criteria: 

• Standard 45 CFR 164.308(a)(1)(i): Security management process. Implement policies and procedures to prevent, detect, contain, and correct security violations. 
  • Implementation specifications 45 CFR 164.308(a)(1)(ii)(A): Risk analysis (Required). Conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information held by the covered entity or business associate. 
• Standard 45 CFR 164.308(a)(8): Evaluation. Perform a periodic technical and nontechnical evaluation, based initially upon the standards implemented under this rule and, subsequently, in response to environmental or operational changes affecting the security of electronic protected health information, that establishes the extent to which a covered entity’s or business associate’s security policies and procedures meet the requirements of this subpart. 

Within this section, you will also find standards and implementation specifications around workforce security, information access management, security awareness training, and contingency planning. All of which can be evaluated and validated through a variety of offensive security engagements, such as pentesting, red teams, breach and attack simulation, or social engineering engagements. 

HIPAA does a great job highlighting the requirements clearly, without providing actionable steps to achieve compliance. To help, we put together a checklist to ensure your security testing program meets the needs of Security Rule. 

HIPAA Pentesting Checklist

  Continuous Penetration Testing

HIPAA requires “periodic” evaluations, particularly in response to environmental or operational changes. The rate of change in healthcare environments has increased exponentially over the years. Continuous pentesting can take form of more frequent tests enabled by a penetration testing as a service (PTaaS) delivery model, or through an attack surface management platform. As a rule of thumb, key moments of change could include version upgrades of software that houses ePHI or architecture changes. At the very least, perform penetration tests on a quarterly basis. 

  Risk Prioritization, With an Emphasis on Application Security

Are you targeting the applications that pose the greatest risk to your sensitive health information? A pentest that meets HIPAA standards should not stop at vulnerability discovery. Whether you are pentesting internally or working with a third-party partner, work together to identify which application pentests should be prioritized – and, more importantly, align on vulnerability severity definitions and remediation timelines based on your organization’s risk profile.  

  Validation of Security Controls

It is important to note that pentests can and should also be used to validate your security controls. Are your pentests alerting you to flaws and policy gaps within your identity and access management, threat detection, and other security controls implemented? Additionally, consider breach and attack simulation (BAS) platforms to help evaluate and improve the effectiveness of your detective controls. Learn about the top use case for BAS technology in this Gartner report.  

  Comprehensive Reporting and Historical Data

Standard 45 CFR 164.316(a) in the HIPAA Security Rule highlights the policies and procedures and documentation requirements. According to the standard, healthcare organizations must maintain a written record of each action, activity, or assessment. They also must retain documentation for six years from the date of its creation. Bonus points to pentesting partners who track and trend historical pentesting reports in a single platform. 

The Relationship Between Pentesting and Privacy 

HIPAA and other privacy regulations (GDPR, FERPA, CPRA) are in place to protect data from being exposed to unintended recipients. To accomplish this, these regulations all require that an organization’s IT Infrastructure must be secure. 

As privacy regulations and standards have evolved, I’ve found that if you are compliant with PCI DSS and are HITRUST certified, it is likely you will be HIPAA compliant as well. Both are significantly more prescriptive and actionable than the HIPAA rules and can help you proactively secure ePHI. 

Securing an IT infrastructure involves many steps that we will not get into here, but instead will concentrate on how to ensure that an environment remains in a constant state of security. Regular and sometimes continuous penetration testing is the most effective way to provide continued assurance. 

Penetration Testing is used to identify how a hacker can gain access to an environment and provide an organization with a roadmap of how to address those vulnerabilities and findings. Pentesting does not inherently make you secure; it makes you aware of your security flaws. 

By conducting regular penetration testing, an organization can check that they have successfully remedied known issues and identify any new concerns due to new equipment, configuration changes, or even missed patches on software or hardware. 

A Proactive Approach to HIPAA Compliance 

Healthcare security and IT teams should approach HIPAA with a foundational mindset. The requirements outline what you should already be doing and thinking about on an ongoing basis.  

Mature healthcare organizations have comprehensive vulnerability management and pentesting programs in place. Pentesting is a powerful first step towards compliance – when done right. 

Be proactive, not reactive. Be a leader, not a pawn. 

NetSPI’s penetration testing solutions can help you chart a clear path to HIPAA compliance. Contact us today.

The post Pentesting: The Forgotten HIPAA Requirement appeared first on NetSPI.

Even the majority of board members across the globe view cybersecurity as a business risk versus a technology risk, according to a survey from Gartner. It makes sense why most security leaders are working hard to shift to this model as organizations are swamped with vulnerabilities – notably, high-severity, business critical vulnerabilities. 

Last year, a record number of critical vulnerabilities were disclosed to the National Institute of Standards and Technology (NIST): 10,342 (source: Security Magazine). A check-the-box, compliance-driven vulnerability management program will no longer cut it. As serious vulnerabilities are on the rise, it’s up to us to determine which are fixed first. 

Before you can successfully implement a risk-based program, there are four realities you must face: 

1. You will have security vulnerabilities that you will never address 
2. CVSS scores do not represent business risk 
3. To have an effective risk-based program, we have to lessen the gap between IT and business  
4. We must adopt a “we’re all in this together” mentality to tackle cybersecurity risk 

In this blog post, I’ll dig into each of these realities and the steps you can take to come to terms with and, in many cases, overcome them. First, a quick primer on risk scoring, a key component to risk-based vulnerability management. 

An introduction to risk scoring 

At NetSPI, one way we’re helping our clients address these challenges, or “realities” as I refer to in this article, is through risk scoring. In simple terms, a risk score quantifies risk for more accurate and efficient vulnerability remediation prioritization.

If you’re a NetSPI customer, you may have noticed the new Risk Overview Dashboard in Resolve, our PTaaS platform. The dashboard features an aggregate risk score, composite risk scores for applications, networks, and cloud, an industry benchmark, the number of open critical vulnerabilities, the riskiest projects or assets, the top 10 highest risks, and more. 

NetSPI’s Risk Score is calculated based on transparent methodology that considers vulnerability risk (impact, likelihood, environmental modifiers, and temporal modifiers), threat actor risk, remediation risk, and industry risk to quantify risk levels on any given asset, project, network, or an entire organization.

Risk scores can be used for remediation prioritization, resource allocation, cybersecurity spend validation, risk management tracking, industry benchmarking, and more. I like to think of it as a behind-the-scenes program manager for risk-based vulnerability management programs – continue reading to learn why. 

You will have security vulnerabilities that you will never address 

It is unrealistic to assume that any organization is vulnerability-free. Once you come to terms with this, risk’s role in vulnerability management becomes a lot clearer. 

You can have the same vulnerability across 6 different assets, but is it wise to fix them all at once? 

Traditionally, this is how many have approached vulnerability management, but the answer is, in most situations, no. It is important to focus on the system with the most risk versus solving the vulnerability across all systems. This holistic approach to vulnerability management is key as it allows you to incorporate business risk into your decisions. 

When you start to factor business risk into the mix, you can identify which assets or systems are most likely to be taken advantage of AND create the most damage if exploited. Then, prioritize remediation, budget, and time accordingly.  

Risk scoring can help expedite this decision-making process. The higher your risk score, the higher priority that system, asset, network, finding, project, etc. And some with very low risk may not warrant remediation at all. 

CVSS scores do not represent business risk 

A Common Vulnerability Scoring System (CVSS) score alone cannot provide a full picture of business risk, but it is a strong starting point for the basis of a risk score. CVSS scores are helpful for vulnerability-specific ratings, but they do not incorporate aggregate factors such as active threat intelligence or correlation to other penetration testing data points.  

Additionally, CVSS scores follow a standard formula, regardless of the size, industry, or other business factors, leaving little to no room for customization. This results in organizations not getting the complete picture of a vulnerability’s potential impact.  

CVSS scores are often used as a metric for return on security investments. I believe they should not be used as such. As an alternative, if you are utilizing a true risk program, risk scoring can be used as a quantitative metric to represent business risk across your organizations. 

To have an effective risk-based program, we have to lessen the gap between IT and business  

There’s a knowledge gap between IT and the business and we cannot achieve a risk-based vulnerability management program until that gap shrinks.  

In the healthcare industry, risk alignment between IT and the business is critical. The business is patient health and safety and its up to security and IT leaders to help the business understand how it directly impacts and protects patient health and safety, whether that’s through protecting Personal Health Information (PHI) or saving lives through ransomware prevention activities. 

This is the same with any business. You have to find common ground between what you’re doing from an IT perspective to show how you’re a part of the business and are critical in the day-to-day operations. 

A simple shift in the way we talk about cybersecurity to business leaders could make a massive difference. A risk-forward approach is key. Here are two examples of this: 

We must adopt a “we’re all in this together” mentality to tackle cybersecurity risk 

Industry benchmarking is an incredibly powerful tool to communicate your risk-based vulnerability management program successes and progress.  

However, we must not fall into the pattern of comparing our programs against others in our industry. There is an analogy that we need to retire. It’s used so often that Red Bull even uses it as the premise for one of its most popular commercials. It’s the idea that, if you’re better than your industry peers, you’re less likely to fall victim to a cyberattack. 

It is important to remember that we’re all fighting the same fight: to eliminate or alleviate the cybersecurity risks that lurk not only in specific industries but across all organizations. We need to work together, not against one another, for the greater good – and a risk-based vulnerability management program is a step in the right direction. Even auditors and cyber insurers are recognizing this shift towards risk-based programs to steer security programs towards maturity. 

With these four realities addressed, there’s no better time to get started. Focus your attention on high-risk vulnerabilities, use risk scores to communicate business risk, shrink the gap between IT and business, and work together to make the shift to a risk-based vulnerability management program a reality for your organization.  

Connect with NetSPI to learn how to achieve risk-based vulnerability management with PTaaS.

The post 4 Risk-Based Vulnerability Management Realities Cybersecurity Leaders Must Face appeared first on NetSPI.