LOGbinder Blog

Updates, Tips and News   RSS Feed  

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!


New technical updates posted and available for customers with current maintenance and support contracts

Mon, 27 Jul 2015 13:43:27 GMT

Within the last few weeks we posted new versions of our software containing features and improvements to all 3 of our applications. Two major features will bring immediate performance benefits:

  1. Split Syslog output if over 100mb. Prior to this update, LOGbinder started a new Syslog output every day (with the file named appropriately), but some organizations’ audit activities would generate more than 1GB of data in a day. This large output file size caused problems. So, we updated all 3 of our applications to create a new file after every 100mb of output and creating a file name suited to this new schema.

  2. Streamlined internal audit request and delivery process. To protect the monitored application’s performance and stability, LOGbinder carefully manages the process by which it requests audit log data. Persistent audit log demands can cause harm to the application. We have released an update to all 3 of our products that adds further refinement to the audit request technology by improving the calculated times for audit request and processing. The net effect is reduced resource demand on the monitored application while maintaining delivery speed and audit integrity.

The new updates are available via the website’s download resource page. Customers with current support and maintenance contracts may download and apply these new updates at no additional charge.


Exchange auditing: a look back and a look ahead

Mon, 27 Jul 2015 13:43:08 GMT

A year ago we announced an update to LOGbinder for Exchange that removed Exchange System Administrators’ final obstacle to security auditing. It was a seminal moment for security analysts everywhere-- no joke. Our version 2.5 removed the threat of Exchange server’s backlogged audit files and introduced vastly superior audit log query intelligence. Those 2 big-time challenges were causing headaches all over the world. Exchange servers in organizations whose brand you would immediately recognize were on their knees just from a tentative attempt of an audit.

Now security analysts can deploy Exchange auditing using LOGbinder with confidence that the sys admins aren’t going to get a strong case of (warranted) heart-burn.

It is important to look back every so often for it serves as a reminder of how fast and how far application security intelligence has come.

Since that milestone release, we introduced another huge advancement with version 3.0: automatic mailbox audit policy configuration by Active Directory Organizational Unit (OU) or Group.

Last week Microsoft released the Exchange Server 2016 public preview and within hours we ran tests against it in our labs and initial results look good. So it looks like an upcoming release for compatibility with the newest version of Exchange server is on-track!


previous | next

powered by Bloget™