Security operations is a mindset. Healthcare entities do not necessarily need to have a dedicated security operations center or contract with a managed service provider delivering virtual security operations center (SOC) services. But the mindset needs to be there. Once the overarching cybersecurity program is designed and implemented, the real work on implementing security begins. In the forward to Snort: IDS and IPS Toolkit,1 Stephen Northcutt talks about the difference between managing security via checklists and policies and understanding how to implement security. This means frameworks like the NIST Cybersecurity Framework (CSF) are great tools to guide entities in implementing security, risk assessment, and management strategies – but more is needed. Entities must perform threat assessments and in-depth analysis of vulnerabilities and attack vectors to implement high-functioning detection capabilities. This comes from knowledge of the network traffic characteristics and how to protect it from malicious use. As the security operations center grows in maturity, higher levels of visibility and understanding create opportunities for granular detection of specific activities in the environment.
To reach this goal, the team must first think in terms of outcomes. What does a high-functioning security operations center look like? As an example, in our work here, a SOC that is baselined, built on intelligence, and automated represents what the team is striving toward.
Collecting logs for monitoring and developing alerts creates noise. Utilizing tools like the Mandiant/FireEye Attack Lifecycle and/or MITRE’s ATT&CK framework guide the SOC on what actions to alert against. Even with significant tuning of alerts, certain types of logging – Windows logging in particular – will still be noisy. As the SOC filters and refines logging to reduce the noise, the focus of the SOC becomes clearer improving over time.
Security Operations Components
Security operations consists of vulnerability management, threat intelligence, continuous monitoring, and incident response. These are important pieces of overall information security program, and maturing these pieces into a repeatable security operations program is necessary.
Vulnerability Management
Vulnerability management makes sense as a starting point for two reasons. First, documenting all vulnerabilities is a necessary component of risk analysis and assessment. Risk analysis should be one of the first things created by the information security team. Second, managing vulnerabilities is a key piece of overall cyber hygiene.
Vulnerabilities are typically identified through technical scans – but it is also important for each entity to assess their environment, people, processes, and technology. One example of why this is necessary is discussed in Chapter 4: the use of and lack of monitoring or restrictions regarding PowerShell. While this may not be something that would show up on a vulnerability scan, it is still a vulnerability attackers can use to perform the initial attack, escalate privileges, and maintain persistence. Combining technical scans with analyzing the environment against attack techniques creates a much more comprehensive list of potentially exploitable vulnerabilities. Throughout the vulnerability management process, the SOC can monitor for activity targeting these weaknesses.
The security operations team needs to understand what infrastructure teams and business owners are doing to remediate the vulnerabilities. In most cases, vulnerabilities found via technical scans are remediated with patches and bug fixes. People- and process-related vulnerabilities are different. These can often require the creation of new processes or elimination of high-risk processes entirely. If it’s not possible to fully remediate a vulnerability, security measures must be implemented to reduce the risk to an acceptable level. The SOC team must also implement ways to measure and prioritize vulnerabilities and stay up to date on the status of vulnerability remediation. By doing so, they can better understand the potential impact to the entity when using threat intelligence, monitoring the environment, and responding to incidents.
Threat Intelligence
Initial Access
Execution
Persistence
Privilege Escalation
Defense Evasion
Credential Access
Discovery
Lateral Movement
Collection
Command and Control
Exfiltration
Impact
Pyramid of Pain2
The ATT&CK framework focuses on the top three portions of the pyramid. Other threat feeds focus on the bottom three portions of the pyramid. These free and paid subscriptions focus much of the intelligence provided on malicious domain names, IP addresses, and hash values of the files used during an attack. These indicators change easily and make detecting attackers more difficult.
Continuous Monitoring
Examples of monitoring tools used on the network and endpoints
Network | Endpoint |
|---|---|
Packet capture | Host-based firewalls |
Intrusion detection system | Endpoint logging |
Network analyzer | |
Firewall/router/switch | |
Web proxy |
These solutions/capabilities have commercial and open source choices available to healthcare entities of all budgets. Open source does not mean the tools are free, since manpower is required to operate and maintain each solution. One benefit to open source tools is customization. With the right knowledge and skill, most solutions of this type are customizable. A potential drawback to open source is limited support from vendors, but there are other third-party professional support resources available for some solutions.
A couple of open source tools that we have discussed include Moloch (packet capture), Snort (intrusion detection system), Zeek (network analyzer), and Squid (web proxy). Solutions like these are frequently used sources for network visibility. On endpoints, Windows and UNIX/Linux operating systems come with built-in logging tools. One free tool available for Windows endpoints is Sysmon. The detailed command-line logging is useful for investigating potential attacks.
The most essential aspect of continuous monitoring that is not included in the table is the Security Incident and Event Management (SIEM). All the data logged by the solutions in Table 8-1 are collected in that one location for examination and correlation. SIEM solutions come in open source and commercial varieties as well.
Incident Response
The incident response plan/program is invoked when analysis of an event requires escalation. When events occur, SOC analysts and incident response teams investigate and triage the situation. The SOC analysts escalate the incident when necessary based on defined criteria. These investigations start with the point of notification. When an alert is triggered by anomalous network traffic, analysis of the rules and the traffic that caused the alert to generate begin the process. The team follows the trail, until every path is uncovered. The conclusion of this work ends with a set of endpoints impacted by the incident. The goal is to detail the scope of the incident as efficiently as possible and move toward eradication and recovery. Having the right tools, processes, and people in place is key to success.
Think in Terms of Outcomes
Example SOC objectives
The plan represents three pillars of success for the SOC.
Who are the top talkers outside the network?
Who are the top talkers inside the network?
What protocols are used most outbound?
What protocols are used most inbound?
What is the level of randomness to DNS queries?
What applications are the most/least common on endpoints?
The second key to success is implementing a SOC program built on intelligence. The goal here is to focus energy on monitoring events likely to be of interest to the entity. Understanding how to alert on techniques used by attackers creates an opportunity for what many practitioners call “high-fidelity” alerts, which contain less false positives and are better indications of true malicious activity. Using MITRE ATT&CK is a great way to start. Additionally, the Center for Internet Security (CIS) posts blogs each month with the Top 10 Malware. Reading reports on highly active malware offers opportunities to create alerts-based malware behavior. The goal is not to get a list of IP addresses, domain names, and hashes to alert on – the goal is to alert on techniques requiring threat actors to recompile code. Remember the Pyramid of Pain from earlier in this chapter? The focus of alerts is on the tools and tactics, techniques, and procedures (TTPs) at the top of the pyramid in Figure 8-1 because it is more difficult for attackers to change.
The third success measure is automating as much of the security operations processes as possible. Automation can be as simple as automating vulnerability scans or as complex as automated remediation workflows and activities when alerts are generated. The latter takes time. Mistakenly blocking an end user from doing his or her job because of a false positive means the SOC just caused a denial of service. That is not the reputation the SOC wants. New offerings focused on security orchestration and automated response (SOAR) are popular now. Some vendors offer SOAR solutions as part of an existing SIEM solution or as a stand-alone product. The driving force behind these tools is reducing workloads for SOC analysts. Key processes where automation should be focused are mundane or simple tasks. One use case would be if new malicious IP addresses or URLs were provided via a threat feed, the automation tools could block those right away and prevent a SOC analyst from completing the task manually.
Cutting Through the Noise
Cybersecurity is filled with noise. It comes from news outlets and social media pundits talking about how “breaches are inevitable” and how “attackers are more advanced with more resources than those protecting networks.” Logging creates noise. Without knowing why, a log is collected and what specifically the SOC wants to monitor within a log, just ingesting a log into a SIEM causes noise. Imagine a SIEM dashboard with a list of all network connections made by every endpoint in the entity. That would be thousands of connections per minute. No one can view that much information and make sense out of it. Logging and monitoring need to be focused. The same is true of threat intelligence. Threat intelligence is delivered in many formats. Emails, direct feeds to monitoring tools, and via Twitter are three examples. If multiple feeds are captured by the SOC in each format, it is difficult to effectively manage each and use to the fullest extent. Each threat feed captured by the SOC must be done for a specific purpose with specifically document process for utilization. The best method for getting started is focusing on threats that attack healthcare entities, such as Deep Panda discussed in Chapter 3 and detailed by the MITRE ATT&CK framework. The SOC can also incorporate intelligence on malware variants most active. At the time of this writing, Emotet with Trickbot infections were common. Incorporating new intelligence on this malware activity adds focus.
An unusually high number of connections inbound to certain endpoints
Unusually long connection durations
Internal endpoints that should not talk to each other, such as a production and development servers connecting
Protocol usage not normally seen, like endpoints making DNS requests to external servers
The Mandiant/FireEye Attack Lifecycle
Using this model and knowledge of the tactics, techniques, and procedures of attackers targeting healthcare helps to focus monitoring capabilities. Then the entity designs monitoring to detect exploitation of available vulnerabilities in each tactical stage based on what was learned through the gathering of intelligence. For instance, most healthcare organizations are vulnerable to end users interacting with malicious emails. An attack using Emotet to download begins by end users opening word documents and enabling macros that initiate the attack.4 Since Emotet is a downloader for Trickbot, these attacks feature the initial Emotet infection, followed by a download of Trickbot from a malicious site. Reviewing packet captures published by Brad Duncan at Malware-Traffic-Analysis, a SOC analyst in charge of gathering threat intelligence might notice that during the initial stages of the attack, two GET requests over HTTP occur. Creating an alert for two GET requests by the same endpoint within a minute can be tested by the SOC. If this alert is not too noisy, anytime that alert fires, the analyst can look for evidence the user received and clicked a word document just before the downloads occurred.
This same process can be used to also detect malicious insiders. Understanding where users can circumvent controls, especially those protecting ePHI, intellectual property, and sensitive corporate information, then mapping the exploitation of those vulnerabilities to techniques used to exploit them is one way a SOC can monitor for insider threat activity. End users planning on a job change often try to take work products with them upon their departure. Email, uploads to file sharing sites, and use of removable media are some ways to get documents out the door. Savvier end users might find open ports like TCP 3389, used for Remote Desktop Protocol and use this avenue to move documents to an endpoint at home. If there is a chance that these capabilities exist for end users, the SOC must detect the occurrences. This upfront planning focuses the team on specific monitoring actions and avoids haphazard approaches to detection.
Adjust and Improve
Everything gets better with time. Books get better with each new edition, sports teams improve with practice, and each year of experience brings more maturity to security operations centers. Whether the SIEM is the single pane of glass for all monitoring and detection or reliance is placed on individual solutions, new techniques are discovered all the time. Many great security practitioners make newly discovered ideas available via webcasts, podcasts, and YouTube. There are also many classroom opportunities. Good ones send students home with ideas ready for implementation. This is best way to get better at security operations. Do the best job possible and try to get better every day.
Conclusion
Detecting attacks is hard. Even with all the right monitoring processes in place, it is not easy to spot well-trained adversaries. These attackers test malware against detection engines like those found at VirusTotal to confirm it does not cause alerts. That leaves it up to the SOC team to find other means of detection. Attackers also use resources available in the entity’s network. The objective is to blend the malicious activity inside legitimate processes. Attackers can bury malware deep within file systems and do everything possible to prevent detection by endpoint detection tools, but malware needs to run/execute and communicate with its command and control (C2) infrastructure to operate. Open up the task manager on a Windows endpoint and review the processes running in the background, and you might see one called svchost.exe or Service Host: <additional details about the process>. This generic service runs anytime processes are run from Dynamic Link Libraries (DLLs). Those details are important for this point. If an attacker wants to run malware, a process might be created called svch0st.exe, replacing the o in host with a numerical 0. An analyst running through a dashboard showing new processes created might miss this subtle nuance. Attackers also blend communication to the C2 servers within HTTP or DNS traffic. Entities do not block HTTP or DNS by default because the information technology function would not operate. So the SOC needs to find this traffic among all the legitimate uses of those protocols.
This does not mean it is impossible for the SOC to find malicious activity. Some professionals adopt the notion attackers only need to be successful once, while the entity needs to be perfect all the time, or else a successful attack is inevitable. The processes described in this book are meant to dispel those myths. Gaining access to a network is not the ultimate goal of an attack. Exfiltration, destruction, and manipulation of data are the more common objectives for an attack. That means attackers must get inside the network, enumerate the environment, move laterally, and escalate privileges before finally achieving the objectives of the attack. Healthcare entities can build SOC processes capable of catching this activity and preventing a successful attack. It takes time and focus to get there.