Summary
Digital transformation is expanding the enterprise attack surface faster than teams can secure it. This white paper from Authentic Web sets out nine known TLS and DNS risks that put enterprise security and compliance at risk, and argues that the main cause is people working in silos with manual, legacy processes, so security needs a systems-based approach.
Key points
- The “chain of trust” for data in motion depends on flawless TLS and DNS implementation, and the human factor is the single greatest enterprise risk.
- Only 3.8% of the domains in a Farsight Security sample had DNSSEC implemented: 141 true against 3,618 false.
- The nine risks: TLS version control, chain of trust key exchange, certificate authority compromises, weak endpoint verification, expanding top-level domains, lack of DNSSEC, compliance monitoring, human error and network scaling cost.
- The paper proposes anchoring trust on a brand registry (a .brand TLD) with an automated management system.
The digital chain of trust is broken
Digital transformation is expanding the enterprise attack surface, and network endpoints are growing exponentially. Deloitte cites the World Economic Forum Global Risks Report 2017: “Digital technologies and innovation are growing exponentially, accelerating cyber risks, new attack vectors, and greatly expanding the attack surface that organizations must patrol and defend” (Deloitte, Take the lead on cyber risk, 2017). Alan Woodward, professor of computer science at the University of Surrey, says “BGP and DNS are the soft underbelly of the web”.
Endpoints are where proprietary enterprise and customer data is captured, processed and set in motion, so data-in-motion security depends on flawless DNS and TLS implementation and monitoring to maintain the chain of trust. Digital business services run on the Domain Name System, the network foundation for digital communications, customer engagement and service delivery. A query involves a client computer, the internet service provider’s DNS server, a root DNS server, the top-level DNS server (for example for .com) and the company’s own DNS server, so a failure at any step exposes the business.
DNS and Transport Layer Security (TLS)
DNS has known security exposures because DNSSEC is under-used and connections using TLS encryption and authentication are poorly managed. DNSSEC and TLS promise a foundation of security, but legacy tools, outdated processes and human actions create exposure, and data security and compliance need revisiting as DNS networks scale. Enterprise systems and processes tend to operate in silos, and a lack of visibility, control and compliance over the actions and inactions of personnel is the primary source of network security vulnerability. Lack of compliance among internal, partner and supplier parties weakens the chain of trust. Independent research cited in the paper finds the biggest enterprise risk is reliance on people operating in silos with legacy tools and inconsistent expertise and motivation.
| External threats | Internal causes |
|---|---|
| Social engineering, botnets, DDoS, man-in-the-middle, DNS hacks, TLS compromise, domain hijack, malware, exfiltration | Key exchange automation, errors, omissions, policy enforcement, process controls, lack of expertise |
TLS and DNS: the frontline of data-in-motion security
Transport Layer Security authenticates communications between systems and encrypts data in motion. DNS is the address book of the internet, routing data between endpoints. Gartner (Best Practices for Detecting and Mitigating Advanced Threats, 2016) says “silos between network edge, endpoint and data security systems can restrict an organization’s ability to prevent, detect and respond to advanced attacks”. Enterprises use many third-party vendors for TLS and rely on internal staff and Certificate Authority (CA) employees, and with separate teams, siloed systems and manual processes, control and visibility over the factors that can break the chain of trust is practically impossible.
TLS: manual steps to establish one endpoint
Securing a single server host or DNS endpoint takes a 16-step manual process, and many steps can invalidate the certificate if done wrong:
- Create a new private key (an invalid key means a new key is needed).
- Store the key securely (a key security issue invalidates the CSR and HTTPS certificate).
- Prepare the CSR (incomplete documents or errors prevent or invalidate it).
- Submit the CSR to the CA (a poor choice of CA can invalidate the certificate).
- Receive the confirmed CSR from the CA.
- Prepare the HTTPS certificate order (an incorrect type, shared, DV, OV or EV, is an error).
- Paste the CA-issued CSR into the order form (an error invalidates the certificate).
- Specify the domain validation control method.
- Receive the signed certificate and download it.
- Back up existing keys and certificates (errors installing new certificates can invalidate existing ones).
- Open the SSL manager or server (installation varies by server type, and a company may have several).
- Select and upload the certificate.
- Verify the HTTPS fields are correct.
- Test that HTTPS is active (errors can be missed without a final test).
- Manage and maintain certificates.
- Renew certificates (track the renewal date).
Multiply that by hundreds or thousands of endpoints over their lifecycle, while vendors evolve and staff turn over. TLS deployments are hard to trust because of manual steps, people dependencies and lifecycle management.
DNS security: DNSSEC implementation
Like TLS, the DNS chain of trust depends on proper implementation and maintenance of DNSSEC, which protects against man-in-the-middle compromises. A paper from MIT (Security Vulnerabilities in DNS and DNSSEC) concludes that DNS has major security issues to address urgently: man-in-the-middle attacks and cache poisoning arise from a lack of authentication and integrity in the DNS transaction process, and DNSSEC, developed by the IETF, “allows transaction level authentication and secure zone transfers protecting all data in the zone during the transfer”.
Despite the acknowledged value, adoption is low. Farsight Security research shows 141 domains with DNSSEC against 3,618 without, so 3.8% implemented, leaving data in motion exposed to recursive server DNS cache poisoning. DNSSEC takes technical expertise and diligence over the endpoint lifecycle and must be configured at both the registrar/registry level and the managed DNS level. DNSKEY management complexity and administrative oversights can cause loss of route lookup authenticity, often without IT staff knowing.
The 9 security risks with TLS and DNS
1. TLS version control
Old versions of SSL and TLS (before version 1.3) have numerous known security weaknesses. Failing to track and update legacy versions exposes data in motion to security and compliance risk. Enforcing TLS version control and best-practice implementation reduces it.
2. Chain of trust key exchange practices
Trusted key exchange and storage depend on people: internal staff, third-party CAs and third-party endpoint server administrators. The chain of trust assumes every party acts professionally, without error and without exception. With silos, separate business entities and disparate systems, guaranteeing the chain over the lifecycle of even one TLS endpoint is practically impossible, let alone hundreds or thousands.
3. CA compromises: market disruption and uncertainty
CA compromises are frequent and ongoing. When a CA is compromised, fraudulent or exposed certificates are issued and used, undermining the trust parties place in SSL certificates. Any entity can establish itself with a browser firm to be included in CA bundles, and CA/Browser Forum standards are arguably hard to enforce. New CA business models such as Let’s Encrypt’s free certificates add disruption. Browser firms have flagged non-compliant CA practices: Google declared certain Symantec certificates untrustworthy after chain of trust failures, and SSL reseller Trustico was exposed when an executive reportedly emailed 23,000 private keys, making affected Symantec, GeoTrust, Thawte and RapidSSL certificates untrustworthy. The paper’s conclusion is that trusted SSL coverage is increasingly uncertain.
4. CA endpoint or entity verification is weak
A domain-validated certificate can be obtained when the CA only checks that the requester controls a web server or the DNS of the domain. That does not stop attackers who access servers to show control, hack a DNS service, use social engineering or run a man-in-the-middle attack. Initiatives such as the Google TLS Transparency Project are slowly addressing this, but verification remains a weak link. Extended validation certificates may be more effective, but the difference may not be noticeable, and their high cost and manual administration make them impractical for scaled network TLS.
5. Expanding top-level domain spaces
The expansion of new TLDs has created trust and brand identity challenges. In a noisy, largely unregulated name space, a signed TLS certificate holds little inherent trust, yet users tend to trust anything with a certificate. That gives attackers more room to register domains that look brand-authentic and TLS-enabled. The exception is a brand TLD or brand registry, where authority, authenticity and control are verifiable by ICANN and can anchor digital trust.
6. DNSSEC: lack of use and understanding
Under-deployment of DNSSEC exposes the enterprise to man-in-the-middle attacks. Without DNSSEC, cache poisoning lets attackers reroute valid queries to fraudulent destinations. Operators have not widely implemented it because of lack of knowledge and lack of integrated control systems to implement it and manage DS keys. As ICANN (2019) puts it, full deployment of DNSSEC “will ensure the end user is connecting to the actual web site or other service corresponding to a particular domain name”, protecting the directory lookup and complementing SSL.
7. Compliance: chain of trust monitoring and remediation
Automated monitoring and remediation of TLS and DNS security policy is not widely deployed. Organizations may monitor connections, data flow and active status, but even with DNS threat detection tools, connections are rarely checked for compliance with TLS and DNS policy. Automating monitoring and remediation is critical to chain of trust integrity over the lifecycle.
8. The human factor: operating errors and omissions
Organizations rely on internal and third-party people to ensure DNS and TLS compliance, and expect them to perform flawlessly at all times. Even strict policies and procedures are not enough: people make mistakes, forget, are overworked, don’t know, don’t care, sometimes deliberately don’t act, and turn over, which erodes institutional knowledge. The paper calls the human factor the single greatest enterprise risk, one that requires system-based automation (reference: SANS Incident Response Survey 2017).
9. Network scaling: digital transformation complexity
Growth in scale and complexity of the digital attack surface adds pressure on infrastructure and operations teams to scale efficiently while keeping data security compliance. Current TLS and DNS practices rely on complex manual processes and dependencies, and it is too costly and inefficient to keep compliance with manual legacy practices.
Summary and conclusion
Network communications depend on DNS using TLS, and the nine risks show a fragile ecosystem for securing growing numbers of endpoints. Known process flaws compromise the chain of trust for data in motion, and the main source is people using antiquated legacy processes. Without systems that scale economically, teams cannot be trusted to ensure security compliance. Authentication and HTTPS encryption across all endpoints has proven hard, and the widespread failure to deploy DNSSEC despite repeated calls from security and regulatory agencies underlines the exposure. IT security and network infrastructure managers need an easier, more scalable way to ensure authentication and encryption of enterprise data in motion.
The brand registry can solve chain of trust issues
The paper proposes a systems-based approach anchored on the trust authority of a brand registry. Brand registries are highly securable assets with stronger encryption and authentication than generic TLD-based DNS networks. Authentic Web built these strengths into a system that secures the DNS chain of trust: it automates, monitors and remediates network connections, and assures TLS security and application authentication with remediation and auditability over the lifecycle of all endpoints. Use cases named: supply chain, cloud, IoT, applications and EDI.
To learn more, contact Authentic Web at info@authenticweb.com, North America 1.855.436.8853, international +1.416.583.3770.