3.13.15 — Protect Session Integrity

The One-Liner

If an attacker can take over your active session or insert themselves between two communicating systems, your communications aren’t trustworthy.

What It Says

Protect the authenticity of communications sessions.

What It Actually Means

Session authenticity means both sides of a communication can verify they’re talking to the legitimate party — and that the session can’t be taken over mid-stream.

Threats this addresses:

• Session hijacking — attacker steals a session cookie or token and takes over an active session
• Man-in-the-middle (MITM) — attacker intercepts communications between two systems, reading or modifying data in transit
• Session fixation — attacker sets a known session ID before the user authenticates

Controls that satisfy this:

• TLS 1.2+ with strong cipher suites — encrypts and authenticates the session
• HSTS (HTTP Strict Transport Security) — prevents downgrade attacks from HTTPS to HTTP
• Secure session tokens — random, unpredictable, short-lived, transmitted only over encrypted channels
• Certificate validation — verify TLS certificates are valid, not self-signed or expired
• Mutual TLS — both client and server authenticate via certificates (for service-to-service)

The assessor will check your TLS configuration, HSTS headers, and session management settings.

---

Pass or Fail

Your assessor needs a “yes” to every row:

#	Question	What “yes” looks like
1	Are communications sessions protected from hijacking?	TLS, HSTS, secure session management implemented
2	Are mechanisms in place to verify session authenticity?	Certificate validation, mutual TLS where appropriate

---

What to Have Ready on Assessment Day

Documents they’ll review: System and communications protection policy; system security plan; system configuration settings for TLS and session management; HSTS configuration; certificate management documentation

People they’ll talk to: System or network administrators; personnel with information security responsibilities; system developers

Live demos they’ll ask for: TLS configuration; HSTS headers; session token security; certificate validation

---

The Assessor’s Playbook

These are the actual questions. Have answers ready.

• “What TLS version and cipher suites do your web applications use?”
• “Is HSTS enabled on your web services? Show me the headers.”
• “How are session tokens generated — are they random and unpredictable?”
• “What’s the session token lifetime?”
• “Do you use mutual TLS for any service-to-service communications?”
• “Show me certificate validation is enforced — what happens with an expired or self-signed cert?”

Real-World Example

A contractor’s web applications are configured with: TLS 1.3 (TLS 1.0/1.1 disabled), HSTS headers with a 1-year max-age and includeSubDomains, session tokens generated using cryptographically secure random number generators, 1-hour session lifetime with re-authentication, and certificate pinning for critical internal services. The assessor runs an SSL Labs scan against the public web application — scores A+. Checks the response headers — HSTS present with 31536000 max-age. Attempts to access with an expired certificate — connection refused.

---

Where Companies Trip Up

No HSTS. Users can be redirected from HTTPS to HTTP via a MITM attack. Enable HSTS headers.

Weak cipher suites. Allowing RC4, DES, or export-grade ciphers. Configure strong cipher suites only.

Long-lived session tokens. Tokens that last for days or weeks. Keep session lifetimes short — 1 hour for sensitive applications.

Self-signed certificates accepted. Applications configured to skip certificate validation. Always validate certificates.

TLS 1.0/1.1 still enabled. Deprecated and vulnerable. Disable them. TLS 1.2 minimum.

---

How to Talk About This

To a CEO or Board

Our communications are protected against session hijacking and interception. Both sides verify each other’s identity, and sessions can’t be taken over.

To an Engineering Team

TLS 1.2+ (1.3 preferred), strong ciphers only. HSTS: 1-year max-age, includeSubDomains. Session tokens: CSPRNG, 1-hour lifetime, secure flag. Certificate validation enforced everywhere. Mutual TLS for service-to-service. TLS 1.0/1.1 disabled.

---

Connected Requirements

Requirement	Why it matters here
3.13.8 — Encrypt in Transit	TLS provides both encryption and session authenticity
3.5.4 — Replay-Resistant Auth	Authentication that prevents session replay attacks
3.13.11 — FIPS or It Doesn’t Count	TLS modules must be FIPS-validated

---

Implementation (coming soon)

Step-by-step setup for Microsoft 365 / Entra ID, AWS, Azure, and GCP — console steps, CLI commands, and evidence screenshots.

---

CMMC Practice ID: SC.L2-3.13.15 | SPRS Weight: 5 points | POA&M Eligible: No