Top External Network Risks And How to Fix Them

By: The Center for Internet Security® (CIS®) Cyber Threat Intelligence (CTI) team

Published August 27, 2025

In the first half of 2025, the CIS Red Team and Cyber Threat Intelligence (CTI) Team conducted external network scans across Multi-State Information Sharing and Analysis Center^® (MS-ISAC^®) member organizations, identifying numerous high-risk vulnerabilities and insecure software configurations. A significant portion of these findings stemmed from cryptographic failures, the second highest risk in the OWASP 2025 Top 10 Web Application Security Risks. The most critical of these issues related to Transport Layer Security (TLS) and Secure Sockets Layer (SSL) implementations. These weaknesses undermine encrypted communications and leave systems exposed to potential exploitation. The five most prevalent and severe TLS/SSL-related issues observed were:

1. End-of-Life TLS/SSL Version
2. Weak Encryption Ciphers
3. Weak Key Exchange Mechanisms
4. Misconfigured SSL Certificates
5. Known High-Risk TLS/SSL Vulnerabilities

It is critical that organizations address these external network risks by keeping their software updated, using strong configurations such as the CIS Benchmarks^®, and engaging services such as the 24x7x365 CIS Security Operations Center (SOC), Cyber Incident Response Team (CIRT), and CIS Red Team, as appropriate.

This blog post is intended to serve as an analysis of these external network risks for technical staff who are interested in hardening their configurations.

CIS sent notifications to the individual organizations observed in our data. All organizations are encouraged to verify the findings on their networks, as scanning and profiling often produces false negatives.

1. End-of-Life TLS/SSL Versions

End-of-life (EOL) products are no longer supported or updated by their developers. This means any vulnerabilities discovered in these products will remain unpatched, leaving systems exposed. One common example is the continued use of outdated TLS/SSL protocols. According to a CIS vulnerability scan, more than 16% of observed devices were still using TLS 1.0 or 1.1, both of which are deprecated due to known security weaknesses. These older versions lack modern cryptographic protections and are vulnerable to a range of attacks, making them unsuitable for securing sensitive communications.

2. Weak Encryption Ciphers

TLS and SSL provide confidentiality, integrity, and authenticity services to other protocols that lack these features. TLS/SSL protocols use ciphers to encrypt the content of the higher layer protocols to provide confidentiality. The output of the encryption process is a sequence of random unintelligible bytes to anyone intercepting it. However, some older ciphers, such as RC4, DES, 3DES, and ARC4, are now insecure due to known vulnerabilities and weaknesses, undermining the entire purpose of TLS/SSL. Organizations using these ciphers are exposed to serious risk, such as having sensitive data decrypted, downgrade attacks that force weaker encryption, authentication bypass, or the injection of malicious content.

3. Weak Key Exchange Mechanisms

The key exchange process is a critical component of the TLS/SSL handshake. The key exchange establishes the secure communication channel between the client and server by allowing them to agree on a shared session key used to encrypt data in transit. A weak key exchange mechanism occurs when the TLS/SSL server supports encryption algorithms that do not meet industry standards. The key exchange mechanism should provide at least 112 bits of security, which is a minimum key size of 2048 bits for Diffie Hellman or RSA key exchanges, or 224 bits for Elliptic Curve Diffie Hellman key exchanges. Cyber Threat Actors (CTAs) could recover the session key and decrypt communications between the client and server if the key exchange mechanism is weak.

4. Misconfigured SSL Certificates

SSL certificates play a critical role in securing internet communication by authenticating a website’s identity and encrypting communication between a user’s browser and the web server. However, misconfigured SSL certificates can be a serious security risk, as it can compromise the confidentiality, integrity, and authenticity of the data in transit.

Through CIS vulnerability scans, the four most common and high-risk SSL certificate misconfigurations observed are:

• Expired SSL Certificate: Certificates that are expired can no longer be validated or trusted by a Certificate Authority (CA). Without a valid SSL certificate, data in transit is no longer being encrypted and is vulnerable to Adversary-in-The-Middle (AiTM) attacks.
• Subject Common Name Does Not Match Server Fully Qualified Domain Name (FQDN): The certificate’s FQDN identifies the specific server or resource on the internet and needs to include all domain levels to locate and identify a resource within the domain name system (DNS). When the certificate’s Subject “commonName” or “subjectALTName” does not match the server’s FQDN, the certificate fails to properly authenticate the server and only encrypts the data in transit. This mismatch leaves it vulnerable to an AiTM attack, especially when combined with DNS cache poisoning — allowing CTAs to redirect the client to a malicious server allowing for the encrypted communication to be stolen.
• Invalid Maximum Validity Date Detected: SLL certificates are issued a validity period for certificate holders to reauthenticate their identity on a regular basis. For example, certificates issued on or after September 1, 2020, should not have a validity period greater than 397 days and must not have a validity period greater than 398 days. Certificates that have dates outside of the validity period may be rejected by modern browsers and have an increased risk of AiTM attack.
• Self-Signed Certificate: Clients can trust certificates only if they are signed by a mutually trusted third-party CA. Self-signed certificates should only be used for testing purposes. Self-signed certificates should not be used on any production or critical server. These certificates pose a serious risk, as CTAs can impersonate the server by presenting a fake self-signed certificate and conduct an AiTM attack. If the client knows that the server does not have a trusted certificate, it will accept this spoofed certificate and communicate with the malicious server.

