This document was submitted by the Massachusetts Health Data Consortium (MHDC) and its Data Governance Collaborative (DGC) on June 3, 2024 in response to the CISA Cyber Incident Reporting for Critical Infrastructure Act (CIRCIA) Reporting Requirements NPRM (CISA-2022-0010) posted in the Federal Register on April 4, 2024 and found here:
Founded in 1978, MHDC, a not-for-profit corporation, convenes the Massachusetts’s health information community in advancing multi-stakeholder health data collaborations. MHDC’s members include payers, providers, industry associations, state and federal agencies, technology and services companies, and consumers. The Consortium is the oldest organization of its kind in the country.
MHDC provides a variety of services to its members including educational and networking opportunities, analytics services on both the administrative and clinical side (Spotlight), and data governance and standardization efforts for both clinical and administrative data (the Data Governance Collaborative/DGC and the New England Healthcare Exchange Network, respectively).
The DGC is a collaboration between payer and provider organizations convened to discuss, design, and implement data sharing and interoperability among payers, providers, patients/members, and other interested parties who need health data. It is a one stop interoperability resource. The DGC primarily focuses on three areas:
This section comments on the general approach taken by CISA or provides comments on items that cross multiple sections of or items in the plan.
We recognize that this proposed rule was likely written prior to the major cyber incident at Change Healthcare this spring and urge CISA to consider how this rule would have impacted the healthcare industry at a time when it was already burdened by the outage had it been in place when the incident occurred.
This incident affects nearly every organization working in the healthcare space in some way. Most providers lost some or all of their ability to file claims, many lost their ability to request prior authorizations, and some to discover the coverage limitations of patients being seen and thus maximize their chances of reimbursement, and so on. Other types of organizations were affected in other ways.
By the rules set forth in this proposed rule, each of those organizations would be required to independently report the incident not of their making and located within a third party because it significantly disrupted their business practices. CISA would likely have gotten hundreds of thousands of reports, if not millions (with supplemental reporting considered) about a single incident. Providers would have been asked to calculate the costs on their business at a time when their business was under extreme stress and likely having cash flow issues because of the incident. These costs are still ongoing now, months after the initial incident, and so supplemental reports and related extra administrative burdens would likely be mandated for many months.
We understand that one goal is to be able to determine how many organizations are affected by specific incidents, how those incidents affect different organizations differently, whether analysis shows trends or other actionable analysis for specific types of organizations and/or incidents, and so on, but we question whether the significant added burden on those organizations combined with the absolute glut of reporting that CISA would be getting to review is really needed to meet the intent of the CIRCIA law and if the information gained would be worth the effort expended on all sides.
We do not necessarily have a magic answer here, but certainly as much of the report obligation as possible should be moved closer to the source of the incident. In many cases, the organizations affected by this particular incident use a vendor who uses a vendor who uses Change Healthcare so they didn’t even know they would be affected until stuff stopped working for them. Perhaps there is a way to leverage the chain of vendors to get some or all of the required data in a way that limits the report requirements for the healthcare providers, payers, and other unsuspecting users, especially those several steps removed from the original incident source.
Separate and apart from reporting, two things that could be separately mandated (likely outside of this rule) that might help are the following:
The Change Healthcare incident is an extreme example of the single incident impacting multiple covered entities case, but participants in our Data Governance Collaborative note that it is not uncommon for multiple covered entities to be impacted by an incident that occurs in systems they do not directly operate; for many organizations this is more likely than experiencing a direct attack given that incidents at health IT vendors or other third party organizations will likely have a larger effect than incidents directly impacting their customers individually. Thus, a more efficient and effective solution for reporting these types of increasingly more common incidents is likely needed.
We believe this rule should provide more specifics about what to include in the calculations regarding the cost of a cyber incident and how to calculate those costs. It is easy to determine actual fees paid to mitigate ongoing incidents, but are all internal employees supposed to track time and have their salaries included in the costs? Are lost revenues from the inability to develop new revenue-generating things because those resources were spent on the cyber incident supposed to be tracked and, if so, how? What about lost interest on revenues that were delayed while systems were down? And so on.
Without some sort of consistent rules and expectations, there is no useful way to calculate or compare the costs of cyber incidents writ large, and the value of collecting this information – likely time consuming and expensive to calculate – is minimized.
Our Data Governance Collaborative notes that this rule frequently uses terms like substantial or significant without a clear definition of what they mean. While in some cases, such as what qualifies as a substantial cyber incident, there are some minimum thresholds laid out, even they rely greatly on judgement calls and interpretation that could legitimately be applied differently by different organizations even when all are acting in good faith. We urge CISA to be explicit whenever possible, and to provide as much guidance as possible (such as that minimum floor criteria) when it cannot.
This section will list specific questions asked in the proposed rule and our responses to them.
Participants in our Data Governance Collaborative note that there may be significant challenges in meeting reporting requirements when a covered entity uses third parties/vendors to perform or host health IT functions. Among other potential difficulties, they specifically point out:
In addition, our Change Healthcare Incident comment above touches on what reporting requirements may be reasonable for covered entities suffering from incidents stemming from third parties, particularly when that third party incident affects multiple covered entities.
In general, we agree with the approach that the sophistication or novelty of the tactics used in a cyber incident should not drive whether it needs to be reported. However, we do believe that zero-day vulnerabilities should be considered special cases and always be reported (note that we had one contrary opinion, supplied outside of our interactive discussions, that felt this would be overkill and overwhelm the system). See our comment below for more on this.
Participants in our Data Governance Collaborative note that many of the more impactful incidents in the healthcare sector have come from exploitation of zero-day vulnerabilities and from entities not applying patches to software they use when patches become available (including the recent Change Healthcare incident discussed above, which was caused in part by a vulnerability in unpatched remote access software that was a known vector for attacks). Further, once a zero-day vulnerability is discovered and exploited, it is often a vulnerability in many other systems unless or until a patch fixing it is widely available and applied. Thus, if even a minor incident resulting from a previously unknown or unfixed zero-day vulnerability is reported, that report could prevent many other more significant incidents from occurring by being the catalyst for patch development or for indicating the need for wider promotion of patch availability/the importance of applying a related patch.
As such, they suggest that, contrary to CISA’s current plans in this area, requiring reporting of incidents resulting from zero-day vulnerabilities may be warranted regardless of the severity/impact of the incident by other measurement criteria once the cause of the incident is known to be a zero-day vulnerability. Specific suggestions include reporting on whether relevant patches were available at the time of an incident, whether they had been applied, and if not applied, how long they had been available/whether any pre-application testing was underway.
Our Data Governance Collaborative reviewed the criteria specific to the Healthcare and Public Health sector and feels some adjustments would be prudent.
First, while it is likely most payers would meet the size criteria, not all of them do and the loss of a payer would significantly disrupt care for all patients using that payer. Further, depending on the portion of patients under a particular provider’s care using that payer, the temporary loss of revenues from a payer can cause significant disruption to the ability of a provider to successfully operate and meet its ongoing financial obligations. Thus, we believe payers are just as much part of the healthcare sector’s critical infrastructure as providers and should be treated as such.
Secondly, we note that neither medical device companies nor pharmacy benefit managers are listed as part of the entities considered part of the Healthcare and Public Health sector. We believe both should quality and should be subject to this rule as entities in one of the 16 critical access sectors should they meet the size threshold or other requirements (we note that certain medical device companies are called out in the sector-specific rules so that aspect is already covered).
Third, we note that the size of a health IT developer/vendor Is often not commensurate with the impact it has in the industry. Software can be developed, tested, and sold with a relatively small number of people involved and some small vendors may fill large roles in the health IT ecosystem. We believe that all health IT developers/vendors, regardless of size, should be covered by this rule. We know that in some cases, their incidents will also need to be reported by other covered entities (see our Change Healthcare comment above), but even if that’s the case, the central data around the incident, how it occurred, and how to prevent future similar incidents clearly lies with the entity that was directly affected – the health IT developer/vendor. Regardless of whatever other reporting is received from users of the affected systems, without the core reporting from the directly affected entity reconstructing the incident or learning much of value from a prevention standpoint is likely not possible.
As a general note, CISA notes that one reason they did not explicitly include some of the organizations above was the belief that most cyber incidents affecting them are data breaches and those are not the main focus of CIRCIA. However, in our experience, when a breach of any sort occurs, the affected entity often closes all external connections as a protective/cautionary measure and the entire business is disrupted for a time until the entity is confident it is safe to reopen their connections to the outside world. Thus, while data breaches may not be the major focus of CISA for this rule, they do affect the ongoing ability of an entity to conduct normal business until either investigation has been completed or any potential issues/vulnerabilities/risks beyond data loss are mitigated.
We believe that, in many cases, a size-based criterion makes sense, but CISA should be cautious about applying it universally as there are many types of organizations that fill an outsized role with a small number of employees or with relatively small revenues compared to those of larger corporations doing other types of business (see our comment about health IT vendors above). This becomes a balancing act between burden vs benefits of reporting, including the likelihood of outsized impact.
If the general size-based criterion was removed, we believe the majority of entities in the Healthcare and Public Health Sector SSP list should be covered by this rule, as well as medical device manufacturers and pharmacy benefit managers.
In general, we support this exception with a data sharing agreement that allows CISA access to information about the incidents that otherwise would have been covered by CIRCIA.
We approve of standardized, structured data and believe this is likely the best way to ensure relative consistency to allow better analysis. We did receive one comment (outside of our interactive discussion) that indicated concern that a web-based form would not be scalable enough to support the level of reporting this rule is likely to generate (see further related comments below).
We approve of this as a backup only, with the expectation that someone is entering the reported data into the web-based system on behalf of the caller and the mechanism of reporting is noted in the provenance of the entered data.
Participants in our Data Governance Collaborative were confused by this option, believing it the most likely to be compromised/inaccessible immediately after a cyber incident. In general, organizations shut down any and all of their direct external connections after experiencing a cyber incident and thus direct machine-to-machine access would likely be forbidden. Further, it seems somewhat dangerous to allow, let alone encourage, this until such time as a covered entity is absolutely certain there are no residual artifacts of an incursion that could potentially be spread to other systems should a connection be allowed.
We note one contrary opinion, supplied outside of our interactive discussions, that believes a continuous integration pipeline for reporting cyber incidents would be helpful because “these types of incidents as described, happen every day, sometimes multiple times a day” so having to report them individually via a web form would not be sustainable.
We support this. There is no reason to have different reporting mechanisms depending on whether an incident is reported directly or via an approved third party.
In general, we approve of the requested content, although we have some additional suggestions in our zero-day vulnerability comment above and it may be worth considering whether there are other types of incidents that may warrant type-specific additional data requirements.
We also wonder if some of the requested information might be further refined into more granular structured data to better categorize and analyze results. For example, while some ability to provide descriptive content is clearly needed, the basic details of a report could be reported via a set of specific enumerated value lists (always offering other and/or N/A options) supplemented by the longer text description.
There could, perhaps, be a bit more clarity on the specific requirements around considering an incident resolved. Does that mean analysis complete? Mitigation efforts for future incidents complete? An expectation that no new information will be obtained regardless of current state?
It is unclear how many of these enforcement actions would be public. Presumably subpoenas are public documents, but are RFIs also made public or are they private? What about acquisition, suspension, and debarment procedures? Clarification on what can be expected on this front seems warranted. We suggest that differentiating between the existence of an action versus the specific contents may make sense here (i.e. the existence of X being public or private versus the contents of X being public or private) and that the existence of enforcement actions should be public if possible whereas their contents likely should not be in many cases, or should not be without redactions per the information protections outlined in the proposed rule.