Is your security stack blind?

Co-author: Adair Collins

"Study the past if you would define the future." — Confucius (551 BC - 479 BC)

Introduction

Is your security stack blind to evolving threats? Network Security Monitoring (NSM) is great, but when we get attacks from or exfiltration to trusted sources, non-intercepted SSL traffic, or tunneling, what do we do? In any event, we need a combination of Security Operations Center (SOC) methodology, Security Incident & Event Monitoring (SIEM), Security Orchestration, Automation & Response (SOAR), Managed Detection & Response (MDR), End-point Detection & Response (EDR) and combining them with kill-chain model and MITRE ATT&CK framework for context. The problem that we are currently facing is not just the need for centralization and automation of security, but also the need for monitoring, detection and response to shift towards end-points. In this article, we have reviewed a possible implementation combining NSM with Incident Response (IR), Threat Hunting (TH), Threat Intelligence (TI) and end-point monitoring and response.

Network security monitoring (NSM) is the collection, analysis, and escalation of indications and warnings (I&W) to detect and respond to intrusions. — Richard Bejtlich and Bamm Visscher

NSM: What is & What isn't?

To enable a world-class SOC, we would require a combination of best-in-the-market commercial and open-source resources, comprehension of threats that are to be resolved at the end-points no matter where they get detected and enabling visibility into the applications, processes, networks and end-points themselves. Every organization including service providers are striving really hard to keep up with detection speeds, quality of alerting and effectiveness of reporting incidents. We have the need to prioritize the focus on visibility and granularity over all of the above. The following architecture would help us look into a version of state-of-the art implementation of NSM:

NSM and its components vary based on the seven pivots that are,

• Intelligence: Threat intelligence is a collection of IoC sources to map threats with collected logs and generate rules.
• Collection: Log generation is performed based on rules, intelligence and traffic collected from the security stack appliances.
• Logging, Caching & Enrichment: Identifying and enriching log types, parsing values and shipping to the search component. Log enrichment can be used for applying context and filters, to narrow down the search to events of interest and create pivot points.
• Alerting: Correlation logic is applied on the logs to generate alerts of interest, based on log enrichment, threat intelligence and other mapping conditions.
• Search: Searching and indexing logs is core component for threat hunting and incident response.
• Visualization: Visualization is a means to view the relationships between the events, parameters and intelligence.
• Response: Responding to the detected threats can be performed through manual or automated shunning.

Why is your security stack blind?

NSS Labs Predicts 75% of Web Traffic Will Be Encrypted by 2019 — NSS Labs

Majority of the internet traffic that we tend to monitor are encrypted. Popularity of Let's Encrypt has grown significantly beyond 50 million active certificates. We have been noticing that phishing campaigns, malware downloads, malicious beaconing, data exfiltration and other techniques that has been going over encrypted channels such as SSL. What can we do without SSL interception?

Let alone malicious traffic from/to known malware domains that are blacklisted from TTPs, trusted sites are being used by bad actors to distribute ransomware, malware call-backs through social media, and other means. DNS tunneling is another technique used by threat actors for C&C or data-exfiltration that bypasses common elements of security stack. SSH tunneling is another technique utilized by threat actors, although it can be restricted by next generation firewalls or IDPs to specific trusted or whitelisted IPs. This is accomplished by ensuring protocol awareness in the request-response handshakes.

Visibility is also a problem based on the placement of security appliances within the network. Questions that arise when we place the appliances should be,

• Are we placing it behind a NAT or in front of the NAT?
• Are we looking at various VLANs or micro-segments within the network?
• Are we tapping (expensive) the traffic or are utilizing spanning ports (packet loss)?
• What is encrypted or tunneled within the NAT or micro-segment?

There are approaches that we could take if SSL interception is not an option such as,

• Certificate hash: SSL blacklist based on the certificate hash .
• Server Name Identifier (SNI): Bro SSL analyzer can be utilized to parse, inspect and evaluate certificate based on hashes, values, SNI data, revocation and other info.
• Certificate value: Analyzing based on Common Name, Organizational Unit, etc.
• UPDATE: JA3 and JA3S are means to fingerprint TLS client-server connections. TLS fingerprinting capability is widely available on open-source and commercial products.

SSL interception is the most important step when it comes to visibility and granularity of the collected traffic. If SSL interception is an option, we would be able to view and analyze intercepted traffic (excluding banking, healthcare, and any other sites categorized for handling PII/PHI data) that would provide context, full visibility and threat inspection. Ideally, we would want to create a decryption zone where the intercepted traffic is analyzed by the security stack, as opposed to decrypting the traffic within an individual appliance. Regardless of SSL interception, end-point diagnostics and monitoring in combination with NSM will provide a greater insight for TH and IR.

EDR: What's on your host?

Security stack can inspect network traffic to/from hosts, but does not have any visibility into the activities, or applications within the host itself. Common EDR capabilities include monitoring the host for events, memory, processes, file system, registry and network connections. Heuristics and pattern-matching of the above has existed for a very long time, with recent changes enhancing it with Artificial Intelligence (AI) and Machine Learning (ML). The following image shows some of the components and sub-components that are commonly monitored by EDR,

Combining NSM with EDR host visibility will enable us to provide the context behind an incident or threat, root cause or initial vector, the spread, blast radius and rapidly respond using built-in EDR quarantine or removal processes to prevent further infection at the host and network level.

SWOT Analysis: EDR with NSM

Here are the Strengths, Weaknesses, Opportunities & Threats (SWOT) analysis of the combination of EDR with NSM. In here, we purely focused from the integration aspect of visibility and capability. There is potential for growth in EDR providers, if they combine the network monitoring intelligence with what they obtain from the hosts. Adding host-based packet capture with live memory analysis in EDR would provide greater flexibility to rapidly respond to threats.

Closing the gap between NSM and EDR

Obtaining data analytics involves intelligence not only from a threat perspective, but also to understand applications, performance, norm and anomalies, and other components within the network. To enable this we could also look into,

• SSL-enabled web-application logs from DMZ
• Performance and health logs
• Database logs - Transaction, Access and Memory
• Operating system command-line (cmd.exe, PowerShell, WMI and AppLocker), application and security event logs
• Kernel and driver logs
• Volatile memory forensic analysis
• SSH, RDP, VPN and other remote connectivity logs
• Honeypot and sandbox logs

TH & IR with EDR & NSM

Understanding the integration between EDR and NSM involves integrating them into the process of IR and TH. In the following diagram, we have defined a generic model for IR and TI, which involves supplementing intelligence into an SIEM for event generation. Events generated are then alerted for analysis, which involves correlating with the history of past and present threats and potential TI.

Incident is then validated and responded to, based on the category of threats. Incidents that are responded and the ones that did not require a response either are then documented and reviewed. Threat repository is a collection of all of the threats, intelligence, alerted logs and events that are gathered from multiple phases and provides an additional perspective into TI. This process is the same for NSM, although EDR benefits here by adding host-based events, file system, registry, memory, processes and network connections to completely correlate the scope on what is being observed on the network, with what was obtained from the host. In our next post, we will discuss more on malware playground, memory analysis, threat intelligence and OS event logging.

Kindly, share your comments on what you think about the article, or your personal observations and experiences. We value your opinion!

“A smart man makes a mistake, learns from it, and never makes that mistake again. But a wise man finds a smart man and learns from him how to avoid the mistake altogether.”  ―   Roy H. Williams

Disclaimer: Please note that these posts and what is described in them are for educational purposes only. Opinions expressed are solely my own and do not express the views or opinions of my employer.