From my Gartner Blog - SIEM, Detection & Response: Build or Buy?
As Anton already blogged (many times) and twitted about, we are working to refresh some of our SIEM research and also on a new document about SaaS SIEM. This specific one has triggered some interesting conversations about who buy services and who buy products, and how that decision is usually made.
There are usually some shortcuts to find out if the organization should look, for example, for a MDR service or for a SIEM (and related processes and team to manage/use it). They are usually related to the organization’s preference for relying on external parties or doing things internally, the availability of resources to manage and operate technology or some weird accounting strategy that moves the needle towards capital investments or operational expenses. But what if there’s no shortcut? What if there’s really no preference for either path, how should an organization decide if it should rely on services for threat detection and response, or if it should build those capabilities internally? Making things more complicated, what if the answer is a bit of each, how to define the right mix?
Initially I can see a few factors as key points for that decision:
Cost – What option would be cheaper?
Flexibility – Which option would give me more freedom to change direction, put less restrictions on how things could/should be done?
Control – Which option gives me more control over the outcome and results?
Effectiveness – Which option will provide me, for lack of a better word, “better” threat detection / response capabilities?
Time to value – Which option can be implemented and provide value faster?
(Yes, there are other factors, including the security of your own data, but many times those factors end up in the “shortcuts” category above. Stuff like “we don’t put our stuff in the cloud”; makes the decision really easy, but that’s not the point here.)
Some of these factors have clear winners: time to value is almost always better with services, while doing everything yourself will obviously give you more control than any type of service.
Flexibility is more contentious. Services will be less flexible as no service provider (apart from pure staff augmentation) will give you the option to define how every piece of the puzzle should work. However, building things and hiring people will often freeze your resources more than just paying a services monthly bill. If you build everything in a certain way and then decide to change everything, you’ll probably have to pay some things twice. Moving from one service provider to another can be easier when contracts are made for flexibility.
And what about the last point, which model will provide the best results? If you are a Fortune 100 company, you’ll probably be in a position, in terms of resources, context and requirements, to build something that will be better than any service provider will be able to do for you. But if you’re not in that category, the best service providers will probably be able to give you better capabilities that you would be able to build AND maintain; just think about the challenge of keeping a very good and motivated team for more than a few months!
A simple framework for deciding between outsourcing or building in house could just look at those 5 factors, but you didn’t think the problem was that easy, right? Because the decision IS NOT BINARY! Today you can fully outsource your security operations, outsource some processes or even keep processes and people and rely on tools provided in a SaaS model. The number of questions to ask yourself and factors to consider grows exponentially.
For now we are just looking at a very specific outsourcing point, the SIEM as a tool. We hope to build some type of decision framework as one of the outcomes of our current research, but I’d like to revisit the broader problem in the future. And you, how did you decide between build or buy your detection and response capabilities?
The post SIEM, Detection & Response: Build or Buy? appeared first on Augusto Barros.
from Augusto Barros http://ift.tt/2w4FzpU
via IFTTT