Recently, 3 different customers in as many days came to us with the same problem: LOGbinder installation would return “Error 1001” and fail to install. We’re not sure why this suddenly became an issue mid-January 2016, but the problem turned out to be with the Local Security Policy setting enabling “FIPS mode”, specifically the security option called “System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing”.

FIPS mode has an interesting history. We thought we’d pass along Microsoft’s TechNet post about it so you can understand how to address this issue should it come up in your organization.

In April 2014 Microsoft posted “Why We’re Not Recommending ‘FIPS Mode’ Anymore.” Prior to this post, Microsoft recommended a Local Security policy setting to impose compliance with a US Federal Information Processing Standard (FIPS) 140 requiring National Institute of Standards and Technology (NIST) validation of an implementation of cryptographic algorithms. When this setting was enabled a particular algorithm that had not been submitted to NIST would not be allowed on the local system.

However, the April posting listed multiple, compelling reasons why FIPS-140 is deficient, and even went so far as to call it “particularly onerous”. Enabling FIPS mode in Security Policy arbitrarily presumes that non-validated cryptographic classes are undesirable, when in fact they may be just as good and provide much faster operations. But the problems associated with applications using the .NET Framework are more troublesome. To quote the article:

“If FIPS mode is enabled, the .NET Framework disallows the use of all non-validated cryptographic classes. The problem here is that the Framework offers multiple implementations of most algorithms, and not all of them have been submitted for validation, even though they are similar or identical to implementations that have been approved...

Compounding the problem is that in most cases the Managed implementations of the various cryptographic algorithms have been available much longer than their Cng and CryptoServiceProvider counterparts, and on top of that, the Managed implementations tend to be significantly faster….

“Finally, the .NET Framework’s enforcement of FIPS mode cannot tell whether any particular use of a cryptographic class is not for security purposes and thus not in violation of standards.”

It is in this context that we report LOGbinder will not run if FIPS mode is enabled on the installed server. LOGbinder software uses Microsoft’s recommended cryptography implementations; they perform well and provide excellent protection. However, they are incompatible with FIPS mode.

If your organization must enable FIPS mode on the server running LOGbinder (for some reason greater than all the reasons not to do so as described in Microsoft’s post nearly 2 years ago), then contact our support desk using the word “FIPS” in the subject line. They can walk you through how to manually install files in the LOGbinder installation directory to overcome the security policy setting just for the LOGbinder application.

Click here to read the TechNet post: http://blogs.technet.com/b/secguide/archive/2014/04/07/why-we-re-not-recommending-fips-mode-anymore.aspx

We’ve said this before, but in light of the recent spate of data breaches it bears repeating:

1. Your sensitive information is an asset more valuable than many listed on the balance sheet. It’s so valuable that the accountants can’t figure out how to put a dollar figure on it (which explains its absence from the balance sheet). But lose that information to the outside world and the value of the assets and equity on the balance sheet soon drop off a cliff.
2. Valuable assets must be monitored. Tell the C-Suite people: If your SIEM doesn’t have LOGbinder delivering critical audit logs from the enterprise applications, your organization is failing to monitor its most critical assets.

Chief Financial Officer’s make a lot of money managing the balance sheet. They and the rest of the C-suite have a vested interest in giving you the resources you need to monitor and protect one of the biggest assets there is that also happens to be off their radar (because it’s missing from the balance sheet).

So tell them you need LOGbinder to protect their big asset. :-)

A simple solution to a complex problem can be up-and-running in minutes.

The CEO of one of the world’s largest and progressive companies said in a speech last November “the top eight or so data breaches [in 2015] have led to 160 million data records being compromised.” He continued his remarks to government and business leaders by saying “the biggest challenges that we all face is the time to detect an intrusion; it’s something like 229 days between when you have been intruded versus when you know and you can start to respond.”

If that’s true, and we’ll take Satya Nadella at his speech-writers’ word, we can get you 228 days back.

While it may take 229 days to detect an intrusion, you can get application security audit events within minutes. One reason why we stress the importance of watching what matters most, the applications’ stored information: it can help to reduce your data breach time-to-detection.

For years Microsoft has done everyone a favor by building a robust security audit function in their enterprise information-storing applications (Exchange, SharePoint and SQL Server). Because of this, LOGbinder tells your SIEM about application security-related events in minutes. Which fact has led many of the globe’s most advanced and security-focused organizations to add LOGbinder to their InfoSec budget. (Note: see our blog post about the 24-hour delay associated with Exchange mailbox audit and what we are doing to address that problem.)

Application Security Audit Must Be a Priority

Don’t confuse intrusion detection with application audit. The time it takes for you to detect an intrusion may be, to a very large extent, a factor outside a reasonable domain of control. Monitoring the information stored inside applications isn’t.

So, forget thinking 229 days for intrusion detection is the just “the way it is” in your shop. We think the best intrusion detection ROI comes from LOGbinder software watching the sensitive information for your SIEM security analysts. It can begin feeding your SIEM today, in fact.

Think about it. You are looking the wrong way if there’s no “close eye” on confidential information. Watching your sensitive information inside applications, and feeding their security audit events to the SIEM within minutes (or seconds) has got to be a priority. Frankly, it is inexcusable for an organization to fail to have at least a daily report on the safety of its sensitive information.

Application security audit is not “the solution” all by itself, but it is a critical InfoSec component. Such audit allows security analysts to monitor with greater effectiveness and in much smaller windows of time.