6.3 Public Key Infrastructure (PKI), TLS & Network Security

Public Key Infrastructure (PKI), TLS & Network Security

Quick Summary: Public Key Infrastructure (PKI) provides the organizational hierarchy, digital certificates, and revocation mechanisms that establish verifiable trust across untrusted networks. Coupled with Transport Layer Security (TLS 1.3), Virtual Private Networks (VPNs), and Zero Trust Architecture (ZTA), these technologies protect corporate communications against interception, session tampering, and lateral threat movement.

---

1. Public Key Infrastructure (PKI) Architecture & Hierarchy

While asymmetric cryptography provides public and private keys, it presents a fundamental vulnerability: The Trust Problem. How can a user verify that a public key belonging to banking.com genuinely belongs to their financial institution rather than an adversary conducting a man-in-the-middle attack? Public Key Infrastructure (PKI) solves this by binding public keys to verified legal identities through digitally signed X.509 Digital Certificates.

The Core Components of PKI

1. Certificate Authority (CA): The trusted third party that validates identities and issues digitally signed digital certificates.
   • Root CA: The apex of trust. The Root CA issues a self-signed root certificate embedded directly into operating system and browser trust stores (e.g., Microsoft, Apple, Mozilla). To prevent catastrophic compromise, the Root CA is kept permanently offline in an air-gapped physical vault.
   • Intermediate (Subordinate) CAs: Online operational CAs authorized by the Root CA to handle daily certificate issuance. If an intermediate CA is compromised, only that intermediate branch is revoked, leaving the offline Root CA secure.
2. Registration Authority (RA): An operational entity that verifies the identity and credentials of applicants before requesting the CA to generate certificates. The RA does not sign certificates itself.
3. Certificate Repository: A publicly accessible directory hosting active certificates and revocation data.

Anatomy of an X.509 v3 Digital Certificate

Defined by ITU-T recommendation X.509 and RFC 5280, a standard digital certificate contains standardized metadata:

• Version: Typically v3 (supporting extensions).
• Serial Number: Unique identifier assigned by the issuing CA.
• Signature Algorithm: Cryptographic cipher used by the CA to sign the certificate (e.g., sha256WithRSAEncryption).
• Issuer: Distinguished Name (DN) of the issuing Certificate Authority.
• Validity Period: Strict "Not Before" and "Not After" calendar dates.
• Subject: Identity of the certificate owner (e.g., Common Name CN=api.company.com or Subject Alternative Name SAN).
• Subject Public Key Info: The actual public key (RSA 2048/4096 or ECC P-256) and its algorithm identifier.
• Extensions: Key usage constraints (e.g., Server Authentication, Client Authentication, Code Signing) and CRL/OCSP endpoints.
• CA Digital Signature: The hash of the above fields encrypted with the issuing CA's private key.

---

2. Certificate Revocation: CRL vs. OCSP vs. OCSP Stapling

A certificate must be revoked before its natural expiration date if the associated private key is compromised, the domain ownership changes, or the employee departs.

Certificate Revocation List (CRL)

A CRL is a time-stamped list of revoked certificate serial numbers signed and published periodically by the CA.

• Operational Limitations: CRL files grow substantially over time, consuming bandwidth. Furthermore, browsers cache CRLs; if an attacker compromises a private key between CRL publication intervals, client browsers accept the fraudulent certificate as valid.

Online Certificate Status Protocol (OCSP - RFC 6960)

OCSP replaces bulky lists with a real-time protocol. When a client connects to a server, the client sends a query containing the certificate serial number directly to the CA's OCSP Responder, which replies with one of three statuses: Good, Revoked, or Unknown.

• Operational Limitations:
  • Privacy Leak: The CA learns the IP address of every client and every website the client visits.
  • Performance Latency: Every new TLS connection requires a separate DNS lookup and HTTP round-trip to the CA's OCSP responder.
  • Soft-Fail Vulnerability: If the CA's OCSP server goes offline or is blocked by an attacker, most browsers default to "soft-fail" (allowing the connection anyway), nullifying revocation protection.

OCSP Stapling (TLS Certificate Status Request)

OCSP Stapling eliminates both the privacy leak and performance overhead:

1. The web server queries the CA's OCSP responder at regular intervals (e.g., every 60 minutes).
2. The CA returns a digitally signed, timestamped OCSP response to the web server.
3. During the initial TLS handshake with a client, the web server "staples" this signed OCSP response directly to the certificate it presents to the client.
4. The client verifies the CA's signature on the stapled response without ever communicating with the CA.

---

3. Transport Layer Security (TLS) and the Handshake Protocol

