Risk Analysis For Information Systems Free Download
Open access peer-reviewed chapter
Risk in Healthcare It: Creating a Standardized Take a chance Assessment Framework
Submitted: January 9th, 2021 Reviewed: Feb 5th, 2021 Published: October sixth, 2021
DOI: 10.5772/intechopen.96456
IntechOpen Downloads
92
Total Chapter Downloads on intechopen.com
Abstract
Data breaches are occurring at an unprecedented charge per unit. Between June 2019 and early Oct 2020, over 564 data breaches affected over 36.6 million patients equally 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, inquiry, 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 manufacture 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 direction standardized framework library to meliorate the coordination and communication of the aforementioned problematic management components. The healthcare manufacture would benefit from adopting such a standardized risk-centric framework.
Keywords
- risk associated with computer communications
- healthcare
- data breaches
- GDPR
- HITECH
- HIPAA
- standardized risk library
- take chances management
- patient information
- identity theft
- cybersecurity
- laws
- penetration test
- chance assessments
- insurance
*Address all correspondence to: schmeels@stjohns.edu
one. Introduction
Across the globe, data security is becoming more regulated. For example, in the European Wedlock, the General Data Protection Regulation (GDPR) protects its citizens [1]. In Mainland china, the Cybersecurity Law of 2017 was ane of the first well known laws passed to protect the data and communications of its citizens [2]. In the United states of america, medical entities in the country's critical infrastructure are covered nether Federal laws to protect patient information. Specifically, the Health Insurance Portability and Accountability Act (HIPAA) [3] and Health It for Economic and Clinical Wellness Human activity (HITECH) [4] are Federal-level regulations for covered entities that secure patient-protected health data (PHI). PHI covers a gamut of dissimilar 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 The states, vendors and services which are not covered nether HIPAA (perhaps considering they practise not bill patients for services rendered) are regulated by the Federal Merchandise Commission (FTC) and must self-report health data breaches to the FTC [5]. Furthermore, the European Commission officially ratified the last version of the GDPR to include notification from a breached supervisory authority to be made within 72 hours (or provide reasons for a delay) [ane].
In the United states, both HIPAA-covered and not-covered entities may too be nether other legal requirements, such equally non-disclosure, confidentiality restrictions, or other security requirements, for other organizational, research, or employee information.
The management within covered groups has historically remained siloed intra-organization where different components of the organizational risk are being managed and decisions fabricated past different units within the organizations without a standardized and well-continued systematic methodology. For instance, the legal, audit, upkeep, health informatics, security, privacy, medical, and data 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 consequence in unidentified operational risk if the dissimilar departments are not consistently coordinated and periodically reviewing, perhaps updating, the associated risks.
This chapter begins by describing information breach risks in HIPAA-covered entities as reported to the U.s. regime that cause patients college risks for identity theft. Then it integrates current enquiry into building a standardized risk assessment library that enables both inter- and intra-organizational risk coordination. This design facilitates standardizing and communicating risks too 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 organization assembly of risks.
Advert
2. Patient information data breaches can lead to patient identity theft
In the United States, citizens are protected past 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 non 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 agreement and in the feasibility of current technological constraints.
2.1 Entities covered under HIPAA
HIPAA requires at least 3 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 concern assembly. Healthcare providers transmit electronic patient information in connection with a Health and Human Services (HHS)-adopted standard transaction. Wellness plans include insurance companies, wellness maintenance organizations (HMOs), corporate wellness plans, and government programs. Business concern associates are external groups/organizations that perform activities or services on ePHI on behalf of some other group covered under HIPAA. Figure 1 [6] shows i yr of reports by covered entity to the Office of Ceremonious Rights (OCR).
Figure 1.
OCR-covered entities investigated.
2.ii Risks in HIPAA-covered entities
Research at large has studied risk direction of medical information [7, 8, 9, x], merely not specifically as related by dissimilar HIPAA-covered domains. Recent research [6, 7, xi] explores potential concerns for each legally covered segment based on self-study to the US Government equally required by the HITECH Act. In the sector-specific threat probability-specific research [6, 7, 11] over a i-twelvemonth interval, the inquiry showed that different the different domains may indeed take unlike sources of concerns and bug. For case, healthcare providers and business associates accept reportedly different higher probability of concerns to alleviate than health programme entities, as shown in Figure 2 [vi]. This indicates that the different domains may need to manage their threats differently by perhaps investing more heavily in different mitigating controls.
Effigy 2.
OCR-covered entities risk sources.
2.iii Data breaches reported to the HHS OCR across the USA
The HHS unauthorized information release portal provides the number of affected individuals from the cybersecurity events for each self-reported or discovered data release. Figure 3 [vi] shows states across the USA with the most reported individuals, whom are now at chance from the leaking of their patient data. In any given i-twelvemonth interval, each state may be as probable to take higher counts depending on the released data size. Farther research is needed to decide country likelihood.
Figure 3.
OCR breached individuals past state.
2.iv Reported data breach counts per country sorted past 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 political party receives access to the provider's ePHI. A properly written BAA somewhat "protects" the provider if the outside political party breaches the ePHI. Figure iv [6] shows country BAA presence notated with past the HHS portal with either a "yes" or "no." The portal reports are not described, and then the inquiry below shows the categorical information as posted to the portal.
Figure 4.
OCR-covered entities investigated BAA by country.
Ad
three. Risk cess 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 beingness integrated into an organization.
Recently, in October 2020, Boil and Perlrotha [12] reported on a cyber-assail that resulted in a patient death. The set on occurred when "ransomware invaded xxx servers at University Hospital Düsseldorf [,…] crashing systems and forcing the hospital to turn away emergency patients." This is one of the start ransomware-attack-related suspected deaths reported publicly. In such a high-profile and morbid case, we tin can run into the essential importance for having a standardized language for discussing cyber-risks.
3.1 Take a chance cess standards
The United States National Institute of Standards and Technologies (NIST) has produced many Special Publications on Risk Assessments [13]. Figures 5 and 6 [xiv] evidence NIST's generic risk model and risk assessment process respectively. In fact, many organizations effectually the world are following the NIST Risk Cess frameworks.
Figure five.
NIST'due south generic run a risk model with central adventure factors.
Figure 6.
NIST gamble assessment process.
3.2 Automating take a chance assessments
Risk cess automation has been proposed in the form of automatic penetration testing frameworks [nine, 10, xi, 13, 14, fifteen, xvi, 17, 18, xix]. Testing frameworks and automatic tools are extremely useful for detecting known bugs and vulnerabilities. Withal, in general, these tools do not written report on the larger run a risk-assessment picture. Specifically, they may not accurately report on legal requirements or assistance an system prepare for prospective data-breach-associated costs. In improver, in that location is limited (if whatsoever) language standardization on risk findings to enable intra- and inter-organizational risk advice, which is essential for subsequent auditing and legal ramifications.
3.3 Framework libraries for malware and software developments
In improver to developing a standardized framework, NIST and MITRE.org have worked tirelessly to produce a standardized lexicon for set on and malware. For example, they take produced the
three.4 Penetration testing reports
As risk direction is still clearly its own type of innovation phase within the technology adoption life-cycle, gamble researchers are finding a need to communicate risk through standardized language. For example, let u.s. consider a penetration exam study. Historically, there is none of the post-obit: (ane) a stock-still template, (2) a fixed-strategy, or (3) stock-still-finding language. Such non-standardization is subject area to farthermost bias and misrepresentation. In fact, if every internal or external penetration test is written differently, how tin whatsoever system fully understand their ain risks? Similarly, if every employee in an arrangement spoke their ain verbal language, how could anything be communicated? Historically, manufacture has focused on standardizing software vulnerabilities and malicious code patterns. A major gap still exists for hazard management components, including budgeting for financial penalties and legal ramifications.
3.5 Risk assessment education
Research on take chances-cess educational activity has primarily focused on learning penetration testing techniques [25]. The curriculums discussed in this research neither considers the meta-organizational risk nor risks specifically associated with the medical sector. Schmeelk [26] fills a literature gap by emphasizing that all the chance components should be strategically aligned in terms of standardization.
Advert
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 case, outside and within risk management strategies may not properly align. Also, many organizations, especially in healthcare, are employing a task-based ticketing organization to rail 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 linguistic communication.
Schmeelk [26] reports that the following five subsections should be included in identifying organizational components. As a centralized library has however to exist created, a working grouping 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 courtroom.
four.1 Regulatory requirements
Regulatory requirements encompass a broad range of organizational responsibilities, which tin can exist bodily governmental laws and/or industry-specific requirements. Let us discuss both.
4.ane.i Industry-specific regulations
In the United States, medical critical infrastructure entities have both sector-specific regulatory requirements every bit well as other requirements, such as Payment Card Manufacture (PCI)-compliance, to consider in risk management [27]. If an organization does non pass PCI (re)compliance auditing, and so they are at adventure of losing the use of credit cards, among other payment sources nether PCI regulations. In the past, organizations would consider themselves a greenbacks-merely facility if they lost PCI (re)compliance. Today, with the birth of cryptocurrencies and alternative payment methods non under PCI, losing the use of credit cards might not be as drastic as information technology has been historically. Other regulations include compliance with those from the International Standards Organization (ISO). Globally, there are many manufacture-specific regulations that are not necessarily enforceable laws.
four.i.ii Manufacture-specific Laws
Medical-covered entities nether HIPAA/HITECH are bailiwick to audits by the United states of america Health and Human Services (HHS) Part of Civil Rights (OCR). The OCR manages many civil rights beyond the Us in add-on 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 area to federal fines and corrective deportment. The OCR likewise tin audit covered entities at whatever point in time. HIPAA is a very well-organized police. It has specific mandates for electronic health data requirements, which should exist 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 Grooming requirements
Security educational activity and training sensation (SETA) needs may occur at the vendor level or equally federal, state, or city regulations. They are not merely legally mandated in many instances for legal responsibilities, but also are ethical mitigations. For case, employing staff who have non 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. As well, in New York Land, the loss of employee Social Security Numbers (SSN) through any sort of data breach is a law-breaking bailiwick to legal penalties [28].
4.2.ane Regulation trainings
Different regulations require different levels of SETA. In the credit bill of fare industry, organizations using alternatives to cash which are highly-corporately regulated must protect the information 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 lawmaking such systems. In addition, federal laws such as HIPAA also accept specific training requirements. Lastly, little work on cybersecurity grooming is existence done at land or city levels; nevertheless, proper awareness could exist suddenly mandated at these local levels. If an system or their accepted vendors are missing any of these training requirements, the arrangement may be financially liable.
4.2.2 Best do trainings
Training based on current best practices is difficult to assess because all-time practices in cybersecurity hateful different things to different people and organizations. Training based on all-time practices is really subjective. Typically in the USA, organizations follow NIST and the Open Web Application Security Project (OWASP) guidance [14, 29]; nevertheless, still no industry-wide standards exist for exactly what best practices entail.
iv.iii 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 accept proper agreements and hazard mitigations in place. Two major sources of such agreements are: business organization associate agreements (BAAs) and other agreements, such as non-disclosure agreements. Allow us examine both in the following subsections.
4.three.1 Concern associate agreements (BAAs)
Historically, services providers (or business associates) working with a covered entity's sensitive patient information 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 nonetheless written report breaches where a properly formed BAA was not in identify. In such cases, all parties may be considered responsible for the alienation by the HHS OCR in the United states of america.
four.three.ii Not-disclosure agreements and/or other agreements
Business partners may negotiate many different types of agreements and/or partner requirements for their data and products. I 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 instance, malware that makes NDA-protected data public by releasing information technology on a popular spider web application du jour, also as its actual authors, could be faulted to violate the NDA. Cases that fall into this category can take many dissimilar negative outcomes, such as legal ramifications, reputational damage, amongst others.
In addition to NDAs, other Federal or organizational legal regulations may require run a risk assessments and other services or service-level agreements (SLAs). Similarly, the GDPR requires entities exposed to unauthorized admission to notify afflicted breached individuals inside a short timeframe. Violations to such agreements can take extremely negative consequences to the healthcare entities.
4.4 Application and system requirements
Application and organization security are typically measured through certifications (e.k., 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 tin either develop their own methodologies to communicate risk that are acceptable by covered entities, or the entities themselves can inquire to perform such probability assessments for adverse events. When the covered entity is performing the assessment, they must advisedly obtain legal potency to do so in most cases. In general, Information System silos prevent considering a full-threat landscape for the technical component with the legal, upkeep, and business apply cases. Additionally, digital assessments may be filed for HHS OCR audits into the Integrated Adventure Management (IRM) system without updates to the overall concern threat mitigations. Periodically, teams must carefully reassess and update the stored organizational predicted levels. In such cases, the assessments are more of a adventure "impression" rather than an informed, reproducible, scientific informing on the true likelihood and impact of agin events. Figure 7 [30] provides a high-level overview of different technical security controls reported past NIST. The following subsections place viii subcategories potentially employed during a chance cess.
Figure 7.
Technical security controls.
4.4.one Authentication
Co-ordinate to NIST [30], authentication is the procedure 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 [31] currently gives ten best-do 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 Hallmark 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-practise guide at-large lists
four.4.2 Session management
Session management is the information period between endpoints—typically following a customer and server model. A web session is a series of requests and response transactions created past a client after authentication. In well-nigh cases, the endpoints communicate with a special identifier to limit re-authentications. Current best practices in session direction include session flags, random token generation, and timeout intervals. The OWASP Application Testing Guide [31] currently lists the following 8 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."
iv.four.iii Data-in-transport, data-at-remainder, information-in-utilise
The protection of sensitive information is cardinal to risk management. Data-in-motility is the transfer of textile between endpoints. This category changes frequently and includes industry all-time practices in how to transmit the information, such as confidentiality controls and integrity controls during message manual. Once information is stored on a system, it is referred to as data-at-remainder. Lastly, information-in-employ refers to messages in retentiveness. Historically, a concern of data-in-use is that processes and other virtualized components could have improper admission to the information.
four.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 authority. Every bit such, access controls speak to lowering probabilities confronting unauthorized admission, which could cause loss to information integrity, confidentiality, and availability. The effectiveness and the strength of unauthorized admission reduction depend on the correctness of the admittance command decisions and the force of entry control enforcement. The electric current OWASP Testing Framework [31] promotes the testing of four primal 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."
four.4.5 Auditing and monitoring
Systems and applications should create records for auditing and monitoring. Specifically, athenaeum should be generated before and after disquisitional 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 adventure management.
iv.4.6 Injection and input vulnerabilities
Injections and input vulnerabilities enable maliciously crafted lawmaking to change the underlying intended beliefs of a system or application. The OWASP Testing Guide [31] currently lists eighteen common best practise tests, including SQL/NoSQL injection, Cross Site Scripting (XSS), and HTTP injection attacks, among others.
iv.five Organizational control requirements
At the organizational-level, controls such every bit policies, procedures, physical security and financial budgeting should exist considered during an assessment. Even so, these components of risk management tin can be managed by entirely dissimilar entities.
iv.5.i Policies and procedures
Organizations should take policies in place [32] 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 too be in place and specifically in writing [32]. Specific procedures, which must be in place at the federal level, include business continuity and disaster recovery plans.
4.v.2 Concrete and environmental security
This component describes the physical and environmental security aspects of the arrangement, 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 equally public, private, and shared. Information technology as well includes means to protect organizations from fire and other environmental concerns affecting gamble.
4.v.iii Upkeep 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 assay model. Many organizations are not storing-upwardly financial resources in accordance with the uncertain probability beingness generated to pay for patient identity protections. Digital Guardian [33] has diverse reports on current costs per record; the costs vary with time. Simply indicating that a organization is vulnerable to CSRF may really accept no budgetary ramification nether certain other weather. 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 [34]. For most HIPAA covered entities, the HHS OCR enforcement of the Privacy Rule began April fourteen, 2003, and the Security Dominion began on April 20, 2005. The web portal currently lists government corrective activity 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 cosmetic action plans for violations to the HIPAA Privacy and Security Rules.
Advertising
5. A adventure assessment library
Schmeelk [26] contributed a new open source risk cess library example to enable researchers, penetration testers, hazard assessment managers and institutions to further expand on a consistent risk-cess findings library with their policies, procedures, organizational controls and legal requirements. Every bit noted in the research bug libraries, dictionaries are existence maintained by large organizations but exercise not include risk-assessment findings, thus complicating risk-management methods. As cited, during experience with internal audits hazard assessment, linguistic communication made analysis next to incommunicable. For example, modern natural language processing methods would need to have place on penetration tests to evaluate cess reports amid unlike assessors, each applying different methodologies and terminologies.
five.i Example chance assessment frameworks
Currently, assessment frameworks are entirely intra-system. In improver, accessing patient databases is incommunicable—luckily—in the U.s.a. due to HIPAA. That said, NIST has guidance on developing an bodily take chances-assessment procedure [fourteen]. Nonetheless, NIST 800–30, equally seen in Figure 5, does non actually specify threat source, threat event, bodily vulnerabilities, or touch. The actual linguistic communication used to describe these components is entirely left upwardly to each organization to develop. Even worse, each risk assessor on the team may, in fact, draw these components differently (i.e., use entirely different words). In such cases, making any kind of accurate meta-analysis about the organizational adventure is entirely impossible. Therefore, we contend that risk assessment frameworks need a standardized library to describe the identified risk.
5.2 Example findings library
An open-source library case from Schmeelk [26] is seen in Figure viii applying an example-consequent risk language. The library needs to exist expanded from industry working groups, similarly to MITER'due south CWE and NIST's BF.
Figure eight.
Risk assessment library paradigm.
Some important elements for language specification and risk description are seen in Figure 8 [26]; they are the following: vulnerability brusque 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 not-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 past major organizations (e.thousand. MITER) and/or government entities (e.g. NIST). Based on healthcare operation needs, we developed the post-obit descriptions of the prototype categories.
five.two.1 Standardizing the bodily risk vulnerability and remediation language
The
5.2.two Standardizing the actual risk likelihood and impact language
The
5.ii.three Standardizing the actual risk associated with policies and NIST controls
Historically, organizations should develop policies and standards to assist the organization frame their own cybersecurity stance. The NIST Cybersecurity Framework [35] (the NIST CSF Tool is seen in Effigy 9) is one useful guide for developing an organizational cybersecurity posture and policies/standards.
Figure nine.
NIST cybersecurity framework reference tool [
The category in Figure 8, risk cess 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 [14] to business relationship for industry trends.
v.2.4 Standardizing the actual hazard 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 [27], The Sarbanes-Oxley Deed (SOX) of 2002 [36], FTC requirements, service-level agreements (SLAs), state information alienation laws [29], and research not-disclosure agreements, tin can also play their roles in risk management. For example, SOX "is mandatory. ALL organizations, large and pocket-size, MUST comply [36]." Organizations allowing customers to pay with credit cards may directly or indirectly exist under PCI compliance. The column
5.2.six Standardizing the actual budget to estimate breach-associated costs
The cavalcade on
five.iii Performance metrics for an cess risk framework library
In that location practise exist libraries for software development concerns and known vulnerabilities such every bit the NIST NVD, NIST Bug Framework, and MITER'due south CWE. They assess their performance. MITER provides an analysis of how the library tin 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 linguistic communication. MITER [38] currently lists the following stakeholders of their weakness enumeration (i.east., 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.
Co-ordinate to Schmeelk [26], the library is currently prototyped as a spreadsheet, similarly to the NIST Cybersecurity Framework Reference Tool spreadsheet representation [35]. Currently, each canvas of the spreadsheet refers to specific domains of findings that tin be identified during a risk-cess process. For instance, weakness in the physical, technical, or administrative security requirements would each autumn on different spreadsheet pages. In addition, each of these three domains tin be further broken into subdomains.
5.4 Benefits from a standardized risk-cess framework library
Currently organizations are developing their ain personal linguistic communication for describing take a chance. In fact, many gamble assessors within the organizations can actually employ their own personal language. When tertiary-party audits and internal audits transpire, there is no fashion to appraise the take chances across the hazard-assessment reports. For case, 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 be within the organization. Hence, the meta-analysis of risk is entirely flawed. As such, information technology volition exist improperly conveyed to insurance companies and third-party auditors. Currently, the only style to develop a unified agreement of the risk is to first develop ontologies of potential words used to describe the risk. Then, perhaps aggregate meta-statistics about the organisation tin be developed by using natural language processing methods on the written reports. For case, modern natural language processing methods would need to accept place on penetration tests to evaluate cess reports amid different assessors, each applying different methodologies and terminologies. Every bit such, most insurance companies and 3rd-political party auditors are taking large chances on organizations who actually practice 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 adventure language is standardized other than the vulnerability language frameworks of MITER and NIST. This lack of standardized risk language remains a major gap in take chances analysis. Schmeelk [26] reports on an analysis for the prototype take a chance library and connects the library to New York State (NYS) Data Applied science Security (ITS) Policies [39]. 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 courtroom verdict. For example, if a business chooses to accept a finding where "unauthorized access" was identified during a take chances cess, the organization may exist responsible for accepting the risk. 2nd, when an organization whose assessments take been written using whatever plethora of words is trying to collect internal metrics, characterizing the current land of cybersecurity inside the organisation is near impossible. This would be a useful application for Natural language Processing (NLP), trying to narrate quantitatively verbal numbers of password violations, XSS, SQL injection, and other findings. Without standardization, knowing at whatever fourth dimension an organizational stance on cybersecurity becomes next to impossible. In addition, remediation efforts and risk mitigation efforts are significantly hindered by text-based adventure assessments which do not conform to standards. Lastly, if every organization'south employees compose/compile/develop their ain libraries, there will be no fashion to properly coordinate with insurance companies for breach budgeting. Sadly, without any standardization or proper planning, organizations may larn "the hard way" that they are entirely financially responsible for cleaning up a major data breach or ransomware set on.
5.6 Industry concerns addressed past a standardized adventure library
The U.s.a. and the world are adopting, either explicitly or implicitly, applied science-related risk at an unprecedented charge per unit. In addition, regulations are beingness adopted beyond the world at an equally unprecedented charge per unit. 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 data involving personally identifiable data [29]." Each land law is potentially different from the other country laws, further complicating situations involving out-of-country patients. Most organizations have adopted Integrated Run a risk Management (IRM) solutions, simply many of these solutions crave extreme customization from clients. In addition, not anybody in the organization has an overall "view" of the organizational risks. Since Information Systems (IS) trends remain in silos [40], coordinating risk among the unlike healthcare departments and all the IS sectors is hard. In addition, entities inside an organization that sign off on risk, typically referred to equally organisation owners, may find an imbalance on the risk they must have on the behalf of the business. Then, equally 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 oftentimes enquire the arrangement for audits prior to taking, or during the first year of, a new job. That way they can criterion the inherited risks.
Advertisement
6. Conclusions
Equally take chances management evolves, then exercise the needs for hazard advice and run a risk articulation. Healthcare entities need to know, in accelerate, exactly what their insurance covers involving privacy and security risks. Patients need to be aware of identity theft concerns if their personal identifying data (PII) is breached and sold in alternative marketplaces. Applied science in the healthcare-related infrastructure is here to stay; ultimately, order will need to standardize how they bargain with and respond to privacy and cybersecurity risks. The sooner we adopt a framework of actual privacy and security violations and corrections, the better manufacture volition be able to communicate and mitigate risks—especially in healthcare where human life is at ultimately at risk.
References
- one.
Europe Spousal relationship (2020) The EU Full general Data Protection Regulation (GDPR). Retrieved from: https://eugdpr.org - ii.
Maranto, Lauren (2020) Who Benefits from Communist china's Cybersecurity Laws? Retrieved from: https://www.csis.org/blogs/new-perspectives-asia/who-benefits-chinas-cybersecurity-laws - iii.
U.S. Section of Health and Man Services (HHS). (2020). Health Data Privacy, from https://world wide web.hhs.gov/hipaa/index.html - 4.
U.Due south. Department of Wellness and Human being Services (HHS). (2013, July 26). HITECH Human action Breach Notification Guidance and Request for Public Comment. Retrieved July 11, 2020, from https://world wide web.hhs.gov/hipaa/for-professionals/security/guidance/HITECH-human action-breach-notification-guidance/alphabetize.html - five.
Federal Trade Commission (2020) Health Breach Notification Rule. Retrieved from: https://www.ftc.gov/tips-advice/business-eye/guidance/wellness-breach-notification-rule - 6.
Schmeelk, South. (2019). Where is the Risk? Analysis of Government Reported Patient Medical Data Breaches. In IEEE/WIC/ACM International Conference on Web Intelligence - Companion Volume (WI '19 Companion). Association for Computing Machinery. New York, NY. doi: https://dl.acm.org/doi/x.1145/3358695.3361754 - vii.
Schmeelk, S. (2019). Identity Theft: Anatomy of a Information Breach. New York, New York: Parsons - The New School for Design. URL https://parsons.nyc/thesis-2019 - 8.
Grand. Catelani, L. Ciani and C. Risaliti, "Hazard assessment in the utilize of medical devices: A proposal to evaluate the bear upon of the homo factor," 2014 IEEE International Symposium on Medical Measurements and Applications (MeMeA), Lisboa, 2014, pp. one-half-dozen - ix.
F. Kammüller, "Combining Secure System Design with Adventure Assessment for IoT Healthcare Systems," 2019 IEEE International Conference on Pervasive Calculating and Communications Workshops (PerCom Workshops), Kyoto, Nihon, 2019, pp. 961-966 - ten.
Sonia H. Stephens. 2015. Interactive data visualization for risk assessment: tin there be too much user agency?. In Proceedings of the 33rd Annual International Conference on the Pattern of Communication (SIGDOC '15). ACM, New York, NY, USA, Article 9 , 2 pages. DOI: http://dx.doi.org/10.1145/2775441.2775446 - 11.
Schmeelk, Due south., Dragos, D., & DeBello, J. (2021). What Can We Learn well-nigh Healthcare IT Hazard from HITECH? Run a risk Lessons Learned from the U.s.a. HHS OCR Breach Portal. Hawaii International Conference on Organization Sciences-54 (Under review) (p. 10). Kuai, HI, The states: University of Hawaii at Manoa - 12.
Eddy, Grand. and Perlroth, N. (2020) Cyber Assail Suspected in German Woman's Death Retrieved from: https://world wide web.nytimes.com/2020/09/eighteen/world/europe/cyber-attack-germany-ransomeware-death.html - 13.
U.S. NIST (2020) Cybersecurity Resources Center. Retrieved from: https://csrc.nist.gov/Topics/Security-and-Privacy/take chances-management/take chances-assessment - xiv.
U.S. NIST (2012) NIST Special Publication 800-thirty. Guide for Conducting Take chances Assessments. Retrieved from: https://csrc.nist.gov/publications/detail/sp/800-30/rev-1/final - 15.
B. Xing, Fifty. Gao, J. Zhang and D. Sun, "Design and Implementation of an XML-Based Penetration Testing System," 2010 International Symposium on Intelligence Information Processing and Trusted Computing, Huanggang, 2010, pp. 224-229 - 16.
One thousand. P. Haubris and J. J. Pauli, "Improving the Efficiency and Effectiveness of Penetration Exam Automation," 2013 10th International Briefing on It: New Generations, Las Vegas, NV, 2013, pp. 387-391 - 17.
H. Radwan and K. Prole, "Code Pulse: Real-time code coverage for penetration testing activities," 2015 IEEE International Symposium on Technologies for Homeland Security (HST), Waltham, MA, 2015, pp. 1-6 - eighteen.
Lei Liu, Jing Xu, Chenkai Guo, Jiehui Kang, Sihan Xu and Biao Zhang, "Exposing SQL Injection Vulnerability through Penetration Test based on Finite Country Machine," 2016 2nd IEEE International Briefing on Estimator and Communications (ICCC), Chengdu, 2016, pp. 1171-1175. doi: x.1109/CompComm.2016.7924889 - 19.
A. Blome, M. Ochoa, K. Li, One thousand. Peroli and M. T. Dashti, "VERA: A Flexible Model-Based Vulnerability Testing Tool," 2013 IEEE Sixth International Conference on Software Testing, Verification and Validation, Luxembourg, 2013, pp. 471-478 - 20.
MITRE (2020) Common Attack Pattern Enumeration and Classification. Retrieved from https://capec.mitre.org - 21.
NIST (2020) National Vulnerability Database. Retrieved from: https://nvd.nist.gov - 22.
MITRE (2020) Common Weakness Enumeration. Retrieved from: https://cwe.mitre.org - 23.
I. Bojanova, P. E. Blackness, Y. Yesha and Y. Wu, "The Bugs Framework (BF): A Structured Approach to Express Bugs," 2016 IEEE International Briefing on Software Quality, Reliability and Security (QRS), Vienna, 2016, pp. 175-182. doi: 10.1109/QRS.2016.29 - 24.
NIST (2020) Bug Framework. Retrieved from: https://samate.nist.gov/BF - 25.
Lee Epling, Brandon Hinkel and Yi Hu. 2015. Penetration testing in a box. In Proceedings of the 2015 Information Security Curriculum Development Conference (InfoSec 'xv). ACM, New York, NY, The states, Commodity 6, 4 pages. DOI: https://doi.org/10.1145/2885990.2885996 - 26.
Schmeelk, Due south. (2020) Creating a Standardized Take chances Assessment Framework Library for Healthcare It, HICSS-53: Hawaii International Conference on Arrangement Sciences, DOI: 10.24251/HICSS.2020.474 - 27.
PCI Security Standards Council (2020). Securing the Future of Payments Together. Retrieved from: https://www.pcisecuritystandards.org - 28.
New York Country (2020) New York State Social Security Number Protection Law. Retrieved from: https://www.albany.edu/ampra/avails/New_York_Social_Security_Number_Protection_Law.pdf - 29.
NCSL (2020) Security Breach Notification Laws. Retrieved from: https://www.ncsl.org/inquiry/telecommunication-and-information-technology/security-breach-notification-laws.aspx - 30.
U.South. NIST (2002). Chance Management Guide for It Systems. Retrieved from: https://csrc.nist.gov/publications/detail/sp/800-30/archive/2002-07-01 - 31.
OWASP (2020) OWASP Testing Guide. Retrieved from: https://owasp.org/www-project-web-security-testing-guide - 32.
Santos, O. (2019). Developing cybersecurity programs and policies - 33.
Digital Guardian (2019) What'south the Toll of a Information Breach in 2019? Retrieved from: https://digitalguardian.com/web log/whats-price-information-breach-2019 - 34.
HHS (2020) HIPAA Enforcement. Retrieved from: https://www.hhs.gov/hipaa/for-professionals/compliance-enforcement/alphabetize.html - 35.
NIST (2020) NIST Cybersecurity Framework. Retrieved from: https://www.nist.gov/cyberframework - 36.
SOX Law (2020) Sarbanes-Oxley Act of 2002 Retrieved from: https://www.soxlaw.com - 37.
Jeff Horwitz (2019) Facebook Sets Aside $3 Billion to Cover Expected FTC Fine. Retrieved from: https://www.wsj.com/articles/facebook-sets-bated-3-billion-to-cover-expected-ftc-fine-11556137113 - 38.
MITRE (2020) CWE Stakeholder Analysis. Retrieved from: https://cwe.mitre.org/community/research/stakeholders.html - 39.
New York State (2020) ITS Security Policies. Retrieved from: https://its.ny.gov/eiso/policies/security - xl.
Benson, R.J., Ribbers, P.M., and Blitstein, R.B. (2014) Preface and Chapter 1. Trust and Partnership: Strategic IT: Direction for Turbulent Times. Wiley. 1118443934
Submitted: January 9th, 2021 Reviewed: Feb 5th, 2021 Published: October 6th, 2021
© 2021 The Writer(s). Licensee IntechOpen. This chapter is distributed under the terms of the Artistic Commons Attribution 3.0 License, which permits unrestricted utilise, distribution, and reproduction in whatsoever medium, provided the original piece of work is properly cited.
DOWNLOAD HERE
Posted by: walkertheire.blogspot.com
0 Comments