CHAPTER 1

Security Operations:
The Why and the
Roadmap
Information security teams deal with a lot of noise. This noise is meant to be both
negative and positive in tone. Negative noise can include statements like

• 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.

1
© Eric C. Thompson 2020
E. C. Thompson, Designing a HIPAA-Compliant Security Operations Center,
https://doi.org/10.1007/978-1-4842-5608-4_1
Chapter 1 Security Operations: The Why and the Roadmap

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?

Cybersecurity operations is a sub-component of an overarching cybersecurity program.
In Building a HIPAA-Compliant Cybersecurity Program,1 the NIST Cybersecurity
Framework was used as a model for establishing the cybersecurity program to
protect healthcare information and comply with the Health Insurance Portability and
Accountability Act (HIPAA). Security operations plays a vital role in entities charged
with protecting healthcare records. This component is about detection and response.
It consists of four elements: threat intelligence, vulnerability management, operations/
continuous monitoring, and incident response. Figure 1-1 illustrates these elements of
security operations.

1
Eric Thompson, Building a HIPAA-Compliant Cybersecurity Program, 2017

2
 Chapter 1 Security Operations: The Why and the Roadmap

Threat
Intelligence

Incident Security Vulnerability

Response
Operations Management

Security
Monitoring

Figure 1-1. 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.
In Cybersecurity Incident Response,2 cybersecurity programs were broken into several
sub-programs. Figure 1-2 shows the breakdown of a cybersecurity program into its
sub-programs. The point is to show the vastness of domains involved in cybersecurity

2
Eric Thompson, Cybersecurity Incident Response, 2018
3
Chapter 1 Security Operations: The Why and the Roadmap

and how security operations are pulled from many of the domains to form specialized
processes with specific objectives within the entire program. Threat intelligence pulls
from controls in the threat detection program, built from controls aligned with the
categories and sub-categories of the Detect Function. Vulnerability management has
roots in network protection, data protection, and governance. Continuous monitoring
comes from nearly every domain: endpoint protection, access management, network
protection, and threat detection. Incident response is the same as incident response
capabilities for the cybersecurity program.

Figure 1-2. Cybersecurity sub-program elements as part of a larger cybersecurity

program

4
 Chapter 1 Security Operations: The Why and the Roadmap

Each of these sub-programs possesses written strategy, procedures, processes, and –

if exceedingly mature – metrics. For example, let’s examine the training and awareness
program. Figure 1-3 highlights these examples.

Figure 1-3. Examples of the strategy, procedures, processes, and metrics for the
training and awareness program

The same actions are required to create and mature a security operations program.
There must be a strategy for collecting threat intelligence, identifying and monitoring
vulnerabilities, establishing monitoring capabilities, and responding to events of interest
including incidents and breaches.

5
Chapter 1 Security Operations: The Why and the Roadmap

Figure 1-4. Security operations strategy, procedures, processes, and metrics

examples

Security Operations: Large Entity vs. Small Entity

Security operations centers (SOCs) are distinct from the rest of the information security
team in large entities. These SOCs are staffed with analysts, senior analysts, managers,
and a leader overseeing the entire function. Team members focus on identifying threats,
vulnerabilities, and anomalies and responding to these items of interest. The response
process does often coordinate with others on the information security team. Leaders of
SOC environments focus on continuing to mature processes and improve the program
function. Table 1-1 highlights the different responsibilities of traditional information
security practitioners and those who work in a SOC.

6
 Chapter 1 Security Operations: The Why and the Roadmap

Table 1-1. 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.
Procedures and processes develop the “how” for the threat intelligence strategy:

• 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?
7
Chapter 1 Security Operations: The Why and the Roadmap

Many processes need documentation to make threat intelligence effective. Several

important ones are highlighted in Figure 1-5.

Collecting,
enriching and
Formal inventory
Roles and Risk assessment integrating IOCs
of approved
responsibilities and analysis with detection
sources
and monitoring
solutions

Figure 1-5. 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.

8
 Chapter 1 Security Operations: The Why and the Roadmap

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, a company known for providing contextual threat intelligence,
defines intelligence as a product of the process depicted in Figure 1-6.

Collect Analyze View It in

Data Data Context

Figure 1-6. Recorded Future process for collecting threat intelligence

9
Chapter 1 Security Operations: The Why and the Roadmap

Threat intelligence comes in several forms like feeds (paid and free) or podcasts and
downloads from groups like the SANS Internet Storm Center. Threat intelligence can
also come from news posts on social media. No matter where the intelligence comes
from, there needs to be a mechanism for analysis and integration. Analysis of the threat
intelligence includes

• 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.

10
 Chapter 1 Security Operations: The Why and the Roadmap

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

When designing operations, referring to the Mandiant/FireEye Kill Chain is useful
(see Figure 1-7). SOC leadership can break down threat indicators, vulnerabilities, and
log data into manageable buckets for each stage of the kill chain. It acts as reference
when evaluating threat intelligence indicators and applying defenses for the team to
understand where in the attack lifecycle each indicator and defense is operating.

3
https://securityintelligence.com/is-full-packet-capture-worth-the-investment

11
Chapter 1 Security Operations: The Why and the Roadmap

Figure 1-7. Mandiant/FireEye Kill Chain

Figure 1-7 shows the steps required for an attacker to complete its mission. Gaining
an initial foothold or compromising systems is not the mission. Administrative access
does not constitute a successful attack unless it leads to completion of the objective,
which for the purposes identified here are disrupting the confidentiality, integrity,
or availability of electronic Protected Health Information (ePHI). The objective of
cybersecurity operations is to detect and stop the attacker anywhere along this chain
before mission completion. To create a blueprint for program development, use cases
derived from the kill chain offer a starting point. This process quiets the noise and
focuses the team. The high-level use cases include

