traffic to logger from workers

Does the logger receive traffic over an encrypted tunnel? It does not appear to be the case.

n Wed, Jan 18, 2017 at 07:51:54AM -0500, erik clark wrote:

Does the logger receive traffic over an encrypted tunnel? It does not
appear to be the case.

No, Bro to Bro communication is not encrypted.

Johanna

This seems to be a pretty big oversight. Depending on the controls you implement from NIST 800-53 Rev 4, encryption between processes is mentioned. In our environment, it is not just nice to have, it is a requirement.

Since no Bro to Bro communication is encrypted, this makes it 100% impossible for us to have a Bro cluster spanning multiple servers. We are relegated to load balancing via a smart tap and hosting all-in-one Bro instances in disparate hardware, and then forwarding the logs off the box with Splunk which does do encrypted log handoff to the indexers.

I understand that there is some concern about possible performance implications, but making an application that is completely devoid of FIPS 140-2 compliance does not seem to be very good.

What can be done to get encryption into Bro to Bro communication? If nothing else, at least to the logger. The other elements (workers, proxies) can be handled by pushing proxies to the individual hosts and blocking proxy port requests from Bro between hosts.

This seems to be a pretty big oversight. Depending on the controls you implement from NIST 800-53 Rev 4, encryption between processes is mentioned. In our environment, it is not just nice to have, it is a requirement.

Since no Bro to Bro communication is encrypted, this makes it 100% impossible for us to have a Bro cluster spanning multiple servers. We are relegated to load balancing via a smart tap and hosting all-in-one Bro instances in disparate hardware, and then forwarding the logs off the box with Splunk which _does_ do encrypted log handoff to the indexers.

I understand that there is some concern about possible performance implications, but making an application that is completely devoid of FIPS 140-2 compliance does not seem to be very good.

If encryption between all processes is a requirement in your environment then what exactly is Bro seeing via the taps? Anything that Bro is seeing on the taps is not encrypted and is ALREADY being transmitted in plain text in the first place.

What can be done to get encryption into Bro to Bro communication? If nothing else, at least to the logger. The other elements (workers, proxies) can be handled by pushing proxies to the individual hosts and blocking proxy port requests from Bro between hosts.

ipsec, openvpn, etc. Or possibly via tls via broker at some point.

I've used stunnel for this in the past, and it worked well.

"Azoff, Justin S" <jazoff@illinois.edu> writes:

Which 800-53 control are you referencing? I’d like to help you.

I think this refers to AC-4 for information flow enforcement. But this is where you would configure border protections or segmentation of your bro data on its own private network, or configure encrypted tunnels.

Isn’t that how everyone does it? I never have IDS or other security events passing over the internal network. It’s always on a private, dark, network.