Forrester TEI Report – Microsoft Azure Sentinel

Last month, Forrester released a Total Economic Impact (TEI) research document which revealed significant cost savings and business benefits associated with using Microsoft Azure Sentinel. To be clear – it revealed those benefits when the users switched from an existing traditional SIEM or “SIEM-like” (whatever that is) logging and correlation infrastructure. There are a lot of people considering doing just that at the moment and so the report is timely. As a pioneering provider of managed security services based on Sentinel we have, of course, analysed the report ourselves to see if we can match the Forrester findings to our own experience.

In the interests of equality, I should say that Microsoft commissioned the TEI report from Forrester, which is pretty standard – someone has to pay for the work – and told them which customers to talk to so, as with everything, it is possible to see the hidden hand of manipulation if you really want to, but I’ve never come across a customer who would publicly make stuff up to keep a vendor happy, let alone several of them all on the same topic. Yes, Microsoft may have been so pleased with itself that it asked a research company to validate its figures and even pointed them at their proudest handiwork to examine, but that doesn’t change the fact that switching to Azure Sentinel really delivered for these customers, as it could for anyone.

Some of the numbers are jaw-dropping even in an industry which thrives on big numbers:

  • 201% ROI
  • 79% reduction in false positives
  • 48% cheaper than traditional SIEM
  • Payback in less than 6 months

As a renowned sceptic, if we weren’t seeing benefits for our Sentinel customers on a similar level, this would have been a very different document – it just seems too good to be true.

It is not though. All Microsoft has done is shake up an industry which has been largely glacial in its pace of development for a long time. SIEM platforms which are costed and licensed by Events Per Second (EPS) are expensive, so Microsoft started out by making their product licensing itself cheap, or sometimes free. Obviously, it is a business model which only works if you have a huge SaaS infrastructure already on which to run it – slight barrier to entry there for most other vendors. Microsoft also made sure that the Azure Sentinel product is good, and that is a key thing – simply cheap is not going to cut it, as we all know from the days when Defender was a means of slowing a PC down rather than protecting it. Customers have built complex, customised and optimised SIEM platforms on Splunk, QRadar, LogRhythm et al over many years and as a provider we can attest to the blood, sweat and tears that have been poured into making something like an efficient security tool emerge from the components. That is before we talk about the sheer volume of high-performance equipment you need to maintain for an on-premise SIEM solution, and the potentially vast storage requirements.

The thing about SIEM, of any kind, is that the volume of traffic and processing is by its very nature highly changeable. It can be predictable, but then anything is predictable – it is the accuracy of those predictions which matter, and you can only truly get confident with your annual budgeting for EPS licensing and supporting hardware and storage as the years of use roll by. The truthful answer to the “how many EPS are you going to need next year?” question is, “enough to support the number of events we have.” How many events will you have? Well, that’s easy, how many things are going to happen? It is not an exact science. In fact, if you looked up “exact science” it should say, “not SIEM sizing”.

Microsoft have not fixed this. Other than selling the service at a fixed price regardless of consumption, nobody is going to fix this. However, what Microsoft has done is enable the more accurate prediction of the volume of storage you are likely to need via their own tools and by enabling organisations like ITC to carry out estate audits and ROI reviews by making as much of their current consumption data as possible available to us. Microsoft have focused the variable costs in one area – the volume of data processed by Sentinel and the security stack – not the volume ingested. This means that we, and our customers, can have a very real, and very immediate impact on costs by tuning which logs are processed and optimising false-positive handling and processing tasks. Another number, this one from us; ITC has, overall, reduced the initial Microsoft Sentinel processing charges for customers implementing Sentinel as part of our managed service by 15% from month one to month three. This without any loss of fidelity and while still, in most cases, rolling out additional log sources for ingestion.

Customers can scale their utilisation, and therefore their costs, at will. It has always been easy to scale up, even with a traditional SIEM – but turning the costs down is much harder to make work, but our experience is that it’s not only possible with Sentinel, it’s become part of BAU.