Despite its name, Transport Layer Security (TLS) runs above the transport layer: it rides on top of TCP and secures application data, which maps to the OSI session/presentation layers (Layers 5-6) rather than Layer 4 itself. It provides encrypted, authenticated communication channels for application protocols, most prominently HTTPS over TCP port 443.

Protocol Evolution and Deprecations

• SSL 2.0 / 3.0: Completely broken (vulnerable to POODLE and cipher degradation). Prohibited under all audit frameworks.
• TLS 1.0 / 1.1: Formally deprecated by NIST and the Internet Engineering Task Force (IETF RFC 8996). Vulnerable to BEAST and CRIME attacks, and lacks modern cipher support. Any system using TLS 1.0/1.1 fails PCI-DSS and SOC 2 security evaluations.
• TLS 1.2: Established in 2008 (RFC 5246). Secure when configured with authenticated ciphers (AES-GCM), but requires two full network round-trips (2-RTT) and allows legacy, non-forward-secret ciphers.
• TLS 1.3: Ratified in 2018 (RFC 8446). The current gold standard, engineered for speed and cryptographic minimization.

Architectural Advances in TLS 1.3

1. 1-RTT Handshake Latency: TLS 1.3 reduces the handshake from two network round-trips to one round-trip (1-RTT) by guessing the server's key exchange algorithm and sending the client's Diffie-Hellman key share in the very first ClientHello message. Returning visitors can utilize 0-RTT resumption.
2. Aggressive Cipher Pruning: TLS 1.3 completely removed all deprecated, insecure cryptographic constructs: no static RSA key transport, no CBC-mode block ciphers, no SHA-1 or MD5 hashing, and no RC4 stream ciphers.
3. Mandatory Perfect Forward Secrecy (PFS): In legacy systems using static RSA key exchange, if an attacker recorded encrypted network traffic over years and subsequently stole the server's long-term private key, the attacker could retroactively decrypt all historical communications. TLS 1.3 mandates Ephemeral Diffie-Hellman (ECDHE) for all connections. Each session generates unique, temporary keys that are discarded immediately post-session; compromising the server's long-term certificate private key does not compromise past sessions.

---

4. Virtual Private Networks (VPNs): IPsec vs. SSL/TLS

Virtual Private Networks establish encrypted tunnels across public networks, enabling secure remote workforce connectivity and branch-office interconnectivity.

IPsec VPN Architecture (OSI Layer 3 - Network Layer)

IPsec operates directly at the IP layer, securing all communications between endpoints regardless of application.

• Authentication Header (AH): Provides data integrity and authentication, but no confidentiality (no encryption). Rarely used in isolation.
• Encapsulating Security Payload (ESP): Provides confidentiality (encryption), data origin authentication, and anti-replay protection. Industry standard.
• Operational Modes:
  • Transport Mode: Encrypts only the IP packet payload, leaving the original IP packet header untouched. Used primarily for host-to-host communications on trusted internal networks.
  • Tunnel Mode: Encrypts the entire original IP packet (header and payload) and prepends a brand-new external IP header. Standard for site-to-site VPNs connecting branch offices to corporate headquarters.
• Internet Key Exchange (IKEv2): The protocol that authenticates endpoints, negotiates security associations (SAs), and exchanges keys.

SSL/TLS VPN Architecture (OSI Layer 4–7 - Transport/Application Layer)

SSL/TLS VPNs operate at higher network layers, utilizing standard web browsers or lightweight client software.

• Clientless Web VPNs: Users access specific internal web applications via an authenticated web portal without installing any endpoint software.
• Client-Based SSL VPNs: A lightweight virtual network adapter routes traffic from the user endpoint through a secure TLS tunnel.

---

5. Network Segmentation and Microsegmentation

Traditional enterprise security relied upon the Perimeter ("Castle-and-Moat") Model: build a formidable perimeter firewall, trust everything inside the internal network, and inspect only incoming external traffic. In modern hybrid cloud environments, the perimeter model is catastrophically deficient—once an adversary establishes an initial foothold (via phishing or unpatched VPN vulnerability), they move laterally across the flat network with impunity.

Traditional Network Segmentation

• Demilitarized Zone (DMZ): A perimeter network segment bounded by firewalls that hosts external-facing services (web servers, public DNS, mail gateways). Internal database servers are separated from the DMZ by an internal firewall.
• Virtual Local Area Networks (VLANs) & ACLs: Dividing physical switches into logical broadcast domains. Traffic between VLANs must pass through a router or firewall enforcing Access Control Lists (ACLs).
• Traffic Dimensions:
  • North-South Traffic: Traffic entering or leaving the enterprise data center from the external internet.
  • East-West Traffic: Traffic moving laterally between servers, containers, or virtual machines inside the internal data center.

