What it SIEMs vs. What it is: Exploring the Commonalities and Differences between SIEM, MSSP, and MDR.
Adopting a new technology in the workplace can lead to major changes in policies and/or procedures. Adopting a new security technology is no different; no matter your choice, there will be benefits and downsides. And while the title might have been a punny stretch, I hope it led you to realize that this article is here to explore SIEMs, MSSPs, and MDRs so you can make your next security technology adoption an informed decision.
First, it would behoove us to have an equal understanding of what SIEM, MSSP, and MDR stand for. A SIEM system refers to a Security Incident and Event Management system. The primary purpose of a SIEM is to collect information in the form of system and network logs and aggregate that data to inform the user of incidents. MSSP stands for Managed Security Service Provider, which, as the name might suggest, is a means of outsourcing various security monitoring needs to another party. Finally, we come to MDR, which stands for Managed Detection and Response. From these brief descriptions, you may already be picking up on the primary differences between the three options. The most significant difference falls on the onus of responsibility to the organization that utilizes the option, requiring a bit more work for the adopting organization.
Security Incident and Event Management Systems
Starting with the SIEM system, this will likely be the most demanding to the client while also requiring the most knowledge to support. Operating a SIEM in your environment requires not only a general knowledge of the network, such as how systems communicate and how/where data is logged so that it can be pulled to the SIEM. The user also needs to understand what might be considered indicators of compromise on a network. Indicators of compromise come in various forms, some of which might look like regular or everyday activities. Some examples of the indicators are; multiple password failures, port scans, web crawling, etc. Just knowing the various indicators of compromise is not enough, however. To fully utilize the SIEM, a user will have to understand what data combinations would need to be present to suggest one of those indicators of compromise was occurring. Let's use the multiple password failures as an example. As an indicator of compromise, this may seem obvious; however, it comes with many questions. How many attempts is multiple? Do all of these attempts need to be for the same account? Does the account matter? The list could stretch on much longer than I'm willing to consider. Now, let's assume some responses to these questions. I'm just as guilty as the next person in fat fingering my password on occasion; however, that does not mean I'm guessing my password if I have to retype it once or twice; nor does it mean I'm trying to break into a system. This could also be someone who has learned my user name and decided it would be fun to log in as me to see what access they can get in the network. While this example could go on, the point is that while there are various alerts your SIEM provides, there are also countless questions and logic that are needed to filter them. This filter prevents the response team from being overburdened with alerts or chasing leads like Alice chased the white rabbit.
Managed Security Service Provider
Let's move on to MSSP or Managed Security Service Provider. As one might imagine, the MSSP will be less demanding than having your own SIEM to deal with, but that does not mean you hire someone to do the work and your plate is clean. With that, the MSSP you are opting to use may have a list of security options to choose for your organization. It'll be essential to understand these options and their uses. To me, MSSPs are akin to having lunch at a diner. First, you have to recognize your appetite. In the diner example, this could be related to what you had for breakfast that morning or what you're willing to spend to fill your belly. MSSPs will likely have a full menu of options for you to choose from, including not limited to: SIEM, Firewall, VPN, Anti-virus, etc. Now the reason I appreciate diners is because of the variety on the menu. Generally, they are written in ways most people can understand. The MSSP will be comparable to that menu, where they will have their suggestions but don't quite know what your taste buds can handle.
Purchasing your own SIEM might come with a lot of necessary knowledge; coming into an agreement with an MSSP will still require you to know a bit about the activity on your network and what you want to keep an eye on. Luckily, the MSSP is there to help you, and a reason for their existence is that some organizations don't have the time/knowledge/personnel to put in roles like SIEM management. Also, much like just having and running your own SIEM, MSSPs are going to focus more on the prevention side of network security, and much like a diner can serve you lunch, it is still up to you to chew and swallow.
Managed Detection and Response
Finally, we come to the MDR or Managed Detection and Response. I've seen other articles referencing MDRs as a sub-set of MSSPs, and while it may be, the MDR is going to take that subset and build on it by adding response actions to those malicious findings. The MSSP mentioned previously has a focus primarily on preventing disaster and recognizing compromise before it happens. An MDR, on the other hand, is intended to not only identify when bad things are happening but also assist with the response to ensure their client's network is safe and secure. In sticking with my analogous writer's mindset, consider an MDR comparable to that of using daycare or another form of child care provider, in particular infant care. There is a lot of responsibility when caring for infants. Similarly, the MDR will have a lot of responsibility in caring for its client organization. With childrearing, the caretaker is responsible for everything to do with that kid, from cooking and feeding to cleaning up the messes (both on and created by the child) because they cannot do it themselves. An MDR should be there for your organization to monitor the potential threats and help recover from when things get messy. To be clear, I'm not calling your organization childish if you decide an MDR is right for you; more they should be supportive to your organization like a parent/caregiver to a child because your organization may just not have the resources necessary to take on the role(s) and equipment that would be required to do it yourself.
To Recap
As you can tell, all three of the cybersecurity options that have been discussed in this article could be the right or wrong solution for your organization. When deciding which is correct, consider some of the following questions: Do we have the knowledge we need for this choice? Do we have the human bandwidth to dedicate? What are the up-front cost and what are recurring costs? Do we want to take on responsibility? Do we trust the provider? Who are some of the provider's other clients? What is the provider's reputation? How does this impact our cyber insurance, or how does our cyber insurance impact this decision? The final suggested question, referring to cyber insurance, will likely have a broad impact no matter which decision you make and will likely include actions your organization is or is not allowed to take at the detection and onset of a cyber-attack. For more information on cyber insurance, please refer to our article, Cybersecurity Insurance – Another tool in your risk management strategy.
