TLS Communications

by Michael Willison
August 22, 2014

The TLS Communications dashboard identifies system vulnerabilities to the TLS, DTLS, and SSL protocols. Also included are two components that identify the Heartbleed and OpenSSL ChangeCipherSpec vulnerabilities.TLS, DTLS, POP SSL/TLS, IMAP SSL/TLS and CAPWAP are security protocols for communications for sensitive information transmitted over the internet. The DTLS (Datagram Transport Layer security) protocol allows datagram-base applications to communicate in a secure way to prevent eavesdropping, tampering, or message forgery. TLS (Transport Layer Security) and SSL (Secure Socket Layer) are interchangeable unless referring to a specific version. SSL is the predecessor to TLS and both are cryptographic protocols designed to provide secure communications. CAPWAP (Control and Provisioning of Wireless Access Points) is a protocol used by wireless clients and servers to detect and configure nodes within the wireless network. By using this dashboard, an IT security team can determine what type of secure communications are being used within the network, what risks are associated with these secure communication protocols, and what actions can be taken to reduce these security risks.

The dashboard and its components are available in the SecurityCenter Feed, a comprehensive collection of dashboards, reports, assurance report cards and assets. The dashboard can be easily located in the SecurityCenter Feed under the category Monitoring.

The dashboard requirements are:

  • LCE 4.2.2
  • Nessus 5.2.7
  • PVS 4.02

Listed below are the included components:

  • TLS Communications - TLS Indicator: This indicators provides information on the different types of vulnerability (informational to critical) associated with TLS v1 (Traffic, Negotiation), TLS v1.1 (Traffic, Negotiation), TLS v1.2 (Traffic, Negotiation), DTLS v1 (Traffic), DTLS v1.2 (Traffic), DTLS (Detection, Heartbeat, Client, Client Error, and Error), and CAPWAP Protocol Client. By using this indicator an IT security team can determine what type of secure communication are being used within the network, what risk are associated with these secure communication protocols, and what action can be implemented to reduce these security risk. If the vulnerability is detected, the indicator will change color to purple.
  • Heartbleed - Indicators: This component provides a series of indicators of systems that may be at risk to the HeartBleed vulnerability. The matrix is organized by column to provide indication of the identification method. Each row then displays indicators of vulnerabilities discovered.  The first row will turn red for systems that have been identified to have the HeartBleed vulnerability. The second row reports on the OpenSSL version 1.0.1 vulnerabilities, and will turn red if a system is discovered. The third row provides a listing for all OpenSSl vulnerabilities, while the fourth row provides the DTLS vulnerabilities.  The indicators for the OpenSSL and DTLS will turn red for the active and passive detection, and will turn orange for the event detections.  With event detections, the severity cannot always be discovered, therefore many of the logs have a severity level of info.  Thus, the indicators will be orange to indicate a warning and manual review and verification is required.
  • HTTP SSL Service Detection: This matrix component has an indicator for each SSL-based service. For each indicator, we selected plugins that have HTTP, SSL, TLS or Web listed in the plugin description.
  • OpenSSL ChangeCipherSpec - Indicators: This component provides an overview of OpenSSL vulnerabilities and the related ChangeCipherSpec vulnerabilities.  There are three columns, one for each vulnerability type (active, passive, event).  Each column has an indicator for the six CVEs related to OpenSSL ChangeCipherSpec vulnerability, and one indicator for all OpenSSL related vulnerabilities.  The active and passive indicators will turn red, signifying immediate action should be taken, while the event vulnerabilities are orange and signify that administrators should investigate the true severity of the event.