Breaches are inevitable.
Attackers are inside our networks long before we ever find out.
Attackers have more resources available than those protecting networks.
Positive noise comes from the information sharing available to assist information security and security operations teams. Numerous messages about new malware variants and detection methods are available daily. There are updates about attack groups and possible new targets. Dissemination of vulnerabilities newly identified and urgent warnings about patches and remediation are found. Often, the noise created by this last example occurs when business leaders start sending notes asking what the security team is doing about the said vulnerability or exploit.
Security operations equals noise. This is collateral noise that comes from collecting logs filled with immeasurable amounts of data points. Talk to anyone working in security operations, and you hear the word noise quite a bit. Certain types of logs are noisy because of the volume of events collected. This is where identifying use cases and focused alerts based on threat intelligence and vulnerabilities comes into play. Logging for the sake of collecting all logs available is neither efficient nor useful in defending against unwanted actions.
Understanding where security operations fits into the organization and documenting the strategy, policies, procedures, and metrics are key to laying the groundwork. With the exception of deciding how security operations fits into the organization, the other items will change periodically. The strategy may change. Processes and procedures will change. Metrics may be removed and added based on what the organization needs to measure.
Methods designed to quiet the noise – negative, positive, and collateral – are needed. One way is leveraging the Mandiant Kill Chain and identifying use cases for continuous monitoring of tools, software, tactics, and techniques threat actors use. These use cases naturally become more granular through program maturity. The benefits derived are focused on what matters contextually to the organization and reduced distractions of all types.
This might lead to the question, why is security operations so important for entities in possession of individual health information? Because threat actor’s goals are not limited to gaining access to a network. The goal is to steal, modify, and/or render patient information unavailable. It takes time for this to happen. Over time, effective security operations programs possess the people, processes, and technology to detect unwanted activity and respond to it. Hopefully, before the attacker’s objectives are met.
What Is Security Operations?
Elements of security operations
Moving clockwise in Figure 1-1, each bubble delivers information to the next. Threat intelligence feeds data to vulnerability management. Vulnerabilities are primarily identified via technical scans, but this goes beyond that. In Chapters 3 and 4, we will discuss tactics and techniques used by a threat actor known as Deep Panda. One technique used was downloading exploit code with PowerShell. Two vulnerabilities that may exist in such a scenario are widespread use of PowerShell across the organization without restriction and no ability to monitor PowerShell command usage. These vulnerabilities allow the attacker to go about their business without prevention or detection. Vulnerabilities like these do not show up on scanners and must be addressed by continuous monitoring.
Cybersecurity sub-program elements as part of a larger cybersecurity program
Examples of the strategy, procedures, processes, and metrics for the training and awareness program
Security operations strategy, procedures, processes, and metrics examples
Security Operations: Large Entity vs. Small Entity
Comparison of information security roles and security operations roles
Information Security Roles | Security Operations Roles |
|---|---|
Physical security | Threat management and monitoring |
Business continuity/disaster recovery | Vulnerability identification and monitoring |
Governance and compliance | Network monitoring |
Training and awareness | Endpoint monitoring |
Access control | Investigation of anomalies |
Smaller entities do not possess the resources to operate a SOC and staff the remaining cybersecurity program needs. SOC responsibilities might be outsourced to managed security service providers, but the entire operation cannot be offloaded. In these environments, team members have traditional information security duties like those found in the Identify and Protect Functions of the NIST Cybersecurity Framework (CSF) while also holding responsibilities related to security operations duties such as vulnerability management and continuous monitoring.
Managed security service providers (MSSPs) offer virtual SOC services. These services’ resources are monitoring the environment, investigation anomalies, and threat hunting. The purpose is for these resources to be an extension of the internal team.
Threat Intelligence
Threat intelligence requires a strategy, procedures, and processes. These elements guide the organization toward the types of intelligence to gather, where to get the intelligence, how it is used internally, and stakeholder reporting needs. The strategy can be short and simple. A good example might be to collect intelligence from reputable sources, useful to the entity, and adding value of our security tools and capabilities.
How does the entity conclude the intelligence is from a reputable source?
How does the entity conclude the intelligence is relevant and useful?
How will threat intelligence increase the value derived from cybersecurity tools and capabilities?
Key processes of the threat intelligence program
The team should only use approved and agreed-upon threat intelligence sources to prevent overuse of threat feeds. The volume of free feeds makes it too easy to try and integrate every feed possible. Threat feeds must take a quality over quantity approach; otherwise, it becomes difficult to contextualize the threat information ingested.
Specific roles for team members must be defined as well. One reason is to prevent duplication of effort. Having more than one person analyzing intelligence and making decisions regarding its use is inefficient and inconsistent. The key objective is process development and execution of that process by the team. Experienced security or threat intelligence analysts are appropriate personnel to review and analyze intelligence and pass it along to senior analysts and SOC leaders if necessary. Again, the analysis is based on the goals, objectives, and strategy of the SOC’s threat intelligence program.
Threat analysis is the second step in the risk assessment and analysis process, after critical assets are identified. Protected Health Information is the asset class in scope for these risk assessments. Threats mean to affect the confidentiality, integrity, and availability of ePHI. Common threats include nation states, cybercriminals, malicious insiders, and environmental threats. The threat intelligence gathered enhances risk assessment and analysis by adding specific attack types, indicators, and exploits used.
Finally, what good is threat intelligence if it is not used to quickly identify and respond to evil in the environment. Once inside a network, adversaries must pivot from one endpoint to another, elevating privileges along the way, until the goal is reached. These adversaries use tactics, techniques, and software tools that leave behind artifacts as evidence of their presence. Threat indicators are those details defenders can use to discover intrusions and respond. Threat indicators are used during ongoing monitoring of the environment or to look back historically for the presence of adversaries in the network.
Recorded Future process for collecting threat intelligence
Understanding what the threat is
Concluding if the threat affects the environment and data
What to do about it
If anyone else needs to know about it
These considerations are key for analyzing and acting on threat indicators.
Vulnerability Management
Vulnerability management seems straightforward, but often is complicated by lack of process, resource availability, legacy systems, and a lack of understanding. Cybersecurity incidents such as WannaCry and the breach at Equifax resulted from exploits targeting known vulnerabilities with available patches. Why does this happen? It is common for vulnerability identification and management to focus on technical scans to identify vulnerabilities and patch management to resolve them. The scanner of choice executes on a schedule. It might be weekly, monthly, or quarterly. Those responsible for addressing the issues found in the scan identify patches available and, based on time and resources, patch the most serious issues. Often, this leads to focus on critical and high vulnerabilities with moderate/medium vulnerabilities ignored. A process to confirm vulnerabilities are mitigated or methods to confirm all parts of the network are scanned are often missing in healthcare entities. This leads to exploits of vulnerabilities that should be patched. It’s also not realistic to expect all items found in scans to be fixed right away. The procedures and processes need to focus on proper evaluation of vulnerabilities when prioritizing remediation and mitigation. This pillar of the cyber operations program requires a strategy, procedures, processes, and guidelines to address vulnerabilities and reduce the risk to ePHI.
Security Monitoring
Security monitoring is important and complex. Even the most immature cybersecurity program with limited logging has access to vast amounts of data related to the environment – enough data to make it easy to miss indicators of an attack. The key to effective monitoring is understanding how to use the data to detect and respond to unwanted activity inside the network. The event logs and log correlation engines are often seen as detection capabilities. These tools are important and need to be implemented based on data derived by threat intelligence and vulnerability management.
Data sources are broken down into two groups: endpoints and traffic. When we say endpoints, we are talking about servers, laptops, and other mobile devices. Traffic data comes from routers, switches, packet captures, intrusion detection/protection, and so on.
Endpoints generate event logs for various activities such as new processes starting and file system updates. Network traffic is generated constantly, even when no one is at the keyboard. If a device is on a network, it is generating traffic. Endpoints constantly communicate with the rest of the network. Things like network addresses and health are continually updated. During normal operations, a vast amount of traffic is generated. In his blog, “Is Full Packet Capture Worth the Investment,” author Tom Obremski illustrates how a 1 Gbps network requires 316.4 TB of storage to retain 30 days’ worth of traffic.3
Incident Response
Incident response is the final piece of security operations. When notable events are detected, the team must act efficiently and appropriately investigate these issues.
The Kill Chain
Mandiant/FireEye Kill Chain
Establish Foothold (Initial Compromise)
Escalate Privileges
Internal Reconnaissance
Move Laterally
Maintain Persistence
Complete Mission (Data Exfiltration)
Using threat intelligence, security operations identifies ways to detect the indicators for each use case. A more granular use case within Escalate Privileges is monitoring for users added to specific groups. This might trip an alert to investigate the new user account and confirm the creation was authorized. Other examples are identified in Chapter 5 – from the perimeter to the endpoint.
Getting Started
Accounting for reasonably anticipated threats
Addressing vulnerabilities affecting systems with ePHI
Logging pertinent activities within ePHI systems
Responding to incidents involving ePHI
This is a lot of effort for only compliance. The goal should be about the desire to successfully anticipate, detect, and respond to malicious activity. Healthcare companies have an obligation to develop key processes to more effectively protect patient information. Patient information can be reasonably protected by assessing and understanding risks to the information and mitigating the risks through effective implementation of security measures designed to reduce the risks. Combine that process with adopting fundamental security principles like the Center for Internet Security 20 Critical Security Controls.4 These controls are necessary to foundational security and protect against many types of attacks. But once the foundation is laid, focus on security operations is a must.
Developing robust processes and people necessary to effectively conduct security operations is important. The information system components processing, transmitting, and storing healthcare data generate vast amounts of data and metadata about what is taking place in the network. Security tools also provide data points key to understanding what is happening in the environment. The team must understand what happens in the network during normal operations so unusual activity is noticed. Without that knowledge and ability, proactively detecting attacks or conducting forensic investigations is nearly impossible.
First Things First: Assess the Current State
Once the decision is made to develop security operations, it is necessary to understand the current state. The focus is understanding what people, processes, and technology exist in order to establish a baseline and identify gaps. The process can start by taking the framework of choice, the NIST Cybersecurity Framework (CSF ) or CIS 20 Critical Security Controls, and assess the level of maturity for pertinent controls related to threat intelligence, vulnerability management, monitoring, and incident response.
NIST Cybersecurity Framework (CSF)
NIST CSF categories and sub-categories of the Detect function
Detect Category | Sub-category | In Scope |
|---|---|---|
Anomalies and Events | DE.AE-1: A baseline of network operations and expected data flows for users and systems is established and managed | Yes |
DE.AE-2: Detected events are analyzed to understand attack targets and methods | Yes | |
DE.AE-3: Event data are aggregated and correlated from multiple sources and sensors | Yes | |
DE.AE-4: Impact of events is determined | Yes | |
DE.AE-5: Incident alert thresholds are established | Yes | |
Security Monitoring | DE.CM-1: The network is monitored to detect potential cybersecurity events | Yes |
DE.CM-2: The physical environment is monitored to detect potential cybersecurity events | No | |
DE.CM-3: Personnel activity is monitored to detect potential cybersecurity events | Yes | |
DE.CM-4: Malicious code is detected | Yes | |
DE.CM-5: Unauthorized mobile code is detected | Yes | |
DE.CM-6: External service provider activity is monitored to detect potential cybersecurity events | No | |
DE.CM-7: Monitoring for unauthorized personnel, connections, devices, and software is performed | Yes | |
DE.CM-8: Vulnerability scans are performed | Yes | |
Detection Processes | DE. DP-1: Roles and responsibilities for detection are well defined to ensure accountability | Yes |
DE. DP-2: Detection activities comply with all applicable requirements | No | |
DE. DP-3: Detection processes are tested | Yes | |
DE. DP-4: Event detection information is communicated to appropriate parties | Yes | |
DE. DP-5: Detection processes are continuously improved | Yes |
NIST CSF categories and sub-categories of the Respond function
Respond Category | Sub-category | In Scope |
|---|---|---|
Communications | RS.CO-1: Personnel know their roles and order of operations when a response is needed | No |
RS.CO-2: Events are reported consistent with established criteria | No | |
RS.CO-3: Information is shared consistent with response plans | No | |
RS.CO-4: Coordination with stakeholders occurs consistent with response plans | No | |
RS.CO-5: Voluntary information sharing occurs with external stakeholders to achieve broader cybersecurity situational awareness | No | |
Analysis | RS.AN-1: Notifications from detection systems are investigated | No |
RS.AN-2: The impact of the incident is understood | Yes | |
RS.AN-3: Forensics are performed | Yes | |
RS.AN-4: Incidents are categorized consistent with response plans | No | |
Mitigation | RS.MI-1: Incidents are contained | No |
RS.MI-2: Incidents are mitigated | No | |
RS.MI-3: Newly identified vulnerabilities are mitigated or documented as accepted risks | No | |
Improvement | RS.IM-1: Response plans incorporate lessons learned | No |
RS.IM-2: Response strategies are updated | No |
NIST CSF categories and sub-categories of the Recover function
Recover Category | Sub-category | In Scope |
|---|---|---|
Recovery Planning | RC.RP-1: Recovery plan is executed during or after an event | No |
Improvement | RC.IM-1: Recovery plans incorporate lessons learned | No |
RC.IM-2: Recovery strategies are updated | No | |
Communication | RC.CO-1: Public relations are managed | No |
RC.CO-2: Reputation after an event is repaired | No | |
RC.CO-3: Recovery activities are communicated to internal stakeholders and executive and management teams | No |
The controls not in scope for this book focus on elements of incident response. Processes such as detecting, containing, and eradicating events can be found in Cybersecurity Incident Response.5 This book discusses the elements required for building a cybersecurity incident response program.
Where Does the Control Framework Fit?
Control frameworks provide clues for identifying processes and controls necessary to carry out the function of a security program and, in this case, the capabilities found in security operations centers (SOCs). Focusing on developing these capabilities is easier when a blueprint is available. The NIST Cybersecurity Framework (CSF) and Center for Internet Security (CIS) Top 20 are shown here, but other frameworks exist. Control frameworks help identify processes required for successful implementation of a security program. Control wording for each pillar of security operations should be documented and monitored by management.
Threat Intelligence
Threat intelligence control wording examples
Threat intelligence aids security operations vulnerability management, monitoring, and incident management components. Knowing threat actors target specific vulnerabilities focuses the team on remediating those specific issues. Identifying specific, contextual events for detection increases the operations team’s ability to quickly identify and respond.
Vulnerability Management
Vulnerability management is not just about scanning for missing patches and configuration settings. That is a key portion of vulnerability management, but it involves much more. If a threat intelligence program is implemented, using a framework and focused on elements other than malicious domains, IPs, and file hashes, then the tactics, techniques, and procedures used by threat actors should be mapped to vulnerabilities. For example, Deep Panda uses PowerShell to download and execute programs once an initial foothold is gained. If PowerShell is not restricted and not logged, then a vulnerability documenting this weakness should be documented. Example controls addressing vulnerability management are documented in Figure 1-9.
It would be prudent to document the preceding PowerShell example as a risk on the risk register.
Control wording related to vulnerability management
Continuous Monitoring
Control wording examples for continuous monitoring processes
Incident Response
Control wording examples for incident response processes
These controls are important to the incident response program. A plan is required, and it needs practice. Members of the team need to know his or her responsibilities. It is also important to have the program assessed to identify improvements. The focus should be on investigation processes and documentation used by the team.
Conclusion
Four components encompass security operations. These include threat intelligence, vulnerability management, continuous monitoring, and incident response. This takes different forms in companies of different sizes. Large organizations sometimes have the resources to staff a security operations center separate from the information security team. For entities without these resources, third-party service providers offer virtual security operations center services. These arrangements offer monitoring services to entities. These services can be cost-effective because the service providers perform these services multiple entities. If neither of these approaches is feasible, then members of the information security team must perform security operations activities and the remaining information security duties as well. It is not unusual for a hybrid approach where the entity utilizes the services of a third-party and internal team members also have security operations duties.
The final element of consideration is processes and controls defining what actions are necessary. Identifying and monitoring controls creates accountability for the team. It prevents ad hoc actions and key processes from being missed.