Journal:Automated cyber and privacy risk management toolkit - Revision history

Shawndouglas: Converted ombox to template

2021-10-06T18:40:30Z

Converted ombox to template

← Older revision		Revision as of 18:40, 6 October 2021
Line 19:		Line 19:
	\|download = [https://www.mdpi.com/1424-8220/21/16/5493/pdf https://www.mdpi.com/1424-8220/21/16/5493/pdf] (PDF)		\|download = [https://www.mdpi.com/1424-8220/21/16/5493/pdf https://www.mdpi.com/1424-8220/21/16/5493/pdf] (PDF)
	}}		}}
	{{~~ombox~~
	~~\| type = content~~		{{Ombox math}}
	~~\| style =~~
	\| text = This article contains rendered mathematical formulae. You ''may'' require the [https://chrome.google.com/webstore/detail/tex-all-the-things/cbimabofgmfdkicghcadidpemeenbffn?hl=en TeX All the Things] plugin for Chrome or the [https://addons.mozilla.org/en-US/firefox/addon/native-mathml/ Native MathML] add-on and [https://developer.mozilla.org/en-US/docs/Web/MathML/Fonts fonts] for Firefox if they don't render properly for you.
	}}

	==Abstract==		==Abstract==

Shawndouglas: Fixed deprecated parameters

2021-10-06T18:32:26Z

Fixed deprecated parameters

Show changes

Shawndouglas: Finished adding rest of content.

2021-10-06T18:01:24Z

Finished adding rest of content.

← Older revision		Revision as of 18:01, 6 October 2021
Line 19:		Line 19:
	\|download = [https://www.mdpi.com/1424-8220/21/16/5493/pdf https://www.mdpi.com/1424-8220/21/16/5493/pdf] (PDF)		\|download = [https://www.mdpi.com/1424-8220/21/16/5493/pdf https://www.mdpi.com/1424-8220/21/16/5493/pdf] (PDF)
	}}		}}
	{{ombox		{{ombox
	\| type = ~~notice~~		\| type = content
	~~\| image = [[Image:Emblem-important-yellow.svg\|40px]]~~		\| style =
	\| style = ~~width: 500px;~~		\| text = This article contains rendered mathematical formulae. You ''may'' require the [https://chrome.google.com/webstore/detail/tex-all-the-things/cbimabofgmfdkicghcadidpemeenbffn?hl=en TeX All the Things] plugin for Chrome or the [https://addons.mozilla.org/en-US/firefox/addon/native-mathml/ Native MathML] add-on and [https://developer.mozilla.org/en-US/docs/Web/MathML/Fonts fonts] for Firefox if they don't render properly for you.
	\| text = This article ~~should be considered a work in progress~~ and ~~incomplete~~. ~~Consider this article incomplete until this notice is removed~~.
	}}		}}

Line 692:		Line 691:

	===Conclusions===		===Conclusions===
			This paper described AMBIENT (Automated Cyber and Privacy Risk Management Toolkit) that evaluates and analyzes the cyber and privacy risks of an organization and recommends mitigation measures that maximize risk reduction given a knowledge base of countermeasures, along with their direct and indirect costs, and subject to a financial budget. The proposed toolkit is composed of three main modules: a Cybersecurity Risk Assessment module, responsible for analyzing potential cyber threat scenarios; a Privacy Risk Assessment module, responsible for analyzing potential privacy risks in alignment with the GDPR objectives; and a Risk Mitigation module, responsible for evaluating and selecting optimal measures to mitigate selected risks.

			AMBIENT was deployed in a healthcare infrastructure to evaluate different attack scenarios potentially affecting their daily operations. As such, AMBIENT has been created to support cybersecurity decision makers with cybersecurity and privacy assessment identifying critical assets, potential threats to face, consequences that these threats may cause if they occur, and the actions to be implemented for their mitigation.

			As a decision support tool, AMBIENT provides advice on the basis of the potential security and privacy risks affecting target infrastructures, however, it does not automatically implement mitigation actions. Security managers can use AMBIENT’s results as a guide in their decision-making process to define appropriate security policies and strategies that keep risk scores within acceptable levels. Future work will focus on the integration of additional threat and vulnerability frameworks towards a more holistic risk management suite of tools. Additionally, exploring novel privacy-preserving techniques in the context of blockchain applications is left as future work which could bring more possibilities to extend the use of AMBIENT. It will also investigate the applicability of the toolkit to mitigate social attacks, which represent the highest risk to organizations and appear in the most claims as reported by cyber insurers.

			==Acknowledgements==
			===Author contributions===
			G.G.-G. performed conceptualization, methodology, software, validation, formal analysis, investigation, writing original draft, writing—review & editing, visualization, supervision. S.A.M. performed conceptualization, methodology, software, validation, formal analysis, investigation, writing original draft, writing—review & editing, visualization, supervision. D.P. performed conceptualization, methodology, software, validation, formal analysis, investigation, writing original draft, writing—review & editing, visualization, supervision. R.R. performed validation, resources, writing original Draft. D.N.-L. performed validation, resources, writing original Draft. C.O. performed conceptualization and methodology, paper editing. S.N. performed conceptualization and methodology and paper editing. C.X. performed conceptualization, methodology, investigation, writing—review & editing. E.P. performed conceptualization, methodology, validation, formal analysis, investigation, writing original draft, writing—review & editing, visualization, supervision, funding acquisition. All authors have read and agreed to the published version of the manuscript.

			===Funding===
			The research work presented in this article has been supported by the European Commission under the H2020 Programme, through funding of the “CUREX: seCUre and pRivate hEalth data eXchange” project (with Grant Agreement number 826404).

			===Conflict of interest===
			The authors declare no conflict of interest.

	==References==		==References==
Line 704:		Line 716:
	[[Category:LIMSwiki journal articles (added in 2021)]]		[[Category:LIMSwiki journal articles (added in 2021)]]
	[[Category:LIMSwiki journal articles (all)]]		[[Category:LIMSwiki journal articles (all)]]
			[[Category:LIMSwiki journal articles (with rendered math)]]
	[[Category:LIMSwiki journal articles on cybersecurity]]		[[Category:LIMSwiki journal articles on cybersecurity]]
	[[Category:LIMSwiki journal articles on health informatics]]		[[Category:LIMSwiki journal articles on health informatics]]

Shawndouglas: Saving and adding more.

2021-10-06T17:42:56Z

Saving and adding more.

← Older revision		Revision as of 17:42, 6 October 2021
Line 603:		Line 603:
	\|}		\|}
	\|}		\|}

			The advice suggests that by implementing this sub-control, the organization will benefit from improvement in various different areas of threat prevention such as DoS, malware, and man-in-the-middle attacks. The direct cost is also presented there, split into the different network layers (Demilitarized Zone-DMZ, Intranet, Private Subnet) for this specific sub-control in this organization.

			Figure 6 provides examples of the Risk Mitigation dashboard, which outputs data presenting the cost levels for the proposed CIS 8 Control “Malware Defenses” using 8.6 “Centralize Anti-Malware Logging.”


			[[File:Fig6 Gonzalez-Granadillo Sensors21 21-16.png\|1000px]]
			{{clear}}
			{\|
			\| style="vertical-align:top;" \|
			{\| border="0" cellpadding="5" cellspacing="0" width="1000px"
			\|-
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|<blockquote>'''Fig. 6''' Risk Mitigation module dashboard output</blockquote>
			\|-
			\|}
			\|}

			==Discussion and conclusions==
			===Discussion===
			Most risk assessment tools found in the literature either perform a cybersecurity or a privacy risk assessment. Most tools on the market have a rather narrow scope of application, with a single use case being the norm. There exists a considerable number of tools supporting the documentation of data processing practices, the formulation of consent templates, or the documentation of privacy and data protection policies. Apart from CNIL’s PIA tool, available methods make no reference to any tools that can automate the PIA process or create a PIA report. While, the cybersecurity status of the organization in which the impact analysis is performed is largely neglected by those tools.

			Furthermore, the current state-of-practice on risk assessment and analysis of data-related vulnerabilities in the healthcare domain includes mostly custom and proprietary solutions (tools, mechanisms, techniques, procedures) that are typically employed on demand, e.g., when new systems or components are installed, or when new policies need to be enforced. Most standards specify framework conditions for the risk management process but rarely go into detail of specific methods for the risk analysis or risk assessment. This is one of the reasons why often differences in the risk assessment arise within specific areas of application, such as in healthcare, making a direct comparison of the results cumbersome.

			In addition, the interoperability and information sharing among the underlying security-related components (usually coming from different technology providers and vendors) is hard to achieve, which in turn increases operational costs and stress during the daily tasks in hospitals and care centers. As a consequence, the healthcare sector is still far from a unified framework that will address vulnerability and risk assessments and analysis through a holistic solution that will compose and orchestrate the heterogeneous tools, mechanisms, techniques, and procedures while at the same time respecting privacy and adhering to GDPR policies.

			Regarding limitations of the toolkit, in order to perform the cybersecurity risk assessment, AMBIENT requires a minimum set of input data from the healthcare organization. If no vulnerability is detected or no business profile is provided by the healthcare organization, our proposed toolkit will not be able to compute the cybersecurity risk score. The qualitative and quantitative risk scores associated with the SQL injection attack discussed in the previous section evaluate a threat scenario that considers eight indicators (see Table 11), as well as the identification of potential vulnerabilities and weaknesses. The exploitation of these weaknesses will potentially lead to four unwanted incidents (i.e., privilege escalation by an attacker, unauthorized reading of data, unauthorized code execution, and unauthorized modification of data). Such incidents, if realized, will negatively impact confidentiality, integrity, and availability of the infrastructure’s assets, and hence privacy.

			{\|
			\| style="vertical-align:top;" \|
			{\| class="wikitable" border="1" cellpadding="5" cellspacing="0" width="80%"
			\|-
			\| colspan="2" style="background-color:white; padding-left:10px; padding-right:10px;" \|'''Table 11.''' Risk Indicators for an SQL injection attack
			\|-
			\|-
			! style="background-color:#e2e2e2; padding-left:10px; padding-right:10px;" \|Indicator
			! style="background-color:#e2e2e2; padding-left:10px; padding-right:10px;" \|Means
			! style="background-color:#e2e2e2; padding-left:10px; padding-right:10px;" \|Data type
			! style="background-color:#e2e2e2; padding-left:10px; padding-right:10px;" \|Source type
			\|-
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|IN-32: Does the web application consist of HTML forms?
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|questionnaire
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|Boolean
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|business
			\|-
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|IN-37: Do HTTP requests contain special elements used in an SQL command successfully executed?
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|event
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|Boolean
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|test
			\|-
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|IN-38: Do records in the database consist of corrupt or invalid data?
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|vulnerability
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|Boolean
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|application
			\|-
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|IN-44: Do HTTP requests contain special elements used in an SQL command?
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|event
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|Boolean
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|network
			\|-
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|IN-45: Do HTTP responses contain malicious scripts?
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|network, test, app
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|Boolean
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|network
			\|-
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|IN-54: How many sanitized HTTP requests contain special elements used in an SQL command?
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|application
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|Integer
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|event
			\|-
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|IN-55: How many abnormal (suspicious) SQL queries are executed?
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|application
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|Integer
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|event
			\|-
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|IN-56: How many SQL-related errors have been recorded in the log?
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|application
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|Integer
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|event
			\|-
			\|}
			\|}

			Limited input data will lead to inaccurate cybersecurity and/or privacy risk scores which will affect the selection of optimal mitigation measures. Cybersecurity and privacy scores are therefore highly dependent on the input data provided by the target infrastructure. Similarly, the risk mitigation module highly depends on the input data provided by the cybersecurity and privacy modules about the potential mitigation measures for each threat scenario.

			In addition, it is important to mention that AMBIENT is a decision support tool that provides advice and guidelines to security analysts and administrators on the basis of the potential risks affecting their infrastructures, but it does not implement automatic security actions to reduce the organization’s risk level. Security administrators and C-level managers should decide which strategy to deploy, and use the AMBIENT outcome as a guide in their decision-making process. The implementation of a mitigation measure therefore requires manual intervention from the healthcare infrastructure and will generate an effect on the cyber climate, as it will change indicator values in the system, and consequently, cybersecurity and privacy risk scores are expected to decrease. Mitigation measures are displayed in a simple way in the toolkit dashboard (including an ID, the name, and a description of the mitigation measure), and can also be shared in the JSON format.

			Another important aspect in the risk assessment process is the time spent for AMBIENT to compute their results. In general, scores are generated within a few minutes (depending on the type of threat analyzed and the number of indicators to compute), and mitigation measures are analyzed within seconds (right after the safeguard candidates are generated by the cybersecurity and privacy modules). The cost/benefit information associated with each mitigation measure is input data obtained through expert knowledge from the healthcare technical personnel. The accuracy of the results provided by risk mitigation module depends on the reliability of the provided input data, and the statistical and mathematical model used in the evaluation. It is worth noting that the risk mitigation part of AMBIENT is able to analyze not only reactive mitigation measures but also proactive mitigation measures. The former are immediate actions required to eliminate or reduce the risk level of a given organization, whereas the latter refers to medium or long-term actions required to reduce the attack surface of the target organization. The two threat scenarios presented in the previous section only include reactive mitigation measures, as we have assumed that the risk assessment is requested after a security event has been detected on the system. AMBIENT relies on this technology to enforce GDPR and record the risk assessment reports. As a result, the proposed approach will control the health data exchange process by reinforcing security, improving traceability, and improving auditability functionalities.

			===Conclusions===

