The traditional architecture for SIEMs puts all hardware and software on premises at your organization, and your organization's staff is fully responsible for monitoring and administering the SIEM. Today, many other arrangements are possible, all of which involve your organization and one or more third parties sharing SIEM responsibilities.
What's come to be known as SIEM as a service is when a managed security services provider assumes some or all of the responsibility for your organization's SIEM monitoring and administration. Another form, cloud-based SIEM, is when some or all of the SIEM hardware and software are hosted in the cloud instead of on premises.
SIEM as a service, cloud SIEM or something else?
In reality, many organizations use combinations of these, handling some services themselves and outsourcing some and hosting some hardware and software themselves and using cloud-based services for others. The terms themselves aren't important; what's important is knowing these options exist and understanding their advantages and pitfalls so you can choose the arrangement that's best for your organization's needs and requirements.
There are some key things to keep in mind when evaluating SIEM as a service or cloud options:
- Using external personnel can save money and improve the speed and accuracy of incident detection. This is especially helpful for smaller organizations that don't have their own around-the-clock SIEM analysts. Outsourcing SIEM monitoring and analysis may actually save money because the outsourcer can have a relatively small number of people monitoring SIEMs for numerous customers simultaneously. Also, a service provider can recognize patterns across customers and use knowledge of attacks on one customer to better protect other customers immediately.
- SIEM bandwidth and data-storage requirements are increasingly important and challenging to meet. Organizations already have more distributed computing operations than they used to, with many services and applications hosted in different clouds. To correlate events across hosts and get the big picture, the vast amount of security event data needs to be pulled together in one location, and that requires bandwidth and storage. Ultimately, it may not be feasible to do that for all data. Instead, it may be necessary to have a tiered SIEM, with parts of the data collection and analysis occurring in numerous locations and a higher-level SIEM collecting certain data from the rest for further analysis. However, the longer it takes to bring data together, the more delayed incident detection and response actions will be too.
- There may be major issues with trust when responsibilities are shared. Suppose that an external provider is hosting your SIEM data in the cloud. In which countries or local jurisdictions are those cloud servers located? Your data is subject to the security and privacy laws in those places, and you may not be aware of that. There are also insider threat issues. A provider of SIEM as a service might detect a data breach and reveal that information to unauthorized parties, or they might access and misuse sensitive data like passwords inadvertently captured by your SIEM. There are also authority issues to consider, such as giving a third party the ability to automatically reconfigure some of your own security controls.
All these issues should be considered together as part of considering SIEM as a service, and they should guide your determinations about how to architect and staff your SIEM implementation.