Audit a TLS Configuration — UprootSecurity Bootcamp

Reading a TLS scan and turning it into a remediation plan is a core GRC Engineer skill — it is the difference between "the SSL Labs report says C" and "here is exactly what to fix, who owns it, and what proves it's fixed." In this exercise you will first work through how to read a scan report, then translate a real-world-style transit-encryption finding into a concrete technical remediation plan in YAML.

Running the SSL Labs scan on the legacy endpoint

Warm-up: reading the scan

Before the main exercise, calibrate on how each scan result maps to a control gap.

Quick check

An SSL Labs scan of api.example.com returns grade B with these notes: TLS 1.3 and 1.2 supported; TLS 1.0 also enabled; one cipher suite without forward secrecy; certificate valid, expires in 9 days, renewed manually. Which item is the most urgent to act on right now?

The grade B — push it to A+ before anything else

The certificate expiring in 9 days with manual renewal — an expiry causes a hard outage and there is no automation to prevent it; that is the immediate operational risk, alongside disabling TLS 1.0

The forward-secrecy cipher — it is the only thing that matters

Nothing is urgent; grade B is acceptable

Quick check

A scan of an internal service-to-service endpoint shows it accepts plaintext (no TLS) connections on the internal network, with the justification 'it's behind the firewall, so the network is trusted.' How should you assess this?

Acceptable — internal traffic on a trusted network does not need encryption

A finding: internal traffic carrying sensitive data should be encrypted (TLS, ideally mTLS) regardless of network location — "trusted network" is exactly the assumption zero-trust and modern frameworks reject, and an attacker with any internal foothold can read plaintext east-west traffic

Only a finding if the data is PII; all other internal traffic can be plaintext

Acceptable as long as the firewall logs the connections

The exercise: translate the finding

Below is a SOC 2-style transit-encryption finding. Write the remediation plan in YAML — name the technical root cause, the concrete fix steps with owners and evidence, the evidence package, and a timeline. Apply everything from the TLS lesson: disable deprecated protocols, fix the cipher policy, and automate the certificate lifecycle with an inventory.

Exercise

~30 min

Translate this audit finding into a technical remediation plan

SOC 2 Type II Finding

Weak and inconsistent encryption-in-transit configuration

ID:

CC6.7-2026-014

Criterion:

CC6.7 — Protecting data in transit

Severity:

High

During testing we scanned the organization's internet-facing and internal endpoints. The primary web application (app.example.com) supports TLS 1.2 and 1.3 with strong ciphers. However, a legacy admin portal (admin.example.com) still accepts TLS 1.0 and 1.1 and offers two cipher suites without forward secrecy. The TLS certificate for admin.example.com expires in 12 days and is renewed manually by a single engineer; there is no certificate inventory or expiry monitoring. Additionally, two internal microservice endpoints accept plaintext HTTP connections on the internal network.

Auditor Notes

Management represented that policy requires TLS 1.2 minimum (IS-009). The admin portal predates the policy and was not remediated. No certificate management tooling is in place; the last near-miss expiry caused a 40-minute outage in the prior period. The 'trusted internal network' rationale was cited for the plaintext microservice traffic.

Write your remediation plan in YAML below. Fill in every field — replace all placeholder comments.

Loading editor…

How to use this in practice

When you audit encryption in transit as a GRC Engineer, work three questions for every endpoint — internal ones included: what protocol version and cipher policy does it offer (prove it with a scan, not a claim), is service-to-service traffic actually encrypted or just assumed-safe behind a firewall, and is the certificate lifecycle automated with an inventory and expiry alerting. A remediation plan is only as good as the evidence it specifies, so for each fix name the artifact that proves it — a scan report, a config diff, a certificate inventory, an expiry alert. That is what turns "we use TLS" into a demonstrable, auditable control.