Shawndouglas: Saving and adding more.

2021-10-06T17:04:32Z

Saving and adding more.

Show changes

Shawndouglas: Saving and adding more.

2021-10-05T23:19:58Z

Saving and adding more.

← Older revision		Revision as of 23:19, 5 October 2021
Line 337:		Line 337:
	\| style="background-color:white; padding-left:10px; padding-right:10px;" \|“Available budget”: “30,000 EUR”		\| style="background-color:white; padding-left:10px; padding-right:10px;" \|“Available budget”: “30,000 EUR”
	\|-		\|-
	\| style="background-color:white; padding-left:10px; padding-right:10px;" \|Cyber and privacy risk reports		\| style="background-color:white; padding-left:10px; padding-right:10px;" \|Cyber and privacy risk reports
	\| style="background-color:white; padding-left:10px; padding-right:10px;" \|The outputs of the other two modules of AMBIENT, used by the Risk Mitigation module to decide on how to mitigate risks using controls.		\| style="background-color:white; padding-left:10px; padding-right:10px;" \|The outputs of the other two modules of AMBIENT, used by the Risk Mitigation module to decide on how to mitigate risks using controls.
	\| style="background-color:white; padding-left:10px; padding-right:10px;" \|“risk model”: “WPR8”; “measures”: “M8, M10, M13, M22, M41, M42, M43, M45, M46, M47, M48, M49”; “privacy quantitative”: “9.8”; “privacy qualitative”: “VH”		\| style="background-color:white; padding-left:10px; padding-right:10px;" \|“risk model”: “WPR8”; “measures”: “M8, M10, M13, M22, M41, M42, M43, M45, M46, M47, M48, M49”; “privacy quantitative”: “9.8”; “privacy qualitative”: “VH”
