Logging Sources

These are just a few examples of protect devices critical to detection and response.

Information assets also produce valuable logging. Laptops and servers generate event logs useful to SOC analysts. Windows is the most common operating system in endpoints, although some environments may use various flavors of Linux or Unix. Each of these operating systems can generate significant amounts of log data.

Endpoints offer vast opportunities to log events of interest. Both Linux and Windows offer logging by default. Windows especially offers additional logging options important to analysts. Sysmon, short for System Monitor, is a Windows system service and device driver offering more robust details than default logging. A more detailed discussion on the importance of filtering out noisy logs appears in Chapter 5.

HIPAA Security Rule 45 C.F.R. Part 164

45 C.F.R. Part 164 Subpart C dictates the security standards for Protection of Electronic Protected Health Information (ePHI).² It states in 164.302 that covered entities and business associates must comply with applicable standards, implementation specifications, and requirements with respect to ePHI.

Section 164.304 contains key definitions under the HIPAA Security Rule. Examples are outlined in Figure 2-1.

These definitions help when designing the security operations center/program, to avoid confusion regarding compliance with HIPAA requirements.

164.308(a)(1)(ii)(A) Risk analysis (Required)

Conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information held by the covered entity or business associate.

This safeguard was the focus of the book Building a HIPAA-Compliant Cybersecurity Program.³ This safeguard is often cited as lacking during breach investigations conducted by the Office for Civil Rights (OCR), the group within HHS enforcing compliance with HIPAA. The risk analysis must include all instances of ePHI located across the enterprise. It must also be comprehensive enough to include all risks to ePHI and include reasonably anticipated threats.⁴ When designing the security operations center, it is necessary to use the risk analysis as your guide. The assets storing, processing, and transmitting ePHI are identified during the risk analysis. Threats and vulnerabilities affecting the confidentiality, integrity, and availability of ePHI are also identified. These data points are key when designing security operations.

164.308(a)(1)(ii)(B) Risk management (Required)

Implement security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level to comply with § 164.306(a).

Entities must identify security measures meant to reduce residual risks to acceptable levels. For example, if weak passwords in an application can allow unauthorized users to gain access to the system, a security measure is identified to mitigate this risk. Identifying someone to review system access frequently to identify unusual or unauthorized logins is an example of a mitigating control.

164.308(a)(1)(ii)(D) Information system activity review (Required)

Implement procedures to regularly review records of information system activity, such as audit logs, access reports, and security incident tracking reports.

The first sub-category, DE.AE-1, expects entities to baseline what is normal within the IT environment and map expected data flows. If you are dealing with ePHI, this means understanding the flow of ePHI through IT systems. The team must also review the network architecture to identify key points where network traffic can be captured and logged. Ideally this visibility is comprehensive and does not duplicate logging in order to reduce the potential for noise. DE.AE-3 is usually fulfilled by implementing a Security Incident and Event Management (SIEM) solution. The control dictates gathering log data from all parts of the network and endpoints. These logs are then used by the SIEM operators for correlation. DE.CM-1 focuses on firewall, intrusion detection, and anything that captures network flow data or full packets to be employed. DE.CM-3 requires endpoint monitoring. This can be achieved by utilizing Windows logs or by placing another solution on the endpoint for monitoring. DE.CM-4 requires network and endpoint analysis tools to detect malware, and DE.CM-5 focuses on these tools detecting unauthorized mobile code. Mobile code refers to applets – an example includes programs written in code such as Java appearing on web pages. DE.CM-6 is required when service providers have connections into the network for support purposes. The entity needs visibility into these connections to confirm all activity conforms to the business agreement. DE.CM-7 requires entities to monitor everything on the network to detect the anomalies mentioned.

164.308(a)(2) Standard: Assigned security responsibility

Identify the security official who is responsible for the development and implementation of the policies and procedures required by this subpart for the covered entity or business associate.

Some will be part of the initial response team, and others might be part of an extended team. Often, members of the information security team, IT operations, and IT compliance make up the initial response team. Key business owners, C-suite executives, and outside experts are common functions assigned to extended response teams. These individuals are engaged when events are escalated to incidents and breaches.

164.308(a)(5)(ii)(B) Protection from malicious software (Addressable)

Procedures for guarding against, detecting, and reporting malicious software.

This is an implementation specification identified as addressable. This does not mean it is not required. Addressable means that covered entities or business associates must meet this safeguard unless a documented reason why it is not applicable exists.

