What security measures are used in BES Relay to BES Client communications?

Usage and Config Platform
1

I’m not talking about BigFix Enhanced Security. I’m just talking about a basic out of the box installation. What encryption methods are currently used, how secure is the communication between BES Clients and BES Relays (and Relay to Relay as well), and how is the BES Client/BES Relay initial handshake handled?

I need to tell my security architect exactly how BigFix secures all of its communication, and how each endpoint trusts the infrastructure (and vice versa).

Thanks!
-D

1 Like
2

Disco,

This is what it looks like when Enhanced Security is not enabled (this is the default), there is no encryption key deployed (this is the default) and relay authentication is not turned on (this is the default).

Client <-> HTTP Unencrypted and Interceptable <-> Relay <-> HTTP Unencrypted and Interceptable <-> Server

Good:

  • Server commands are signed before submitting to relay/client preventing modification
  • Client reports are signed before submitting to the relay preventing modification

Not Good:

  • All communication at every level occurs in plain text (Fixed with Enhanced Security)
  • There is no handshake to send a report (Fixed by enabling relay authentication)
  • Reports are stored in plain text on the relays (Fixed by enabling Encrypted Reports)
  • Anybody can request any file from your BigFix infrastructure without a client (Fixed by enabling relay authentication)

An important feature of the architecture is that all content that a client receives is signed by the server/operators. This means an attacker who takes control of a relay has access to the report data from your endpoints but cannot send them malicious actions.

4 Likes
3

One of the biggest improvements you can make and the easiest to implement is set all clients report encryption to optional and have the root and/or top level relays set up to handle decryption.

One reason to set the encryption to optional is that the clients will use it if they can, but fail back if they can’t. You can eventually switch this to required, but optional is the way to start.

@strawgate I didn’t realize that the default communication was unencrypted between client & relay. I figured it would at least use SSL even if it doesn’t validate the relay using SSL. (self signed)

Related: