Towards Design and Development of a Data Security and Privacy Risk Management Framework for WBAN Based Healthcare Applications
Abstract
:1. Introduction
2. Background and Related Work
2.1. Regulations and Standards
- FDA: The 800 series under Title 21 of the Code of Federal Regulations (CFR) outlines the regulations which govern medical devices within the United States (US). This regulation is enforced by the Food and Drug Administration (FDA). The FDA recognizes that the security and privacy of medical devices is a shared responsibility among stakeholders, including health care facilities, patients, health care providers, and manufacturers of medical devices [9]. Medical devices should be designed to protect assets and functionality, and to reduce the risk of loss of authenticity, availability, integrity and confidentiality. As part of Title 21 CFR part 820 -Quality System Regulation states that the medical device manufacturer needs to employ a cybersecurity risk management program [10]. The aim of the risk management program is to reduce the likelihood of the device functionality being compromised, intentionally or unintentionally, by inadequate cybersecurity. An effective cybersecurity risk management program should address cybersecurity in both premarket and postmarket medical device development lifecycle phases.
- HIPAA: The Health Insurance Portability and Accountability Act of 1996 (HIPAA) was brought forward by the Secretary of the US Department of Health and Human Services (HHS) as a law to enforce regulations for governing electronically managed patient information in the healthcare industry, and includes privacy and security protection of electronic personal health information(e-PHI) [11]. Title II of HIPAA provides five rules: Privacy Rule, Transactions and Code Sets Rule, Security Rule, Unique Identifiers Rule, and Enforcement Rule. The purpose of these rules is to prevent fraud and abuse within the healthcare system. The Privacy Rule requires implementing different policies and procedures to provide federal protections for personal health information held by covered entities. This rule also ensures patient rights concerning that information. The Security Rule specifies a series of administrative, physical, and technical safeguards to assure the confidentiality, integrity, and availability of electronically protected health information. Below are the key security and privacy requirements outlined in the HIPAA Security and Privacy Rule:
- ○
- Ensure the confidentiality, integrity, and availability of all PHI while they create, receive, store and transmit.
- ○
- Identify and protect against reasonably anticipated threats to the security or integrity of the information.
- ○
- Protect against reasonably anticipated, impermissible uses or disclosures of the information.
- ○
- Perform risk analysis as part of the security management processes
- ○
- Implement technical policies and procedures that allow only authorized persons to access e-PHI.
- ○
- Implement policies and procedures to ensure that e-PHI is not improperly altered or destroyed.
- ○
- Implement security measures to guard against unauthorized access to e-PHI.
- EU Medical Devices Regulations: The European Medical Device Regulation (EU MDR) ensures high standards of safety, security, and quality of medical devices being marketed within the EU for human uses [12]. EU MDR is also known as EU Directive 2017/745 and 2017/746, which was published in 2017. The cybersecurity requirements listed in Annex I of the MDR deal with the medical device’s premarket and postmarket aspects. Below is the list of key cybersecurity requirements from the EU MDR:
- ○
- Manufacturers shall establish, implement, document and maintain a risk management system.
- ○
- Medical device software should be developed in accordance with the state-of-the-art principles of the development life cycle, risk management, including information security, verification and validation.
- ○
- Manufacturers shall set out minimum requirements concerning hardware, IT networks security measures, including protection against unauthorized access.
- ○
- Implement proper safeguards to avoid unauthorized access, disclosure, dissemination, alteration or loss of information and personal data processed.
- ○
- Implement adequate safeguards to ensure confidentiality of records and personal data of subjects.
- ○
- Implement proper incident response plan and safeguards in case of a data security breach in order to mitigate the possible adverse effects.
- GDPR: The General Data Protection Regulation (GDPR) is a regulation on data protection and privacy for citizens in the European Union (EU) and European Economic Area [13]. It was introduced in May 2018. The EU commission designed the GDPR to achieve key goals such as, (1) protect the rights, privacy and freedom of individuals in the EU, (2) reduce the barrier for free movement of data inside the EU, (3) inform individuals how personal data will be processed and who will be given access, (4) individuals will be able to obtain their data and reuse it for their own purposes and (5) individuals have the right to restrict access and erase their data.
- FDA premarket and postmarket guidelines: The FDA provides premarket and postmarket guidelines for organizations and developers that need to be considered during the development lifecycle of a medical device or healthcare application. The premarket guidance [14] outlines the following key security and privacy related recommendations for medical device manufacturers:
- ○
- To employ a risk-based approach to the design and development of medical devices with appropriate cybersecurity protections.
- ○
- Take a holistic approach to device cybersecurity by assessing risks and mitigations throughout the product’s lifecycle.
- ○
- Identify the assets, threats, and vulnerabilities.
- ○
- Perform an impact assessment of the threats and vulnerabilities on device functionality and end-users.
- ○
- Assess the likelihood of a threat and of a vulnerability being exploited.
- ○
- Determine the risk levels and suitable mitigation strategies.
- ○
- Take an approach to monitor the cybersecurity information sources for identification and detection of cybersecurity vulnerabilities and risk.
- ○
- Identify and assess the threats and vulnerabilities being exploited.
- ○
- Take a holistic approach to detect and assess the threat sources.
- ○
- Establish a communication process for incident response.
- ○
- Design a verification and validation process for software updates and patches used to remediate the vulnerabilities.
- IEC 62304: IEC 62304 provides guidelines for each stage of the medical device software lifecycle with activities and tasks required for the safe design and maintenance of medical device software [16]. This standard is recognized by the FDA, EU and other regulatory agencies across the world. IEC 62304 recommends that organizations establish and maintain a risk management process to manage risk associated with security. The process should provide a methodology to identify the vulnerabilities, evaluate the associated threats, and implement risk controls to mitigate these threats. Finally, the process should also monitor the effectiveness of the risk control.
- NIST 800-53: The NIST 800-53 standard provides security and privacy controls to protect the application, data, assets and organizations from a diverse set of attacks, threats and risks [17]. These controls can be employed as safeguards to assure confidentiality, integrity, and availability of the information while it is processed, stored and transmitted.
- ISO 27002: ISO 27002 is an information security standard developed by International Organization for Standardization (ISO) which provides best practice recommendations and information security controls to assure confidentiality, integrity, and availability of data [18]. This standard aims to guide organizations to select, implement, and manage controls to minimize security risk.
2.2. Risk Management Frameworks
- IEC 80001-1:2010: IEC 80001-1—Application of risk management for IT-networks incorporating medical devices was introduced in 2010 to address risks associated with medical devices when connecting to IT-networks [19]. The framework aims to help organizations define the risk management roles, responsibilities, and activities to achieve medical device safety and security. IEC/TR 80001-2-2 [20] is a technical report that provides background processes to address security risk related capabilities for connecting medical devices to IT-networks.
- AAMI TIR57: AAMI TIR57 provides guidance for manufacturers to perform information security risk management to address security risks within medical devices [21]. AAMI TIR57 was developed with guidelines provided by ISO 14971 [22] and NIST SP 800-30 Revision 1—security risk management process developed for traditional IT systems [23]. The goal of AAMI TIR57 is to assist manufacturers with the following key outcomes: (1) identification of assets, threats and vulnerabilities, (2) estimation and evaluation of associated security risk, (3) selection of security risk controls and (4) monitoring the effectiveness of the security risk controls.
- IEC 80001-1:2010 was primarily developed for applications which operate within a healthcare delivery organization’s IT-network, whereas WBAN applications may operate in a public, open network using short-range communication media.
- A WBAN application consists of resource constrained sensor devices which have limited memory and computational power and cannot accommodate complex security solutions like traditional healthcare applications. Neither framework provides any guidance for managing security and privacy risks for resource constrained sensor devices.
3. Methodology
3.1. Identify and Analyse the Healthcare Regulations and Standards for Security and Privacy Requirements
- The Regulated Software Research Centre, of which the authors are members, is widely recognized for its research in the medical device regulatory world. Its members provided advice on the applicable regulations and standards. The respective regions legislative portal website was also checked to identify the regulations. This resulted in a total of four regulations which were the FDA’s Code of Federal regulation for medical devices, HIPAA, EU MDR and GDPR.
- The resultant four regulations were analyzed to extract the security and privacy requirements for developing healthcare applications. The regulations, along with their respective security and privacy requirements are detailed in Section 2.1 above.
- Additionally, a snowballing approach was taken for reviewing each regulation to identify the security and privacy standards. Along with a snowballing approach and guidance from members of the Regulated Software Research, the following standards were identified as applicable: the FDA’s premarket and postmarket guidelines, IEC 62304, NIST 800-53 and ISO 27002.
- The resultant five standards were analyzed to extract the security and privacy requirements. These security and privacy requirements are detailed in Section 2.1 above.
3.2. Identify and Analyse the Healthcare Security and Privacy Risk Management Frameworks
- Review the regulations and standards identified in the previous section (Section 3.1) for references to security and privacy risk management frameworks. The review resulted in a total of four risk management frameworks: ISO/IEC 80001-1:2010, AAMI TIR57, ISO 14971 and NIST 800-30.
- Analyze the risk management frameworks to identify which of them are specific for developing healthcare-based applications. An initial analysis found that only two of these four frameworks were ‘healthcare specific’ security and privacy risk management frameworks, that is ISO/IEC 80001-1:2010 and AAMI TIR57. Details of the risk management frameworks are outlined in Section 2.2. ISO/IEC 80001-1:2010 and AAMI TIR57 were selected for further analysis to identify whether both are applicable for developing WBAN based healthcare applications. It was found that neither of these frameworks were suitable for developing WBAN applications. The reason for their unsuitability is presented at the end of Section 2.2.
3.3. Identify the Challenges for Assuring WBAN Data Security and Privacy
- Conduct a search on IEEEXplore, ScienceDirect and Google scholar using the search string; “healthcare AND (security OR privacy) AND (standard OR regulation OR compliance) AND (barrier OR challenges OR difficulties)”.
- Set inclusion criteria as follows: (1) presented the challenges for assuring security and privacy of healthcare applications that comply with regulations; (2) publication year: 2010–2020; (3) language is English and full text available.
- The initial search resulted in a total of 320 research papers.
- In the first screening each paper was analyzed by reviewing the abstract and conclusion. If the paper addressed any challenges, then it was selected for the second screening. A total of 125 papers out of 320 were selected for the second screening.
- In the second screening each paper was analyzed by reading the full text and checking whether the paper presented any challenges for assuring security and privacy of healthcare applications that comply with regulations. The second screening resulted in a total of 19 papers out of 125.
- Finally, a list of challenges was recorded from those papers which is presented in Section 4.
3.4. Develop the Proposed Security and Privacy Framework
- Identify the possible threats and vulnerabilities of a WBAN based healthcare application by conducting threat modeling.
- Review the report from threat modeling to identify the respective control(s) for each threat and vulnerability.
- Develop the implementation details for these controls (presented in Section 5.2.).
- Validate the effectiveness of the controls by implementation in an industrial setting. This is outlined in Section 6.
- Gather recommendations and suggestions for improvement to the alpha version from the organization who conducted the implementation. This is outlined in Section 6.5.
4. Challenges
5. Data Security and Privacy Framework (Alpha Version)
- Identification of possible threats and vulnerabilities.
- Implement controls to protect the application against those threats and vulnerabilities.
- Evaluate the effectiveness of the controls.
5.1. Identification of Possible Threats and Vulnerabilities
5.2. Implement Controls to Protect the Application against Those Threats and Vulnerabilities
5.2.1. Control Collection
5.2.2. Control Selection
5.2.3. Development of Security Control Implementation Details
5.3. Evaluate the Effectiveness of the Controls
5.4. Implementation Process
6. Validation within an Industrial Setting
6.1. Scope and Application Use-Case
6.2. Develop Data Flow Diagram
6.3. Apply Threat Modelling
- Design and configuration.
- Generate threat report.
- Identify the security controls by analyzing the report.
6.4. Implementation of the Controls
- Force users to have a strong password.
- Do not display or transmit the password in clear text. Validate the email address and password through an input validation technique. Validate email address by sending an email verification link.
- Lock user accounts after a certain number of failed logins attempts during a time-period.
- Maintain a list of commonly used, expected, or compromised passwords and update the list when passwords are compromised directly or indirectly.
6.5. Evaluate the Effectiveness of the Controls
6.5.1. Scope of the Testing
6.5.2. Testing Tools
6.5.3. Penetration Test Result
- Potential denial of service points: During testing, there were four potential DoS points found. These are requests that timeout within 10 s due to malformed data inside the payload. These can be run multiple times in multiple threads, driving up the usage and putting stress and strain on the service.Recommendation: It was advised that the API endpoints backend code should handle potential malformed data gracefully by input validation. Additionally, a proper HTTP response is needed if an API endpoint failed to process a request, so that the user can retry a request later.Action: Added input validation to validate the input data stream. Additionally, an error response code was also added to notify the user that API endpoints were unable to process the malformed input data.
- Security misconfiguration—Stack traces enabled: During testing, it was discovered that stack traces were enabled for some API endpoints.Recommendation: It was advised to turn off the stack trace for all endpoints and use a code review process to detect this coding error during development.Action: Stack trace was disabled for all the endpoints and the exception was written into a log file for auditing.
6.6. Suggestions
- Identify threats and vulnerabilities at the requirement analysis phase to produce security and privacy requirements.
- A guideline for system architecture review would be useful to check whether the minimum security and privacy requirements are taken into consideration.
- A risk evaluation process would be helpful to identify the severity level of the identified threats and vulnerabilities.
- A risk treatment process will be useful to identify the risks which require controls to mitigate.
- A code review process during the control’s implementation will help to minimize coding errors.
- Conduct unit testing during the implementation phase to identify whether the control is implemented properly.
7. Overview of the Data Security and Privacy Risk Management Framework (Beta Version)
- AAMI TIR57 does not clearly define how to conduct the security and privacy risk assessment at both the requirements analysis and the system architecture phases. This framework provides the steps to conduct security and privacy risk assessment at both phases. Additionally, the framework also provides a list of assets, threats and vulnerabilities which are specific to WBAN applications, which can be used as a starting point for conducting risk analysis.
- AAMI TIR57 does not provide any design review guidelines at the system architecture phase. The proposed framework added the design review guidelines recommended by IEC 80001-5-1.
- TIR57 does not include risk treatment to identify unacceptable risks which require controls to mitigate. This framework provides risk treatment steps as part of the risk assessment.
- This framework also consists of a mapping of possible threats and vulnerabilities with respective controls along with implementation details for the controls.
- This framework provides steps and tools to conduct in-house vulnerability scans and penetration testing.
8. Security and Privacy Risk Assessment
8.1. Define Scope and Purpose
- The intended use.
- Initial product requirements.
- Operating environment of the application.
- List of team members presented in Table 4 who will conduct the risk assessment.
- Timeline for the security and privacy risk assessment.
8.2. Risk Assessment Approach
8.3. Security and Privacy Risk Assessment at the Requirements Analysis Phase
- Apply risk analysis to identify the risk.
- Evaluate each risk to identify the acceptable and unacceptable risks.
- Update list of security and privacy requirements for unacceptable risk.
8.3.1. Risk Analysis
8.3.1.1. Identify and Document the Assets
8.3.1.2. Identify and Document Threats
- Using Table A1 in Appendix A, select the threats related to the assets identified in the previous section.
- As the threat landscape is changing rapidly, it is recommended to check for newly discovered threats at the time of threat identification. To gather information about newly discovered threats, the assessor team can use various sources such as research articles, blog posts, OWASP (https://owasp.org/www-community/attacks/ access on 30 July 2021), governmental agencies such as US-CERT (https://www.us-cert.gov/resources/cybersecurity-framework access on 30 July 2021), ENISA (https://etl.enisa.europa.eu/ access on 30 July 2021), NIST (https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-30r1.pdf access on 30 July 2021), BSI (https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Grundschutz/International/bsi-standard-2003_en_pdf.pdf?__blob=publicationFile&v=2 access on 30 July 2021) and private organizations such as HITRUST (https://hitrustalliance.net/threat-catalogue/ access on 30 July 2021). Each newly discovered threat needs to be analyzed by studying the threat description, threat agents, possible attack scenarios and checking whether the same attack scenario can occur within the WBAN application. If a threat is applicable to WBAN applications, then the assessor team needs to identify the assets which will be affected if the threat occurs.
- Document the following in the security and privacy risk assessment report:
- ○
- List of threats and respective affected assets.
- ○
- Date when the threat identification was conducted.
- ○
- The name and role of the person who conducted the threat identification.
8.3.1.3. Identify and Document the Vulnerabilities
- Review the list of vulnerabilities presented in Table A1 in Appendix A and select which are related to the identified assets.
- As the vulnerability landscape is constantly changing, the team need to check in various sources such as OWASP IoT Top 10 (https://wiki.owasp.org/index.php/OWASP_Internet_of_Things_Project access on 30 July 2021) and OWASP Mobile Top 10 (https://owasp.org/www-project-mobile-top-10/ access on 30 July 2021). During the review of a newly discovered vulnerability, the team needs to review the common security weaknesses and possible threat scenario section, in order to check whether the vulnerability can be exploited by any threat and affect any assets.
- Finally, the assessor team will document all the vulnerabilities details, name and role of the person, and date when the vulnerability identification process was conducted in a security and privacy risk assessment report.
8.3.1.4. Identify and Document the Adverse Impacts
- What is the impact if that asset’s confidentiality is compromised, and the information it contained is made available to an attacker?
- What is the impact if that asset’s integrity is compromised?
- What is the impact if that asset is made unavailable?
- What is the impact if that asset’s privacy is compromised?
- Can the immediate impact of a compromised asset lead to another type of attack or vulnerability?
8.3.2. Risk Evaluation and Treatment
8.3.2.1. Determine Impact
- Harm to user health and organization reputation.
- Operational impacts.
- Financial loss.
- Reputational harm.
- Loss of assets.
8.3.2.2. Determine Likelihood
- Adversary intent and skill level.
- The affected asset.
- Historical evidence about the threat.
8.3.2.3. Calculate Risk Score
8.3.2.4. Risk Acceptability Criteria
- The organization’s goals and objectives.
- Business operations.
- Application use case and technology stack used for developing the application.
- Legal and regulatory aspects.
- Budget and time for developing the application.
8.3.2.5. Risk Treatment
- Risk modification: A risk which requires implementation of controls to reduce the impact and/or likelihood to an acceptable level.
- Risk avoidance: A risk can be avoided by eliminating the source of the risk or the asset exposed to the risk. This is usually applied when the severity of the risk impact and/or likelihood outweighs the benefits gained from implementing the countermeasure. For example, physically moving an on-premises server to an alternative location to mitigate the risk caused by nature might be outweighed with the cost of moving the server.
- Risk sharing: A risk can be fully or partially shared or transferred to another party. If the application is using any third-party libraries or public cloud services, risk related to these can be shared or transferred to the owner of the service.
8.3.2.6. Update Security and Privacy Requirements
- Assure data confidentiality by protecting sensor nodes, and database server from unauthorized access.Assure data integrity by protecting data from external modification during transmission or while in storage.
- Assure that data will always be available to an authorized entity of the application.
- Assure privacy of the data during collection, processing and transmission. Allow access of the data only to authorized entities.
- Use a lightweight, memory and energy-efficient cryptographic algorithm for encryption.
- Facilitate a key management service for key generation, key refreshing, key agreement, key distribution and key revocation.
- Include a firewall and intrusion detection system to identify and block suspicious activity on a network.
- Include logging for auditing and accountability.
- Include a data backup strategy to assure high availability of the application.
- Update the initial product requirements with security and privacy requirements.
- Document the security and privacy requirements in the security assessment report.
8.4. Security and Privacy Risk Assessment at the System Architecture Phase
- Review system architecture according to security and privacy principles and requirements identified in Section 8.3.2.6.
- Apply risk analysis to identify the security and privacy risks.
- Identify acceptable and unacceptable risks.
- Identify the list of unacceptable risks which will require controls to mitigate.
- Update security and privacy requirements and product requirements with unacceptable risks.
- Check whether any update to the current system architecture is required due to newly identified security and privacy requirements. If yes, then make necessary changes to the system architecture and conduct risk analysis followed by risk evaluation and treatment.
8.4.1. Review System Architecture
- Review the system architecture for compliance with security and privacy design principles. To review system architecture, organizations should take the following security and privacy design principles into consideration:
- ○
- Identify whether each component of the application will interface externally or internally or both.
- ○
- Identify how the user will access each component of the application and define the trust boundary.
- ○
- Use least privilege principle while accessing and interfacing with any component.
- ○
- Take the threats and vulnerabilities identified in the requirement analysis phase into consideration while designing the security and privacy requirements.
- ○
- Identify the use of any third-party components and their security and privacy capabilities.
- ○
- Keep the system architecture as simple as possible.
- Ensure that all security and privacy requirements identified in Section 8.3.2.6 are implemented.
- If any security and privacy requirements or design principles are not implemented, then implement the missing one and iterate the review process.
8.4.2. Risk Analysis
8.4.2.1. Identify and Document the Assets
- Check whether any new asset is discovered compared to the list of assets identified during the requirement analysis phase in Section 8.3.1.1.
- Document the complete list of assets in the risk assessment report.
8.4.2.2. Identify and Document Threats
- Follow the steps outlined in Section 8.3.1.2.
- Document the complete list of threats in the risk assessment report.
8.4.2.3. Identify and Document the Vulnerabilities
- Apply threat modelling to identify vulnerabilities in a WBAN application. Section 6.3 outlines guidance on how to conduct threat modelling.
- Check if there are any additional vulnerabilities to those in the list of vulnerabilities identified during the requirements analysis phase in Section 8.3.1.3.
- If yes, then record the newly discovered vulnerabilities with possible countermeasures (if available) in the security assessment report.
8.4.2.4. Identify and Document the Adverse Impacts
8.4.3. Risk Evaluation and Treatment
- Follow the steps outlined in Section 8.3.2.1, Section 8.3.2.2, Section 8.3.2.3, Section 8.3.2.4 and Section 8.3.2.5.
- Identify the list of acceptable risks followed by unacceptable risks which require control to mitigate.
- Finally, document the updated product requirements, list the acceptable and unacceptable risks in the security and privacy risk assessment report.
8.4.4. Update Security and Privacy Requirements
- Make necessary modifications to the system architecture.
- Iterate the security risk analysis and security evaluation with treatment process until the security requirements are addressed in the system architecture.
8.5. Security and Privacy Risk Assessment Report
- Scope of the security and privacy risk assessment.
- Team members who conducted the risk analysis, the risk evaluation and treatment with date.
- Initial product requirements.
- Selected risk assessment approach with rationale.
- List of assets identified in both phases.
- List of threats and vulnerabilities, along with impact and likelihood score that were identified in both phases.
- Risk acceptability criteria with rationale for both the requirements and system architecture phases.
- List of acceptable and unacceptable risks with rationale.
- List of unacceptable risks to be shared, avoided and which require controls to mitigate.
- List of security and privacy requirements identified at both the requirement analysis and the system architecture phases.
9. Security and Privacy Risk Controls
9.1. Review and Prioritise the Security and Privacy Risk Controls
- A team, comprised of a technical lead, a developer, and a QA person will review the implementation details presented in Appendix B for each control
- Prioritize the controls based on the following:
- ○
- Risk score.
- ○
- Product delivery plan and timeline of the project.
- ○
- The priority of each use case.
- ○
- Complexity, time required to implement the control.
- Document the list of controls, along with their implementation details and prioritization in the security and privacy risk control report.
9.2. Implementation and Verification of Security and Privacy Risk Controls
- Validate input from all data sources.
- Compile code using the highest warning level and take necessary action to resolve the warnings.
- Use version control to track code changes.
- Sanitize the input to SQL statements. Use parameterized SQL statements. Do not use string concatenation or string replacement to build SQL statements.
- Use the latest version of compilers, which often include defences against coding errors; for example, GCC protects code from buffer overflows.
- Include proper error/exception handling. Check the return values of every function, especially security and privacy related functions.
- Encode HTML input field data. Do not store sensitive data in cookies.
- Use code review tools to find security and privacy issues early.
- Review the reason for the failure and take necessary action based on the scenario presented in Section 9.3.
- Conduct code review and/or unit test again to check whether the failure case is addressed.
- Finally, the result of the code review and the unit testing needs to be documented in the security risk control report with the updated list of controls (if any new control were added).
9.3. Review of Security and Privacy Controls
- The control was not properly implemented according to the implementation guidelines outlined in Appendix B. In that case the developer needs to implement the control again according to the implementation guidelines.
- Appropriate control was not selected for addressing the threats and/or vulnerabilities. If the appropriate control is not available in Appendix B, then analyze external sources such as NIST 800-53, ISO 27005, OWASP and blogs for appropriate control and implementation details.
- The developer did not follow appropriate secure coding practices during implementation.
9.4. Software Integration Testing
- Security and privacy requirements testing—to validate the security and privacy requirements identified during the risk assessment are implemented properly by conducting functional, performance and scalability testing.
- Threat and vulnerabilities mitigating testing—to validate the effectiveness of the implemented controls against the identified threats and vulnerabilities.The following steps should be conducted at the software integration testing stage:
- Perform integration testing by conducting functional, unit-test, black-box, white box and gray box testing. Organizations can use one or a combination of multiple testing approaches to conduct the integration testing based on the QA resource expertise and availability.
- If an integration test fails, then check whether it failed due to a security risk control
- ○
- If no, then take appropriate measures to fix the failure case and conduct the software integration test again.
- ○
- If yes, then review based on considerations presented in Section 9.3 in order to identify the reason for failure and take appropriate measures to address the failure case and conduct the software integration test again.
10. Evaluation of Overall Residual Security and Privacy Risk Acceptability
10.1. Conduct Vulnerability Scanning/Penetration Testing
- Define the scope of the vulnerability scanning and/or penetration testing. The scope will include:
- ○
- List of application use-cases.
- ○
- List of assets.
- ○
- List of threats and vulnerabilities for which countermeasures are implemented.
- Select the tools to be used to conduct the testing.
- Include external expertise (if required).
- Collect the results for review.
- Document the overall residual security and privacy risk acceptability in a report including:
- ○
- Date of the testing.
- ○
- Name of people/organization who performed the scanning and/or testing.
- ○
- Scope of the testing.
- ○
- List of tools used for conducting the testing.
10.2. Review Test Result
- Check whether the threat is a new threat or existing threat which was identified during the security and privacy risk assessment steps.
- If the threat is an existing threat, then perform a review of the control based on the considerations presented in Section 9.3. to identify the reason for failure and take appropriate measures to address the failure case and mitigate the threat.
- If the threat is a new threat, then check whether the suggested control from scanning and/or testing report is available in Appendix B
- ○
- If yes, then implement according to implementation details to mitigate the threat and add the selected control to the existing list.
- ○
- If no, then collect implementation details from external sources such as: NIST 800-53, ISO 27005, OWASP, blogs, etc. Update the existing implementation details in Appendix B with the newly identified threat and respective control with implementation guidelines.
- Upon completion of the implementation of the controls, testing needs to be conducted again to verify that the control successfully mitigates the threat.
- Document the action taken to address each threat in the overall residual security and privacy risk acceptability report.
11. Discussion
11.1. How the Proposed Framework Addresses the Challenges
- Lack of trained staff, responsibilities, budget, and management support—this framework consists of a list of assets, threats, vulnerabilities, and controls with implementation details which are specific to WBAN applications. The implementation of this framework requires minimal security expertise and will help to reduce development time, and thereby development cost.
- The existing standards are too complex and complicated to implement—this framework provides detailed guidance on how to conduct each step of the risk management process. This guidance should greatly assist developers with limited experience in implementing a risk management process.
- Limited knowledge about healthcare regulatory requirements and standards—the framework is based on recommendations and best practice guidelines provided by regulations such as HIPPA and GDPR, and by standards such ISO/IEC 80001-2-2, TIR 57, NIST 800-53 and ISO 27002.
- Understanding the data flow around the system and what assets need to be protected—the framework provide guidance on conducting security risk assessment at both the requirements analysis and the system architecture phases. This guidance will help the organization understand how data flows around the system and to identify the assets that need protection.
- Comprehensive understanding of the architecture for WBAN security and privacy—the framework outlines the possible assets, threats and vulnerabilities, and provides guidelines on how to conduct the architecture review. Additionally, the framework identifies the security requirements that need to be considered during the development of the architecture of a WBAN application. This will help organizations to obtain a comprehensive understanding of WBAN architecture.
- Identifying appropriate security controls with respective implementation details—the framework provides appropriate security controls, along with their implementation details, for a WBAN application. The implementation details will assist a developer to implement the security controls.
- Due to a vast number of security controls, the challenge is prioritizing these controls in addition to planning releases without compromising security and privacy—the security risk score which is identified during the security risk evaluation and treatment stage can be used to prioritize the risk and respective security risk control.
- Security mechanisms for sensor device nodes—the framework suggests using very lightweight encryption and decryption processes. This framework recommends use of the AES symmetric cryptographic algorithm and the Diffie-Hellman process for key exchanges between mobile applications and sensor devices.
11.2. Threat to Validity
12. Conclusions and Future Work
Author Contributions
Funding
Institutional Review Board Statement
Informed Consent Statement
Data Availability Statement
Conflicts of Interest
Appendix A
Asset Name | Asset Sub-Category | Threat Name | Vulnerabilities | Security Controls | |
---|---|---|---|---|---|
Sensor Device | Operating system | Malware | Over-privileged users Over-privileged code Use of the same operating system | Malware protection | |
Code injection | Input validation vulnerability | Input validation Output validation | |||
Software libraries | Third-parties failures | Insecure ecosystem interfaces | Third-Party data distribution policy Monitoring and review of third-party services | ||
Application software | Command injection | Input validation vulnerability | Input validation | ||
Repudiation attack | Access control vulnerability Logging and auditing vulnerability | Logging Access control Non-repudiation | |||
Device identity including location information | Attacks on privacy | Insecure data storage Insufficient privacy protection | Encryption Authorization Data anonymization | ||
Data/Sensitive information leakage | Insecure data storage | Encryption Authorization Data anonymization | |||
Data collected from the sensor device | Modification of information | Insecure communication Insecure data storage | Encryption Data integrity | ||
Replay attack | Lack of session management Insufficient cryptography | Session management Encryption | |||
Device resources | Processing | Buffer overflow attack | Buffer overflow | Code review | |
Denial of Service | Input validation vulnerability | Blocking brute force attacks Access control Session management | |||
Memory | Buffer overflow attack | Buffer overflow | Code review | ||
I/O | communication protocol hijacking | Insecure communication | Encryption Authentication | ||
– | Masquerading attack | Lack of access control Insecure authorization Insufficient cryptography | Access control Authorization Encryption | ||
Physical attacks | Lack of physical hardening | Physical protection Client platform security | |||
Mobile App | – | Cryptanalysis | Insufficient cryptography | Encryption Cryptography Key management | |
Man-in-the-middle attack | Session management vulnerability Insecure communication | Authentication Input validation Session management Encryption | |||
Web parameter tampering | Input validation vulnerability | Input validation | |||
Session hijacking attack | Input validation vulnerability | Session management | |||
Web Application | – | Code injection | Input validation vulnerability | Input validation Output validation | |
Cross Site Scripting (XSS) | Improper data validation | Data validation | |||
Cryptanalysis | Insufficient cryptography | Encryption Cryptography Key management | |||
Man-in-the-middle attack | Session management vulnerability Insecure communication | Authentication Input validation Session management Encryption | |||
Session hijacking attack | Input validation vulnerability | Session management | |||
Web Service | Application software | Modification of information | Insecure communication Insecure data storage | Encryption Data integrity | |
Brute force attack | Insufficient session-ID length | Authentication | |||
SQL injection | Input validation vulnerability | Input validation | |||
Replay attack | Lack of session management Insufficient cryptography | Session management Encryption | |||
Server resources | Processing | Denial of Service | Input validation vulnerability API abuse Lack of intrusion detection | Access control Session management Firewall | |
Command injection | Input validation vulnerability | Input validation | |||
Memory | Buffer overflow attack | Buffer overflow | Code review | ||
I/O | Denial of Service | Input validation vulnerability API abuse Lack of intrusion detection | Access control Session management Firewall | ||
Replay attack | Lack of session management Insufficient cryptography | Session management Encryption | |||
Storage | Attacks on privacy | Insecure data storage Insufficient privacy protection | Encryption Authorization Data anonymization | ||
Modification of information | Insecure communication Insecure data storage | Encryption Data integrity | |||
Data/Sensitive information leakage | Insecure data storage | Encryption Authorization Data anonymization | |||
Physical attacks | Lack of physical hardening | Physical protection Client platform security | |||
Database | Application software | Blind SQL injection | Input validation vulnerability | Input validation | |
SQL Injection | Input validation vulnerability | Query parameterization Input validation | |||
Server resources | Processing | Information or products from an unreliable source | Lack of access control Insecure authorization | Access control Authorization | |
Memory | Denial of Service | Input validation vulnerability Lack of intrusion detection Database access abuse | Access control Session management Firewall | ||
I/O | Denial of Service | Input validation vulnerability Lack of intrusion detection Database access abuse | Access control Session management Firewall | ||
Storage | Data/Sensitive information leakage | Insecure data Storage Insecure communication | Encryption Authorization Data anonymization | ||
– | Physical attacks | Lack of physical hardening | Physical protection Client platform security | ||
Wireless communication | – | Communication protocol hijacking | Insecure communication | Encryption Authentication | |
Interception of information | Insecure communication | Encryption | |||
Eavesdropping | Insecure communication | Encryption | |||
Man-in-the-middle attack | Session management vulnerability Insecure communication | Authentication Input validation Session management Encryption | |||
Masquerading attack | Lack of access control Insecure authorization Insufficient cryptography | Access control Authorization Encryption | |||
Sniffing attack | Insecure communication | Encryption |
Appendix B
Appendix B.1. Auditing and Accountability
- Define the list of parameters that will be captured as part of audit records and use a centralized platform to configure and manage these list of parameters (AU-3, 12.4.1)
- ○
- user IDs.
- ○
- system activities.
- ○
- dates, times and details of key events, e.g., log-on and log-off.
- ○
- device identity or location if possible and system identifier.
- ○
- records of successful and rejected system and other resource access attempts.
- ○
- changes to system configuration.
- ○
- use of privileges.
- ○
- use of system utilities and applications.
- ○
- files accessed and the kind of access.
- ○
- network addresses and protocols.
- ○
- alarms raised by the access control system.
- ○
- activation and de-activation of protection systems, such as anti-virus systems and intrusion detection systems.
- ○
- records of transactions executed by users in applications.
- Limit the capturing of PHI and/or PHR data in audit records to minimize the privacy risk. If required anonymize the PHI and/or PHR data records before capturing in the audit log (AU-3, 12.4.1).
- Provide a warning to respective roles or owner within an organization when allocated audit record storage volume reaches the maximum audit record storage capacity (AU-5, 12.4.2).
- Provide a real-time alert if the system failed to capture audit record in a time-period (AU-5).
- Implement an automated process to review and analysis the audit log which followed by generating report. Use this report to investigation and response to suspicious activities (AU-6).
- Implement the capability to sort and search audit records for an event based on the content fields of audit records (AU-7).
- Use internal system clocks to generate the timestamp for audit records (AU-8).
- Implement cryptographic mechanisms to protect the integrity of audit records and ensure only authorized users obtain access to these audit records. If required, create an authorized user with read-only permission to audit record (AU-9).
- Initiate session audits including automatically file transfer, user request/response at the system start-up (AU-14).
Appendix B.2. Key Management
- A policy on the use, protection and lifetime of cryptographic keys should be developed and implemented through their whole lifecycle (NIST 800-53 SC-12, ISO 27002 10.1.2).
- Create keys with appropriate key size and block size. Do not use a laptop or random application to generate the key. Only generate the key using any application or service provider which supports hardware security modules (HSMs) (ISO/IEC 11770).
- Do not use any random cryptographic algorithms. Select only which are recognized by different standards. For example, AES is currently recognized by the Federal Government standard body for symmetric techniques (NIST 800-175B).
- Consider the proper key size during cryptographic algorithms. For AES 128, 168 or 256-bits key size can be used (NIST 800-175B).
- Generated keys need to be distributed securely by keeping confidentiality and integrity (ISO/IEC 11770).
- Use key wrapping techniques to exchange the key between mobile applications and devices. Diffie-Hellman provides the capability for two parties to agree upon a shared secret for exchanging keys over a public channel (NIST 800-56A).
- If any user and/or device is identified as compromised, the respective key of the user or device needs to be removed from the application and key management server. After the revocation of a compromised key, a new key needs to be generated and distributed using the above steps (ISO/IEC 11770).
- Log each activity related to key management and use this data to perform auditing (ISO 27002 10.1.2).
Appendix C
Name | Description | License | Source |
---|---|---|---|
OpenVAS | OpenVAS Scanner is a vulnerability assessment tool that is used to spot issues related to security in the servers and other devices of the network. | GNU General Public License | https://www.openvas.org/ (access on 30 July 2021) |
Nikto | Nikto is an open-source web scanner employed for assessing the probable issues and vulnerabilities on web servers. | GNU General Public License | https://cirt.net/Nikto2 (access on 30 July 2021) |
Tripwire IP360 | Tripwire IP360 is a vulnerability assessment solution to run wide-ranging of testing on the networks to spot all the vulnerabilities, configurations, applications, network hosts. | Commercial | https://www.tripwire.com/products/tripwire-ip360 (access on 30 July 2021) |
Wireshark | Wireshark is an extensively used as network protocol analyzer tool. | GNU General Public License | https://www.wireshark.org/ (access on 30 July 2021) |
Aircrack | Aircrack is a tool to assess the WiFi network security. | GNU General Public License | https://www.aircrack-ng.org/ (access on 30 July 2021) |
Name | Description | License | Source |
---|---|---|---|
Apache ab test | Apache ab load test tool uses to generate the number of request per second. This tool very useful to perform load testing and DDOS attack scenario. | GNU General Public License | https://httpd.apache.org/docs/2.4/programs/ab.html (access on 30 July 2021) |
OWASP ZAP | The Open Web Application Security Project—Zed Attack Proxy (ZAP) is a penetration testing tool for finding vulnerabilities in applications. | GNU General Public License | https://owasp.org/www-project-zap/ (access on 30 July 2021) |
BURP SUITE | Burp Suite is a platform for performing security testing of applications. | Commercial | https://portswigger.net/burp (access on 30 July 2021) |
NMAP | Nmap (Network Mapper) is a free and open-source utility for network exploration or security auditing. | GNU General Public License | https://nmap.org/ (access on 30 July 2021) |
SSLSCAN | SSLScan tests for different SSL exploits, such as heartbleed and the POODLE vulnerability, it also tests the cipher suites and key exchanges. | GNU General Public License | https://github.com/rbsec/sslscan (access on 30 July 2021) |
HYDRA brute force | Hydra is a rapid dictionary attacker which can be configured against over 50 different protocols. It is most commonly used for brute-forcing user accounts to test for weak passwords. | GNU General Public License | https://github.com/vanhauser-thc/thc-hydra (access on 30 July 2021) |
KALI LINUX | Kali is a Debian-derived Linux distribution designed for digital forensics and penetration testing installed with hundreds of different tools. | GNU General Public License | https://www.kali.org/ (access on 30 July 2021) |
References
- Ullah, S.; Higgins, H.; Braem, B.; Latre, B.; Blondia, C.; Moerman, I.; Saleem, S.; Rahman, Z.; Kwak, K.S. A comprehensive survey of wireless body area networks on PHY, MAC, and network layers solutions. J. Med. Syst. 2012, 36, 1065–1094. [Google Scholar] [CrossRef] [PubMed] [Green Version]
- Antonescu, B.; Basagni, S. Wireless body area networks: Challenges, trends and emerging technologies. In Proceedings of the 8th International Conference on Body Area Networks, Boston, MA, USA, 30 September–2 October 2013; pp. 1–7. [Google Scholar]
- Salayma, M.; Al-dubai, A.; Romdhani, I. Wireless body area network (WBAN): A survey on reliability, fault tolerance, and technologies coexistence. ACM Comput. Surv. 2017, 50, 1–38. [Google Scholar] [CrossRef] [Green Version]
- Kotz, D. A threat taxonomy for mHealth privacy. In Proceedings of the 3rd International Conference on Communication Systems and Networks, COMSNETS, Bangalore, India, 4–8 January 2011; pp. 1–6. [Google Scholar]
- Li, M.; Lou, W.; Ren, K. Data security and privacy in wireless body area networks. IEEE Wirel. Commun. 2010, 17, 51–58. [Google Scholar] [CrossRef]
- Paul, P.C.; Loane, J.; McCaffery, F.; Regan, G. A data security and privacy risk management framework for wban based healthcare applications*. In Proceedings of the IEEE International Conference on Pervasive Computing and Communications Workshops and other Affiliated Events (PerCom Workshops), Kassel, Germany, 22–26 March 2021; pp. 704–710. [Google Scholar]
- Ramli, S.N.; Ahmad, R. Surveying the wireless body area network in the realm of wireless communication. In Proceedings of the 7th International Conference on Information Assurance and Security (IAS), Melacca, Malaysia, 5–8 December 2011; pp. 58–61. [Google Scholar]
- Paul, P.C.; Loane, J.; Regan, G.; McCaffery, F. Analysis of Attacks and Security Requirements for Wireless Body Area Networks-A Systematic Literature Review. In Proceedings of the European Conference on Software Process Improvement, Edinburgh, UK, 18–20 September 2019; pp. 439–452. [Google Scholar]
- FDA Overview of Device Regulation. Available online: https://www.fda.gov/medical-devices/device-advice-comprehensive-regulatory-assistance/overview-device-regulation (accessed on 9 November 2020).
- CFR Electronic Code of Federal Regulations. Available online: https://www.ecfr.gov/cgi-bin/text-idx?SID=ba90ee4a08a5ba017a34366276d68234&mc=true&tpl=/ecfrbrowse/Title21/21cfrv8_02.tpl#0 (accessed on 13 October 2020).
- HIPAA Security Rule. Available online: https://www.hhs.gov/hipaa/for-professionals/security/laws-regulations/index.html (accessed on 10 October 2020).
- EU Commission Medical Device Regulation. Available online: https://eur-lex.europa.eu/eli/reg/2017/745/2017-05-05 (accessed on 13 October 2020).
- EU Commission General Data Protection Regulation. Available online: https://eur-lex.europa.eu/eli/reg/2016/679/oj (accessed on 13 October 2020).
- FDA Content of Premarket Submissions for Management of Cybersecurity in Medical Devices. Available online: https://www.fda.gov/media/119933/download (accessed on 13 October 2020).
- FDA Postmarket Management of Cybersecurity in Medical Devices. Available online: https://www.fda.gov/media/95862/download (accessed on 13 October 2020).
- IEC 62304. Health Software—Software Life Cycle Processes; ISO: Geneva, Switzerland, 2019. [Google Scholar]
- NIST SP800-53. Security and Privacy Controls for Federal Information Systems and Organizations; NIST: Gaithersburg, MD, USA, 2020. [Google Scholar]
- ISO/IEC 27002. Information Technology—Security Techniques—Code of Practice for Information Security Controls; ISO: Geneva, Switzerland, 2017. [Google Scholar]
- IEC 80001-1. Application of Risk Management for IT-Networks Incorporating Medical Devices—Part 1: Roles, Responsibilities and Activities; ISO: Geneva, Switzerland, 2015. [Google Scholar]
- IEC 80001-2-2. Application of Risk Management for IT-Networks Incorporating Medical Devices—Guidance for the Disclosure and Communication of Medical Device Security Needs, Risks and Control; ISO: Geneva, Switzerland, 2011. [Google Scholar]
- AAMI TIR57. Principles for Medical Device Security—Risk Management; AAMI: Bronson, VA, USA, 2016. [Google Scholar]
- ISO 14971. Medical Devices— Application of Risk Management to Medical Devices; ISO: Geneva, Switzerland, 2018. [Google Scholar]
- NIST:800-30. Guide for Conducting Risk Assessments; NIST: Gaithersburg, MD, USA, 2012. [Google Scholar]
- Duc, A.N.; Jabangwe, R.; Paul, P.; Abrahamsson, P. Security challenges in IoT development: A software engineering perspective. In Proceedings of the XP2017 Scientific Workshops, Cologne, Germany, 22–26 May 2017; pp. 1–5. [Google Scholar]
- Townsend, K. Organizations Challenged with Cybersecurity Framework Implementation. Available online: https://www.securityweek.com/organizations-challenged-cybersecurity-framework-implementation (accessed on 10 October 2020).
- Holden, W.L. Bridging the culture gap between healthcare IT and medical device development. Biomed. Instrum. Technol. 2014, 48, 22–28. [Google Scholar] [CrossRef] [PubMed]
- MacMahon, S.T.; Cooper, T.; McCaffery, F. Revising IEC 80001-1: Risk management of health information technology systems. Comput. Stand. Interfaces 2018, 60, 67–72. [Google Scholar] [CrossRef]
- Chen, Q.; Lambright, J.; Abdelwahed, S. Towards Autonomic Security Management of Healthcare Information Systems. In Proceedings of the 2016 IEEE First International Conference on Connected Health: Applications, Systems and Engineering Technologies (CHASE), Washington, DC, USA, 27–29 June 2016; pp. 113–118. [Google Scholar]
- Shah, S.M.; Khan, R.A. Secondary use of electronic health record: Opportunities and challenges. IEEE Access 2020, 8, 136947–136965. [Google Scholar] [CrossRef]
- Eom, D.; Lee, H. A holistic approach to exploring the divided standards landscape in E-Health research. In Proceedings of the 2017 ITU Kaleidoscope: Challenges for a Data-Driven Society (ITU K), Nanjing, China, 27–29 November 2017; pp. 1–7. [Google Scholar]
- Benz, M.; Chatterjee, D. Calculated risk? A cybersecurity evaluation tool for SMEs. Bus. Horiz. 2020, 63, 531–540. [Google Scholar] [CrossRef]
- Chen, J.Q.; Benusa, A. HIPAA security compliance challenges: The case for small healthcare providers. Int. J. Healthc. Manag. 2017, 10, 135–146. [Google Scholar] [CrossRef]
- Mariani, D.M.R.; Mohammed, S. Cybersecurity challenges and compliance issues within the US healthcare sector. Int. J. Bus. Soc. Res. 2015, 5, 55–66. [Google Scholar]
- Ključnikov, A.; Mura, L.; Sklenár, D. Information security management in SMEs: Factors of success. Entrep. Sustain. Issues 2019, 6, 2081. [Google Scholar] [CrossRef]
- Aljohani, M.; Blustein, J. A study using the in-depth interview approach to understand current practices in the management of personal health information and privacy compliance. In Proceedings of the 2018 IEEE International Conference on Healthcare Informatics (ICHI), New York, NY, USA, 4–7 June 2018; pp. 75–86. [Google Scholar]
- Skierka, I.M. The governance of safety and security risks in connected healthcare. In Proceedings of the Living in the Internet of Things: Cybersecurity of the IoT—2018, London, UK, 28–29 March 2018; pp. 1–12. [Google Scholar]
- Thapa, C.; Camtepe, S. Precision health data: Requirements, challenges and existing techniques for data security and privacy. Comput. Biol. Med. 2021, 129, 104130. [Google Scholar] [CrossRef] [PubMed]
- Supriya, S.; Padaki, S. Data Security and Privacy Challenges in Adopting Solutions for IOT. In Proceedings of the 2016 IEEE International Conference on Internet of Things (iThings) and IEEE Green Computing and Communications (GreenCom) and IEEE Cyber, Physical and Social Computing (CPSCom) and IEEE Smart Data (SmartData), Chengdu, China, 15–18 December 2016; pp. 410–415. [Google Scholar]
- Stevovic, J.; Casati, F.; Farraj, B.; Li, J.; Motahari-Nezhad, H.R.; Armellin, G. Compliance aware cross-organization medical record sharing. In Proceedings of the 2013 IFIP/IEEE International Symposium on Integrated Network Management (IM 2013), Ghent, Belgium, 27–31 May 2013; pp. 772–775. [Google Scholar]
- Abraham, C.; Chatterjee, D.; Sims, R.R. Muddling through cybersecurity: Insights from the U.S. healthcare industry. Bus. Horiz. 2019, 62, 539–548. [Google Scholar] [CrossRef]
- Aceto, G.; Persico, V.; Pescapé, A. The role of Information and Communication Technologies in healthcare: Taxonomies, perspectives, and challenges. J. Netw. Comput. Appl. 2018, 107, 125–154. [Google Scholar] [CrossRef]
- Iyengar, A.; Kundu, A.; Pallis, G. Healthcare informatics and privacy. IEEE Internet Comput. 2018, 22, 29–31. [Google Scholar] [CrossRef] [Green Version]
- Paquette, A.; Painter, F.; Jackson, J.L. Management and risk assessment of wireless medical devices in the hospital. Biomed. Instrum. Technol. 2011, 45, 243–248. [Google Scholar] [CrossRef] [PubMed]
- ISO/IEC 80001-2-8. Application of Risk Management for IT-Networks Incorporating Medical Devices Part 2-8: Application Guidance—Guidance on Standards for Establishing the Security Capabilities Identified in IEC TR 80001-2-2; ISO: Geneva, Switzerland, 2016. [Google Scholar]
- ISO 27799:2008. Health Informatics—Information Security Management in Health Using ISO/IEC 27002; ISO: Geneva, Switzerland, 2016. [Google Scholar]
- ISO 11770. BS ISO/IEC 11770-2:2018 IT Security Techniques. Key Management. Mechanisms Using Symmetric Techniques; ISO: Geneva, Switzerland, 2018. [Google Scholar]
- NIST NVD—CVSS v3 Calculator. Available online: https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator (accessed on 19 August 2020).
Challenges | Sources |
---|---|
Lack of trained staff, responsibilities, budget, and management support | Literature [25,26,27,28,29,30,31,32,33,34] |
The existing standards are too complex and complicated to implement | Literature [27,30,35,36,37] |
Limited knowledge about market-specific regulatory requirements, security standards, and policies | Literature & Interview [32,36,38,39,40] |
Lack of comprehensive understanding of the architecture for WBAN security and privacy | Interview |
Understanding the data flow around the system and what assets need to be protected | Interview |
Standards outline each security control at a very high-level with limited amount of implementation details | Literature & Interview [27,33] |
Identification of appropriate security controls with respective implementation details to ensure CIA and privacy of data | Literature & Interview [41] |
Due to a vast number of controls, the challenge is prioritizing these controls in addition to planning releases without compromising security and privacy | Interview |
Lack of security mechanisms for sensor device nodes connected to wireless networks, which are often limited by physical memory, computational power and storage | Literature & Interview [37,38,42,43] |
Vulnerabilities | Description |
---|---|
The device data store could be corrupted | Data flowing across iOS_to_S_Response may be tampered with by an attacker. This may lead to corruption of device. Ensure the integrity of the data flow to the data store. |
Potential weak protections for audit data | Consider what happens when the audit mechanism comes under attack, including attempts to destroy the logs. Ensure access to the log is through channels which control read and write separately. |
Potential data repudiation by REST API | REST API claims that it did not receive data from a source outside the trust boundary. Consider using logging or auditing to record the source, time, and summary of the received data. |
Weak authentication scheme | Custom authentication schemes are susceptible to common weaknesses such as weak credential change management, credential equivalence, easily guessable credentials, null credentials and a weak credential change management system. |
Potential lack of input validation for REST API | Data flowing across Android_to_API_Request may be tampered with by an attacker. This may lead to a denial of service (DoS) attack against REST API or an elevation of privilege attack against REST API or an information disclosure by REST API. |
Vulnerabilities | Control |
---|---|
Weak authentication scheme | Authentication |
Weak credential transit | Authentication, Encryption |
Potential data repudiation by Android and/or iOS application | Auditing, Non-repudiation |
Potential process crash or stop for REST API due to the DOS attack | Access control, Intrusion detection, Auditing |
Lack of data input validation | Data integrity, Input validation |
Lack of encryption on transmitted data | Encryption, Communication security |
Lack of encryption on private/sensitive data at rest | Encryption |
Lack of physical tamper detection and response | Physical protection |
Weak remote access controls | Access control |
Lack of system hardening | Physical protection, Client platform security |
Task No. | Task Definition | Key Roles |
---|---|---|
1 | Defining the scope | * Executives, ** Management, *** Assessor |
2 | Risk analysis | Management, Assessor, **** Third-party resource (if needed) |
4 | Security and privacy risk evaluation | Executives, Management, Assessor |
5 | Security and privacy risk control | Management, Assessor, Third-party resource (if needed) |
7 | Evaluation of overall residual security and privacy risk acceptability | Assessor, Management, Third-party resource (if needed) |
Qualitative Values | Semi-Quantitative Values | Impact Definition | |
---|---|---|---|
– | Scale | Bins | – |
Very Low (1) | 0–4 | 0 | Threat event will have negligible adverse effects |
Low (2) | 5–20 | 2 | Threat event will have limited adverse effects |
Medium (3) | 21–79 | 5 | Threat event will have serious adverse effects |
High (4) | 80–95 | 8 | Threat event will have catastrophic adverse effects |
Very High (5) | 96–100 | 10 | Threat event will have multiple catastrophic effects |
Impact Factor | Impact Description | Impact Level | ||
---|---|---|---|---|
Qualitative | Semi-Quantitative | |||
Scale | Bins | |||
Harm to user health | Only the person who is using the device will be in risk | Very High | 100 | 10 |
Operational impacts | Only that device will be out of operation, it will not severely affect the overall application operation | Medium | 30 | 5 |
Financial loss | Loss of a single device will have limited financial impact | Low | 10 | 2 |
Reputational harm | Loss of a single sensor device will not create severe reputational harm | Medium | 40 | 5 |
Loss of assets | Only one sensor device | Medium | 30 | 5 |
Average | Medium | 70 | 5.2 |
Qualitative Values | Semi-Quantitative Values | Likelihood Score Definition | |
---|---|---|---|
– | Scale | Bins | – |
Very Low (1) | 0–4 | 0 | Highly unlikely the threat event occurs or exploits the vulnerabilities |
Low (2) | 5–20 | 2 | Unlikely the threat event occurs or exploits the vulnerabilities |
Medium (3) | 21–79 | 5 | Somewhat likely the threat event occurs or exploits the vulnerabilities |
High (4) | 80–95 | 8 | Highly likely the threat event occurs or exploits the vulnerabilities |
Very High (5) | 96–100 | 10 | Almost certain the threat event occurs or exploits the vulnerabilities |
Likelihood Factor | Likelihood Description | Likelihood Level | ||
---|---|---|---|---|
Qualitative | Semi-Quantitative | |||
Scale | Bins | |||
Adversary intent | Make the whole application unavailable | Very High | 100 | 10 |
Adversary skill level | Requires medium level skill to launch the attack | High | 90 | 8 |
Affected asset | All assets that depend on the web server including the web server itself | Very High | 100 | 10 |
Historical evidence | Very common attack for web server | Very High | 100 | 10 |
Average | Very High | 97.5 | 9.5 |
Impact | Likelihood | ||||
---|---|---|---|---|---|
Very Low (1) | Low (2) | Medium (3) | High (4) | Very High (5) | |
Very High (5) | 5 | 10 | 15 | 20 | 25 |
High (4) | 4 | 8 | 12 | 16 | 20 |
Medium (3) | 3 | 6 | 9 | 12 | 15 |
Low (2) | 2 | 2 | 6 | 8 | 10 |
Very Low (1) | 1 | 2 | 3 | 4 | 5 |
Risk Score | Semi-Quantitative Values | Description | |
---|---|---|---|
– | Scale | Bins | – |
Very Low | 0–4 | 0 | The risks are acceptable. Plans mitigate the risk should be included in future plans. |
Low | 5–20 | 2 | The risk may be acceptable over the short term. Plans to mitigate risk should be included in future plans and budgets. |
Medium | 21–79 | 5 | The risk is unacceptable. Measures to reduce and mitigate the risk should be implemented as soon as possible. |
High | 80–95 | 8 | The risk is unacceptable. Immediate measures to reduce and mitigate the risk should be implemented as soon as possible. |
Very High | 96–100 | 10 | The risk is totally unacceptable. Immediate measures must be taken to mitigate the risk. |
Id | Test Case | Expected Result |
---|---|---|
Test01 | Testing for valid user with right password | Successful authentication response |
Test02 | Testing for valid user with wrong password | Authentication failed due to the wrong password |
Test03 | Testing for a nonexistent username | Authentication failed due to invalid username |
Test04 | Testing authentication with blank passwords | Authentication failed due to empty password supplied |
Test05 | Attempt to log in with an incorrect password four times | Account locked out due to maximum try with the wrong password. |
Publisher’s Note: MDPI stays neutral with regard to jurisdictional claims in published maps and institutional affiliations. |
© 2021 by the authors. Licensee MDPI, Basel, Switzerland. This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution (CC BY) license (https://creativecommons.org/licenses/by/4.0/).
Share and Cite
Paul, P.C.; Loane, J.; McCaffery, F.; Regan, G. Towards Design and Development of a Data Security and Privacy Risk Management Framework for WBAN Based Healthcare Applications. Appl. Syst. Innov. 2021, 4, 76. https://doi.org/10.3390/asi4040076
Paul PC, Loane J, McCaffery F, Regan G. Towards Design and Development of a Data Security and Privacy Risk Management Framework for WBAN Based Healthcare Applications. Applied System Innovation. 2021; 4(4):76. https://doi.org/10.3390/asi4040076
Chicago/Turabian StylePaul, Pangkaj Chandra, John Loane, Fergal McCaffery, and Gilbert Regan. 2021. "Towards Design and Development of a Data Security and Privacy Risk Management Framework for WBAN Based Healthcare Applications" Applied System Innovation 4, no. 4: 76. https://doi.org/10.3390/asi4040076