Security & Risks
6.1 Threat Landscape for Data Transmission
Critical data transmission systems face a broad and evolving threat landscape that spans passive interception, active manipulation, credential theft, and cryptographic weaknesses. Understanding the specific threat actors, their capabilities, and the attack vectors they exploit is essential for designing controls that are proportionate to the actual risk. The threat landscape has shifted significantly in recent years with the widespread adoption of cloud services, remote work, and API-driven architectures, each of which introduces new exposure surfaces that traditional perimeter-based security models do not adequately address.
The primary threat categories for data-in-transit security are organized into four tiers based on attacker sophistication and the controls required to mitigate them. Nation-state actors and advanced persistent threats (APTs) represent the highest tier, capable of exploiting zero-day vulnerabilities in cryptographic implementations and conducting long-duration supply chain attacks. Organized criminal groups represent the second tier, primarily motivated by financial gain through credential theft, ransomware, and data exfiltration. Insider threats — both malicious and negligent — represent the third tier, with privileged access that bypasses many perimeter controls. Opportunistic attackers represent the fourth tier, exploiting known vulnerabilities and misconfigurations at scale using automated tools.
| Threat Category | Attack Vector | Target Asset | Likelihood | Impact | Risk Level | Primary Mitigation |
|---|---|---|---|---|---|---|
| TLS Downgrade Attack | MITM / Protocol negotiation | Encrypted channels | Medium | High | High | Enforce TLS 1.3 minimum, disable legacy protocols |
| Certificate Spoofing | Rogue CA / BGP hijack | PKI trust chain | Low | Critical | High | Certificate pinning, CAA records, CT logs |
| Credential Theft (API Keys) | Code repo exposure, phishing | API authentication | High | High | Critical | Short-lived tokens, secret scanning, rotation |
| IPsec Tunnel Hijacking | IKE aggressive mode exploit | Site-to-site VPN | Low | High | Medium | IKEv2 only, strong PSK/cert, PFS enabled |
| SSH Brute Force | Direct SSH exposure | Admin access | High | Critical | Critical | Bastion host, MFA, key-only auth, fail2ban |
| Lateral Movement | Compromised service account | Internal east-west | Medium | Critical | High | mTLS, network policy, micro-segmentation |
| Log Tampering | Compromised SIEM credentials | Audit trail | Low | High | Medium | Immutable log storage, WORM, dual-custody |
| Cryptographic Weakness | Weak cipher negotiation | Encrypted data | Medium | High | High | Cipher suite hardening, regular crypto review |
| Supply Chain Attack | Compromised library/firmware | All components | Low | Critical | High | SBOM, signed artifacts, integrity verification |
| Insider Data Exfiltration | Privileged access abuse | Sensitive data flows | Medium | High | High | DLP, session recording, behavioral analytics |
6.2 Cryptographic Risk Management
Cryptographic controls are the foundation of data transmission security, but they introduce their own risk surface through algorithm deprecation, implementation vulnerabilities, and key management failures. A structured cryptographic risk management program ensures that the organization maintains an inventory of all cryptographic assets, monitors for algorithm deprecation announcements, and has tested migration procedures ready before deprecation deadlines. The emergence of quantum computing as a long-term threat requires organizations handling data with long confidentiality requirements to begin planning post-quantum cryptography (PQC) migrations now, even though the threat is not yet realized.
| Algorithm / Protocol | Current Status | Risk Level | Recommended Action | Migration Timeline |
|---|---|---|---|---|
| TLS 1.0 / 1.1 | Deprecated (RFC 8996) | Critical | Disable immediately | Immediate |
| TLS 1.2 | Acceptable (with hardened ciphers) | Medium | Restrict to AEAD ciphers; plan TLS 1.3 migration | Within 2 years |
| TLS 1.3 | Recommended | Low | Enforce as minimum; monitor for vulnerabilities | Ongoing |
| RSA-1024 | Deprecated | Critical | Replace with RSA-2048+ or ECDSA P-256 | Immediate |
| RSA-2048 | Acceptable | Low-Medium | Acceptable until 2030; plan PQC migration | Before 2030 |
| AES-128-CBC | Acceptable (with HMAC) | Medium | Prefer AES-256-GCM (AEAD) | Within 1 year |
| AES-256-GCM | Recommended | Low | Preferred cipher; use for all new deployments | Ongoing |
| SHA-1 | Deprecated for signatures | High | Replace with SHA-256 or SHA-384 | Immediate |
| SHA-256 / SHA-384 | Recommended | Low | Standard for all new deployments | Ongoing |
| IKEv1 (IPsec) | Deprecated | High | Migrate to IKEv2 | Immediate |
| CRYSTALS-Kyber (PQC) | NIST Standard (FIPS 203) | Low (future) | Evaluate for long-lived data; plan hybrid deployment | 2025–2030 |
6.3 Compliance Framework Mapping
Critical data transmission security controls must be mapped to applicable regulatory and industry compliance frameworks to ensure audit readiness and demonstrate due diligence. The mapping below covers the most commonly applicable frameworks for organizations handling sensitive data, showing which specific controls in this guide satisfy each framework's requirements. Organizations subject to multiple frameworks should use the most stringent requirement as the baseline, as this typically satisfies all less-stringent requirements simultaneously.
| Control Domain | This Guide Section | PCI DSS v4.0 | NIST SP 800-53 | ISO 27001:2022 | HIPAA | GDPR Art. |
|---|---|---|---|---|---|---|
| Transport Encryption | Ch. 1, 2, 4 | Req. 4.2.1 | SC-8, SC-28 | A.8.24 | §164.312(e)(2)(ii) | Art. 32 |
| Certificate Management | Ch. 1, 5 | Req. 4.2.1 | SC-17, IA-5 | A.8.24 | §164.312(a)(2)(iv) | Art. 32 |
| Key Management | Ch. 1, 5 | Req. 3.7 | SC-12, SC-28 | A.8.24 | §164.312(a)(2)(iv) | Art. 32 |
| Network Segmentation | Ch. 4 | Req. 1.3 | SC-7, AC-4 | A.8.22 | §164.312(a)(1) | Art. 25, 32 |
| Access Control / MFA | Ch. 3F, 5 | Req. 8.4 | IA-2, AC-2 | A.8.2, A.8.5 | §164.312(d) | Art. 32 |
| Audit Logging | Ch. 1, 6 | Req. 10.2 | AU-2, AU-9 | A.8.15 | §164.312(b) | Art. 30, 32 |
| Vulnerability Management | Ch. 6, 7 | Req. 6.3 | RA-5, SI-2 | A.8.8 | §164.308(a)(1) | Art. 32 |
| Incident Response | Ch. 12 | Req. 12.10 | IR-4, IR-6 | A.5.26 | §164.308(a)(6) | Art. 33, 34 |