Line 347:		Line 347:
	\| style="background-color:white; padding-left:10px; padding-right:10px;" \|Repository of cyber controls		\| style="background-color:white; padding-left:10px; padding-right:10px;" \|Repository of cyber controls
	\| style="background-color:white; padding-left:10px; padding-right:10px;" \|This requires a repository of controls along with their costs (purchase, implementation, maintenance cost) and benefits (efficacy in mitigating threats) to evaluate them during the game-theoretic and the optimization phase of its operation.		\| style="background-color:white; padding-left:10px; padding-right:10px;" \|This requires a repository of controls along with their costs (purchase, implementation, maintenance cost) and benefits (efficacy in mitigating threats) to evaluate them during the game-theoretic and the optimization phase of its operation.
	\| style="background-color:white; padding-left:10px; padding-right:10px;" \|“CIS subControls”: 1.1; “directcost”: 2276.158891; “implementation level”: {H: { “implelevel”: 1; “system performance cost”: 7.491514705; “usability cost”: 6.493688798; “overall indirectcost”: 6.992601751; “efficacy”: 78.36633331; “directcost”: 4097.086004 }}		\| style="background-color:white; padding-left:10px; padding-right:10px;" \|<nowiki>“CIS subControls”: 1.1; “directcost”: 2276.158891; “implementation level”: {H: { “implelevel”: 1; “system performance cost”: 7.491514705; “usability cost”: 6.493688798; “overall indirectcost”: 6.992601751; “efficacy”: 78.36633331; “directcost”: 4097.086004 }}</nowiki>
	\|-		\|-
	\|}		\|}
