The past 5 years or so have brought many Managed Security Services Provider (MSSP) offerings into the market place.  This is for a variety of reasons, the most significant is that a managed service brings in Monthly Recurring Revenue (MRR) which allows the provider the ability to forecast income more reliably.  Other reasons are that there is a talent shortage in the security space and the cost of starting and running a team internally is significant and may not be warranted for your business.

The market for security services includes offerings that run the range of Managed Firewall, Managed IDS/IPS, Managed Identity and Access Management, and others.  We are going to focus on the segment of the market that provides Security Incident and Event Monitoring (SIEM) as a service for this article.  The goal here is to allow you to understand and evaluate what a provider is going to do and whether it fits your particular needs and set of expectations.

SIEM Technology

There are many commercial and open source SIEM solutions that are available.  Most of them operate as follows: A monitored system generates a piece of data like a syslog or event log which gets sent to the SIEM.  The SIEM gathers hundreds to millions of these events per day and then uses some logic in the background to create alerts.  These alerts may be limited to a single technology, such as a firewall that has seen thousands of port scans from some offending IP address and creates an alarm. Another scenario is an alarm that is created due to correlated events from multiple monitored systems.  This could be something like an external SSH server that is under a brute force attack that suddenly has a successful login and then that machine running the SSH service starts scanning others within your environment. 

The overall goal is to collect enough information within your environment to be able to detect when an attack is occurring and hopefully stop it.  The logic and correlation that is allowing this to happen varies slightly from SIEM to SIEM, but the idea is the same.  It is important to note that many SIEM solutions ship with much of this logic missing and it is up to the end user to create it or buy it as an add on. If you are using an MSSP this would be their problem to solve. Your problem would be to make sure that their use cases to detect events meet your technology stack and needs.

What Can Be Monitored

The coolest part of a SIEM is that it can consume logs and events from nearly any type of technology.  Typical sources would be Microsoft Windows, Linux, Databases, Web Servers, Firewalls, IDS, IPS, endpoint protection tools, and list goes on.  Some more novel sources could include physical security devices like card reader systems, wireless access points to measure device geolocation, IOT devices, and just about anything that can send event or log data.  While this all sounds great, the issue is that as you collect more log sources, you have a massive increase in overhead for storage, bandwidth, and processing requirements. Collecting everything seems like its going to be great until you have to pay for it.  If you have ever been to a candy store where you pay by the pound with an 8 year old, you may have experienced something similar.

This leads to the question: What should we monitor?  Ideally you monitor everything.  And since that leads to the having to pay for it problem, we will need to narrow it down.

The first place to start is with the inventory of all of the applications and systems that you run your organization on. If you don’t have that, please refer to the first requirement of nearly every IT Security framework ever written.  All jokes aside, the point here is that we need to decide what is critical to our business and then include that on the list.  Understanding your organizations mission is important here.  I have worked with companies that have a successful food manufacturing business, but when looked at closer, they are really a trucking and logistics company and their critical technologies support that. It is these applications that need to be identified and put on the list.  If you aren’t sure if an application is critical, unplug it from the network.  Someone will make sure you are aware of how important it is.  (Do not do this, or at least do not credit me for it.)

The next step is to understand what technologies are used to provide those critical services or applications and that they be monitored through the technology stack.  This is where many MSSP offerings fail. If you have an eCommerce web application that runs on two operating systems, an application server, and a database for instance, then you need an MSSP that can monitor all of these things. This might be Microsoft Windows Event Logs, Red Hat Linux syslog, SQL database logs, Microsoft IIS Logs, endpoint protection logs, Web Application Firewall logs, and the networking devices in between your customer and the application.  Many MSSP offerings only monitor the IDS/IPS/Firewall logs in this scenario which is a very network centric view and misses a lot of useful data and allow an attack or exfiltration of data to go unnoticed.  It is your responsibility to understand what is in your environment to create an apples to apples comparison of MSSP offerings.

Setting Expectations

I don’t want to delve too much farther into the functionality of a SIEM since most likely if you are reading this, your goal is to hire someone to deal with it.  The goal from here on out is to prepare you to evaluate a prospective MSSP or your current provider and make sure your expectations are met with their service.

Start with the list of critical applications we mentioned above.  Then identify all of the components that make up that application along with any useful security tools that provide detection capabilities.  Next you are going want to consider what I will call “points of aggregation” which are systems that protect or enforce security controls for many systems.  This will include firewall, IDS, IPS, Endpoint Protection Consoles, cloud provisioned security tools, syslog servers, web proxies, and any other system that could be monitored by a person to detect a security event.  Also, if these systems or tools run on a full blown operating system, then that should be included as well. Here is a quick summary:

1. List Critical Applications and Business Process
2. Identify all systems that support them
3. Identify “points of aggregation” such as firewall, IDS, IPS, and endpoint protection consoles
4. Submit this list to your MSSP

Next you should compile a list of the types of events or attacks that you expect your MSSP to detect.  Some simple searching yields a quick, and certainly not comprehensive, list:

1. Ransomware Attack
2. Social Engineering or Phishing Attack
3. Denial of Service/Distributed Denial of Service Attack
4. Traditional Virus/ Malware Event
5. Brute Force Attacks
6. Web Application Attacks (Cross Site Scripting, Cross Site Forgery Request, SQL Injection)

Once you have this list then you can ask your provider if they detect these types of events, how they detect them, and give you some examples of when they last saw them.  It is also important to ask for examples of notifications and reports.

MSSP Customer Service

If you feel that the MSSP is checking all the boxes so far, then the next part is to understand how you will interact with them.  There is no wrong or right here, it really depends on what you want as a customer.  If you just want email or phone notification of an attack, then make sure that is included.  If your expectation is that the MSSP will notify you, open up a conference bridge and guide you through remediation, then document it in the Service Level Agreement.

I have been a part of the conversation from both the provider side and the consumer side. When it comes to and managed services, setting and meeting expectations needs to occur early and with lots of clear communication.  Many times, a customer will expect an MSSP to log into the environment and make changes to fix whatever needs fixing. While it sounds great, there are some risks inherent to allowing a third party into your environment.  These risks range from unmanaged administrator account access to not having enough knowledge of your environment to make changes without impacting other services.  If you require a full service MSSP, make sure you have found a reputable company that has the talent on staff to competently manage your technology stack.

The last point I will hit on here is making sure that even if there are no major security events that you have some cadence of meetings with your MSSP to make sure things are running smoothly.   While at a previous role, we had a major security incident and contacted the MSSP (a very large MSSP) for help only to find out that the monitoring solution had been down for months.  Ask to see regular reports that outline what has happened over the past weeks/months/year.  See if you have access to a reporting system that allows you to pull reports when you need them. If you are in the buying phase, ask to see a de-identified report from the last week or so.

Summary

When selecting an MSSP you need to understand enough about your environment to make sure that the service meets your needs.  You need to do some basic education and then ask the MSSP the right questions to ensure that you are getting the value that you are expecting, and that the MSSP has the opportunity to address and meet expectations from inception.  Ideally it would be a simple ‘set-and-forget’ situation, but as we all know that with technology, it rarely is.