Last year’s SolarWinds attack and its aftermath have provided numerous lessons concerning the dangers of IT supply chain attacks. Not all apply to every small and medium-sized business—most are unlikely to be targeted by highly trained state-backed hackers with virtually limitless funding—but some will be.

We learned, for instance, that even IT pros could use a refresher on basic password hygiene through security awareness training. A more substantive lesson is the importance of defense in depth, an approach that prioritizes mutually reinforcing layers of security.

In the case of SolarWinds, the Trojanized Orion update was able to elude endpoint security because it was issued by such a trusted source. As we’ve discussed, however, the damage from the compromise could have been limited significantly by using a defense in depth approach backed by leading threat intelligence.

A firewall with the right threat intelligence embedded could have blocked communications with the command-and-control server thus preventing a Trojanized Orion install from connecting back to the attackers and stopping them from furthering the attack. An endpoint DNS solution could have stopped the Trojanized Orion version by refusing to resolve the domain names of the command-and-control servers, again disrupting the infection to the point that no real damage could be done.

This is what we mean when we stress the importance of a layered defense. Take a hypothetical scenario in which the opposite happens, for example. A zero-day threat with no known connection to malicious IPs, files, or other data objects may not be known to the threat intelligence feed informing a network security solution. Once it has made its way to the endpoint, however, it begins to engage in behaviors known to be malicious. Examples include elevating privileges, moving laterally, or trying to establish outbound communications to name a few.

In this case, it is the endpoint security solution’s turn to save the day. If equipped with a rollback or remediation feature, endpoint solutions can not only stop the activity but also remediate the damage already done. These two layers work in concert to pick up the slack left by the other, helping organizations remain resilient against different types of attacks.

Remote work threatens defense in depth

Most larger organizations and a growing number of smaller ones have caught on to the need for layering endpoint and network protection. Firewalls embed threat intelligence and DNS security solutions are used to both block malware and control internet use. But recent events have worked to undermine this growing understanding.

Remote work exploded in 2020 with the advent of COVID-19, rapidly ushering in a new way of working before all of the security details could really be worked out. This presents a new set of stubborn challenges for IT security admins that’s not likely to fade soon. Outside of the corporate firewall, it is the Wild West. Every employee’s home network has a different set of security protocols and internet use is unregulated.

Webroot’s report on COVID-19 work habits found that three out of four people (76%) worldwide admit they use personal devices for work tasks, use work devices for personal tasks, or both. The 2020 Webroot Threat Report also found that personal devices were about twice as likely to encounter a malware infection as business devices. Together these numbers suggest a significant security threat for companies with remote workers.

DNS security solutions are one way of addressing this risk. Installed as an agent on each corporate endpoint, they route traffic through protected DNS servers that can identify, stop and disrupt communications threats. Of course, personal device use still represents a problem for companies not enforcing strict policies against their use. Nevertheless, DNS security remains a way to protect business-issued devices beyond the company network.   

The “next one” will look different

Focusing solely on how the SolarWinds attack is not the key to preventing future breaches. The next large supply chain attack will likely look very different than the SolarWinds attack. In fact, other than the infamous CC Cleaner hack of 2017, in which more than 2.3 million users of the computer cleanup software were duped into downloading malware onto their own machines, these types of attacks leveraging trusted but Trojanized updates are relatively rare.

But this fact makes defense in depth more critical, not less. Zero days will continue to be encountered. There is no telling which techniques the next one will employ, so it is important to make use of multiple tools to limit potential damage.

Cybercriminals will continue to undermine individual defenses. Smart organizations will hedge their cybersecurity bets so they are not all overcome at one time.

Every device on an MSP’s managed network provides insight into what’s happening on that network. This includes network routers, switches, printers, wireless devices to servers, endpoints, IoT devices and everything else connected to the network. Each creates a log in its own format, or syntax, that a technician can review for troubleshooting, configuration confirmation, the creation of specific alerts based on a device’s activity or a host of other reasons. These records of each devices’ activities are known as syslogs.

Syslogs present information in a variety of ways, including custom formatting, industry-standard formatting, even raw data lacking a consistent format. The good news is that any activity requiring a security review is buried somewhere in these syslogs. The bad news is that data can buried in these syslogs.

Whole mountain ranges of information are regularly processed by these systems. Millions upon millions of data points may be present, making the set overwhelmingly confusing. At best, sorting meaningful information from noise is a daunting task, even for well-staffed IT departments.

