Security

The Solution has been designed to meet the industry's best practices with regard to application security, using US DoD STIGS guidelines as a baseline. The system has the following key security attributes:

1. Role-based security with separate Security Administrator role.
2. The Security policy can only be defined by the Security Administrator.
3. Users are assigned to User Groups, which have assignable permissions for individual aspects of the system.
4. Permissions can be separately applied to functionality and data.
5. Strong password rules, including password complexity, password re-use, expiry, and grace period rules.
6. Passwords are stored using a strong hash algorithm.
7. There are no default passwords for any aspect of the system.
8. Repeated login failure lockout, and IP blacklisting.
9. Configurable inactivity timeout.
10. Ability to force the use of HTTPS for connection by user.
11. User input is subject to multi-level validation to prevent SQL/XSS injection.
12. System tested for URL modification and fuzzing.
13. Security audit log — tracks user login/logout and any attempted security violations.
14. User-identifying data in database is encrypted or privacy protected.
15. Configurable warning messages for login screen and for system screens.

The following diagram illustrates the trust boundary that separates internal components with various external clients and reporting applications.

Interface from the Controller to each Endpoint Clients (EPC) uses AES encryption and authentication. EPCs trust configuration commands and test requests from the Controller. The Controller trusts data reported by agents to be valid.

A Controller IP blacklist provides information about external or internal attempts to gain unauthorized access. Security Administrators review the IP blacklist regularly; checking for the presence of numerous IP addresses that have been automatically blacklisted and may indicate a brute force password attack.

The EPCs send local configuration details back to the controller. This data includes:

• Hostname
• external IP address
• endpoint up time
• host environment (OS)
• Host CPU type
• Average CPU%,
• Total RAM
• Used RAM
• LAN interfaces including MAC address and internal IP Address.

The EPCs also sends test results back to the controller. The actual data depends on the test run (e.g., Ping, Peer to Peer or VoIP).

The Controller <-> EPC control/data channels are negotiated using a proprietary TLS-like protocol over an AES-128 encrypted TCP connection. Unlike TLS that uses a private/public key pair, the Controller <-> EPC communication uses an application private key that is randomized per Controller <-> endpoint connection. Upon key synchronization, the AES-128 channel is started and a secondary domain passphrase authentication process occurs. The nature of this proprietary protocol means a) the Controller <-> EPC can only communicate with each other - unlike an open protocol like HTTPS, and b) it is resistant to man-in-the-middle attacks.