We are currently running IEM 9.1.1117.0, and we are being told by our security officer that the Bigfix DMZ relay is not secure, and we are going to have to shut it down which we just did.
The DMZ relay is not passing a security audit, apparently because the certificate used is an internal IBM certificate and not a trusted third party certificate.
What are other doing about this? We were told by support that there are not plans to add a different certificate.
Are you saying that an audit from an external source found a self-signed certificate error on your DMZ relay? What exactly was the finding?
Untrusted TLS/SSL server x.509 certificate. The auditor manually verified that noted host (Bigfix DMZ) supports an untrusted x.509 certificate. A new certificated is required that is signed by a trusted CA, such as Thawte or VeriSign.
Did he mention what port it was?
The port listed as failed was the Bigfix port 52311/tcp.
Are your DMZ relays authenticating relays? Are you using Message Level Encryption? (MLE)
I haven’t really looked at the certificates but I think this is a misunderstanding of the nature of the SSL security being used.
If an SSL connection is using self signed certificates and all self signed certificates are blindly trusted by the connecting client, then this is problematic because it allows for man in the middle attacks. If however you have a client that only trusts signed certificates by a set of root CAs like VeriSign and others, then this should help mitigate man in the middle attacks because not just anyone could get a certificate signed by a root CA, but this means that ANY trusted root CA could provide the certificate, which means you have to trust all of the root CAs do the right thing and only give out the certificates to those that they are supposed to. If however you use a self signed certificate and then provide that certificate to all connecting clients so that they trust only that specific certificate, then that is actually more secure than trusting all root CAs because you are trusting only 1 specific certificate, and not all potential certificates signed by all root CAs. Instead of using a self signed certificate, you can use a self signed root certificate that is provided to all clients to specifically trust, and that certificate can sign all of the relay certificates. This is basically an internal PKI.
Add on top of this the use of the masthead and other signing / security in play, and the threat of an active man in the middle attacks is minimal and wouldn’t be able to actually cause any ill effects on the clients themselves. (other than denial of service)
We haven’t done any extra setup for our DMZ relay. I am not sure what is meant by authenticating relay and Message Level Encryption. I will do some research. Do you have a link that describes these and how to implement them? I know with 9.1 there is the ability to turn on encryption which we have not done yet.
I got the following from the product team.
“We have historically seen false positives on vulnerability scans resulting from the fact that we use certificates generated from our own trust chain for relays, rather than certificates that are rooted in a common certificate authority. These vulnerabilities are not “true vulnerabilities” because they are not exploitable in any way and do not weaken our security model. We regularly see reports like this where details are sparse and those testers analyzing the products don’t fully understand how our product works. They focus on our single port for public facing DMZ relays and thus incorrectly conclude this to be a vulnerability.”
The ability to exploit a self signed server certificate scenario is largely dependant on the underlying protocol and communication between client and server. In a web browser to web server scenario, this is valid. In the context of communication between the BigFix client and a relay, this is not the case.
Thanks for the follow up with the response you got. This is definitely what I was getting at.
Technically if all web browsers connecting to your Intranet sites are within your control you can put your own RootCA in the certificate store and then you can use that RootCA on all of your internal websites to provide SSL. This would be similar to how the PKI internal to BigFix and Active Directory and other similar systems work. The issue is that this is not typically the case with websites and would be insecure if you cannot pre-provide the custom RootCA to all connecting endpoints.
One major issue with using a Custom RootCA this way for your intranet browsing is that if you don’t limit it to sign only domains within your organization, then it could be used by the organization as a way to do man in the middle between all sites and the endpoints connecting to them, which allows the organization to snoop on all internal traffic, which is often how this is used. This issue does not apply to the way the BigFix internal PKI works because it is only used for a very narrow use and does not affect what the browsers see as valid RootCAs.
After our third party auditor met with the IBM Bigfix security team, and IBM explained that the only traffic that can possibly hit the DMZ relay is from the Bigfix endpoints, the auditor agreed to pass the audit for the Bigfix DMZ relay.