5. Known High-Risk TLS/SSL Vulnerabilities

Despite the widespread adoption of TLS, several vulnerabilities continue to threaten encrypted communication, especially when legacy protocols or weak configurations are still in use. Although many of these can be easily mitigated, organizations often continue to rely on outdated versions or insecure settings, leaving their systems exposed to serious risk.

According to a CIS vulnerability scan, the three most common and high-risk vulnerabilities observed across external networks are:

• Sweet32: Exploits collision vulnerability CVE-2016-2183 in long TLS/SSL sessions that use legacy block ciphers with a block size of 64 bits. All versions of TLS/SSL protocols that support cipher suites which use DES, 3DES, IDEA, or RC2 as symmetric encryption ciphers are affected. These ciphers are susceptible to a birthday attack in which CTAs find two inputs that produce the same encrypted output, allowing the CTA to decrypt weakly encrypted data.
• BEAST: Exploits vulnerability CVE-2011-3389 in TLS 1.0 and SSL 3.0 protocols implementation of the cipher block chaining (CBC) mode encryption, resulting in a CBC server-side vulnerability. CTAs can exploit the predictable initialization vectors to decrypt parts of the HTTPS session, enabling AiTM attacks.
• POODLE: Exploits vulnerability CVE-2014-3566 in SSL 3.0 handling of block cipher padding. SSL 3.0 has a design error where it uses nondeterministic CBC padding, which can be manipulated to leak encrypted data. Due to the negotiation feature built into TLS/SSL, CTAs can force a downgrade and the use of SSL 3.0 to then use the Padding Oracle Attack Information Disclosure (POODLE) attack to exploit the padding vulnerability to decrypt content within the SSL session and enable the ability to conduct AiTM attacks.

Recommendations

To address the five most prevalent external network risks discussed above, please follow these recommendations:

• Disable TLS 1.0 and 1.1 in favor of TLS 1.2 or higher, which offers stronger encryption and modern cipher suites. (See CIS Critical Security Control 4.2: Establish and Maintain a Secure Configuration Process for Network Infrastructure.)
• Organizations should ensure that TLS/SSL server configurations only allow for strong key exchanges. Key exchanges used should provide at least 112 bits of security, which is a minimum key size of 2048 bits for Diffie Hellman or RSA key exchanges, or 224 bits for Elliptic Curve Diffie Hellman key exchanges. (See CIS Critical Security Control 4.6: Securely Manage Enterprise Assets and Software.)
• Keep all SSL certificates valid, properly configured, and issued by a trusted CA. (See CIS Critical Security Control 4.2: Establish and Maintain a Secure Configuration Process for Network Infrastructure.)
• For Sweet32, organizations should disable and stop the use of DES, 3DES, IDEA, or RC2 ciphers. (See CIS Critical Security Control 4.6: Securely Manage Enterprise Assets and Software.)
• For BEAST, upgrade to TLS 1.2 or higher. If upgrading is not feasible, disable CBC mode ciphers. (See CIS Critical Security Control 4.6: Securely Manage Enterprise Assets and Software.)
• For POODLE, disable SSL 3.0 on all systems and enforce the use of TLS 1.2 or higher. (See CIS Critical Security Control 4.6: Securely Manage Enterprise Assets and Software.)
• Conduct regular vulnerability assessments and penetration tests with a qualified red team, such as the CIS Red Team, to proactively identify and address weaknesses. (See CIS Critical Security Control 18: Penetration Testing.)
• Eligible organizations who provide their external IPs to CIS may receive notifications when we observe potentially vulnerable software on their network. (See CIS Critical Security Control 7.1 and 7.2: Establish and Maintain a Vulnerability Management Process and a Remediation Process.)
• Maintain a comprehensive inventory of all software assets to identify and remove outdated or unsupported components. (See CIS Critical Security Control 2: Inventory and Control of Software Assets.)

Leverage the Power of Tailored Threat Intelligence

This threat intelligence briefing illustrates how the CIS CTI team supports members of the Multi-State Information Sharing and Analysis Center^® (MS-ISAC^®). Available to U.S. State, Local, Tribal, and Territorial (SLTT) government entities, MS-ISAC membership enables organizations to share information and collaborate on defending against cyber threats. The CIS CTI team supports members by maintaining the only STIX/TAXII threat intelligence feed tailored to U.S. SLTTs. It also routinely releases threat intelligence briefings along with detailed reports, such as the Quarterly Threat Report and Operational Cyber Analytic Report, to provide decision-makers with actionable threat intelligence they can use to take a proactive approach to their organization's cyber defense.

Ready to augment your cybersecurity posture using the expertise of the CIS CTI team?