"It's too bad I am not building an open-source SIEM … but if I would" (extra credit: guess the inspiration for this line), I would actually not build a software security information and event management (SIEM) product.
If I were doing it (and I am not!), I’d built an open-source-based “cloud SIEM” with a default option to have it hosted by the vendor (that is you) as well as with a possibility to have it hosted by the customer (that is, old school on-premise model). The latter option would give you a classic open source “product.”
Think about it! If you are a new company, you cannot afford to be in the appliance business. That leaves two choices: software and SaaS. If you want to sell software, you are probably insane, go lock yourself up :-) If you want to give away software and sell services, you are OK. But won’t SaaS be better? And you can combine it with on-prem model, if some folks insist. My recent employment made me quite SaaS-obsessed, since I had a chance to observe an excellent SaaS operation from the inside. It was amazing how easy it is to provision trials as well deploy the service in production, track usage and improve customer experience.
But let’s take a step back first! A lot of folks try to understand the relationship between “open source” and “cloud everything” (discussions about their relationship here, here, here and obviously here). The main idea here is the following: if people have “trust issues” with cloud providers, what is a better “mistrust breaker” than showing the source code for your solution? “Wonna audit?” - “Knock yourself out!” Moreover, if people have “hidden costs issues” with open source software, what is a better way to mitigate it but to offer to run it for them? No hidden costs, not even electricity…
So, if you are possessed by SIEM aspirations (and I am not!), head to the clouds. For starters, your tool will be easier to deploy and update. But what is much more important, you’d take a fare shot at solving scalability problems without being a database tuning uber-guru. Unlike early software SIEM vendors (FAIL!), you won’t have to sheepishly point in the direction of mammoth Sun boxes, you’d just fire up another EC2 instance (or a thousand). Moreover, on the scalability front, you’d have a fare shot against established SIEM vendors: I often hear rumors that even today, in the age of “cheap hardware”, some large organizations with loads of log data simply cannot architect a SIEM to handle all their security log data. And cloud computing leads to affordable scalability!
Solving these performance problems will let you use the CPU resources for log data parsing, correlation, stored data analysis and all sorts of other fun stuff. Storage, whether raw text or parsed data, will be even easier. Bandwidth will be a bit tricky, but I am leaving it out of this piece for a particular reason … don’t want to spill too much (I am leaving “the collection challenge” out as well).
Finally, as cloud applications [as well as web applications, in general] grow in importance, the whole idea of “SIEM in the cloud for the cloud” won’t be as naive. As we know, the need for auditing comes last (here), but when it does come, it will come in force and both SMBs and F2000s will have this problem. And it never hurts to be better prepared for the death of on-prem apps, if we are to believe certain visionaries.
So, throw together some EC2 magic, some database code and a sleek, well-designed UI to delight the users – and you are ready to do battle with foes 10x your size…
Any thoughts?
Possibly related posts:
Obligatory “added everywhere” posts :-)
- I am not at Qualys anymore and looking for the next big security idea to work on! Meanwhile, I might be available for fun consulting projects related to PCI, log management or other fun security things.
