Endpoint and Network Security Operations

Let’s talk about endpoint protection strategy and its relation to security operations (SIEM+SOC or MSSP/MDR).
While there is sometimes overlap in parts of these technologies, both endpoint and security operations are important. They both play a distinct role in an effective security program. Network sensors “see” activity that endpoints don’t. Endpoint agents are closest to process execution and “see” activity network sensors won’t. The SIEM (with a SOC) ties it all together.

So, you build this beautiful manse on a cliff in Malibu. You have this great alarm system service. You didn’t opt to put sensors on the second-floor balcony doors. You do have some basic locks on the doors and use them most of the time. An enterprising criminal recon’s your place, figuring out how to hide (where cameras won’t see). Said person throws a giant ladder up one day, picks the lock and is in. Your precious Ashera is sleeping on the bed and the perp walks off with her.

To whom do you “point the finger”? The alarm company? The lock company?

OK, so that might be a stretch of a story. Here’s the point and how it relates – a good SIEM+SOC or service (MSSP/MDR) is most effective when provided good telemetry (or data) from endpoint agents (and other devices). A good endpoint solution is most effective when paired holistically with a SIEM+SOC or service (MSSP/MDR), which parses and aggregates the disparate telemetry sources, to derive information (which may lead to actions).

If an organization has endpoint protection which doesn’t send data to a SIEM for SOC processing, they’re missing a big chunk of the picture. Ick. In today’s world of complex threats … yikes. Organizations need software that detects, protects, and sends data to a SIEM for SOC analytics. Anecdotally, the products that can’t send info via API or syslog to a SIEM aren’t generally that sophisticated on the detection/protection front either.

Likewise, the organization’s SIEM+SOC would ideally leverage telemetry from network sensors, firewalls, endpoints, Active Directory, Cloud, SaaS apps, etc. to make sense of events. That is, use correlation to indicate what events are likely to be bad.

Let’s pick on PowerShell. There are a bunch of legitimate uses for PowerShell scripts. If you watch what’s going on, even on your own computer, you’ll notice they are actually part of “good” installed packages. In fact, a bunch of driver software and MSP-like apps use PowerShell for inventory and restarting services and such.

Conversely, here’s an oversimplified example: On a network, some machines are running a PowerShell script. Endpoint protection software isn’t necessarily flagging it as “known bad”.  The endpoint agent is continuously updating the SIEM with telemetry about all execution state. What the endpoint protection software alone does not necessarily know, is that the PowerShell script is also running on 65 other machines that are trying to load a variant of Mimikatz via a seemingly innocent PNG file, trying to dump the AD. That’s not to say we should blame the endpoint protection software. A network sensor detected access to the PNG file, but it also didn’t necessarily think it was bad and allowed the action.

If network sensors and endpoint protection agents are sending telemetry to a SIEM and that SIEM has parsers and correlation algorithms, the SIEM could deduce that 65 machines downloaded this unusual PNG and are running a PowerShell script all at the same time. An alert would be generated, a SOC analyst investigates, thus finding the Mimikatz activity.

When it comes to what a SIEM ingests and a SOC analyzes, endpoint protection and network sensors are different. They are complimentary of each other, sometimes overlap. Overlap in cybersecurity is good. A network sensor might not detect unusual PowerShell execution. An endpoint agent might not detect a PNG downloaded from a known malicious site. Neither solution, alone, would correlate events. That’s what a SIEM and SOC analysts are for. The SIEM+SOC (MSSP/MDR) is the overarching, highest level platform/system that unifies this all.

So – TLDR; right?  Bottom line – have:

• Endpoint protection that detects different types of activity (i.e. isn’t the ‘old signature-based)
• Endpoint protection that sends telemetry to a SIEM
• Network sensors that send telemetry to a SIEM
• Use / build parsers for the telemetry
• Use algorithms and analytics in your SIEM that can correlate events
• Have a SOC analyst review events
• Take action

*** If you don’t have the resources to build, optimize, maintain, and manage a SIEM with an active SOC –consume it as a service from a reputable provider. ***

For broader traffic visibility for a distributed workforce (going to your SIEM, from a network sensor):

• Mandatory full-tunnel VPN on corporate-owned/controlled devices
• Internet backhaul for regional sites to a hub
• SD-WAN with traffic inspection capability
• Cloud-based firewall with agents on corporate-owned/controlled devices
• Remote solutions (like VDI), inspect in-session traffic
• Develop an encrypted packet inspection strategy

For more information on Endpoint Security, click here.