Fortunately for security professionals—and more specifically for MSPs and MSSPs focused on providing insight into their managed networks—there is a mature product category that can be incorporated into their technology stack to help. Security information event management (SIEM) solutions have existed for years, but they’ve recently been gaining traction among MSPs and MSSPs. For good reason: knowledge of a network’s activity is essential to protecting it.

Is setting up a SIEM worth the cost and effort for an MSP?

The short answer is: YES. If you want to synthesize information from various sources to determine if a security event has or is taking place on a customer network, then yes, a SIEM is the natural evolution of the MSP security stack.

The longer answer is, well, longer. Let’s break out a couple of options for those interested in establishing a more sophisticated security information and event management solution.

SIM, SEM or SIEM? That’s the question to begin with. While security information management (SIM) and security event management (SEM) solutions have been in place for some time, they’re now commonly combined into the offering referred to as a SIEM.

So, where does an MSP get started? There are three common choices for getting a SIEM stood up and configured:

• On-premise – Stand up a server, add some software (a bunch, actually), point all the syslogs to the device and get started. Easy, right? In reality, on-premise solutions have a higher cost and can be daunting to get started. Software costs range based upon the solution provider’s model. But if control and compliance are important, on-premise solutions may be a great option.
• Cloud-based – Any one of a number of existing solutions that cater to MSPs are simpler to get started. The challenge with cloud-based solutions entails pulling data from many sources and pushing it through firewalls and networks to a public cloud solution.
• Hybrid – As its name implies, some options blend cloud-based solutions with a local collection server to gather information and push a single source, securely, to the cloud for analysis and processing.

Feeding your SIEM a healthy diet of data

Before deciding on a SIEM component, a log collection or data collection solution must be set up to feed it. Syslog collection refers to a number of different activities, but in a SIEM or security-specific sense it usually comes down to what makes the most sense for the application: purpose-built or generic.

• A syslog aggregator or log collector – These are devices that take in all syslog information from all devices. They range from sophisticated solutions with alerting and performance reviews to feeds that simply “normalize” the data, distilling the most relevant input and then reworking the details into a consistent standard and reporting on the highlights.
• Syslog bridges – These are more generic solutions that act mostly as log collectors. Simply point devices to this collector and it maps the data.
• Syslog collector – These are generic log collectors much like a bridges, but they usually provide a little more intelligence, cost more, and often serve multiple purposes like performance, device status and security event reporting.

Log gathering is the most misunderstood aspect of a SIEM and is often overlooked. The key is finding the most appropriate strategy for your needs.

For most MSPs, a basic bridge with a specific security purpose for feeding a SIEM may be the most efficient and cost-effective option. For additional needs like performance or status determinations, a more sophisticated syslog may be good. But most performance and status information is already provided by RMM solutions, so why reinvent the wheel?

What to expect from your SIEM

After deciding on a syslog collector and SIEM setup, it’s time to put the SIEM to work parsing data and making sense of the output. This is the intel that allow technicians to make sound decisions regarding security events.

Which SIEM to incorporate into a given MSPs operations depends on the level of services offered. MSPs building out a SOC or offering managed detection and response (MDR) services may require more sophisticated output from their SIEM. MSPs simply looking to distill information for their respective technical teams to analyze and make security decisions can usually rely on tailored, cloud-based solutions.

Regardless of the provider, a SIEMs should at least do the following:

• Perform log gathering – If log gathering is not directly accounted for by a SIEM, another solution will be necessary for feeding data to it.
• Correlate security events – To spot security threats that may be spread across a network, not only native to a single device’s syslog, a SIEM must be able to track data across multiple devices.
• Connect to threat intelligence feeds – To keep up with a rapidly shifting threat landscape (and therefore useful to preventing attacks) it must be informed by strong threat intelligence feeds, preferably those using machine learning to recognize even zero-day threats.
• Issue security alerts – A key SIEM benefit is the ability to provide timely alerts regarding security events based on large amounts of data to assist with decision making, making it possible to stop attacks before they develop
• Present reports – Many SIEMs can produce reports in a cadence that makes sense for an MSP or MSSP depending on their needs and the needs of their clients.
• Enhance compliance – Because SIEMs aggregate information on a network, it can produce compliance reports for clients based on industry-specific needs.

A good SIEM solution can minimize technician workload and minimize manual data interpretation. It also benefits clients by beefing up your own security capabilities. A SIEM is a natural step for any growing MSP’s looking to provide the best security solution for customers with workable margins.

With a little focus, it shouldn’t take months or an act of congress to setup and use a SIEM. The above guidance should enable any MSP, regardless of size, to devise a viable plan for putting one in place.