Line 381:		Line 381:
	\|}		\|}
	\|}		\|}

			==AMBIENT demonstration==
			This section presents one threat scenario composed of two attacks: an SQL injection and a ransomware attack, both mitigated by AMBIENT. The scenario evaluates concerns with the cybersecurity and privacy awareness level of the organization regarding data exchange in remote healthcare services, as inspired by the use cases of the H2020 CUREX project. [71] Cybersecurity and privacy risk assessments are conducted by the Cyber Risk Assessment and Privacy Risk Assessment components of AMBIENT, and then optimal security measures are proposed by the Risk Mitigation component.

			[[Point-of-care testing\|Point-of-care]] (PoC) systems have been widely used in hospitals in order to provide innovative solutions to medical professionals and physicians and provide them with an overview of the patients’ condition in a way that makes it easier for them to respond on time and prevent critical situations. PoC systems are platforms that incorporate devices and applications in order to collect, process and visualize data. Naturally, these types of platforms represent an expanded attack surface, as the variety of devices and systems used have unique vulnerabilities which can be challenging to identify and address. With an ever-increasing amount of data containing personally identifiable information and sensitive medical data being communicated across various devices, back-end analytic platforms, user workstations, smartphones, or sensors, it becomes evident that there are multiple threats that can breach legitimate systems and data. Hospitals and care centers need to address such cyber–physical challenges by efficiently assessing the associated risks and mitigate them with appropriate cybersecurity safeguards.

			===Testbed description===
			As depicted in Figure 2, and for the purpose of demonstrating the competitive advantages of AMBIENT, we have considered a real testbed composed of a subset of the assets and devices used in the Spanish Hospital Fundació Privada Hospital Asil de Granollers (FPHAG), which includes the following elements:

			*'''SAVAC client application''': Either accessed from the CITRIX server farm or from a PC that has the client version installed locally and connects to the SAVAC database, installed in the hospital’s data center (DC).
			*'''Workstations''': Three PCs are placed inside the users’ VLAN with the basic programs and hospital’s user credential handling procedures.
			*'''SAVAC Database server''': Consists of a cluster of servers that contains all the information stored.
			*'''Firewall''': The hospital’s DC is generally supervised by a firewall system in which specific rules are programmed. Virtual LAN users, servers, and devices are bi-directionally connected to the hospital’s firewall.
			*'''Switch''': This network component has a dedicated link to the cluster of servers and another to the rest of the network’s elements.
			*'''Analyzers''': The hospital uses analytic platforms, which operate directly on data collected by SAVAC and generate analytic dashboards and visualization reports for the hospital managers.
			*'''PACS image server''': The images are stored on [[picture archiving and communication system]] (PACS). To retrieve the images, a call is made from SAVAC to a URL through a unique identifier of the patient’s image study.
			*'''Integration server''': This is used to collect all data and external files and integrate them into SAVAC, either in the database or on the file server, or by external links using identifiers, as in the example of the PACS image server.
			*'''Medical equipment''': Different networked medical devices are placed in VLAN.
			*'''Smartphones''': Smart devices connect through the hospital’s Wi-Fi (open Wi-Fi validated via capture portal), using a specific identification that the hospital’s firewall allows to be visible, to operate and to have internet access.

			[[File:Fig2 Gonzalez-Granadillo Sensors21 21-16.png\|1000px]]
			{{clear}}
			{\|
			\| style="vertical-align:top;" \|
			{\| border="0" cellpadding="5" cellspacing="0" width="1000px"
			\|-
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|<blockquote>'''Fig. 2''' Hospital testbed scenario</blockquote>
			\|-
			\|}
			\|}

			In the testbed infrastructure depicted in Figure 2, the PCs run under the Windows 10 operating system; the servers are then placed in a VMware, while the medical devices will run in different versions of Windows and Linux operating systems. In addition, the mobile application to be assessed will run on an Android v9 smartphone. More information about the testbed and use case scenarios can be found in the work of Jofre ''et al.''<ref>{{Cite journal \|last=Jofre \|first=Marc \|last2=Navarro-Llobet \|first2=Diana \|last3=Agulló \|first3=Ramon \|last4=Puig \|first4=Jordi \|last5=Gonzalez-Granadillo \|first5=Gustavo \|last6=Mora Zamorano \|first6=Juan \|last7=Romeu \|first7=Ramon \|date=2021/1 \|title=Cybersecurity and Privacy Risk Assessment of Point-of-Care Systems in Healthcare—A Use Case Approach \|url=https://www.mdpi.com/2076-3417/11/15/6699 \|journal=Applied Sciences \|language=en \|volume=11 \|issue=15 \|pages=6699 \|doi=10.3390/app11156699}}</ref>

			===Use case scenarios===
			AMBIENT has been designed to be used in the healthcare domain for a variety of use case scenarios related to health data exchange. Examples of use case scenarios where the toolkit can be useful include the following:

			* cross-border patient data exchange, originated when a patient from hospital A has a malaise in a foreign hospital (i.e., hospital B), and due to the emergency, hospital B requests a transfer of a copy of the patient’s health records to hospital A;
			* data exchange in mobile healthcare platforms, which considers malfunctioning IoT devices that fail to register measurements, which imposes not only service disruption but also threatens to compromise the patients’ safety and health;
			* data exchange in remote healthcare services, which includes threats related to the confidentiality and integrity of the patients’ data coming from healthcare devices and applications (e.g., mobile applications for collecting blood pressure, health rate, temperature, etc.); and
			* data exchange for healthcare research, which includes privacy challenges originated from the exchange of health data for research purposes with third parties such as universities and research groups.

			In addition to health data exchange scenarios, AMBIENT is able to analyze a wide variety of threats affecting the appropriate operations of healthcare organizations. Such threat scenarios are derived from risk patterns that include inputs related to different vulnerabilities, incidents, and/or infrastructure context that may cause an undesirable situation with a certain likelihood, and which may have consequences in the risk level and economic loss in terms of confidentiality, integrity, and availability. Examples of these risk patterns include a denial of service attack, invalidated redirects and forwards, bypassed logins, compromised security via Trojan-malware, client-server protocol manipulation, session fixation, cross-site request forgery, and SQL injections.



	==References==		==References==
	{{Reflist\|colwidth=30em}}		{{Reflist\|colwidth=30em}}

Shawndouglas: Saving and adding more.

2021-10-05T23:00:25Z

Saving and adding more.

← Older revision		Revision as of 23:00, 5 October 2021
Line 318:		Line 318:
	*'''Safeguards Plan Solver''': For the budget allocation derived previously, this component calculates the safeguard combination that fits into the available budget of the defending agent and minimizes the maximum risk inflicted by the attacking agent respecting the “weakest link” concept.<ref name=":12" />		*'''Safeguards Plan Solver''': For the budget allocation derived previously, this component calculates the safeguard combination that fits into the available budget of the defending agent and minimizes the maximum risk inflicted by the attacking agent respecting the “weakest link” concept.<ref name=":12" />

			The Dashboard is used for three main high-level purposes: to communicate to the user the optimal risk control recommendation; to visualize its performance, in terms of risk reduction; and to visualize the different costs, direct and indirect, of the safeguards included in the recommendation.

			Input and output data processed and generated by this module are summarised in Table 5 and Table 6, respectively.

			{\|
			\| style="vertical-align:top;" \|
			{\| class="wikitable" border="1" cellpadding="5" cellspacing="0" width="80%"
			\|-
			\| colspan="3" style="background-color:white; padding-left:10px; padding-right:10px;" \|'''Table 5.''' Input to the Risk Mitigation module
			\|-
			\|-
			! style="background-color:#e2e2e2; padding-left:10px; padding-right:10px;" \|Input data
			! style="background-color:#e2e2e2; padding-left:10px; padding-right:10px;" \|Description
			! style="background-color:#e2e2e2; padding-left:10px; padding-right:10px;" \|Expected data
			\|-
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|Cyber investment
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|The budget available to the defending agent to implement cyber controls.
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|“Available budget”: “30,000 EUR”
			\|-
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|Cyber and privacy risk reports
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|The outputs of the other two modules of AMBIENT, used by the Risk Mitigation module to decide on how to mitigate risks using controls.
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|“risk model”: “WPR8”; “measures”: “M8, M10, M13, M22, M41, M42, M43, M45, M46, M47, M48, M49”; “privacy quantitative”: “9.8”; “privacy qualitative”: “VH”
			\|-
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|Risk appetite
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|The organization chooses its own risk appetite, expressed in the degree of impact they can tolerate before they decide to spend on a greater cybersecurity budget.
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|“risk appetite”: “Medium”
			\|-
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|Repository of cyber controls
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|This requires a repository of controls along with their costs (purchase, implementation, maintenance cost) and benefits (efficacy in mitigating threats) to evaluate them during the game-theoretic and the optimization phase of its operation.
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|“CIS subControls”: 1.1; “directcost”: 2276.158891; “implementation level”: {H: { “implelevel”: 1; “system performance cost”: 7.491514705; “usability cost”: 6.493688798; “overall indirectcost”: 6.992601751; “efficacy”: 78.36633331; “directcost”: 4097.086004 }}
			\|-
			\|}
			\|}

			{\|
			\| style="vertical-align:top;" \|
			{\| class="wikitable" border="1" cellpadding="5" cellspacing="0" width="80%"
			\|-
			\| colspan="3" style="background-color:white; padding-left:10px; padding-right:10px;" \|'''Table 6.''' Output generated by the Risk Mitigation module; <sup>1</sup> For this we have used the document published by the U.S. Department of Homeland Security and Emergency Services, Cyber Incident Response Team.
			\|-
			\|-
			! style="background-color:#e2e2e2; padding-left:10px; padding-right:10px;" \|Output data
			! style="background-color:#e2e2e2; padding-left:10px; padding-right:10px;" \|Description
			! style="background-color:#e2e2e2; padding-left:10px; padding-right:10px;" \|Expected data
			\|-
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|Reactive risk mitigation report
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|This report shows which mitigation measures, as proposed by the cyber risk assessment module, must be used and with what priority optimized by the risk mitigation module.
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|“risk mitigation output”: ’id’: 0101, ’report’: 0001; “mitigation measures”: M49, M8, M22, M41, M42, M13, M44, M10, M45, M43, M46, M19, M18, M48; “timestamp”: 2020-01-09T09:46:15.242445Z
			\|-
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|Risk improvement reports
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|These demonstrate to the end user the degree of risk improvement when the proposed safeguards are chosen for implementation. Each selected safeguard exhibits its own improvement against different threats. This is key in allowing the end user to make an informative choice about the required preemptive controls.
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|‘1’: { “malware risk improvement”: 99.11941836; “dos risk improvement”: 96.70459599; “web attack improvement”: 99.18107606; “phishing risk improvement”: 96.01828912; “man in the middle risk improvement”: 99.40160608; “overall risk improvement”: 98.72331726; ...}
			\|-
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|Control guidance reports
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|These are reports that explain to the end user how the selected safeguards assist the organization. They also include suggestions about actual cybersecurity products mapped to the framework of controls selected.
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|Information about the proposed CIS controls with suggestions on how they will help the target organization<sup>1</sup> (as presented later in Figure 5 and Figure 6).
			\|-
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|Control cost reports
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|These reports show to the end user what costs must be tolerated if the proposed safeguards are selected. The costs refer to both direct (e.g., financial losses) and indirect (e.g., system performance loss).
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|“CIS Sub-control”: 1.1; “Implementation Level”: Low; “System Performance Cost”: 0.966163655; “Financial Cost”: 1.789499785; “Usability Cost”: 0.386993268
			\|-
			\|}
			\|}
	==References==		==References==
	{{Reflist\|colwidth=30em}}		{{Reflist\|colwidth=30em}}

Shawndouglas: Saving and adding more.

2021-10-05T22:44:31Z

Saving and adding more.

Show changes

Shawndouglas: Saving and adding more.

2021-10-05T22:34:45Z

Saving and adding more.

← Older revision		Revision as of 22:34, 5 October 2021
Line 307:		Line 307:
	* prioritize short-term cyber actions that the organization must take against specific cyber threats and risks identified by the cybersecurity and privacy risk modules.		* prioritize short-term cyber actions that the organization must take against specific cyber threats and risks identified by the cybersecurity and privacy risk modules.

			The above objectives are also aligned with best practices for cybersecurity in procurement, as published by the European Union Agency for Cybersecurity. [69] The cybersecurity strategies consist of combinations of cybersecurity controls drawn from a well-known repository. The Risk Mitigation module uses the framework of CIS Controls, which comprises a well-known repository of cyber controls based on two items: real attack data, and a consensus development process involving cybersecurity experts to create a prioritized list of actions that increase the cybersecurity level of an organization mitigating both vulnerability-based and threat-based risks.

			The Core consists of six components that all work together to deliver a set of risk control recommendations. These offer actionable advice on what cyber controls to implement and how they perform in terms of costs and risk reduction. The advice is visualized to the user through the Dashboard. The core parts of the Risk Mitigation module are:

			* '''Risk Parameters Initializer''': This component initializes the parameters required to compute the optimal set of safeguards that mitigate cyber and privacy risks, including the reports received by the risk assessment modules.
			* '''Safeguard Game Generator''': This component uses AI optimization generating a strategic game between a defending and an attacking agent based on the game-theoretic concepts used to compute equilibria, i.e., optimal points. [70] This game is represented by the available actions of the agents and their payoff functions. The defending agent can choose among different ways of implementing a cyber control, and the attacking agent can choose among different attack methods.
			* '''Safeguard Game Solver''': This component calculates the game equilibria, which are optimal combinations of implementation ways (can be seen as levels when the ways refer to different intensity of implementing the control) chosen for each control used to mitigate cyber and privacy risks against the attacking agent. The Risk Mitigation module uses the 20 CIS Controls, which include 171 sub-controls. This component solves the game for each of these sub-controls to create a repository of optimal available safeguards.

Shawndouglas: Saving and adding more.

2021-10-05T22:30:19Z

Saving and adding more.

← Older revision		Revision as of 22:30, 5 October 2021
Line 299:		Line 299:

	The Risk Mitigation module of AMBIENT supports organizations with mitigating risks by addressing both cyber strategic decisions (called "CHANGE" in CISO language) and more immediate security actions (called "RUN") system administrators or the security team will benefit from implementing. It computes optimal defensive plans of cybersecurity safeguards for decision-support, which advises cybersecurity decision-makers on how to combine various safeguards to minimize overall cyber–physical risks threatening an organization. It comprises the Core and the Dashboard; the former implements models of cybersecurity control optimization and cyber investment, while the latter visualizes the performance of the selected safeguards and the decision support guidance. The Core generates all required data to be visualized by the Dashboard. The model and mathematical frameworks used in the Core are replicated from Panda ''et al.'' [51]		The Risk Mitigation module of AMBIENT supports organizations with mitigating risks by addressing both cyber strategic decisions (called "CHANGE" in CISO language) and more immediate security actions (called "RUN") system administrators or the security team will benefit from implementing. It computes optimal defensive plans of cybersecurity safeguards for decision-support, which advises cybersecurity decision-makers on how to combine various safeguards to minimize overall cyber–physical risks threatening an organization. It comprises the Core and the Dashboard; the former implements models of cybersecurity control optimization and cyber investment, while the latter visualizes the performance of the selected safeguards and the decision support guidance. The Core generates all required data to be visualized by the Dashboard. The model and mathematical frameworks used in the Core are replicated from Panda ''et al.'' [51]

			The overall aim of the Risk Mitigation module is to act as a decision-support tool for cybersecurity decision makers and help them:

			* determine long-term best cybersecurity strategies—in the form of advice—in terms of mitigating cyber and privacy risks subject to financial constraints by using fundamental principles of cybersecurity risk management to create the Core model and multi-criteria mathematical optimization to solve the underlying decision-making challenge;
			* visualize the cybersecurity advice using the CIS Controls v7.1 [2] (a well-known framework of cybersecurity safeguards) by generating practical and detailed advice on tools and processes required to implement the safeguards and visualizing the performance of cyber controls in terms of risk mitigation;
			* visualize the results of risk improvement to raise awareness of decision makers on how each cybersecurity safeguard improves the security posture of the organization by using the Dashboard; and
			* prioritize short-term cyber actions that the organization must take against specific cyber threats and risks identified by the cybersecurity and privacy risk modules.

← Older revision		Revision as of 17:42, 6 October 2021
Line 603:		Line 603:
	\|}		\|}
	\|}		\|}

			The advice suggests that by implementing this sub-control, the organization will benefit from improvement in various different areas of threat prevention such as DoS, malware, and man-in-the-middle attacks. The direct cost is also presented there, split into the different network layers (Demilitarized Zone-DMZ, Intranet, Private Subnet) for this specific sub-control in this organization.

			Figure 6 provides examples of the Risk Mitigation dashboard, which outputs data presenting the cost levels for the proposed CIS 8 Control “Malware Defenses” using 8.6 “Centralize Anti-Malware Logging.”


			[[File:Fig6 Gonzalez-Granadillo Sensors21 21-16.png\|1000px]]
			{{clear}}
			{\|
			\| style="vertical-align:top;" \|
			{\| border="0" cellpadding="5" cellspacing="0" width="1000px"
			\|-
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|<blockquote>'''Fig. 6''' Risk Mitigation module dashboard output</blockquote>
			\|-
			\|}
			\|}

			==Discussion and conclusions==
			===Discussion===
			Most risk assessment tools found in the literature either perform a cybersecurity or a privacy risk assessment. Most tools on the market have a rather narrow scope of application, with a single use case being the norm. There exists a considerable number of tools supporting the documentation of data processing practices, the formulation of consent templates, or the documentation of privacy and data protection policies. Apart from CNIL’s PIA tool, available methods make no reference to any tools that can automate the PIA process or create a PIA report. While, the cybersecurity status of the organization in which the impact analysis is performed is largely neglected by those tools.

			Furthermore, the current state-of-practice on risk assessment and analysis of data-related vulnerabilities in the healthcare domain includes mostly custom and proprietary solutions (tools, mechanisms, techniques, procedures) that are typically employed on demand, e.g., when new systems or components are installed, or when new policies need to be enforced. Most standards specify framework conditions for the risk management process but rarely go into detail of specific methods for the risk analysis or risk assessment. This is one of the reasons why often differences in the risk assessment arise within specific areas of application, such as in healthcare, making a direct comparison of the results cumbersome.

			In addition, the interoperability and information sharing among the underlying security-related components (usually coming from different technology providers and vendors) is hard to achieve, which in turn increases operational costs and stress during the daily tasks in hospitals and care centers. As a consequence, the healthcare sector is still far from a unified framework that will address vulnerability and risk assessments and analysis through a holistic solution that will compose and orchestrate the heterogeneous tools, mechanisms, techniques, and procedures while at the same time respecting privacy and adhering to GDPR policies.

			Regarding limitations of the toolkit, in order to perform the cybersecurity risk assessment, AMBIENT requires a minimum set of input data from the healthcare organization. If no vulnerability is detected or no business profile is provided by the healthcare organization, our proposed toolkit will not be able to compute the cybersecurity risk score. The qualitative and quantitative risk scores associated with the SQL injection attack discussed in the previous section evaluate a threat scenario that considers eight indicators (see Table 11), as well as the identification of potential vulnerabilities and weaknesses. The exploitation of these weaknesses will potentially lead to four unwanted incidents (i.e., privilege escalation by an attacker, unauthorized reading of data, unauthorized code execution, and unauthorized modification of data). Such incidents, if realized, will negatively impact confidentiality, integrity, and availability of the infrastructure’s assets, and hence privacy.

			{\|
			\| style="vertical-align:top;" \|
			{\| class="wikitable" border="1" cellpadding="5" cellspacing="0" width="80%"
			\|-
			\| colspan="2" style="background-color:white; padding-left:10px; padding-right:10px;" \|'''Table 11.''' Risk Indicators for an SQL injection attack
			\|-
			\|-
			! style="background-color:#e2e2e2; padding-left:10px; padding-right:10px;" \|Indicator
			! style="background-color:#e2e2e2; padding-left:10px; padding-right:10px;" \|Means
			! style="background-color:#e2e2e2; padding-left:10px; padding-right:10px;" \|Data type
			! style="background-color:#e2e2e2; padding-left:10px; padding-right:10px;" \|Source type
			\|-
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|IN-32: Does the web application consist of HTML forms?
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|questionnaire
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|Boolean
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|business
			\|-
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|IN-37: Do HTTP requests contain special elements used in an SQL command successfully executed?
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|event
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|Boolean
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|test
			\|-
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|IN-38: Do records in the database consist of corrupt or invalid data?
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|vulnerability
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|Boolean
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|application
			\|-
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|IN-44: Do HTTP requests contain special elements used in an SQL command?
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|event
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|Boolean
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|network
			\|-
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|IN-45: Do HTTP responses contain malicious scripts?
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|network, test, app
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|Boolean
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|network
			\|-
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|IN-54: How many sanitized HTTP requests contain special elements used in an SQL command?
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|application
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|Integer
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|event
			\|-
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|IN-55: How many abnormal (suspicious) SQL queries are executed?
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|application
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|Integer
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|event
			\|-
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|IN-56: How many SQL-related errors have been recorded in the log?
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|application
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|Integer
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|event
			\|-
			\|}
			\|}

			Limited input data will lead to inaccurate cybersecurity and/or privacy risk scores which will affect the selection of optimal mitigation measures. Cybersecurity and privacy scores are therefore highly dependent on the input data provided by the target infrastructure. Similarly, the risk mitigation module highly depends on the input data provided by the cybersecurity and privacy modules about the potential mitigation measures for each threat scenario.

			In addition, it is important to mention that AMBIENT is a decision support tool that provides advice and guidelines to security analysts and administrators on the basis of the potential risks affecting their infrastructures, but it does not implement automatic security actions to reduce the organization’s risk level. Security administrators and C-level managers should decide which strategy to deploy, and use the AMBIENT outcome as a guide in their decision-making process. The implementation of a mitigation measure therefore requires manual intervention from the healthcare infrastructure and will generate an effect on the cyber climate, as it will change indicator values in the system, and consequently, cybersecurity and privacy risk scores are expected to decrease. Mitigation measures are displayed in a simple way in the toolkit dashboard (including an ID, the name, and a description of the mitigation measure), and can also be shared in the JSON format.

			Another important aspect in the risk assessment process is the time spent for AMBIENT to compute their results. In general, scores are generated within a few minutes (depending on the type of threat analyzed and the number of indicators to compute), and mitigation measures are analyzed within seconds (right after the safeguard candidates are generated by the cybersecurity and privacy modules). The cost/benefit information associated with each mitigation measure is input data obtained through expert knowledge from the healthcare technical personnel. The accuracy of the results provided by risk mitigation module depends on the reliability of the provided input data, and the statistical and mathematical model used in the evaluation. It is worth noting that the risk mitigation part of AMBIENT is able to analyze not only reactive mitigation measures but also proactive mitigation measures. The former are immediate actions required to eliminate or reduce the risk level of a given organization, whereas the latter refers to medium or long-term actions required to reduce the attack surface of the target organization. The two threat scenarios presented in the previous section only include reactive mitigation measures, as we have assumed that the risk assessment is requested after a security event has been detected on the system. AMBIENT relies on this technology to enforce GDPR and record the risk assessment reports. As a result, the proposed approach will control the health data exchange process by reinforcing security, improving traceability, and improving auditability functionalities.

			===Conclusions===

