branching Bro

We need to branch Bro due to FIPS non-compliance. Is there any thorough documentation as to what parts are FIPS non-compliant, other than the md5 analyzer, and is there any documentation on the md5 analyzer hooks (built in stock scripts, so on so forth) so we can begin attempting to branch this into a FIPS compliant tool?


I hereby grant you an exception to FIPS compliance that allows you to use Bro as it is intended and to its full capabilities.

Note: This exception is equally as meaningless as FIPS compliance.

Sadly, in the federal world, FIPS compliance isn’t meaningless. There is a real need for it.

And handicapping the best tool you'd have to detect noncompliant certificates is extremely misguided and counterproductive.

It's like if you had a tool that could scan for use of 512bit key SSL certificates, and someone prevented you from using it because it "supports" 512bit certificates and 512bit certificates are not FIPS compliant.

FIPS compliance isn’t an application “thing”. FIPS compliance is an implementation “thing”.

FIPS does not apply to the md5 file hash analyzer because in this case no cryptography is being performed. FIPS also does not apply to the calls in the SSL analysis stuff to md5 because once again, no cryptography occurs with the calculation of that MD5 hash. I don’t remember which portion of Bro ultimately caused this issue for you, but whether it was the file analyzer or the SSL analyzer—I am not aware of segments of either of those analyzers performing any cryptography.

FIPS is a process by which the government assesses implementations of cryptography. Is your question “Where is cryptography implemented in Bro so that I review those sections to determine whether or not they would pass a FIPS validation assessment?” To the best of my knowledge, cryptography isn’t implemented anywhere in Bro.

I suspect that what you really want is for the communication that occurs when network traffic leaves the server to be encrypted in a manner that would pass FIPS 140 validation tests. My recommendation for that would be to run the cluster traffic in an isolated network and document that in your system security plan. Not only is this the best scenario for you, this is almost always how the most active people on this mailing list would deploy Bro. If what is really going on here is that a STIG check is ‘requiring’ you to run everything in FIPS mode, then documenting an exception is usually alright.

If it is unacceptable for your audit that you document an exception (which would be a new one for me since the government that you are working with generally only wants data encrypted when it leaves the system), then you should follow Vlad’s advice about setting up tunnels between cluster nodes and the master. This implementation (assuming that you perform the configuration right) has the ability to pass FIPS-140 validation.

Branching Bro and rewriting all of its cluster communications to use encryption that you write yourself from scratch is almost certainly going to be a bad idea. You’re unlikely to pass FIPS validation writing something yourself. While I don’t doubt your skills, FIPS validation is something that development teams strive for and a developer would likely struggle with. You will also be introducing an immense amount of risk. You have the risk that you’ll almost certainly never be able to pull down updates from the origin—since you’re working with completely different clustering code. You’re going to have the risk that your version of Bro—which I’m assuming will be closed source—will now only ever be reviewed by you or your team. Your implementation will likely be significantly weaker because of this.

For those watching: please feel free to correct any information you feel that I have misrepresented. I would normally include sources and double check everything in an email this lengthy, but I have to rush off and want to make an attempt at being helpful here.

Erik, Justin -

You both have good points. For Erik, I think you have solid ground on which to stand if you make the following distinctions:

  (a) Bro is capable of inspecting/monitoring/detecting FIPS non-compliant encryption; this is a valid and necessary capability for the defense and security of your network; and

  (b) Is Bro being used to PROTECT federal information (whether in transit or at rest)? If not, then no worries, argument alleviated. But if so, then is Bro able to implement a FIPS-compliant encryption to do so?

As long as Bro uses FIPS-compliant encryption to PROTECT information (or if you can come up with an appropriate mitigation), then I believe you can make a reasonable case to your certification and accreditation folks to allow Bro to also continue monitoring for non-compliance.

Mark Fernandez

Stephen, Bro flat out does not run if your kernel is in fips mode. You specifically get:

ValueError: error:060800A3: digitial envelope routines:EVP_DigestInit_ex:disabled for fips

I brought up the cross network logging encryption issue previously. This is very specifically an issue where you can not run Bro at all with a FIPS compliant kernel. Getting someone to sign off on an exception not only for Bro, but the kernel as well, is unlikely. The issue with the md5 crypto libs in Bro causing it to simply not run with a FIPS kernel was already brought up in the list as well, by Gary.