LOGbinder Blog

Updates, Tips and News   RSS Feed  

«  SQL Server auditing tutor... | New technical updates pos... »

LOGbinder use case (Simplified edition)

Mon, 27 Jul 2015 13:51:01 GMT

If an organization has a SIEM (any SIEM) and also has Microsoft’s Exchange, SharePoint and/or SQL Server applications, LOGbinder is required. No SIEM can get the security audit logs from those applications via normal collection methods. What does this mean in real-world terms? And why does it matter, aren’t Operating System logs, packet data and network traffic sufficient?

Some applications make it dead simple to audit. They push the events in plain-text directly to the Windows Event log or a custom application log. Not so the enterprise Microsoft applications Exchange, SharePoint and SQL Server. They do a great job of generating the appropriate events. But they have a unique way of storing them. And they do not make them easy to read and understand. Each of the 3 applications have differing reasons for why this is true and we have published extensive information about this over the years. See www.logbinder.com/resources for the highlights.

By the way, some SIEM solution providers will tell you that their SIEM collects the needed logs via a free collector, but this is not fully the case. Some organizations may be satisfied with a partial collection of the events (which may not be the security events), and they may not require that the event data be understandable or even intelligible. In our experience most organizations are unhappy with such collectors and eventually improve their security intelligence via LOGbinder.

Application security intelligence may be the only thing that truly matters

The logic is very simple. The bad guys’ ultimate goal is information. Operating system logs, net traffic—that’s just data. Therefore:

  1. What causes real harm and embarrassment is when information – that can only be stored inside applications – is breached.

  2. The only way to know what’s happening inside the application is when the application is telling you.

    1. Only Exchange can tell you that John is reading the CEO’s mailbox. Or that a privileged user changed permissions on the CEO’s mailbox.

    2. Only SharePoint can tell you that Bob is downloading a significant percentage of documents in a sensitive library.

    3. Only SQL Server can tell you that Alice changed permissions on the confidential data table(s).

    4. Only the application can tell you that an external APT is downloading mass downloads of content data.

So that’s all the use-cases distilled into a very clear and simple concept. Application security intelligence belongs in the SIEM. And at this point, the only way to get it from Exchange, SharePoint and SQL Server is with LOGbinder software.

Browse our solutions pages (click the Solutions tab up top) or drop us a line to get information specific to your use case. We would love to hear from you!

Comments disabled

powered by Bloget™