Microsegmentation

Microsegmentation is the granular isolation of individual workloads, containers, and virtual machines within the same subnet.

• Enforced via Software-Defined Networking (SDN) controllers, cloud security groups, and host-based distributed firewalls.
• Prevents East-West lateral movement: Even if an attacker compromises Web Server A, host-level microsegmentation rules prevent Web Server A from communicating with Web Server B on the same subnet, completely containing the blast radius.

---

6. Zero Trust Architecture (ZTA - NIST SP 800-207)

Zero Trust Architecture replaces implicit perimeter trust with an uncompromising operational doctrine: "Never Trust, Always Verify."

The Seven Tenets of Zero Trust (NIST SP 800-207, Section 2.1)

NIST SP 800-207 defines zero trust through seven tenets. Many vendor summaries compress them into a three-line slogan ("verify explicitly, use least privilege, assume breach"); that shorthand is a marketing abstraction, not the NIST list:

1. All data sources and computing services are considered resources. A personally owned phone reading corporate email is a resource; so is a forgotten virtual machine.
2. All communication is secured regardless of network location. Being inside the office LAN confers no trust; internal east-west traffic is authenticated and encrypted like internet traffic.
3. Access to individual enterprise resources is granted on a per-session basis. Trust is evaluated for this request, with the least privilege needed to complete this task, and it does not carry to the next resource.
4. Access to resources is determined by dynamic policy, incorporating client identity, application/service, the requesting asset's observable state, and behavioral and environmental attributes.
5. The enterprise monitors and measures the integrity and security posture of all owned and associated assets. No asset is inherently trusted; posture is continuously re-measured (patch level, configuration, known vulnerabilities).
6. All resource authentication and authorization are dynamic and strictly enforced before access is allowed. Authentication is a continuous cycle of scan, assess, re-evaluate — not a one-time login event.
7. The enterprise collects as much information as possible about the current state of assets, network infrastructure and communications, and uses it to improve its security posture. Telemetry feeds the policy engine.

Exam framing: "Zero trust" appears in the ISC blueprint alongside least privilege, whitelisting and need-to-know as a definitional task ("Define the concepts of least-privilege, zero-trust, whitelisting and the need-to-know principle"). Be able to state the never-trust-always-verify premise and recognize that trust decisions are per-session, dynamic, and based on continuously refreshed asset posture.

Structural Components: Control Plane vs. Data Plane

• Policy Engine (PE): The brain of ZTA. Evaluates enterprise policy rules alongside real-time threat intelligence and context to decide whether to grant, deny, or revoke access.
• Policy Administrator (PA): The control plane coordinator. Communicates with the Policy Engine to issue commands to establish or terminate communication paths between subject and resource.
• Policy Enforcement Point (PEP): The data plane gateway. Intercepts all traffic between user and enterprise resource, enabling, monitoring, and terminating connections as instructed by the Policy Administrator.

---

7. Audit and Assurance Considerations for PKI and Network Security

When evaluating network and cryptographic security controls under AICPA Trust Services Criteria (CC6.1, CC6.6, CC6.7), auditors perform rigorous substantive and control tests:

PKI and Certificate Audit Testing

1. Inspect Root CA Security: Verify that enterprise Root CAs reside in physically secure, climate-controlled, biometric-restricted vaults and remain powered off when not signing intermediate CAs.
2. Evaluate Certificate Expiration Monitoring: Test whether management utilizes automated certificate lifecycle management (CLM) platforms to track expiration dates, preventing service outages caused by unexpected certificate expiration.
3. Test Revocation Enactment: Verify that compromised certificates are added to revocation systems immediately and that web servers enforce OCSP Stapling with the must-staple flag.

Network Segmentation and Firewall Rulebase Audit Testing

1. Review Firewall Rulebase Architecture:
   • Inspect firewall configuration exports for overly permissive rules (e.g., rules configured with Source: ANY, Destination: ANY, Action: ALLOW).
   • Verify that the bottom rule in every firewall rulebase is an explicit "Deny All / Drop All" rule.
2. Review Firewall Change Governance: Ensure every firewall rule modification is tied to an authorized change ticket documenting the business justification, port requirements, and source/destination IP ranges.
3. Test Microsegmentation Operating Effectiveness: Inspect penetration test reports and automated vulnerability scans. Verify that automated scans confirmed the inability of workloads in test/development environments to communicate with production databases across network boundaries.