• 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.

12
 Chapter 1 Security Operations: The Why and the Roadmap

Getting Started
The best to start is with “why.” Why do you want to establish and create a security
operations program? There are compliance requirements that can be mapped to
cybersecurity operations. Those include

• 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.

4
https://learn.cisecurity.org/20-controls-download

13
Chapter 1 Security Operations: The Why and the Roadmap

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)

The security controls in scope for cybersecurity operations include those from the
Detect, Respond, and Recover functions. Tables 1-2, 1-3, and 1-4 display the control
objectives for each and indications of those controls that this book will focus on.

Table 1-2. 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 Yes
flows for users and systems is established and managed
DE.AE-2: Detected events are analyzed to understand attack Yes
targets and methods
DE.AE-3: Event data are aggregated and correlated from Yes
multiple sources and sensors
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 Yes
cybersecurity events
DE.CM-2: The physical environment is monitored to detect No
potential cybersecurity events
DE.CM-3: Personnel activity is monitored to detect potential Yes
cybersecurity events
DE.CM-4: Malicious code is detected Yes
(continued)

14
 Chapter 1 Security Operations: The Why and the Roadmap

Table 1-2. (continued)

Detect Category Sub-category In Scope

DE.CM-5: Unauthorized mobile code is detected Yes

DE.CM-6: External service provider activity is monitored to No
detect potential cybersecurity events
DE.CM-7: Monitoring for unauthorized personnel, connections, Yes
devices, and software is performed
DE.CM-8: Vulnerability scans are performed Yes
Detection Processes DE. DP-1: Roles and responsibilities for detection are well Yes
defined to ensure accountability
DE. DP-2: Detection activities comply with all applicable No
requirements
DE. DP-3: Detection processes are tested Yes
DE. DP-4: Event detection information is communicated to Yes
appropriate parties
DE. DP-5: Detection processes are continuously improved Yes

Table 1-3. 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 No

when a response is needed
RS.CO-2: Events are reported consistent with established No
criteria
RS.CO-3: Information is shared consistent with response plans No
RS.CO-4: Coordination with stakeholders occurs consistent with No
response plans
(continued)

15
Chapter 1 Security Operations: The Why and the Roadmap

Table 1-3. (continued)

Respond Category Sub-category In Scope

RS.CO-5: Voluntary information sharing occurs with external No

stakeholders to achieve broader cybersecurity situational
awareness
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 No
plans
Mitigation RS.MI-1: Incidents are contained No
RS.MI-2: Incidents are mitigated No
RS.MI-3: Newly identified vulnerabilities are mitigated or No
documented as accepted risks
Improvement RS.IM-1: Response plans incorporate lessons learned No
RS.IM-2: Response strategies are updated No

Table 1-4. 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 No
stakeholders and executive and management teams

16
 Chapter 1 Security Operations: The Why and the Roadmap

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
This category assesses the entities’ ability to identify sources, disseminate, incorporate,
and report on information pertinent and actionable to the organization related to threat
actors targeting ePHI. Figure 1-8 outlines several basic controls requiring the entity
to adopt a threat intelligence framework and utilize and measure the quality of threat
intelligence. Establishing controls and holding owners accountable increases the odds of
program success.

5
Eric Thompson, Cybersecurity Incident Response (Apress, 2018)

17
Chapter 1 Security Operations: The Why and the Roadmap

Threat A threat intelligence framework is used to

Intelligence identify the types, sources and uses of threat
intelligence.

Threat intelligence is utilized by detection

capabilities and measured to confirm it meets
needs of the security operations program.

Metrics are identified and tracked by the

security operations team and used to evaluate
the effectiveness of the program.

Figure 1-8. 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.

18
 Chapter 1 Security Operations: The Why and the Roadmap

Note It would be prudent to document the preceding PowerShell example as a

risk on the risk register.

Vulnerability Vulnerability scans are conducted monthly.

Management

Critical and high vulnerabilities identified are

remediated within 30 days. If vulnerabilities cannot
be remediated within this time frame then rationale
and compensating controls are documented.

Vulnerabilities are identified based on threat

intelligence and control processes are identified to
reduce the likelihood of exploit.

Figure 1-9. Control wording related to vulnerability management

Continuous Monitoring
Continuous monitoring is essential to security operations and monitoring for possible
exploits of identified vulnerabilities and actions taken by threat actors (see Figure 1-10).
The elements of continuous monitoring include endpoint capabilities such as malware
detection, data loss prevention, detection, and response and built-in capabilities offered
by operating systems. Figure 1-10 documents examples of controls for establishing
continuous monitoring.

19
Chapter 1 Security Operations: The Why and the Roadmap

Continuous Monitoring capabilities necessary to

Monitoring
mitigate risks are identified and
implemented.

Alerts are investigated, escalated as

incidents if necessary, and resolution
documented.

A logging and monitoring strategy is

documented and reviewed annually by the
Information Security Steering Committee.

Figure 1-10. Control wording examples for continuous monitoring processes

Incident Response
The incident response program is an essential and very important piece of the security
operations program. Events occur almost daily in some environments and all need
investigation to understand if escalation to an incident and beyond is required. Security
operations and information security programs are often judged by the ability to respond
quickly and appropriately to incidents (see Figure 1-11). These control and accountable
owners are also necessary to build and maintain an incident response program.

20
 Chapter 1 Security Operations: The Why and the Roadmap

Incident An incident response plan is

Response documented and reviewed annually.

Incident response table-top exercises

are conducted annually. Findings are
remediated within 90 days.
Incident response processes and
procedures are assessed annually and
identified improvements implemented.
Figure 1-11. 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

21
Chapter 1 Security Operations: The Why and the Roadmap

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.

22