Security Information and Event Management, or SIEM, is worthless unless you are precise in your data collection. The old adage, garbage-in garbage-out, or GIGO, continues to hold true. Successful SIEM deployments are built on rock solid log management and real-time transport. What do we mean by “rock solid logging”? It means you are efficiently collecting the data you need and not getting bogged down in the superfluous data you don’t. This requires you to properly archive data for compliance and incident response while feeding pertinent real-time data to your analytics platform that should ideally be purpose-built for SIEM solutions.

How can you make sure your logging is up to par? Simple. Make sure you, and your organization, do these five things.

Properly Configure Windows Audit Policy

We see this less often than we used to, but we still find people wondering why their network isn’t generating logs. The simple answer is that Windows Audit Policy needs to be turned on, and often times users need to go in a select want events they want generated. In other words you have to switch on event log generation in Windows environments. You can learn how to do that on Microsoft’s TechNet.

Once on you need to tune the policy to your log collection needs. Our Snare Agents can do that automatically by checking a box in settings, you can also find Microsoft’s recommendations on there website.

You may notice Microsoft doesn’t recommend collecting everything. While we understand the temptation to put up a catch all, you will bog yourself down in copious amounts of worthless data. Our Snare experts are happy to walk through your audit policy with you as needs easily vary from company to company.

Secure and Reliable Log Transport

There are only three protocols for transporting logs from A to B. UDP, TCP and TLS each have their own pros and cons. In an ideal world everybody would use TLS, and if you are sending sensitive data, or transporting across an untrusted network, you better be using TLS.

It used to be that all log data was considered trivial, nice to have but not essential, and UDP was the default protocol for transporting logs. UDP can lose upwards of 10% of your logs and that network bandwidth you think you’re saving can easily be saved with output driven filtering. Rather than transporting your logs with a “fire and forget” mentality, implement logging software that efficiently and securely transports logs without introducing the potential of critical logs being lost while traversing your network. Exceptions to these best practices are rare, and odds are your organization should be using TLS or TCP. Take the time to make sure you are using the ideal protocol for your company’s logging needs and networking environment

Output Driven Filtering

Security professionals should only collect logs where there is a clear requirement defining how they will be used. Are you archiving for compliance? For potential forensics? Do you need to forward on to an analytics platform? Strong analytics is a pivotal piece in reducing MTTD/R, or Mean Time to Detection and Response, as well as automated response tools.

While listing the logs you want collected creates efficiency in your entire SIEM ecosystem, company is unique and you should be thorough in exactly what logs are required to achieve your desired result. You can also add in a blacklist of everything you don’t require. A sound strategy is to collect too many logs at first, and eliminate unnecessary logs (noise) through an iterative practice of continuous evaluation and improvement.

Now you are not only saving system resources and reducing network traffic, but saving money on the SIEM side where many vendors charge on the volume of data ingested.

Centralized Collection

Centralizing your logs saves you time, money and increases the readability of your logs. It’s a crucial step in minimizing MTTD/R. The average time it takes to detect and respond to an event. A critical KPI as it can vary from minutes, to hours, to days and in extreme cases, months. Identifying events in minutes is not only critical, but is a key ROI metric used for justifying the initial investment in a SIEM, in turn protecting your company from potential hazards and liabilities.

So the question is, how easy is it to centralize your logs? The answer often times is “not very”. The problem with this is, it shouldn’t be the case. Software can do almost anything we can dream up, so when companies force vendor lock-in or require substantial coding to make the simplest of changes, you have to wonder, do they really have my best interest in mind. Invest in a logging solution (*cough* Snare *cough*) that can be your SIEM, or tie into the SIEM of  your choice so that no matter where you collect from, the logs end up where you need them. There is also the incredibly large bonus of being able to easily change SIEM vendors if you don’t have to rip and replace software on every machine in your organization. Pretty cool, right?

Sophisticated Architecture Capabilities

Sophisticated enterprise logging architecture enables your organization to maximize bandwidth by archiving logs for forensics and compliance before forwarding on critical logs to the central SIEM for analytics. This way only mission critical logs eat up system resources, but you preserve any logs necessary for potential work in the future.

Flexible architecture also allows you to implement custom deployments across various business units and still consolidate everything in an efficient manner. Give your head office visibility via analytics, but take care of the more granular forensic and compliance work at branch offices. Or maybe different departments have different security and compliance standards. Simply deploy accordingly. There are a near infinite number of ways to deploy your SIEM efficiently across your organization.

There you have it. The five logging musts in an enterprise level logging solution. For a deeper dive into this check out our resources page. There are a number of brochures you’ll want to check out. Of course sometimes talking through everything with a human is better than scrolling through digital content. Please feel free to reach out and get in touch with us as well!

In typical Microsoft fashion they had to go and create their own version of logging which in turn created a more convoluted IT ecosystem. As if IT didn’t have enough to do. When it comes to collecting logs from several disparate systems and then trying to glean insight from them; having multiple formats is not only inconvenient, it requires additional functionality in collectors. This is actually why Snare Open Source Agents became so popular. You could set up free Snare Agents and streamline collection at a central server.

With all the options out on the marketplace nowadays, merging syslog and windows event data tends to be far less of a concern. There are even those who still snag our open source agents to accomplish the task in a makeshift SIEM. Still, far too many companies are not centralizing their logs and they should remedy that immediately. Centralizing logs may seem obvious to some, but for others the benefits may be a bit obfuscated until they actually start profiting from the practice. By centralizing your log collection you not only save time but improve the reliability of your logging. You create a system of record, you streamline forensics, you keep logs secure and can quickly check on the health of your systems. While any centralizing system may seem sufficient there is one factor to keep in mind: cost.

Why? Because the data gets unwieldy as your logging needs increase in scope. When SIEM providers charge by data collected, that cost can easily increase exponentially with seemingly little you can do about it. So when you are shopping logging solutions you should not only make sure they can centralize your log collection but they should help you reduce the noise so you can efficiently manage cost.

In a day and age filled with ePhone 14s and Gamebox 7000s, there is no reason for enterprise B2B software to be so opaque, so convoluted, that it requires weeks of implementation and months of training. Which is how a vast number of open source offerings pay their way. Software isn’t “free” when you have to pay for documentation and months of training. It certainly isn’t free when you have to pay people to come in so you can implement it. The crazy part is that countless open source solutions end up costing significantly more than their commercial counterparts when all is said and done. The unavoidable costs of software whether you buy or build is well documented, and when people opt for the open source solution they end up learning the hard way.

There are other reasons people go with open source solutions even when it ends up costing them money in the long run. Vendor lock-in being another major reason as companies want to be free to switch providers if necessary and that can be difficult after making a large investment in a particular vendor’s solution. We broke Snare out into platform agnostic parts so that Snare can be a standalone solution or work in conjunction with a new or existing SIEM. We work with other software so well that customers use Snare when migrating SIEMs and love it so much they leave it in place to enhance the new SIEM platform. In other words, Snare isn’t an alternative, it’s an enhancement. Forcing vendor lock-in is antithetical to any customer driven software company’s philosophy.

There is a lot more coming from Snare and we have an especially exciting 2017 planned. In the meantime check out the following to learn more.

Download our brochure on the differences between our Enterprise and Open Source products get the paper.

Or check out the free Enterprise trial and get hands on with the differences yourself.