This safeguard is very similar to the information system activity review safeguard discussed earlier. The first five controls were covered in that section.

RS.CO-2 requires entities to report incidents based on criteria, such as the mandatory reporting required by HITECH. RS.CO-3 dictates sharing event-related information is shared based on the incident response plan. This includes sharing information internally with business leaders and sharing with others within the industry if appropriate and regulators or law enforcement. What is shared and with who depends on the incident response plan. RS.AN-1 requires a process to document the investigation and resolution of alerts generated by monitoring tools.

164.308(a)(5)(ii)(C) Log-in monitoring (Addressable)

Procedures for monitoring log-in attempts and reporting discrepancies.

No new NIST CSF controls are mapped to this safeguard. Details of these control activities are discussed earlier.

164.308(6)(i) Standard: Security incident procedures

Implement policies and procedures to address security incidents.

To effectively implement these processes, risks must be understood. Assets identified during the risk analysis must be understood well enough to know what proper behavior is and what is not. In DE.AE-2, knowing which assets interact with ePHI is necessary. Incident alert thresholds are documented as a part of DE.AE-5. For example, failed logins are not concerning until they exceed a specific number and are performed by unusual end users, at unusual times, or from unusual locations. RS.CO-4 means that members of the business affected by any events related to the systems he or she is responsible for are communicated with during an investigation.

164.308(a)(6)(ii) Implementation specification: Response and reporting (Required)

Identify and respond to suspected or known security incidents; mitigate, to the extent practicable, harmful effects of security incidents that are known to the covered entity or business associate; and document security incidents and their outcomes.

There are several controls in this section not previously discussed. DE.AE-4 comes from the risk analysis. Documented impacts from that analysis let the analyst understand potential impacts of events. DE.DP-4 is important because alerts and notifications by monitoring systems should be shared with other teams. For instance, high rates of failed logins by a service account could mean a configuration was changed. The infrastructure team would want to look into such an event. RS.RP-1 requires the entity to invoke a response plan if an event is escalated. RS.AN-2 is the same as DE.AE-4. Incident response plans should document the types of data/assets important to the entity and how each type is categorized. Complying with RS.AN-4 means the incident response plan categorized accordingly. For example, ePHI events may be categorized as critical severity, credit cards as high severity, and corporate data as moderate severity. RS.MI1-2 are essential pieces to an incident response plan. Plans and the playbooks document how to contain and mitigate the outbreak of all types of incidents. RS.MI-3 keeps the incident response and vulnerability management plans up-to-date as new vulnerabilities are expected to be uncovered and evaluated.

164.308(a)(8) Standard: Evaluation

Perform a periodic technical and nontechnical evaluation, based initially upon the standards implemented under this rule and, subsequently, in response to environmental or operational changes affecting the security of electronic protected health information, that establishes the extent to which a covered entity’s or business associate’s security policies and procedures meet the requirements of this subpart.

Evaluation here focuses on the detection and monitoring processes and finding improvement opportunities, DE.DP-5. A Purple Team assessment might pay dividends here. Using a Purple Team does not focus just on penetration testing by attackers, but helping the SOC team improve its ability to detect events of interest. This utilizes two teams, one acting as the attackers trying to find the trophies identified in the environment (Red Team) and another trying to detect the movements are used to test these controls (Blue Team). The assessment focuses on when, where, and how the attack was detected. Non-technical assessments could focus on assessing logging capabilities for gaps or assessing threat intelligence and alerting to confirm detection rules make sense. These assessments are built on fact finding, utilizing inquiry and observation to develop findings and recommendation reports. Consultants draw from experiences on other engagements to recommend leading practices seen across many entities. Security operations fundamentally complies with DE.CM-1 since it focuses on building continuous monitoring processes. Mapping the security operations processes to HIPAA gets compliance with the DE.DP-2 control.

164.312(b) b) Standard: Audit controls

Implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information.

Entities need a SIEM to manage all the data available for security monitoring. Several methods should be used to monitor the network and endpoints. Chapter 5 provides the details for solutions meeting these requirements.

164.312(e)(2)(i) Integrity controls (Addressable)

This control process appeared in several of the safeguards discussed previously.

HIPAA expects covered entities and business associates to (document expectations for protecting patient information). The safeguards documented in this chapter point to cyber operation controls. References to these controls are found in the NIST Cybersecurity Framework (CSF) and Center for Internet Security (CIS) Top 20 controls.