← Older revision		Revision as of 23:00, 5 October 2021
Line 318:		Line 318:
	*'''Safeguards Plan Solver''': For the budget allocation derived previously, this component calculates the safeguard combination that fits into the available budget of the defending agent and minimizes the maximum risk inflicted by the attacking agent respecting the “weakest link” concept.<ref name=":12" />		*'''Safeguards Plan Solver''': For the budget allocation derived previously, this component calculates the safeguard combination that fits into the available budget of the defending agent and minimizes the maximum risk inflicted by the attacking agent respecting the “weakest link” concept.<ref name=":12" />

			The Dashboard is used for three main high-level purposes: to communicate to the user the optimal risk control recommendation; to visualize its performance, in terms of risk reduction; and to visualize the different costs, direct and indirect, of the safeguards included in the recommendation.

			Input and output data processed and generated by this module are summarised in Table 5 and Table 6, respectively.

			{\|
			\| style="vertical-align:top;" \|
			{\| class="wikitable" border="1" cellpadding="5" cellspacing="0" width="80%"
			\|-
			\| colspan="3" style="background-color:white; padding-left:10px; padding-right:10px;" \|'''Table 5.''' Input to the Risk Mitigation module
			\|-
			\|-
			! style="background-color:#e2e2e2; padding-left:10px; padding-right:10px;" \|Input data
			! style="background-color:#e2e2e2; padding-left:10px; padding-right:10px;" \|Description
			! style="background-color:#e2e2e2; padding-left:10px; padding-right:10px;" \|Expected data
			\|-
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|Cyber investment
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|The budget available to the defending agent to implement cyber controls.
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|“Available budget”: “30,000 EUR”
			\|-
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|Cyber and privacy risk reports
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|The outputs of the other two modules of AMBIENT, used by the Risk Mitigation module to decide on how to mitigate risks using controls.
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|“risk model”: “WPR8”; “measures”: “M8, M10, M13, M22, M41, M42, M43, M45, M46, M47, M48, M49”; “privacy quantitative”: “9.8”; “privacy qualitative”: “VH”
			\|-
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|Risk appetite
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|The organization chooses its own risk appetite, expressed in the degree of impact they can tolerate before they decide to spend on a greater cybersecurity budget.
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|“risk appetite”: “Medium”
			\|-
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|Repository of cyber controls
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|This requires a repository of controls along with their costs (purchase, implementation, maintenance cost) and benefits (efficacy in mitigating threats) to evaluate them during the game-theoretic and the optimization phase of its operation.
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|“CIS subControls”: 1.1; “directcost”: 2276.158891; “implementation level”: {H: { “implelevel”: 1; “system performance cost”: 7.491514705; “usability cost”: 6.493688798; “overall indirectcost”: 6.992601751; “efficacy”: 78.36633331; “directcost”: 4097.086004 }}
			\|-
			\|}
			\|}

			{\|
			\| style="vertical-align:top;" \|
			{\| class="wikitable" border="1" cellpadding="5" cellspacing="0" width="80%"
			\|-
			\| colspan="3" style="background-color:white; padding-left:10px; padding-right:10px;" \|'''Table 6.''' Output generated by the Risk Mitigation module; <sup>1</sup> For this we have used the document published by the U.S. Department of Homeland Security and Emergency Services, Cyber Incident Response Team.
			\|-
			\|-
			! style="background-color:#e2e2e2; padding-left:10px; padding-right:10px;" \|Output data
			! style="background-color:#e2e2e2; padding-left:10px; padding-right:10px;" \|Description
			! style="background-color:#e2e2e2; padding-left:10px; padding-right:10px;" \|Expected data
			\|-
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|Reactive risk mitigation report
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|This report shows which mitigation measures, as proposed by the cyber risk assessment module, must be used and with what priority optimized by the risk mitigation module.
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|“risk mitigation output”: ’id’: 0101, ’report’: 0001; “mitigation measures”: M49, M8, M22, M41, M42, M13, M44, M10, M45, M43, M46, M19, M18, M48; “timestamp”: 2020-01-09T09:46:15.242445Z
			\|-
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|Risk improvement reports
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|These demonstrate to the end user the degree of risk improvement when the proposed safeguards are chosen for implementation. Each selected safeguard exhibits its own improvement against different threats. This is key in allowing the end user to make an informative choice about the required preemptive controls.
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|‘1’: { “malware risk improvement”: 99.11941836; “dos risk improvement”: 96.70459599; “web attack improvement”: 99.18107606; “phishing risk improvement”: 96.01828912; “man in the middle risk improvement”: 99.40160608; “overall risk improvement”: 98.72331726; ...}
			\|-
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|Control guidance reports
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|These are reports that explain to the end user how the selected safeguards assist the organization. They also include suggestions about actual cybersecurity products mapped to the framework of controls selected.
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|Information about the proposed CIS controls with suggestions on how they will help the target organization<sup>1</sup> (as presented later in Figure 5 and Figure 6).
			\|-
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|Control cost reports
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|These reports show to the end user what costs must be tolerated if the proposed safeguards are selected. The costs refer to both direct (e.g., financial losses) and indirect (e.g., system performance loss).
			\| style="background-color:white; padding-left:10px; padding-right:10px;" \|“CIS Sub-control”: 1.1; “Implementation Level”: Low; “System Performance Cost”: 0.966163655; “Financial Cost”: 1.789499785; “Usability Cost”: 0.386993268
			\|-
			\|}
			\|}
	==References==		==References==
	{{Reflist\|colwidth=30em}}		{{Reflist\|colwidth=30em}}