*4.3.1 Business associate agreements (BAAs)*

Historically, services providers (or business associates) working with a covered entity's sensitive patient data should have properly formed BAAs in place prior to releasing sensitive data or have a well-formed written legal justification as to why no such BAAs exist. Many HIPAA-covered entities still report breaches where a properly formed BAA was not in place. In such cases, all parties may be considered responsible for the breach by the HHS OCR in the USA.

### *4.3.2 Non-disclosure agreements and/or other agreements*

Business partners may negotiate many different types of agreements and/or partner requirements for their data and products. One popular agreement in healthcare and healthcare research is non-disclosure agreements (NDA). Such agreements require parties not to release information without prior approval. In such a case, malware that makes NDA-protected data public by releasing it on a popular web application du jour, as well as its actual authors, could be faulted to violate the NDA. Cases that fall into this category can have many different negative outcomes, such as legal ramifications, reputational damage, among others.

*Risk in Healthcare Information Technology: Creating a Standardized Risk Assessment Framework DOI: http://dx.doi.org/10.5772/intechopen.96456*

In addition to NDAs, other Federal or organizational legal regulations may require risk assessments and other services or service-level agreements (SLAs). Similarly, the GDPR requires entities exposed to unauthorized access to notify affected breached individuals within a short timeframe. Violations to such agreements can have extremely negative consequences to the healthcare entities.

#### **4.4 Application and system requirements**

Application and system security are typically measured through certifications (e.g., International Organization for Standardization or other sources) or from internal tests prior to product release. HIPAA requires security assessments for systems and applications managing ePHI. Organizations can either develop their own methodologies to communicate risk that are acceptable by covered entities, or the entities themselves can ask to perform such probability assessments for adverse events. When the covered entity is performing the assessment, they must carefully obtain legal authorization to do so in most cases. In general, Information System silos prevent considering a full-threat landscape for the technical component with the legal, budget, and business use cases. Additionally, digital assessments may be filed for HHS OCR audits into the Integrated Risk Management (IRM) system without updates to the overall business threat mitigations. Periodically, teams must carefully reassess and update the stored organizational predicted levels. In such cases, the assessments are more of a risk "impression" rather than an informed, reproducible, scientific informing on the true likelihood and impact of adverse events. **Figure 7** [30] provides a high-level overview of different technical security controls reported by NIST. The following subsections identify eight subcategories potentially employed during a risk assessment.

#### *4.4.1 Authentication*

According to NIST [30], authentication is the process or action of proving or showing something to be valid. Specifically, "The authentication control provides the means of verifying the identity of a subject to ensure that a claimed identity is valid." The OWASP Application Testing Guide [31] currently gives ten best-practice tests to perform for authentication: "Testing for Credentials Transported over an Encrypted Channel, Testing for Default Credentials, Testing for Weak Lock Out Mechanism, Testing for Bypassing Authentication Schema, Testing for Vulnerable Remember Password, Testing for Browser Cache Weaknesses, Testing for Weak Password Policy, Testing for Weak Security Question Answer, Testing for Weak Password Change or Reset Functionalities, and Testing for Weaker Authentication in Alternative Channel." It is important to realize that any best-practice guide at-large lists *top* threats and vulnerabilities without perhaps listing *all* threats and vulnerabilities.

#### *4.4.2 Session management*

Session management is the data flow between endpoints—typically following a client and server model. A web session is a series of requests and response transactions created by a client after authentication. In most cases, the endpoints communicate with a special identifier to limit re-authentications. Current best practices in session management include session flags, random token generation, and timeout intervals. The OWASP Application Testing Guide [31] currently lists the following eight session management tests: "Testing for Session Management Schema, Testing for Cookies Attributes, Testing for Session Fixation, Testing

**Figure 7.** *Technical security controls.*

for Exposed Session Variables, Testing for Cross Site Request Forgery, Testing for Logout Functionality, Testing Session Timeout, and Testing for Session Puzzling."
