Practice and strategy · Module 3
Runtime and cloud security
Crypto is only useful when it is applied correctly.
Previously
Exposure reduction and zero trust
Zero trust is simple.
This module
Runtime and cloud security
Crypto is only useful when it is applied correctly.
Next
Supply chain security
Supply chain risk is the uncomfortable truth that you inherit other people’s security decisions.
Progress
Mark this module complete when you can explain it without rereading every paragraph.
Why this matters
Good practice includes modern suites, short lived certificates, hardware backed keys where possible, least privilege access to key stores, and a rotation story that you have actually exercised.
What you will be able to do
- 1 Explain why certificate validation matters and what should fail closed
- 2 Spot common protocol weaknesses that create false safety
- 3 Write a short crypto policy with rotation and exception rules
Before you begin
- You have used HTTPS and you know it relies on certificates
Common ways people get this wrong
- Blind production. If you cannot see behaviour, you cannot secure it. Visibility is a prerequisite.
- Over-collection. Logging everything creates noise and risk. Log what supports decisions.
Main idea at a glance
High level TLS handshake
Client and server agree how to talk securely, check identities with certificates, then switch to encrypted traffic.
TLS trust handshake flow
`sequenceDiagram
participant C as Client
participant S as Server
participant CA as Trusted CA
C->>S: ClientHello (cipher suites, random)
S->>C: ServerHello (chosen suite) + Certificate
C->>CA: Validate certificate chain
CA-->>C: Chain valid or invalid
C->>S: Key exchange material
S-->>C: Handshake finished
C->>S: Encrypted application data
`TLS trust handshake flow
Crypto is only useful when it is applied correctly. Most organisations do not lose because the maths was broken. They lose because assumptions drift, keys leak, validation gets skipped, or somebody treats encryption as a risk stamp that means safe.
Transport Layer Security (TLS) works because both sides agree a cipher suite. A certificate authority vouches for a site identity. mutual TLS when both need to prove who they are. Keys must be generated well, stored safely, rotated, and revoked when things change.
Why this exists. Crypto is how you make identity and data trustworthy across boundaries you do not control. It protects confidentiality, yes, but also integrity and authenticity. Without those, you cannot make reliable decisions from logs, API calls, or financial transactions.
Who owns it. Shared. Platform or SRE teams usually own TLS and certificate lifecycle. App teams own correct use in code, including token validation and signature checks. Security sets policy and guardrails. Third parties often own pieces too, such as managed certificate services or an external public key infrastructure.
Trade offs. Strict validation and short lived certificates reduce risk, but they increase operational load and outage risk if automation is weak. Hardware backed keys and dedicated key management systems reduce blast radius, but cost money and add complexity. Mutual TLS raises assurance, but can slow delivery if identity and certificate operations are immature.
Failure modes. The classics are still the classics. Outdated algorithms, self signed certificates where trust is needed, weak random number generation, keys shared between environments, skipping verification, and quietly disabling checks to unblock a deployment. Another big one is ownership fuzziness. Nobody feels responsible for expiry, revocation, or emergency key rotation until it is on fire.
Maturity thinking. Basic looks like modern defaults, automated certificate renewal, and no secrets in repos. Good looks like policy backed automation, per environment isolation, and reliable revocation and rotation with tests. Excellent looks like hardware backed keys where it matters, measured control effectiveness, and incident ready procedures for rapid key compromise response.
Good practice includes modern suites, short lived certificates, hardware backed keys where possible, least privilege access to key stores, and a rotation story that you have actually exercised. The real goal is not to use crypto. The real goal is to keep identity and data trustworthy under stress.
When validation fails, the right response is rarely to turn off checks. It is to fix trust properly and make failure safe. Write down what must fail closed, who approves exceptions, and what evidence you keep.
After you run it, translate the choices into standards. Define approved primitives, minimum strengths, and deprecation timelines. Then enforce those in CI and procurement. If your system cannot support modern options, that is a risk acceptance decision that should be explicit and time boxed.
Mental model
Runtime signals and controls
Runtime security is about reducing blast radius and making misuse visible.
-
1
Runtime
-
2
Logs
-
3
Alerts
-
4
Response
Assumptions to keep in mind
- Signals are collected safely. Logs should help you, not leak secrets. Decide what must never be logged.
- Response is rehearsed. A response plan is only real if you have practised it.
Failure modes to notice
- Blind production. If you cannot see behaviour, you cannot secure it. Visibility is a prerequisite.
- Over-collection. Logging everything creates noise and risk. Log what supports decisions.
Key terms
- cipher suite
- set of algorithms for key exchange, encryption and integrity
- certificate authority
- trusted issuer of certificates
- mutual TLS
- Both client and server present certificates
Check yourself
Quick check. Runtime and cloud security
0 of 7 opened
Scenario. A team proposes skipping certificate validation to unblock an integration. What is the correct response
Treat it as a serious risk. Fix trust properly with correct CA roots, renewal automation, and hostname verification. Bypassing validation turns encryption into a false sense of safety.
What does a cipher suite specify
The algorithms for key exchange, encryption and integrity used in a session.
Why do we trust a certificate
Because a certificate authority signs it and the client validates that signature and chain.
Scenario. When does mutual TLS make sense
Service to service traffic where both sides must prove identity, especially across a boundary or between environments.
Name one common crypto misuse
Skipping verification, using outdated algorithms, or reusing keys across environments.
Why rotate keys
To limit damage if a key leaks and to keep cryptographic material fresh.
What should happen if certificate validation fails
Fail closed and refuse the connection, then fix trust and automation rather than bypassing checks.
Artefact and reflection
Artefact
A small crypto policy note you could use in engineering standards
Reflection
Where in your work would explain why certificate validation matters and what should fail closed change a decision, and what evidence would make you trust that change?
Optional practice
Toggle common failures and predict when validation should fail closed.
Also in this module
Spot protocol weaknesses
Pick mitigations for replay, downgrade, and error leakage.