Solving Log Storage: How You Can Save Money and Meet Compliance Requirements - Security Boulevard

SBN Solving Log Storage: How You Can Save Money and Meet Compliance Requirements

Logs. At best: They’re a vital part of your information security strategy to “find the bad.” At worst: They’re a nightmare to manage — especially when they take up so much storage space! Of course, we all have numerous regulations to thank for the privilege of storing our logs for what seems like eternity. Perhaps you’re bound to regulations or frameworks such as PCI (one year minimum), HIPAA (open to interpretation, but many suggest 6 YEARS to be safe), NIST, COBIT, and so many others.

FinConDX 2021

Whatever your reasons are, logs have become increasingly problematic as more and more data sources require a higher volume of storage.


This all hits a little too close to home. Recently, one of Preempt’s customers had a situation where they were storing several hundred gigabytes of logs per day thanks to the State of New York’s 23 NYCRR 500 Regulation. According to Section 500.06(2)(b) Audit Trail, “Each Covered Entity shall maintain records required by section 500.06(a)(1) of this Part for not fewer than five years and shall maintain records required by section 500.06(a)(2) of this Part for not fewer than three years.”

Add up hundreds of gigabytes per day over at least three years, and you’re suddenly spending a very large amount of money just to store these logs. The main issue that our customer faced was how large the Windows Event ID 4624 logs were, especially the Type 3 login logs (network logons). These logs were expensive to maintain and a headache to manage. 

As a result, our customer needed a better solution to storing and maintaining their logs. Preempt was able to help this in this scenario by offering a much smaller, compressed version of those logs that were both compliant to regulations as well as easily accessible and reviewable. In this scenario, our customer spent time reviewing the same 4624 Type 3 events in Preempt and ultimately decided they could keep the Preempt logs instead, which are much smaller in size.

By choosing Preempt’s logs, our customer was exporting around 2 GB per day of compressed Preempt logs, saving hundreds of gigabytes of storage and storage costs per day!

Depending on your requirements and regulations, the approach that Preempt offered might not be applicable ubiquitously, and we encourage you to review this approach with your legal and audit teams before implementing. However, given that organizations are both conscientious about their security spend as well as lacking in enough security talent to manage theses logs, Preempt’s lighter approach provides a clear and better solution to log management and storage.  

Reducing the storage costs is critical, but not the only thing that you need to do when managing logs: The other key component is security. 

The reason why you need to maintain logs is so that your SOC team can reference and review them when they are investigating a security incident. However, reviewing logs in the aftermath of a security alert can be overwhelming depending on how many incidents are reported. Even the most sophisticated SOC teams have a limit on how many incidents they can handle in one day.

This is where Preempt can help. Not only does Preempt compress your logs, Preempt can provide an easy and continuous security assessment that helps review many security flaws like privileged access abuse, weak AD configurations, compromised passwords, and more. By providing easy insight into your security hygiene, Preempt gives SOC teams the actionable insights needed to reduce risk and pass your next audit.

In the end, Preempt was able to help our customer solve a storage issue, while also providing value with instant insight into their log history and ways to improve their security hygiene. 

To learn more, please visit our product page or contact us at [email protected].

*** This is a Security Bloggers Network syndicated blog from Preempt Blog authored by Jason Luttrell. Read the original post at: