Deploying MDR/SIEM to gain better visibility

Implementing an MDR/SIEM solution is a big step in the right direction towards improving your security posture while reducing risk exposure. However, if the MDR/SIEM solution isn’t deployed properly, it can result in gaps in visibility, reducing effectiveness.

I’d like to discuss the importance of having a defined MDR/SIEM deployment process along with best practices for providing maximum visibility. I also include an MDR/SIEM deployment checklist to help define this process, which you can get right here.

The basics

Managed Detection & Response (MDR) is typically defined as the monitoring of a network using a combination of technologies, including a sensor that captures network traffic, allowing a provider to detect and respond to potentially malicious activity. These days, some MDR solutions are also coupled with Security Information & Event Management (SIEM) capabilities to provide additional visibility and alerting while also securely maintaining a copy of logs from monitored systems.

For this article, we’ll be including both MDR and SIEM in our deployment strategy.

Information gathering

Before we can deploy an effective managed security solution, we must have a comprehensive understanding of the environment we’ll be monitoring.

For the MDR components, an up-to-date network diagram can be beneficial in determining the number of sensors needed along with optimal placement to capture traffic from all locations, subnets, and VLANs.

It’s also important to capture all points of egress on a network, particularly for organizations that may have multiple locations. A basic rule of thumb, if a location has a point of egress to the internet, a sensor should be installed.

From there, let’s focus on gathering the information we need to deploy the SIEM components effectively. In the case of Perch Security, we can capture logs from operating systems, syslog-enabled devices, file-based logs such as SQL and IIS, and have integrations with many cloud-based services, including Microsoft 365 and G Suite.

Some good resources for gathering the information needed for the SIEM deployment would include:

• A network diagram which should include servers and network appliances (may also include workstations)
• An up-to-date inventory of IT assets including both hardware and software
• A recent network scan using an RMM or network discovery tool

Deployment

While specific deployment strategies will vary, there should always be a defined process that’s effectively conveyed to all stakeholders.

To ensure maximum visibility, this deployment process should cover the following key areas:

• Network
• Endpoint
• Firewalls/Network Appliances
• Cloud

Network

Monitoring network traffic is an essential way to detect indicators of compromise (IoC) and should be a consideration for any managed security deployment.

This is typically achieved by installing a sensor that can ingest traffic and run that traffic through an intrusion detection engine.

Network sensors are normally deployed in one of two configurations, inline or passive.

In an inline installation, the sensor is typically located between the core switching equipment and the firewall, forcing all traffic going in or out of the network to pass through the sensor.

Two drawbacks to an inline installation are a lack of visibility into east-west traffic and the fact that a sensor failure can impact connectivity to the internet or other network resources.

If an inline installation is the preferred method of deployment, a decision must be made regarding whether the sensor will continue to pass traffic in the event of a hardware or software failure, which may limit detection capabilities. This is often referred to as “fail open” or “fail closed.”

Choosing to fail open will continue to allow network traffic to pass through the sensor, minimizing downtime. However, this traffic is no longer being monitored by the intrusion detection engine.

In a fail closed configuration, the sensor stops passing traffic, which may result in a loss of access to the internet or other network resources but is considered the more secure option as there’s no gap in monitoring.

The other deployment method is a “passive” installation. In a passive configuration, the sensor is typically connected to the network using a management interface and an ingestion interface. The ingestion interface would be connected to a mirrored/SPAN port on a switch or firewall or through a network tap.

From there, a copy of the network traffic is sent to the sensor providing excellent visibility with minimal impact to the network itself.

To ensure maximum visibility, I recommend ingesting traffic from a core switch as it will capture traffic coming in and out of the network but will also see east-west traffic/lateral movement.

Endpoint

Capturing information and logs from endpoints on a network can provide excellent visibility into the security-related activity that may not generate suspicious network traffic. This is usually accomplished through the installation of a small agent on the endpoint(s).

In my experience, most major security breaches and/or ransomware attacks start with an attacker establishing local persistence on a server or workstation. From there, they’ll typically use tools like Wireshark to begin capturing network packets to obtain the domain admin credentials.

Wireshark is a packet capture tool that simply listens on the network, so it won’t generate any network activity, making it difficult to detect using a sensor alone.

With that, it’s important to have visibility into endpoint logs, which can be used to create alerts when a local account is created or when a local account gains elevated permissions.

I’m often asked if log collectors should be deployed to all endpoints. My response is always the same:

At a minimum, you should install the log collector agent on at least the Domain Controller(s) and any critical servers. However, in the event of a major security incident where you or a client must reach out to an insurance provider, third-party forensics company, and/or law-enforcement, at some point, they are going to need logs from all systems, not just the Domain Controllers.

With that, I always recommend deploying log collectors to all endpoints.

Firewalls/Network appliances

We can’t talk about network visibility without including firewalls and other network appliances such as switches, routers, and wireless access points. Thankfully, most of these devices provide syslog capabilities allowing you to collect and view this information within your SIEM solution.

Firewall logs, in particular, provide excellent visibility at the perimeter and, in many cases, may also include an Intrusion Prevention System (IPS) and web content information.

Cloud

With cloud services such as Microsoft 365 and G Suite becoming increasingly relied on for productivity, these services have also become a popular target for cybercriminals. With that, having visibility into these cloud tenants has become a key component to effective security monitoring.

Thankfully, many of these services do offer third-party log collection capabilities, typically facilitated through a cloud-to-cloud API or webhooks.

If you rely on a cloud service provider as part of your business operations and/or store any sensitive information within their infrastructure, I would recommend reaching out to the provider to find out more about their integration capabilities, particularly for log collection.

Ongoing monitoring and management

Deploying a comprehensive managed security solution is just the beginning. It’s important to have a process in place to ensure that there are no gaps in visibility due to any failure(s) with the equipment, agents, or integrations.

I typically suggest trying to automate the monitoring of your MDR and SIEM components as much as possible, which can be done through a combination of tools. In many cases, the MDR/SIEM solution will have its own utilities for monitoring itself. Still, you can also utilize other platforms such as Remote Monitoring & Management (RMM) platforms to provide alerting when certain MDR/SIEM services or data collectors stop working as intended.

Beyond automation, it’s also important to have internal processes that include a manual check of the critical MDR/SIEM components on a regular basis.

Reporting

Now that we have visibility into the network traffic, endpoints, and certain cloud services, it’s a good idea to have this information presented in an actionable way through regular reporting.

A fundamental cybersecurity best practice is to establish a baseline of expected network activity. I typically recommend having a report that will show network traffic, failed logins, and basic user account management over the past 24 hours. When reviewed daily, you’ll quickly establish what a normal day should look like, but more importantly, you’ll immediately know when something is out of the norm.

Wrapping it up

While there are many MDR and SIEM providers out there, regardless of which product/services you’re using, your goal should always be to gain maximum visibility. As we discussed, this starts with proper scoping/information gathering. From there, an effective deployment process, in addition to ongoing monitoring and reporting, will greatly help to create and maintain this visibility.

We'd love to hear your thoughts. Find us on Twitter, LinkedIn or write in to hello@perchsecurity.com

Next: Shifting gears: A cybersecurity journey for MSPs (Part 2)