Azure Sentinel: Storage & design considerations

[David Caddick]

Hi All,

Some thoughts on storage & cost from the customer perspective...

• In the same way that the LA Design has been answered here:
• https://techcommunity.microsoft.com/t5/Azure-Sentinel/Best-practices-for-designing-an-Azure-Sentinel...

In a recent example where we had enabled a number of firewall and proxy connectors we were quickly looking at 80 - 100Gb a day that was going to translate into AUD$10K a month based on only a 30 day retention period - this was going to be quite an impact on the cost of the PoC - but it also caused the Customer to have some reservations on whether or not to move forward with Sentinel based on unknown costs from Microsft + Storage costs...

Is it possible to get similar ideas from a Storage perspective of how this *should* be designed?

Some initial thoughts are:

• Office ATP – use free storage, just direct Alerts only to Sentinel
• Azure ATP – use free storage, just direct Alerts only to Sentinel
• Defender ATP – use free storage, just direct Alerts only to Sentinel
• Bluecoat - direct connector only to MCAS
• Palo Alto - direct connector only to MCAS
• Cisco ASA - direct connector only to MCAS
• MCAS - just direct Alerts only to Sentinel

On the surface of it, this would likely reduce the storage needs in Sentinel, however it’s also likely that this will also reduce it’s effectiveness due to less data points and telemetry?

It will also mean that any analyst will then have to fall back to jumping between consoles?

Any thoughts or feedback welcome 

[#2]

@David Caddick 

Understand the concerns.  Pricing will be available at GA which should hopefully clear this up a bit.  For PoCs it really depends.  The customer should define use cases/requirements they need to confirm the product does to move forward.  that might require ingesting all FW logs and be more expensive, then say ingest only the Free O365 logs.  each customer is different.

I agree with alerts from the Microsoft solutions.  besides Office all security products are alerts only (minus MCAS shadow it).  but i would not agree with sending FW/proxy logs to just MCAS.  for example, we have alerts that are built for FW and proxy logs.  you would be possibly limiting what you can detect in your environment.  or correlating alerts from those systems with alerts from other systems.