search cancel

APM 10.7 server side components security and risk assessment

book

Article ID: 200171

calendar_today

Updated On:

Products

CA Application Performance Management Agent (APM / Wily / Introscope) CA Application Performance Management (APM / Wily / Introscope) INTROSCOPE DX Application Performance Management

Issue/Introduction

Within the context of the security and risk assessment of the CA APM solution, the following list of questions was drawn up for which we would need official statements from Broadcom

Q1 : Isengard protocol data integrity: Does (unencrypted) Isengard protocol ensure data integrity (e.g. for agent and WebView connections)? How does Isengard ensure daa integrity, e.g. through hashing?

Q2: Shared secret authentication between MOM and Collectors: According to documentation and knowledge base, MOM and collectors use public/private key encrypted password for authentication.
Can you provide details on the implementation of the authentication and encryption mechanism?
Is the password encrypted in transit at all times?
What complexity does the password for this communication have?

Q3: Encryption of MOM-collector connections: Documentation and knowledge base mention that MOM-collector communication cannot be SSL-encrypted. A KBA mentions that "this is because the communication between these Services is proprietary and encrypted." Can you provide details on the encryption of this communication?

Q4: Security of MOM-Postgres and Collector-Postgres connections: Are there best practices to be followed when implementing SSL for the connections to Postgres?

Q5: Is there any significant overhead or other negative impact to be considered when using SSL for the connections to Postgres?

Q6: How is the password transmitted from EM to Postgres (plain text, MD5, SCRAM-SHA-256)?

Q7: Can APM be configured to use scram-sha-256-based password authentication for connections to Postgres (might require Postgres 10)?

Q8: Can Postgres APM DB be configured to allow connections only from specific hosts (MOM, collectors)?

Q9: Agent authentication: Does APM support authentication of agents against collectors other than through client certificates / mutual TLS?

Q10: Can you recommend best practices to implement a whitelist/blacklist approach for agents, e.g. through loadbalancing.xml?

Q11: Security of WebView-MOM connections: Can we configure the WebView-MOM connections to require authentication, so that WebView authenticates itself against MOM (for both HTTP(S) and Isengard connections)

Environment

Introscope APM 10.7.x

 

Resolution

Q1 : Isengard protocol data integrity: Does (unencrypted) Isengard protocol ensure data integrity (e.g. for agent and WebView connections)? How does Isengard ensure daa integrity, e.g. through hashing?

Answer: Isengard alone does not ensure data integrity. In 10.7 versions there is an option to wrap Isengard in TLS which could provide it. In new versions, WSS/HTTPS is used when APM is installed to run on a TLS-secured port.

 

Q2: Shared secret authentication between MOM and Collectors: According to documentation and knowledge base, MOM and collectors use public/private key encrypted password for authentication.
Can you provide details on the implementation of the authentication and encryption mechanism?
Is the password encrypted in transit at all times?
What complexity does the password for this communication have?

Answer: 

There are two files: config/internal/server/EM.public and config/internal/server/EM.private These files are used for MOM-collector authentication. These files contain 1024 bit RSA public and private key.
The mechanism for authentication is as follows:
A constant string of length 11 (contains symbols, uppercase letters, lowercase letters) is encrypted using RSA with the public key on the side of MOM. Encrypted value is sent from MOM to a collector.
The collector verifies the encrypted string by decrypting it using RSA with private key and comparing it to the same constant string.
Security of this authentication does not rely on the constant string secrecy but rather on the public and private key which can be changed from default one.
A new key pair can be generated using KeyGenerator class using jar files in Introscope directory:

# java -cp lib/IntroscopeJDBC.jar com.wily.util.encryption.KeyGenerator
Usage: KeyGenerator {publickeyname} {privatekeyname}
# java -cp lib/IntroscopeJDBC.jar com.wily.util.encryption.KeyGenerator EM.public EM.private
Generated public/private keys /root/Introscope10.7.0.302/EM.public//root/Introscope10.7.0.302/EM.private

The files config/internal/server/EM.private and config/internal/server/EM.public in MOM and all Collectors need to be replaced by newly generated key files.

The RSA keys are generated by the tool use Bouncy Castle encryption provider. The keys are generated with key length of 1024 bits (unfortunately there is no option to increase key length in the tool).


 Q3: Encryption of MOM-collector connections: Documentation and knowledge base mention that MOM-collector communication cannot be SSL-encrypted. A KBA mentions that "this is because the communication between these Services is proprietary and encrypted." Can you provide details on the encryption of this communication?


Implementation does not support SSL/TLS encryption for MOM-collector connections (unlike connections between Agent and EM/Collector which share same underlaying technology otherwise). There is no strong encryption inside the proprietary protocol except for authentication (explained in answer to question above).

 

Q4: Security of MOM-Postgres and Collector-Postgres connections: Are there best practices to be followed when implementing SSL for the connections to Postgres?

Answer:

I am not aware of any APM document that would describe best practices.

 

Q5: Is there any significant overhead or other negative impact to be considered when using SSL for the connections to Postgres?

Answer:

I have not seen any measurements.

 

Q6: How is the password transmitted from EM to Postgres (plain text, MD5, SCRAM-SHA-256)?

Answer:

In default installation the Postgres 9.6 is configured for plain text password authentication.
A change to md5 password authentication is possible, but the way md5 is used in Postgres is insecure:
https://www.2ndquadrant.com/en/blog/password-authentication-methods-in-postgresql/


Q7: Can APM be configured to use scram-sha-256-based password authentication for connections to Postgres (might require Postgres 10)?

Answer:

SCRAM methods are supported on newer Postgres version than the one that is shipped with APM.
I am not aware if the version 10 that supports SCRAM is compatible with the APM.

On client side the SCRAM support is in driver since 42.2.0 which should be ok in later builds of APM 10.7 (version 10.7.0.266 or later).

 

Q8: Can Postgres APM DB be configured to allow connections only from specific hosts (MOM, collectors)?

Answer:

Yes. There are multiple ways to do it. Postgres itself can define it in pg_hba.conf and it can be restricted at network firewall layer too.

 

Q9: Agent authentication: Does APM support authentication of agents against collectors other than through client certificates / mutual TLS?

Answer:

In APM 10.7 there is no authentication option aside of client certificates. In APM 11 and 20 the authentication of agents to APM is mandatory on the other hand (though there is an option to connect old agents that do not authenticate through a proxy that will add authentication).


Q10: Can you recommend best practices to implement a whitelist/blacklist approach for agents, e.g. through loadbalancing.xml?

Answer:

Load balancing is not a good way to implement whitelist for agents as a security measure.
You can use network firewall of the operating system (e.g. iptables on Linux) to restrict access to TCP port 5001 (and TLS port 5443 if enabled)


For LB information and other options how to block agents you can refer to the below 2 links:

Is there a way to block some agents connections to a Enterprise Manager?
https://knowledge.broadcom.com/external/article/187111

https://techdocs.broadcom.com/us/en/ca-enterprise-software/it-operations-management/application-performance-management/10-7/administrating/configure-enterprise-manager/configure-mom-agent-load-balancing.html


Q11: Security of WebView-MOM connections: Can we configure the WebView-MOM connections to require authentication, so that WebView authenticates itself against MOM (for both HTTP(S) and Isengard connections)

Answer:

WebView uses two connections: the Isengard and regular HTTP(S). The HTTP(S) part is authenticated by a token issued by EM over Isengard. Unfortunately the WebView does not support any authentication to Isengard.