Webinar Recap: Software Supply Chain Risk – Effective Third-Party, “Nth”-Party Management
The top 2 enforcement actions by the Department of Health and Human Services and OCR in 2021 were: 1) Patient Right of Access to their medical information and 2) ransomware attacks. In 2021 there was a 21% increase in cyberattacks in the Healthcare Industry. Supply chain attacks are an emerging kind of threat that target software developers and suppliers. The goal is to access source codes, build processes, or update mechanisms by infecting legitimate apps to distribute malware. The proliferation of third-party, patient-facing technologies makes healthcare organizations more vulnerable. When a single organization has multiple apps or technologies integrated into its systems, any of these technologies could be the weak link and act as a point of entry.
Jim explained that third-party attacks leverage trust between two or more organizations, making them difficult to defend against. Third-party attacks allow attackers to breach multiple targets at once, providing attackers with both scale and efficiency. A traditional cyberattack targets a person, organization, etc. which then gives the attacker access into that one organization’s data or systems. Phishing emails are the most common way used to gain access.
Third-party attacks work a bit differently in that an attacker will try to compromise a vendor. Once the vendor is successfully compromised the attacker then leverages the trust relationship between the vendor and ALL the vendor’s customers to (potentially) compromise all the customers’ systems and data. The initial attack takes the same amount of effort for the attacker, but the payoff is orders of magnitude higher.
Types of third-party attacks:
- True third-party attacks: one of your vendors is attacked and the attacker then uses that to get to you. (Ex. Target in 2013 where Target’s HVAC vendor was compromised)
- “Nth”-party attacks: one of your vendor’s vendors is attacked and then the attacker pivots to get to your vendor and then to you. (Ex. The law firm that your vendor uses is attacked, leading to an attack on your vendor, and then from the vendor to you. Law firms are a very popular target right now because of this leverage!)
- Software supply chain attacks: some piece of commonly used software is attacked, usually by inserting malicious code into the patch cycle (Ex. Solar Winds attack in 2021). When the patch is pushed to all the vendor’s customers, all the customers get infected as soon as they apply the patch.
- Note: this type of attack is rare and requires a high level of sophistication. DO NOT be hesitant about deploying patches. Unpatched environments create a much higher level of risk!
As a covered entity or business associate who engages a vendor, it is your responsibility to understand the completeness of the vendor’s security control environment. One tool we use to do this is leveraging established and accepted security frameworks that provide either guidance or tools to ensure security. There are many widely accepted security frameworks that describe the controls (“safeguards” under HIPAA) that are appliable to a given type of business or situation. These frameworks are designed to provide “commercially reasonable assurance” that the vendor is meeting the minimum legal requirements for security controls. It is important to understand the different frameworks and the types of assurance they offer.
Before diving into the different frameworks and some of the differences between them, let’s take a look at the three types of controls that are measured by the frameworks:
- Administrative Controls – these are typically policy (what to do or not to do) and procedure documents (how things are to be done).
- Technical Controls – firewalls, anti-virus software, and encryption are all examples of technical controls
- Physical Controls – examples include having designated secure areas for people, data, and systems with locked doors and secure badge entry systems
One way to differentiate between the types of security frameworks is to look at those that are externally certified by an auditor vs. those that may not be. It is important for HIM leaders to be aware of these frameworks so that they can adequately evaluate a vendor and the vendor’s security prior to signing a contract for service from them.
Risk management frameworks that don’t necessarily provide external validation and certification include:
- NIST – National Institute of Standards and Technologies (nist.gov): This is required by law for all Federal agencies and many State agencies and for companies wanting to do business with those companies. Highly flexible because the same framework has to be applied to agencies as different as NASA and your local Parks & Rec department. Because of this it can be highly complex to implement. Because it is issued by the Federal Government, it is considered the “gold standard” from a legal perspective.
- CIS Critical Controls – Center for Internet Security (cisecurity.org): Widely used commercially for performing rapid assessments of the most critical controls. Very simple and flexible and is easily customized to any type and size of business. Focuses highly on the technical controls that have been proven to be the most effective in stopping real-world attacks.
- HIPAA Security Rules: HIPAA is also a type of framework that provides both required and “addressable” safeguards (i.e., controls) that covered entities and business associates must follow. One of HIPAA’s safeguards is that it requires detailed Business Associate Agreements (BAAs) to be in place not only for all contracts between covered entities, and between a BA and their vendors. But it’s important to note that just having a Business Associate Agreement that requires the vendor to be HIPAA compliant does not in itself necessarily constitute due diligence on the part of the covered entity; additional due diligence is often required. Another important but often overlooked HIPAA safeguard is that all covered entities and business associates are required to perform an annual HIPAA-centric security risk assessment, and these assessments (or the lack of them) are often used by OCR to determine the severity of penalties. Make sure that you and all of your vendors are doing these!
Risk management frameworks that do provide required external auditing, verification, and certification include:
- SOC 2 – American Institute of Certified Public Accountants (aicpa.org)
- There are other types of “SOC” audit reports, but “SOC 2” is the one that applies to a company’s security controls
- Annual audit performed by an accredited CPA firm
- Can be Type I (“point in time”) or Type II (“over a period of time”)
- Failing any of the Trust Criteria can result in a “qualified” report, at auditor’s discretion
- Not as prescriptive as some other frameworks because the company has the flexibility to write its own control statements
- Should be done every year, but “Bridge Letters” may be issued by the company if they don’t do a SOC 2 within a given year. The Bridge Letter is the company’s official statement that there have been no significant changes in their control environment.
- Typically, 75 to 150 controls that are audited
- HITRUST r2 Validated Assessment – (hitrustalliance.net)
- There are several HITRUST assessments that provide varying levels of assurance; the R2 validated assessment provides the highest
- Full audit every other year, with “interim” assessments in the off years
- Failing any of the 19 domains results in failing the certification
- Very prescriptive, controls are provided based on scoping, and then scored based on the completeness of policy and procedure documentation plus evidence that the control has been implemented.
- Typically, 300 audited controls, and can be over a thousand depending on the scoping
- Leverages NIST and provides a report that shows how the company is doing against the relevant NIST standards.
- ISO-27000 – International Standards Organization (iso.org)
- An internationally recognized standard that provides an externally audited certification that is accepted around the world, not just in the US. In healthcare this is typically used by medical device manufacturers who sell in multiple countries, and by larger international law firms.
As HIM leaders are charged with protecting PHI, we should be looking for vendors who are leveraging security frameworks that provide some level of externally validated certification. We don’t have to be experts in all the details of cyber security, but we need to understand what these various certifications mean when evaluating a vendor. Understand not just your third-party, but also your “Nth”-party risks, all the way down to your entire vendor supply chain. Require ALL vendors who provide software or who have any kind of direct access to your systems to have at the very least a SOC 2 Type II report that is renewed annually. HITRST is a high bar for small vendors but is rapidly becoming the standard in healthcare especially for larger technology vendors who deal with large volumes of PHI, such as Verisma. Any certification requirements should be written into your Business Associate Agreements. Ask the vendor to supply a SOC 2 or HITRUST r2 certification report. Read reports and ask questions about findings and corrective action plans. It is possible for your vendor to be certified but still have gaps. Understanding any relevant gaps is key to understanding and managing your risk, so read the reports carefully! Do an annual inventory of your vendors and identify what they have access to and assess whether the access they have is the minimum required for them to do their job.
In conclusion, protecting PHI from cyberattacks is not just the job of the IT Department, but it is also the responsibility of Healthcare Leaders to ensure the many vendors we deal with and who have access to our PHI are certified to protect our most valuable information.