Data breaches are occurring at an unprecedented rate. Between June 2019 and early October 2020, over 564 data breaches affected over 36.6 million patients as posted to the United States Federal government HITECH portal. These patients are at risk for having their identities stolen or sold on alternative marketplaces. Some healthcare entities are working to manage privacy and security risks to their operations, research, and patients. However, many have some procedures and policies in place, with few (if any) centrally managing all their infrastructure risks. For example, many healthcare organizations are not tracking or updating all the known and potential concerns and elements into a centralized repository following industry best practice timetables for auditing and insurance quantification. This chapter examines known and potential problems in healthcare information technology and discusses a new open source risk management standardized framework library to improve the coordination and communication of the aforementioned problematic management components. The healthcare industry would benefit from adopting such a standardized risk-centric framework.
- risk associated with computer communications
- data breaches
- standardized risk library
- risk management
- patient information
- identity theft
- penetration test
- risk assessments
Across the globe, data security is becoming more regulated. For example, in the European Union, the General Data Protection Regulation (GDPR) protects its citizens . In China, the Cybersecurity Law of 2017 was one of the first well known laws passed to protect the data and communications of its citizens . In the United States of America, medical entities in the country’s critical infrastructure are covered under Federal laws to protect patient information. Specifically, the Health Insurance Portability and Accountability Act (HIPAA)  and Health Information Technology for Economic and Clinical Health Act (HITECH)  are Federal-level regulations for covered entities that secure patient-protected health information (PHI). PHI covers a gamut of different identifiers and includes patient names, birthdays, social security numbers, medical record numbers, license plate numbers, biometric data, among a few others. The digital form of PHI is electronic PHI or ePHI. In the United States, vendors and services which are not covered under HIPAA (perhaps because they do not bill patients for services rendered) are regulated by the Federal Trade Commission (FTC) and must self-report health data breaches to the FTC . Furthermore, the European Commission officially ratified the final version of the GDPR to include notification from a breached supervisory authority to be made within 72 hours (or provide reasons for a delay) .
In the United States, both HIPAA-covered and non-covered entities may also be under other legal requirements, such as non-disclosure, confidentiality restrictions, or other security requirements, for other organizational, research, or employee data.
The management within covered groups has historically remained siloed intra-organization where different components of the organizational risk are being managed and decisions made by different units within the organizations without a standardized and well-connected systematic methodology. For example, the legal, audit, budget, health informatics, security, privacy, medical, and information systems teams may all be disjointly managed, causing frustrations in adequately quantifying and coordinating the organizational risks. In such disjoint cases, an exception to an organizational policy may result in unidentified operational risk if the different departments are not consistently coordinated and periodically reviewing, perhaps updating, the associated risks.
This chapter begins by describing data breach risks in HIPAA-covered entities as reported to the United States government that cause patients higher risks for identity theft. Then it integrates current research into building a standardized risk assessment library that enables both inter- and intra-organizational risk coordination. This design facilitates standardizing and communicating risks as well as reasonable internal statistics related to technical and administrative limitations, organizational policy exceptions, and federal legal requirements to inform the business, auditors, insurance companies, and business associates of risks.
2. Patient information data breaches can lead to patient identity theft
In the United States, citizens are protected by federal, state, and potentially smaller sub-state regulations. Each industry sector are potentially under unique legal and other sector-specific requirements. In fact, today most, if not all, states have different personally identifying information (PII) legislation. Historically, these laws are not well understood and are written in most cases by non-technical writers. As such, the legal and technical specifications have gaps both in understanding and in the feasibility of current technological constraints.
2.1 Entities covered under HIPAA
HIPAA requires at least three covered groups, referred to by the law as Covered Entities, to protect health information. Examples of covered entities are: healthcare providers, health Plans, and business associates. Healthcare providers transmit electronic patient information in connection with a Health and Human Services (HHS)-adopted standard transaction. Health plans include insurance companies, health maintenance organizations (HMOs), corporate health plans, and government programs. Business associates are external groups/organizations that perform activities or services on ePHI on behalf of another group covered under HIPAA. Figure 1  shows one year of reports by covered entity to the Office of Civil Rights (OCR).
2.2 Risks in HIPAA-covered entities
Research at large has studied risk management of medical information [7, 8, 9, 10], but not specifically as related by different HIPAA-covered domains. Recent research [6, 7, 11] explores potential concerns for each legally covered segment based on self-report to the US Government as required by the HITECH Act. In the sector-specific threat probability-specific research [6, 7, 11] over a one-year interval, the research showed that different the different domains may indeed have different sources of concerns and issues. For example, healthcare providers and business associates have reportedly different higher probability of concerns to alleviate than health plan entities, as shown in Figure 2 . This indicates that the different domains may need to manage their threats differently by perhaps investing more heavily in different mitigating controls.
2.3 Data breaches reported to the HHS OCR across the USA
The HHS unauthorized data release portal provides the number of affected individuals from the cybersecurity events for each self-reported or discovered data release. Figure 3  shows states across the USA with the most reported individuals, whom are now at risk from the leaking of their patient data. In any given one-year interval, each state may be equally likely to have higher counts depending on the released data size. Further research is needed to determine state likelihood.
2.4 Reported data breach counts per state sorted by number of reports
Another element tracked on the HHS portal is the presence of business associate agreements (BAA). A provider enters into a BAA with an outside party when an outside party receives access to the provider’s ePHI. A properly written BAA somewhat “protects” the provider if the outside party breaches the ePHI. Figure 4  shows state BAA presence notated with by the HHS portal with either a “yes” or “no.” The portal reports are not described, so the research below shows the categorical data as posted to the portal.
3. Risk assessment literature and standards
Risk management has been slowly moving into industry. In the United States, HIPAA mandates risk assessment be in place prior to new technology’s being integrated into an organization.
Recently, in October 2020, Eddy and Perlrotha  reported on a cyber-attack that resulted in a patient death. The attack occurred when “ransomware invaded 30 servers at University Hospital Düsseldorf [,…] crashing systems and forcing the hospital to turn away emergency patients.” This is one of the first ransomware-attack-related suspected deaths reported publicly. In such a high-profile and morbid case, we can see the essential importance for having a standardized language for discussing cyber-risks.
3.1 Risk assessment standards
The United States National Institute of Standards and Technologies (NIST) has produced many Special Publications on Risk Assessments . Figures 5 and 6  show NIST’s generic risk model and risk assessment process respectively. In fact, many organizations around the world are following the NIST Risk Assessment frameworks.
3.2 Automating risk assessments
Risk assessment automation has been proposed in the form of automated penetration testing frameworks [9, 10, 11, 13, 14, 15, 16, 17, 18, 19]. Testing frameworks and automated tools are extremely useful for detecting known bugs and vulnerabilities. However, in general, these tools do not report on the larger risk-assessment picture. Specifically, they may not accurately report on legal requirements or help an organization prepare for prospective data-breach-associated costs. In addition, there is limited (if any) language standardization on risk findings to enable intra- and inter-organizational risk communication, which is essential for subsequent auditing and legal ramifications.
3.3 Framework libraries for malware and software developments
In addition to developing a standardized framework, NIST and MITRE.org have worked tirelessly to produce a standardized dictionary for attack and malware. For example, they have produced the
3.4 Penetration testing reports
As risk management is still clearly its own type of innovation phase within the technology adoption life-cycle, risk researchers are finding a need to communicate risk through standardized language. For example, let us consider a penetration test report. Historically, there is none of the following: (1) a fixed template, (2) a fixed-strategy, or (3) fixed-finding language. Such non-standardization is subject to extreme bias and misrepresentation. In fact, if every internal or external penetration test is written differently, how can any organization fully understand their own risks? Similarly, if every employee in an organization spoke their own verbal language, how could anything be communicated? Historically, industry has focused on standardizing software vulnerabilities and malicious code patterns. A major gap still exists for risk management components, including budgeting for financial penalties and legal ramifications.
3.5 Risk assessment education
Research on risk-assessment education has primarily focused on learning penetration testing techniques . The curriculums discussed in this research neither considers the meta-organizational risk nor risks specifically associated with the medical sector. Schmeelk  fills a literature gap by emphasizing that all the risk components should be strategically aligned in terms of standardization.
4. Risk assessment library considerations
Managing the risk in a medical setting is unique because of specific regulations that come with significant potential financial fines and corrective actions. For example, outside and inside risk management strategies may not properly align. Also, many organizations, especially in healthcare, are employing a task-based ticketing system to track internal processes. These ticketing systems enable the Information System silos and other organizational risk components to entirely misalign and improperly manage risk by using neither standardized nor repeatable language.
Schmeelk  reports that the following five subsections should be included in identifying organizational components. As a centralized library has yet to be created, a working group should focus on exactly what to include in a standardized public-risk-assessment language dictionary. Important historical components are: legal, training, vendor, and system security requirements, as well as organizational controls. A standardized risk-finding library encourages cross-organizational collaboration, communication, auditing, and legal consistency if a case ever goes to court.
4.1 Regulatory requirements
Regulatory requirements encompass a wide range of organizational responsibilities, which can be actual governmental laws and/or industry-specific requirements. Let us discuss both.
4.1.1 Industry-specific regulations
In the United States, medical critical infrastructure entities have both sector-specific regulatory requirements as well as other requirements, such as Payment Card Industry (PCI)-compliance, to consider in risk management . If an organization does not pass PCI (re)compliance auditing, then they are at risk of losing the use of credit cards, among other payment sources under PCI regulations. In the past, organizations would consider themselves a cash-only facility if they lost PCI (re)compliance. Today, with the birth of cryptocurrencies and alternative payment methods not under PCI, losing the use of credit cards might not be as drastic as it has been historically. Other regulations include compliance with those from the International Standards Organization (ISO). Globally, there are many industry-specific regulations that are not necessarily enforceable laws.
4.1.2 Industry-specific Laws
Medical-covered entities under HIPAA/HITECH are subject to audits by the United States Health and Human Services (HHS) Office of Civil Rights (OCR). The OCR manages many civil rights across the United States in addition to HIPAA. Organizational breaches of patient electronic health information of over 500 individuals must be reported to the OCR as ruled in HITECH. Such breaches are both subject to federal fines and corrective actions. The OCR also can audit covered entities at any point in time. HIPAA is a very well-organized law. It has specific mandates for electronic health data requirements, which should be consistently mapped during a risk assessment to appropriately manage organizational risk. HHS lists many documents for guidance on their website, including mappings between NIST frameworks for cybersecurity and HIPAA requirements. These are extremely useful resources for practitioners.
4.2 Training requirements
Security education and training awareness (SETA) needs may occur at the vendor level or as federal, state, or city regulations. They are not only legally mandated in many instances for legal responsibilities, but also are ethical mitigations. For example, employing staff who have not been properly trained on data security and then holding them responsible for data security mistakes is unethical. In fact, in such a case, labor laws may also be violated. Also, in New York State, the loss of employee Social Security Numbers (SSN) through any sort of data breach is a crime subject to legal penalties .
4.2.1 Regulation trainings
Different regulations require different levels of SETA. In the credit card industry, organizations using alternatives to cash which are highly-corporately regulated must protect the data by complying with the Payment Card Industry (PCI) regulation. The PCI Data Security Standard (DSS) requires software developers for services using credit cards to be properly trained to code such systems. In addition, federal laws such as HIPAA also have specific training requirements. Lastly, little work on cybersecurity training is being done at state or city levels; however, proper awareness could be suddenly mandated at these local levels. If an organization or their accepted vendors are missing any of these training requirements, the organization may be financially liable.
4.2.2 Best practice trainings
Training based on current best practices is hard to assess because best practices in cybersecurity mean different things to different people and organizations. Training based on best practices is really subjective. Typically in the USA, organizations follow NIST and the Open Web Application Security Project (OWASP) guidance [14, 29]; however, still no industry-wide standards exist for exactly what best practices entail.
4.3 Service provider requirements
Service providers and vendors may be subject to different potential cybersecurity risk requirements than the actual provider or covered entity. If a covered entity works with a service provider, it should have proper agreements and risk mitigations in place. Two major sources of such agreements are: business associate agreements (BAAs) and other agreements, such as non-disclosure agreements. Let us examine both in the following subsections.
4.3.1 Business associate agreements (BAAs)
Historically, services providers (or business associates) working with a covered entity’s sensitive patient data should have properly formed BAAs in place prior to releasing sensitive data or have a well-formed written legal justification as to why no such BAAs exist. Many HIPAA-covered entities still report breaches where a properly formed BAA was not in place. In such cases, all parties may be considered responsible for the breach by the HHS OCR in the USA.
4.3.2 Non-disclosure agreements and/or other agreements
Business partners may negotiate many different types of agreements and/or partner requirements for their data and products. One popular agreement in healthcare and healthcare research is non-disclosure agreements (NDA). Such agreements require parties not to release information without prior approval. In such a case, malware that makes NDA-protected data public by releasing it on a popular web application du jour, as well as its actual authors, could be faulted to violate the NDA. Cases that fall into this category can have many different negative outcomes, such as legal ramifications, reputational damage, among others.
In addition to NDAs, other Federal or organizational legal regulations may require risk assessments and other services or service-level agreements (SLAs). Similarly, the GDPR requires entities exposed to unauthorized access to notify affected breached individuals within a short timeframe. Violations to such agreements can have extremely negative consequences to the healthcare entities.
4.4 Application and system requirements
Application and system security are typically measured through certifications (e.g., International Organization for Standardization or other sources) or from internal tests prior to product release. HIPAA requires security assessments for systems and applications managing ePHI. Organizations can either develop their own methodologies to communicate risk that are acceptable by covered entities, or the entities themselves can ask to perform such probability assessments for adverse events. When the covered entity is performing the assessment, they must carefully obtain legal authorization to do so in most cases. In general, Information System silos prevent considering a full-threat landscape for the technical component with the legal, budget, and business use cases. Additionally, digital assessments may be filed for HHS OCR audits into the Integrated Risk Management (IRM) system without updates to the overall business threat mitigations. Periodically, teams must carefully reassess and update the stored organizational predicted levels. In such cases, the assessments are more of a risk “impression” rather than an informed, reproducible, scientific informing on the true likelihood and impact of adverse events. Figure 7  provides a high-level overview of different technical security controls reported by NIST. The following subsections identify eight subcategories potentially employed during a risk assessment.
According to NIST , authentication is the process or action of proving or showing something to be valid. Specifically, “The authentication control provides the means of verifying the identity of a subject to ensure that a claimed identity is valid.” The OWASP Application Testing Guide  currently gives ten best-practice tests to perform for authentication: “Testing for Credentials Transported over an Encrypted Channel, Testing for Default Credentials, Testing for Weak Lock Out Mechanism, Testing for Bypassing Authentication Schema, Testing for Vulnerable Remember Password, Testing for Browser Cache Weaknesses, Testing for Weak Password Policy, Testing for Weak Security Question Answer, Testing for Weak Password Change or Reset Functionalities, and Testing for Weaker Authentication in Alternative Channel.” It is important to realize that any best-practice guide at-large lists
4.4.2 Session management
Session management is the data flow between endpoints—typically following a client and server model. A web session is a series of requests and response transactions created by a client after authentication. In most cases, the endpoints communicate with a special identifier to limit re-authentications. Current best practices in session management include session flags, random token generation, and timeout intervals. The OWASP Application Testing Guide  currently lists the following eight session management tests: “Testing for Session Management Schema, Testing for Cookies Attributes, Testing for Session Fixation, Testing for Exposed Session Variables, Testing for Cross Site Request Forgery, Testing for Logout Functionality, Testing Session Timeout, and Testing for Session Puzzling.”
4.4.3 Data-in-transport, data-at-rest, data-in-use
The protection of sensitive information is fundamental to risk management. Data-in-motion is the transfer of material between endpoints. This category changes frequently and includes industry best practices in how to transmit the information, such as confidentiality controls and integrity controls during message transmission. Once information is stored on a system, it is referred to as data-at-rest. Lastly, data-in-use refers to messages in memory. Historically, a concern of data-in-use is that processes and other virtualized components could have improper access to the information.
4.4.4 Authorization and access control
Authorization policies define access capabilities for groups and entities. Access controls, sometimes referred to as permissions or privileges, are mitigating controls to enforce authorization. As such, access controls speak to lowering probabilities against unauthorized access, which could cause loss to data integrity, confidentiality, and availability. The effectiveness and the strength of unauthorized access reduction depend on the correctness of the admittance control decisions and the strength of entry control enforcement. The current OWASP Testing Framework  promotes the testing of four key elements in this security area: “Testing Directory Traversal File Include, Testing for Bypassing Authorization Schema, Testing for Privilege Escalation, Testing for Insecure Direct Object References.”
4.4.5 Auditing and monitoring
Systems and applications should create records for auditing and monitoring. Specifically, archives should be generated before and after critical functions take place. These logs are stored in the system/server backend for regulatory requirements, performance indicators and other analytics. Different components are typically checked during risk management.
4.4.6 Injection and input vulnerabilities
Injections and input vulnerabilities enable maliciously crafted code to change the underlying intended behavior of a system or application. The OWASP Testing Guide  currently lists eighteen common best practice tests, including SQL/NoSQL injection, Cross Site Scripting (XSS), and HTTP injection attacks, among others.
4.5 Organizational control requirements
At the organizational-level, controls such as policies, procedures, physical security and financial budgeting should be considered during an assessment. However, these components of risk management can be managed by entirely different entities.
4.5.1 Policies and procedures
Organizations should have policies in place  at technical, physical, and administrative levels, which are repetitively and consistently followed to avoid different legal ramifications (e.g., from valid discrimination cases to data breaches). Standard operating procedures (SOPs) should also be in place and specifically in writing . Specific procedures, which must be in place at the federal level, include business continuity and disaster recovery plans.
4.5.2 Physical and environmental security
This component describes the physical and environmental security aspects of the system, if any, which are requirements in the United States Federal HIPAA laws. Physical security encompasses the physical environment to lower the probability of a threat occurring in spaces such as public, private, and shared. It also includes ways to protect organizations from fire and other environmental concerns affecting risk.
4.5.3 Budget for adverse effects
Risk assessment traditionally includes developing a budget for adverse effects, such as in the Factor Analysis of Information Risk (FAIR) quantitative uncertainty analysis model. Many organizations are not storing-up financial resources in accordance with the uncertain probability being generated to pay for patient identity protections. Digital Guardian  has various reports on current costs per record; the costs vary with time. Simply indicating that a system is vulnerable to CSRF may really have no budgetary ramification under certain other conditions. Thus, probability of cost concerns inform on the overall organizational probability of concerns and insurance.
The HHS has historically been responsible for enforcing the Privacy and Security Rules of HIPAA . For most HIPAA covered entities, the HHS OCR enforcement of the Privacy Rule began April 14, 2003, and the Security Rule began on April 20, 2005. The web portal currently lists government corrective action plans detailing the causes of potential violations of the HIPAA Privacy and Security Rules. Notably, in October 2020, the OCR posted four announcements, most with either sub-cases or multi-breaches, of case settlement with potential corrective action plans for violations to the HIPAA Privacy and Security Rules.
5. A risk assessment library
Schmeelk  contributed a new open source risk assessment library example to enable researchers, penetration testers, risk assessment managers and institutions to further expand on a consistent risk-assessment findings library with their policies, procedures, organizational controls and legal requirements. As noted in the research bug libraries, dictionaries are being maintained by large organizations but do not include risk-assessment findings, thus complicating risk-management methods. As cited, during experience with internal audits risk assessment, language made analysis next to impossible. For example, modern natural language processing methods would need to take place on penetration tests to evaluate assessment reports among different assessors, each applying different methodologies and terminologies.
5.1 Example risk assessment frameworks
Currently, assessment frameworks are entirely intra-organization. In addition, accessing patient databases is impossible—luckily—in the USA due to HIPAA. That said, NIST has guidance on developing an actual risk-assessment process . However, NIST 800–30, as seen in Figure 5, does not actually specify threat source, threat event, actual vulnerabilities, or impact. The actual language used to describe these components is entirely left up to each organization to develop. Even worse, each risk assessor on the team may, in fact, describe these components differently (i.e., use entirely different words). In such cases, making any kind of accurate meta-analysis about the organizational risk is entirely impossible. Therefore, we argue that risk assessment frameworks need a standardized library to describe the identified risk.
5.2 Example findings library
An open-source library example from Schmeelk  is seen in Figure 8 applying an example-consistent risk language. The library needs to be expanded from industry working groups, similarly to MITER’s CWE and NIST’s BF.
Some important elements for language specification and risk clarification are seen in Figure 8 ; they are the following: vulnerability short descriptive name, vulnerability expanded description, techniques to remediate or mitigate the vulnerability, estimated likelihood factors, estimated impact factors, related organizational policies/standards, related NIST Controls, related HIPAA regulatory requirements, other related legal requirements such as non-disclosure agreements, and estimated breach cost factors for insurance and related required patient identity-theft protection costs/notifications.
These categories listed in the prototype can arguably be expanded or removed. Historically, vulnerability standardization libraries [20, 21, 22] are maintained by major organizations (e.g. MITER) and/or government entities (e.g. NIST). Based on healthcare operation needs, we developed the following descriptions of the prototype categories.
5.2.1 Standardizing the actual risk vulnerability and remediation language
5.2.2 Standardizing the actual risk likelihood and impact language
5.2.3 Standardizing the actual risk associated with policies and NIST controls
Historically, organizations should develop policies and standards to help the organization frame their own cybersecurity stance. The NIST Cybersecurity Framework  (the NIST CSF Tool is seen in Figure 9) is one useful guide for developing an organizational cybersecurity posture and policies/standards.
The category in Figure 8, risk assessment library for the NIST controls, is relevant to mapping mitigating controls to well-known NIST vendor agnostic controls. NIST regularly updates the NIST SP 800–30  to account for industry trends.
5.2.4 Standardizing the actual risk to HIPAA requirements
As Security and Privacy Rules of HIPAA are major and enforceable regulatory legislation in the United States, the related column in the library connects the findings to potential HIPAA regulations. This mapping informs the risk-management process when required regulatory elements are entirely missing or are in jeopardy.
5.2.5 Standardizing the actual risk to other industry-specific regulations
Other regulations, such as PCI compliance , The Sarbanes-Oxley Act (SOX) of 2002 , FTC requirements, service-level agreements (SLAs), state data breach laws , and research non-disclosure agreements, can also play their roles in risk management. For example, SOX “is mandatory. ALL organizations, large and small, MUST comply .” Organizations allowing customers to pay with credit cards may directly or indirectly be under PCI compliance. The column
5.2.6 Standardizing the actual budget to estimate breach-associated costs
The column on
5.3 Performance metrics for an assessment risk framework library
There do exist libraries for software development concerns and known vulnerabilities such as the NIST NVD, NIST Bug Framework, and MITER’s CWE. They assess their performance. MITER provides an analysis of how the library can be used by stakeholders; however, no formal assessment methodologies exist. Assessing a library framework for performance would be like trying to assess the performance of a spoken language. MITER  currently lists the following stakeholders of their weakness enumeration (i.e., framework or library): assessment vendors and customers, software developers and, customers, academic researchers, applied vulnerability researchers, refined vulnerability information (RVI) providers, educators, and specialized communities.
According to Schmeelk , the library is currently prototyped as a spreadsheet, similarly to the NIST Cybersecurity Framework Reference Tool spreadsheet representation . Currently, each sheet of the spreadsheet refers to specific domains of findings that can be identified during a risk-assessment process. For example, weakness in the physical, technical, or administrative security requirements would each fall on different spreadsheet pages. In addition, each of these three domains can be further broken into subdomains.
5.4 Benefits from a standardized risk-assessment framework library
Currently organizations are developing their own personal language for describing risk. In fact, many risk assessors within the organizations can actually employ their own personal language. When third-party audits and internal audits transpire, there is no way to assess the risk across the risk-assessment reports. For example, one risk-assessor employee could identify a vulnerability as cross-site scripting; whereas, another may document an XSS vulnerability. If the risk has been described differently by all employees, it becomes impossible to identify how many cross-site scripting vulnerabilities really exist within the organization. Hence, the meta-analysis of risk is entirely flawed. As such, it will be improperly conveyed to insurance companies and third-party auditors. Currently, the only way to develop a unified understanding of the risk is to first develop ontologies of potential words used to describe the risk. Then, perhaps aggregate meta-statistics about the organization can be developed by using natural language processing methods on the written reports. For example, modern natural language processing methods would need to take place on penetration tests to evaluate assessment reports among different assessors, each applying different methodologies and terminologies. As such, most insurance companies and third-party auditors are taking large chances on organizations who really do not understand their own cybersecurity concerns.
5.5 Improvements made by introducing a standardized risk library
Currently, there are no other relevant approaches where the risk language is standardized other than the vulnerability language frameworks of MITER and NIST. This lack of standardized risk language remains a major gap in risk analysis. Schmeelk  reports on an analysis for the prototype risk library and connects the library to New York State (NYS) Information Technology Security (ITS) Policies . Standardizing the language used during risk assessments is essential for both internal and external factors. First, if a risk-related case ever goes to court, the phrasing of the risk could play a role in the court verdict. For example, if a business chooses to accept a finding where “unauthorized access” was identified during a risk assessment, the organization may be responsible for accepting the risk. Second, when an organization whose assessments have been written using any plethora of words is trying to collect internal metrics, characterizing the current state of cybersecurity within the organization is nearly impossible. This would be a useful application for Natural Language Processing (NLP), trying to characterize quantitatively exact numbers of password violations, XSS, SQL injection, and other findings. Without standardization, knowing at any time an organizational stance on cybersecurity becomes next to impossible. In addition, remediation efforts and risk mitigation efforts are significantly hindered by text-based risk assessments which do not conform to standards. Lastly, if every organization’s employees compose/compile/develop their own libraries, there will be no way to properly coordinate with insurance companies for breach budgeting. Sadly, without any standardization or proper planning, organizations may learn “the hard way” that they are entirely financially responsible for cleaning up a major data breach or ransomware attack.
5.6 Industry concerns addressed by a standardized risk library
The United States and the world are adopting, either explicitly or implicitly, technology-related risk at an unprecedented rate. In addition, regulations are being adopted across the world at an equally unprecedented rate. In fact, each of the 50 United States and “the District of Columbia, Guam, Puerto Rico and the Virgin Islands have enacted legislation requiring private or governmental entities to notify individuals of security breaches of information involving personally identifiable information .” Each state law is potentially different from the other state laws, further complicating situations involving out-of-state patients. Most organizations have adopted Integrated Risk Management (IRM) solutions, but many of these solutions require extreme customization from clients. In addition, not everyone in the organization has an overall “view” of the organizational risks. Since Information Systems (IS) trends remain in silos , coordinating risk among the different healthcare departments and all the IS sectors is difficult. In addition, entities within an organization that sign off on risk, typically referred to as system owners, may find an imbalance on the risk they must accept on the behalf of the business. Then, as system owners leave or retire from an organization, subsequent new hires may not fully understand the risks inherited with their positions. In fact, new hires in security high-level positions often ask the organization for audits prior to taking, or during the first year of, a new job. That way they can benchmark the inherited risks.
As risk management evolves, so do the needs for risk communication and risk articulation. Healthcare entities need to know, in advance, exactly what their insurance covers involving privacy and security risks. Patients need to be aware of identity theft concerns if their personal identifying information (PII) is breached and sold in alternative marketplaces. Technology in the healthcare-related infrastructure is here to stay; ultimately, society will need to standardize how they deal with and respond to privacy and cybersecurity risks. The sooner we adopt a framework of actual privacy and security violations and corrections, the better industry will be able to communicate and mitigate risks—especially in healthcare where human life is at ultimately at risk.