We can also substantiate the claim from the Forrester document that SOC analyst time is used more efficiently. Forrester put a figure on it of a 56% gain. I have no idea how we would arrive at a number which meant anything for our own SOC, but I do know that our analysts spend much less time dealing with erroneous alerts, false positives or things that should be easily automated than they did using a traditional SIEM. We, and our customers, are seeing the benefits of that in terms of more access to our senior men and women and more time for them to focus on alerts which really need attention, optimisation and, crucially, threat hunting. One of the key tasks of any SOC is to go looking for trouble on our customer’s estates – you cannot work from the assumption that bad things will bring attention to themselves – and we tangibly have significantly more time to do this now. The ease of integrating applications like CRMs, CMDBs and ticketing systems has also been a revelation. The rapidly growing volume of native connectors available to us from Microsoft have made projects we would expect to take weeks, like automatic two-way ticket updates, over and done with in half a day.

A key ITC metric is the implementation time of Sentinel compared to other SIEMS. The on-boarding segments of our projects have gone from, on average, 3 weeks, to 2 days, and we are getting this even tighter with every one we do. The time to effectiveness of a new tool is crucial if you are going to see any ROI in year one of ownership, and we’re seeing customers up and running, with useful information on their screens or in their inboxes, literally in hours.

The number and variety of log sources available off the shelf for integration into Sentinel is also impressive and growing fast. We come across fewer and fewer sources for which we need to write something custom, or default to ingesting raw syslog for, as adoption grows.

Obviously, there are some technical benefits of using a Microsoft SIEM platform when connecting your Microsoft log sources, but the sheer ease of integration between Sentinel and Defender and Office365, for example is remarkable, as is the immediate richness of the data and the value of what the SOC analysts are seeing on their screens.

Of course, it is not all roses. Sentinel has it’s share of foibles and we still have to put in the overtime for those truly tricky integrations – in-house applications and heavily customised operating systems for example – but it’s all, so far, been eminently achievable and the support from the vast community of Microsoft security people is accessible and immediate.

In the service provider industry, one of the most obvious but sometimes overlooked indicators of what you should be taking to market is to find out what your customers are interested in. Sounds simple, but we are guilty, as an industry, of sometimes focusing on the novel – finding cutting edge and exciting products which promise radical improvements in security or solve problems the customer didn’t know they had until you tell them.

It is refreshing, therefore, to be aligned with something which is creating a real, customer led buzz in the security community. We are having lots of conversations about Sentinel with lots of customers from all sectors. Partly that’s down to the marketing efforts of the Microsoft colossus, but I’ve yet to see a compelling Microsoft advert for anything and it isn’t just that – Sentinel works. It takes a perennial problem – how to collect billions of events from thousands of sources and make them tell us something useful – and makes it accessible at scale. It’s also accessible and arguably even more useful if you have a very small IT estate and use a couple of SaaS services. This is a market segment traditional SIEM struggled to cope with, it being too small to work economically – but we have all sorts of shapes and sizes reaping visibility benefits from Sentinel now, from the smallest of start-ups to the largest of enterprises, public sector organisations and everything in between.

I am aware that I sound like a Redmond fan boy, but I’m really not. There are plenty of things I think Microsoft still needs to improve. Their licensing, for example, can be as impenetrable as a GCHQ cryptography challenge – and there will always be products which are further up and right in standalone tests – but the combined package of Sentinel on top of Azure infrastructure, with Defender, Office365 and Windows integration is, in my view, the new standard in the SIEM world.

I fully expect there to be challengers in 2021 – Google and Amazon, to name but two (imagine the power of Google search for threat hunting among unstructured data). But for the completeness of its integration, ease of delivery and reduced implementation and running costs, the Sentinel story is going to take some beating.

For once we appear to have an answer to the perennial question, “can you make it better and cheaper?”.