// Part 01
Why Every Security Decision Needs a Framework
Security decisions are trade-offs. Strong encryption improves confidentiality but can hurt availability if key management fails. Aggressive access controls improve confidentiality but may block legitimate users. Detailed audit logging improves accountability but has a performance cost. Without a framework, these trade-offs are made inconsistently — and the inconsistencies create gaps attackers find.
The CIA triad is that framework. It has been the foundation of information security for over 30 years because it captures something true: every security property of a system can be expressed as some combination of Confidentiality, Integrity, and Availability. Every attack violates at least one. Every security control protects at least one. Having this vocabulary makes security conversations precise.
An important clarification upfront: the CIA triad is not a framework for building security systems — it is a vocabulary for analysing them. It does not tell you what to build. It tells you how to think about what you build, which attacks to worry about, and what properties you are trading off when you make a design decision.
// Part 02
Confidentiality — Information Is Accessible Only to the Authorised
Confidentiality means that information is accessible only to those authorised to access it. Unauthorised parties — whether external attackers, curious employees, or compromised systems — should not be able to read protected data.
What Protects Confidentiality
Encryption at rest
Data stored in databases, files, or backups is encrypted. Even if an attacker obtains the physical storage medium or a database dump, they cannot read the data without the encryption key. AWS S3 server-side encryption, Linux LUKS disk encryption, and Transparent Data Encryption in databases implement this.
Encryption in transit
Data moving over networks is encrypted (TLS). An attacker who intercepts network traffic sees only ciphertext. Without HTTPS, passwords and session tokens cross the network in plaintext — readable by anyone on the path.
Access controls
Authentication verifies identity. Authorisation determines what that identity can access. Role-Based Access Control (RBAC) limits each user to the data their role requires — a customer service representative can view order history but not payment card numbers.
Data classification
Not all data needs the same level of protection. Classifying data as Public, Internal, Confidential, and Restricted allows proportionate controls — applying bank-level encryption to an internal birthday list wastes resources; applying minimal controls to customer SSNs is a breach waiting to happen.
Tokenisation and masking
Replace sensitive values with non-sensitive substitutes. A credit card number is replaced with a random token; the actual number lives only in the token vault. Log masking replaces SSNs with *** in application logs. The application handles the token; only the vault holds the sensitive value.
Attacks That Target Confidentiality
Data breach
Unauthorised access to a database or file system exposing protected records — customer PII, payment data, medical records.
Eavesdropping / MITM
Intercepting unencrypted network traffic to read credentials, session tokens, or sensitive content in transit.
Credential theft
Phishing or keylogging captures passwords, giving attackers authenticated access to data they should not see.
Insider threat
A malicious employee with legitimate access exfiltrates data they are authorised to view but not to share.
SQL injection
Injecting SQL into a query causes the database to return data from tables the application should not expose.
Side-channel attacks
Inferring confidential information from observable system behaviour — timing differences, power consumption, or error messages that reveal too much.
The Privacy Extension
Privacy is confidentiality applied to personal data — with legal teeth. GDPR, CCPA, HIPAA, and similar regulations mandate specific confidentiality controls for personal data and impose fines for violations. A confidentiality failure involving personal data is simultaneously a security incident and a regulatory violation. In the US, HIPAA fines for healthcare data breaches range from $100 to $50,000 per record. A breach of 1 million records can result in $50 billion in potential maximum penalties.
// Part 03
Integrity — Information Is Accurate and Unmodified
Integrity means that information is accurate, complete, and has not been modified without authorisation. Data that has been tampered with — whether by an attacker, a software bug, or hardware failure — has lost its integrity.
Integrity is often underweighted compared to confidentiality, but its violations can be more dangerous. A data breach exposes information. An integrity failure corrupts it — and a system that makes decisions based on corrupted data may behave in catastrophically wrong ways.
Integrity Violations by Impact
Financial record tampering
An attacker modifies a pending payment's amount field from $100 to $0.01 before it is processed. Or a malicious insider changes account balances. The system records the transaction faithfully — but the data it is recording is wrong.
🛡 Immutable audit logs, digital signatures on financial records, dual-approval requirements for large transactions, database-level triggers that log all modifications
Software supply chain compromise
An attacker compromises a software build pipeline and injects malicious code into a legitimate software package before it is signed and distributed. Users install what appears to be authentic, signed software but it contains malware. The SolarWinds attack compromised 18,000 organisations this way.
🛡 Code signing, reproducible builds, software bill of materials (SBOM), binary provenance verification, package signature verification in deployment pipelines
DNS record manipulation
An attacker modifies DNS records to point a domain to a malicious server. Users resolve the domain and connect to the attacker, believing they are at the legitimate destination. This is an integrity attack on the DNS infrastructure, with confidentiality consequences for users.
🛡 DNSSEC cryptographically signs DNS records. Monitoring DNS records for unexpected changes provides detection.
Log tampering
An attacker who achieves system access deletes or modifies log files to remove evidence of their activity. Without integrity protection on logs, incident response cannot reconstruct what happened.
🛡 Write-once log storage, centralised logging to a separate server the attacker cannot access, cryptographic log chaining (each log entry hashes the previous one — any deletion is detectable)
Medical record modification
An attacker changes a patient's blood type, allergy records, or medication list in a hospital system. Clinical staff make decisions based on the corrupted record. This is a life-safety integrity violation.
🛡 Cryptographic audit trails for all record modifications, immutable original record storage, strict RBAC limiting who can modify records
What Protects Integrity
Cryptographic hash functions detect modification: SHA-256(data) produces a fixed digest. Any change to data changes the digest — the receiver can detect tampering by recomputing. Digital signatures prove both integrity and authenticity: a signature over a document proves it came from the key holder and was not modified. MACs detect modification by anyone without the secret key. Version control systems (git) use content-addressed storage — every commit is identified by the SHA-1 of its content, making undetected modification of history theoretically impossible. Audit logs record every action; immutable audit logs cannot be retroactively altered.
// Part 04
Availability — Systems and Data Are Accessible When Needed
Availability means that authorised users can access systems and data when they need to. A secure system that is permanently offline provides no security value — it is just broken. Availability is often underemphasised in security discussions despite being the property most visibly violated by modern attacks.
Availability Threats
DDoS (Distributed Denial of Service)
Overwhelming a service with traffic from thousands of compromised machines (botnet) until legitimate users cannot be served. The 2016 Mirai DDoS attack peaked at 1.2 Tbps — enough to take down Dyn DNS and make major websites unreachable for hours.
Ransomware
Encrypts files and demands payment for the decryption key. Primarily an availability attack — the data may not be stolen, but it is inaccessible. Hospitals have cancelled surgeries, pipelines have shut down fuel supply, and governments have declared emergencies due to ransomware availability failures.
Hardware failure
Disk failure, power outage, network equipment failure, or datacenter disaster can take down systems without any attacker involvement. Availability requires resilience against both attacks and failures.
Software bugs
A deployment error, a bad configuration change, or a software crash can cause availability failures that look identical to an attack from the user's perspective. Many "incidents" are not security incidents at all.
Resource exhaustion
A fork bomb fills the process table. A memory leak exhausts RAM. A slow query fills the connection pool. Without resource limits, one process can take down an entire server — no attacker required, but exploitable by one.
What Protects Availability
Availability is protected through redundancy and resilience: multiple servers behind a load balancer mean no single failure takes down the service. Database replicas mean no single disk failure loses data. Multiple availability zones mean no single datacenter fire stops operations. DDoS protection services (Cloudflare, Akamai) absorb volumetric attacks before they reach the origin. Rate limiting prevents resource exhaustion from a single user or IP. Backups allow recovery after ransomware — if they are regularly tested and stored offline where ransomware cannot reach them.
🎯 Pro Tip
Availability SLAs (Service Level Agreements) quantify this property: "99.9% availability" means no more than 8.76 hours of downtime per year. "99.99% availability" means no more than 52 minutes per year. "Five nines" (99.999%) means no more than 5.26 minutes per year. These numbers drive architecture decisions — four nines requires redundant everything; five nines requires active-active multi-region with automated failover. The cost of each additional nine grows exponentially.
// Part 05
The Trade-offs — CIA Properties Conflict
The CIA triad is more useful for reasoning about trade-offs than for building ideal systems, because these three properties conflict. You cannot maximise all three simultaneously — every system is a set of deliberate compromises.
Confidentiality vs Availability
Strong encryption protects confidentiality. But if the encryption keys are lost — the key management system fails, a hardware security module malfunctions, or the key admin is the only one who knows the passphrase and leaves the company — the data is permanently inaccessible. Perfect confidentiality (no one can read it) and perfect availability (always accessible) are directly in tension.
Real-world example
A hospital encrypts patient records for confidentiality. During an emergency, the doctor needs immediate access to a patient's medication history but the key management system is down for maintenance. Maximum confidentiality has compromised critical availability.
Resolution approach: Key escrow, hardware security modules with high availability, key recovery processes, and explicit risk decisions about when availability takes precedence over confidentiality.
Integrity vs Availability
Strict integrity controls require verification before action. A system that requires two-factor approval for every transaction, cryptographic signature verification before loading data, or rigorous schema validation before processing input is more correct — but slower. Under high load or during an incident, these integrity checks become bottlenecks that reduce availability.
Real-world example
A blockchain system where every transaction requires consensus across thousands of nodes — maximum integrity, but only processes 7-15 transactions per second (vs Visa's 65,000/sec). Ethereum's switch to proof-of-stake traded some integrity properties for energy efficiency and throughput.
Resolution approach: Integrity checks scaled proportionally to risk. Low-value operations get lightweight checks; high-value operations get full verification even at the cost of latency.
Confidentiality vs Integrity
End-to-end encryption (E2EE) maximises confidentiality by ensuring only the endpoints can read the content — not even the service provider. But this means the service provider cannot scan for malware, detect abuse, or filter illegal content. Confidentiality prevents the integrity and content-verification functions that require seeing the plaintext.
Real-world example
Apple iMessage's end-to-end encryption means Apple cannot see message content — strong confidentiality. But it also means Apple cannot detect if someone is being harassed, if malware is being distributed via iMessage, or if illegal content is being shared.
Resolution approach: Client-side scanning (controversial — moves the surveillance to the endpoint), trusted hardware enclaves, or accepting the trade-off explicitly and delegating abuse detection to metadata and behavioural signals.
// Part 06
Security Models — Formalising the CIA Triad
Security models provide formal rules for enforcing CIA properties. They were developed primarily in the 1970s-80s for government and military systems but their principles are applied in modern access control systems, operating system design, and database security.
Bell-LaPadula Model — Confidentiality Focus
Bell-LaPadula is a formal model for mandatory access control focused on confidentiality. It defines two rules:
Simple Security Property (No Read Up)
A subject at security level L can only read objects at level ≤ L. A Secret-cleared user cannot read Top Secret documents. This prevents a lower-clearance user from reading higher-classified data.
*-Property (No Write Down)
A subject at security level L can only write to objects at level ≥ L. A Secret-cleared user cannot write to Unclassified documents. This prevents information from flowing from a higher classification to a lower one — even inadvertently.
Modern application: government and military classification systems implement Bell-LaPadula. The principle of "no write down" also applies to cross-tenant data isolation in SaaS applications — a tenant's data must not flow to another tenant's context.
Biba Model — Integrity Focus
Biba is the integrity counterpart to Bell-LaPadula. It also defines two rules, but in the opposite direction:
Simple Integrity Axiom (No Read Down)
A subject at integrity level L can only read objects at level ≥ L. A high-integrity process should not read from a low-integrity source — doing so could corrupt the high-integrity process's state with unreliable data.
*-Integrity Axiom (No Write Up)
A subject at integrity level L can only write to objects at level ≤ L. A low-integrity process cannot write to a high-integrity object — this prevents contaminating trusted data with untrusted input.
Modern application: operating system privilege separation. A web browser (low integrity — it processes arbitrary internet content) is not allowed to write to system files (high integrity). This is enforced by OS-level access controls. Biba also explains why you should not trust input from lower-integrity sources without validation: user input is low-integrity and must not directly modify high-integrity application state.
Brewer-Nash Model (Chinese Wall) — Conflict of Interest
The Chinese Wall model addresses conflict of interest: a consultant who has worked with Coca-Cola should not access Pepsi's confidential data. Access is not based on classification level but on whether a conflict exists. This model is implemented in investment banking (analysts cannot access information about companies in competing deals) and law firms (attorneys cannot represent both sides of a dispute).
Zero Trust — The Modern Security Architecture Model
Zero Trust is not a product — it is an architectural principle: never trust, always verify. The traditional perimeter model granted trust to everything inside the network boundary. Zero Trust rejects this — a compromised internal device is just as dangerous as an external attacker, and the perimeter is increasingly meaningless in cloud and remote work environments.
Old Perimeter Model
• External = untrusted
• Internal = trusted
• VPN gets you in → full access
• One-time authentication per session
• Flat internal network
Zero Trust Model
• Location = irrelevant
• Every request authenticated and authorised
• Least privilege access per request
• Continuous verification (device health, context)
• Micro-segmentation prevents lateral movement
The five pillars of Zero Trust architecture: Identity (verify who every user and device is, every time). Device (verify the health and compliance of every device). Network (segment and encrypt internal traffic — no implicit trust on the LAN). Application (verify access per application, not per network). Data (classify data and apply controls at the data level, not just the perimeter).
// Part 07
Extending the Triad — Parkerian Hexad and the Additional Properties
Some security frameworks extend the CIA triad with additional properties that are important in specific contexts:
Authenticity
The property of being genuine — verifying that a user, document, or system is what it claims to be. Authentication addresses this. Digital signatures prove the authenticity of a document. CIA does not explicitly include authenticity — it is a component of integrity (data is authentic if it was created by who claims to have created it) and access control (users are authentic if their identity is verified).
Non-repudiation
The inability to deny having performed an action. Digital signatures (not MACs) provide this — only the private key holder could have created the signature, so they cannot later claim they did not sign the document. Critical in legal, financial, and compliance contexts where proof of action is required.
Accountability
The ability to trace actions to the identities that performed them. Audit logs, multi-factor authentication, and unique user accounts (no shared accounts) support accountability. Without accountability, you know something happened but cannot determine who is responsible.
Possession / Control
The property of having control over data — even if you cannot read encrypted data, the owner losing control of the encryption key means they have lost possession. The Parkerian Hexad adds Possession as a distinct property because you can violate possession without violating confidentiality (the data is still encrypted but now someone else controls the key).
💡 Note
For most security roles, CIA is sufficient. The Parkerian Hexad (Confidentiality, Possession, Integrity, Authenticity, Availability, Utility) appears in academic and some compliance contexts. The CISSP exam covers the CIA triad as the primary framework. Knowing the CIA triad deeply is more valuable than knowing the Hexad superficially.
// Part 08
Applying the CIA Triad — Threat Modelling in Practice
The CIA triad is most useful when applied to a specific system. Threat modelling asks: for each asset, which CIA properties are at risk, from whom, and what controls address each?
Example: An e-commerce payment system
| Asset | C | I | A | Top Threat | Primary Control |
|---|
| Customer card data | 🔴 Critical | 🟡 High | 🟡 High | Data breach via SQL injection | Tokenisation + TLS + parameterised queries |
| Order database | 🟡 High | 🔴 Critical | 🔴 Critical | Record modification / ransomware | Backups + integrity audit log + RBAC |
| Payment processing API | 🟡 High | 🔴 Critical | 🔴 Critical | Transaction tampering / DDoS | TLS + signing + rate limiting + WAF |
| Authentication system | 🔴 Critical | 🔴 Critical | 🔴 Critical | Credential stuffing / account takeover | MFA + rate limiting + breach password check |
| Admin panel | 🔴 Critical | 🔴 Critical | 🟡 High | Insider threat / phishing admin | MFA + IP allowlist + session recording |
| Static product images | ⚪ None | 🟢 Low | 🟡 High | CDN outage | CDN redundancy + availability monitoring |
The table makes explicit what is often implicit: static product images have no confidentiality requirement (they are public) and low integrity risk (a modified product image is a nuisance, not a crisis). But they have high availability requirements — when images fail to load, conversion rates drop. This tells you: invest in CDN redundancy for images, not encryption. For card data, the reverse: encrypt everything, accept slower processing.
// Part 09
Interview Prep — 5 Questions With Complete Answers
Q: Explain the CIA triad with real-world examples of attacks against each property.
The CIA triad is the foundational framework for information security. It describes three properties that secure information systems must protect: Confidentiality, Integrity, and Availability. Every security decision can be analysed through this lens.
Confidentiality means that information is accessible only to authorised parties. A data breach violates confidentiality — an attacker gains access to customer records, medical data, or financial information that they were not authorised to read. The 2021 T-Mobile breach exposed the personal data of 76 million customers. The 2018 Marriott breach exposed 500 million guest records. In both cases, the attack targeted confidentiality — the data was read by someone who should not have been able to read it. Controls: encryption, access controls, network segmentation, data classification.
Integrity means that information is accurate and has not been modified without authorisation. Man-in-the-middle attacks on unencrypted connections can modify data in transit — an attacker between a client and server can change what the server receives. Software supply chain attacks violate integrity — the SolarWinds attack injected malicious code into legitimate software updates, meaning the software that users installed was not the software the vendor intended. Controls: cryptographic hashes, digital signatures, TLS, code signing, immutable audit logs.
Availability means that systems and data are accessible when authorised users need them. Ransomware is primarily an availability attack — it encrypts files and makes them inaccessible until a ransom is paid. The 2017 NotPetya attack caused $10 billion in damages, largely by destroying data and taking systems offline. DDoS attacks target availability by overwhelming services with traffic. Controls: redundancy, load balancing, DDoS protection, backups (tested and stored offline), disaster recovery planning.
Q: How would you use the CIA triad to evaluate a security decision?
The CIA triad provides a structured way to ask three questions about any security decision: does it improve or harm confidentiality? Does it improve or harm integrity? Does it improve or harm availability? And what are the trade-offs between these properties?
Example: a company is deciding whether to enable full-disk encryption on all employee laptops. Applying the CIA triad: confidentiality — significantly improved. A lost or stolen laptop with full-disk encryption exposes no data. Without encryption, a thief can remove the drive and read all files. Integrity — encryption does not directly protect integrity. A compromised operating system with encryption enabled is still compromised. Availability — potential risk. If an employee forgets the encryption password or the recovery key is lost, the data is inaccessible — a confidentiality/availability trade-off. Hardware failure on an encrypted drive is also a more complex recovery situation.
The CIA triad analysis concludes: enable encryption (confidentiality benefit outweighs availability risk), but mitigate the availability risk with a key escrow process (IT holds recovery keys) and backup policies. This is the kind of structured reasoning that distinguishes security engineering from ad-hoc decision-making.
A second example: implementing rate limiting on an API. Confidentiality — minimal direct effect. Integrity — no direct effect. Availability — dual effect: it protects availability against denial-of-service from abusive clients, but too-aggressive rate limits could deny service to legitimate high-volume users. The decision: set limits high enough to allow legitimate traffic, low enough to stop abuse — a calibration decision informed by the CIA triad's availability analysis.
Q: Why is ransomware primarily an availability attack, not a confidentiality attack?
Ransomware is classified primarily as an availability attack because its core mechanism is encrypting files and demanding payment for the decryption key — making data inaccessible, not necessarily stealing it.
Modern ransomware operators have added a confidentiality component — "double extortion" — where they also exfiltrate data before encrypting it and threaten to publish it if the ransom is not paid. This extends the attack to target confidentiality as well. The 2020 Maze ransomware group pioneered this approach, followed by almost every major ransomware operation since.
But the fundamental threat model of ransomware is availability: the organisation's operational data — databases, file shares, email — becomes inaccessible. Hospitals cannot access patient records. Manufacturers cannot access production systems. Government agencies cannot process applications. The ransom is paid not because secrets were exposed but because operations are stopped.
This distinction matters for defences. If ransomware were purely a confidentiality attack, the defence would be encryption — encrypting your data before ransomware does prevents the threat. But since it is primarily an availability attack, the defence is backups: offline, tested, regularly verified backups allow recovery without paying the ransom. The NHS's response to the 2017 WannaCry attack was impaired because many systems lacked offline backups. Organisations with tested offline backups recovered from ransomware in hours rather than weeks.
The backup must be offline or air-gapped — ransomware specifically searches for and encrypts network-connected backup systems. Online backups on the same network are compromised alongside everything else.
Q: What is the principle of least privilege and which CIA property does it primarily protect?
The principle of least privilege states that every user, process, and system should have access to only the minimum resources and permissions necessary to perform its defined function — nothing more. A customer service representative needs to view order history; they do not need to export the entire customer database or modify pricing. A web server process needs to read web files; it does not need to write to system directories or read /etc/shadow.
Least privilege primarily protects confidentiality: by limiting what each identity can access, it limits the blast radius of a compromise. A compromised customer service account cannot access cardholder data it was never authorised to see. A compromised web server process cannot read database credentials stored in a protected configuration file.
But least privilege also protects integrity and availability. Integrity: if a process cannot write to critical system files, a compromised process cannot corrupt those files. Availability: if a user cannot delete the production database, a disgruntled or compromised user cannot take down the system by dropping tables.
Implementing least privilege in practice: Role-Based Access Control (RBAC) defines roles with the minimum permissions each role needs. Service accounts for applications should have only the database permissions the application actually uses — SELECT on specific tables, not full DBA access. Temporary elevated access (privileged access management) provides elevated permissions only when needed and for a defined time window. Network segmentation limits which services can communicate, preventing lateral movement even by authenticated principals.
Q: Explain Zero Trust architecture. How does it differ from the traditional perimeter security model?
The traditional perimeter security model is built on a distinction between "inside" and "outside": the internal network is trusted, the external network is not. Firewalls enforce the perimeter; once inside — through a VPN, a physical connection, or a compromised credential — an attacker has relatively free movement across the internal network. This model assumed that compromising the perimeter was hard, and that internal actors were trustworthy.
Zero Trust rejects both assumptions. The principle is: never trust, always verify. Network location does not confer trust. A device on the internal corporate network is not more trusted than a device on the public internet. Every request must be authenticated and authorised, regardless of where it comes from.
The practical implications of Zero Trust: strong identity verification before every access (MFA, certificate-based device authentication). Continuous authorisation — not just at login, but per request. Least-privilege access per application, not per network. Network micro-segmentation — each service can only communicate with other services it explicitly needs to reach, preventing lateral movement. Encryption everywhere — internal traffic is encrypted just as external traffic is. All access is logged and monitored regardless of network location.
Why Zero Trust is necessary now: the corporate network perimeter has dissolved. Remote work means corporate devices connect from home networks, coffee shops, and hotels. SaaS applications are outside the corporate network entirely. Cloud workloads run in data centres the company does not control. The "inside" of the network is no longer a meaningful concept. Zero Trust is not a product you buy — it is an architectural principle that requires changes to identity systems, network architecture, access control policies, and monitoring.
Zero Trust directly addresses the most common attack pattern: compromised credentials used to move laterally through a flat internal network. With Zero Trust, compromised credentials provide access only to the specific resources that credential was authorised to reach — not to everything on the internal network.
// Part 10
CIA Triad Failures That Appear in Real Incidents
Confidentiality failure: sensitive data returned in error messages
Cause: A web application returns verbose error messages in production. A SQL error message says: 'Error: column 'credit_card_number' from table 'payments' does not exist — near line 3 of stored procedure uspProcessPayment'. This error message reveals the database table structure, column names, stored procedure name, and the fact that credit card numbers are stored (not tokenised). An attacker deliberately triggers errors to enumerate the database structure before crafting a SQL injection attack.
Fix: Configure production applications to return generic error messages to users — 'An error occurred, please try again' — and log the detailed error server-side. Application frameworks support this via environment-based error display settings (Django's DEBUG=False, Express's error handler). Never include database schema details, stack traces, server paths, or configuration details in user-facing error messages. The detailed error is invaluable for debugging — on the server, in logs, never in the response.
Integrity failure: audit log modification after a security incident
Cause: An attacker achieves root access on a server. The first action is clearing /var/log/auth.log and truncating /var/log/syslog to eliminate evidence of how they got in and what they did. The security team detects the compromise 48 hours later but cannot determine the initial access vector, the full extent of lateral movement, or what data was accessed because the logs do not exist.
Fix: Centralise logs to a remote, append-only log management system before you need them. rsyslog with TLS forwarding to a separate logging server, AWS CloudWatch Logs, or a SIEM like Splunk ensures that local log deletion cannot destroy the evidence trail. For highest integrity requirements, use immutable log storage where records cannot be modified or deleted for a defined retention period. Configure auditd on Linux systems to log at the kernel level — this captures events that application-level logging misses.
Availability failure: backup restoration fails during a ransomware incident
Cause: An organisation has daily backups but has never tested restoration. During a ransomware attack, the operations team attempts to restore from backup. The backup files themselves were encrypted by ransomware three weeks ago (the ransomware had been dormant). Even the backups stored on the backup server were encrypted because it was reachable from the compromised network. The untested backups from before the ransomware infection are six months old.
Fix: Test backups by restoring them to a staging environment quarterly — not just by verifying the backup files exist. Use the 3-2-1 backup rule: three copies, two different media types, one offline (physically disconnected, not just logically separated). Offline or air-gapped backups cannot be encrypted by ransomware that accessed the network. Restore time is as important as backup frequency — a backup that takes three weeks to restore does not meet a 24-hour RTO (Recovery Time Objective). Test the restoration process end-to-end, not just the backup job.
CIA trade-off ignored: strong authentication breaks emergency access
Cause: A hospital implements strict MFA — all clinical systems require a hardware token for authentication. The security posture improves significantly. During a code blue emergency, the on-call physician needs immediate access to a patient's medication list and allergy information. The physician does not have their hardware token — it is in their locker across the hospital. The clinical system is inaccessible. Maximum confidentiality has created a life-safety availability failure.
Fix: Security controls must be designed with the operational context of their users in mind. Healthcare systems use 'break-glass' accounts — emergency access procedures that bypass normal authentication controls during defined emergencies, with full audit logging of the break-glass access. Every use is reviewed after the fact. The CIA trade-off is explicit: availability takes precedence in a life-safety emergency, with accountability compensating for reduced access control. Security requirements do not override operational requirements — they must accommodate them with appropriate compensating controls.
Zero Trust not applied internally: compromised developer account = production database access
Cause: A company implements Zero Trust at the network perimeter but maintains a flat internal network. Developer accounts are in the same Active Directory domain as production systems. A developer's laptop is compromised via a phishing email. The attacker uses the developer's credentials to browse the internal network, discovers the production database server on the same subnet, and connects directly using the developer's AD credentials — which also have read access to the production database because 'developers need it for debugging'.
Fix: Zero Trust must apply to the internal network, not just the perimeter. Micro-segment the network: production systems should be in a separate network segment reachable only from specific jump hosts with additional authentication. Production database access should require a separate credential distinct from the developer's workstation credential. Privileged access management (PAM) provides time-limited, logged access to production resources — accessed via a separate authentication step, not automatic inheritance from workstation credentials. The blast radius of a compromised developer laptop should not reach production databases.
🎯 Key Takeaways
- ✓The CIA triad — Confidentiality, Integrity, Availability — is the foundational vocabulary for reasoning about information security. Every attack violates at least one property; every control protects at least one. Without this vocabulary, security decisions are made without a shared framework.
- ✓Confidentiality: only authorised parties can read information. Protected by encryption, access controls, data classification, and tokenisation. Violated by data breaches, eavesdropping, SQL injection, and credential theft. Extending to privacy adds legal obligations via GDPR, HIPAA, and CCPA.
- ✓Integrity: information is accurate and unmodified. Protected by cryptographic hashes, digital signatures, MACs, audit logs, and immutable storage. Violated by man-in-the-middle modifications, supply chain attacks, log tampering, and financial record manipulation. Integrity failures are often more dangerous than confidentiality failures — corrupted data leads to wrong decisions.
- ✓Availability: systems and data are accessible when needed. Protected by redundancy, load balancing, DDoS mitigation, backups, and disaster recovery. Violated by ransomware, DDoS attacks, hardware failures, and software bugs. Availability SLAs (99.9%, 99.99%) drive architecture complexity and cost.
- ✓CIA properties conflict and cannot all be maximised simultaneously. Confidentiality and availability trade off (lost encryption keys make data inaccessible). Integrity checks reduce throughput. End-to-end encryption prevents content moderation. Every security design is a deliberate set of trade-offs, not an optimisation.
- ✓Bell-LaPadula enforces confidentiality: no read up (cannot read above your clearance), no write down (cannot write below your clearance — prevents information downgrade). Biba enforces integrity: no read down (do not trust lower-integrity sources), no write up (low-integrity subjects cannot modify high-integrity objects).
- ✓Zero Trust rejects the premise that network location implies trust. Never trust, always verify — every request is authenticated and authorised regardless of where it originates. Identity, device health, context, and least-privilege access per request replace network perimeter as the primary security boundary.
- ✓Threat modelling with the CIA triad makes implicit risks explicit: which assets are at risk, which CIA properties are at stake, what is the likelihood and impact of each threat, and which controls address each risk. This converts security from intuition to a documented, prioritised risk register.
- ✓Ransomware is primarily an availability attack — data becomes inaccessible, not necessarily stolen. The defence is offline backups, not encryption. Modern ransomware adds double extortion (exfiltration + encryption), adding a confidentiality component. Know which property is being attacked to choose the right control.
- ✓The principle of least privilege protects all three CIA properties: confidentiality (can only access what is needed), integrity (can only modify what is needed), availability (cannot accidentally or maliciously destroy resources beyond role scope). It directly limits the blast radius of any single compromised account.
What comes next
In Module 06, you get the full picture of the US cybersecurity job market — every role mapped with real salary data, which certifications are worth pursuing at which stage, and the companies hiring the most security engineers right now.
Module 06 → Cybersecurity Career Paths and the US Job Market