Security and Risk Management Reference Guide
CISSP Domain 1 · 12 topics · Concepts, real-world examples, and controls
Professional ethics in information security establishes the behavioral foundation for every practitioner. Ethics are not aspirational guidelines — they are enforceable obligations that govern how security professionals act, advise, and protect, even when no one is watching and no regulation compels a specific behavior.
(ISC)² Code of Professional Ethics
The (ISC)² Code consists of a mandatory preamble and four canons listed in priority order. When canons conflict, higher-ranked canons take precedence. This ordering is deliberate and frequently tested.
🌐 Real-world example — canon conflict
A security consultant discovers their client is running a massive fraud scheme that harms thousands of customers. The client instructs the consultant to keep silent under NDA (Canon III: serve principals). But Canon I requires protecting society. Canon I wins — the consultant must report to appropriate authorities. This ordering is not accidental: society’s protection always outranks employer loyalty under (ISC)² ethics.
Organizational code of ethics
Organizations typically layer their own code of ethics on top of the (ISC)² framework. Organizational codes address context-specific obligations: conflicts of interest, use of company resources, insider trading restrictions, and acceptable use of security capabilities. Security professionals must adhere to both — and where they conflict, the (ISC)² canon ordering provides the resolution hierarchy.
Understand and apply security concepts
The five pillars of information security provide a conceptual framework for evaluating every security decision, control, and incident. They are not independent — protecting one pillar sometimes creates tension with another. Understanding those trade-offs is the mark of a mature security practitioner.
Select a pillar to see its full definition, trade-offs, and a real-world example.
Confidentiality
Only authorized parties access data
Integrity
Data is accurate and unaltered
Availability
Systems accessible when needed
Authenticity
Identity is genuine and verified
Non-repudiation
Actions cannot be denied later
Confidentiality
Ensuring that information is accessible only to those authorized to have access. Implemented through access controls, encryption, data classification, and need-to-know principles. The goal is to prevent unauthorized disclosure — whether by external attackers, insider threats, or accidental exposure.
Key trade-off
Strong confidentiality controls can reduce availability. End-to-end encryption protects data in transit but may prevent security inspection tools from detecting malicious payloads. Every confidentiality control introduces friction that must be weighed against operational need.
Real-world example
The 2013 Edward Snowden disclosures were a confidentiality failure at scale. The NSA had granted Snowden — a contractor — access to systems far beyond his operational need. Excessive access permissions, combined with insufficient monitoring of data movement, allowed him to exfiltrate terabytes of classified material. The failure was not encryption — it was access control and least privilege.
Integrity
Ensuring that data and systems are accurate, complete, and have not been modified by unauthorized parties. Implemented through hashing, digital signatures, version control, input validation, and audit logs. Integrity covers both data integrity (the data itself) and system integrity (the system behaves as intended).
Key trade-off
Integrity controls add overhead. Cryptographic hashing of every database record is computationally expensive. Write-once audit logs consume storage. Organizations must balance the rigor of integrity controls against operational performance — and document the risk acceptance for any control they choose to relax.
Real-world example
In 2016, attackers used the SWIFT interbank messaging system to instruct the Bangladesh Bank to transfer $81 million to fraudulent accounts. The attackers modified transaction logs to hide the transfers — a direct integrity attack. SWIFT had no mechanism to detect unauthorized modification of transaction records. A cryptographic integrity check on log entries would have flagged the tampering immediately.
Availability
Ensuring that systems, applications, and data are accessible to authorized users when needed. Implemented through redundancy, failover, load balancing, backup and recovery, and DDoS mitigation. Availability is often the pillar most directly measured in SLAs and most directly impacted by ransomware and denial-of-service attacks.
Key trade-off
Maximizing availability can conflict with confidentiality and integrity. Caching data in multiple locations improves availability but increases the surface area for unauthorized access. Rapid recovery from backups is only possible if backups are accessible — but accessible backups are also accessible to ransomware. Availability architecture must account for threat scenarios, not just failure scenarios.
Real-world example
The 2021 Colonial Pipeline ransomware attack did not breach the operational technology (OT) network. Yet Colonial shut down the pipeline proactively because the IT billing system — needed to confirm deliveries and invoice customers — was unavailable. The availability failure of a business system caused a real-world fuel shortage across the US east coast. Availability is not just a technical metric; it has operational and societal consequences.
Authenticity
Ensuring that the identity of a user, system, or message is genuine and verifiable. Implemented through multi-factor authentication, digital certificates, PKI, biometrics, and secure boot. Authenticity is the precondition for meaningful access control — if you cannot verify who is connecting, you cannot enforce who should be allowed to connect.
Key trade-off
Stronger authentication increases friction for users and can create availability risk if authentication systems fail. Hardware tokens can be lost. Biometric systems can be fooled or excluded. Backup authentication mechanisms must exist — but each backup mechanism is a potential attack vector if not equally secured.
Real-world example
The 2020 Twitter hack began with a phone-based social engineering attack against Twitter employees. The attackers convinced Twitter’s support staff they were legitimate colleagues needing urgent access — defeating human authentication with social engineering rather than technical exploitation. Authenticity controls that rely on human judgment are only as strong as the training and verification processes behind them.
Non-repudiation
Ensuring that an entity cannot deny having performed an action. Implemented through digital signatures, audit logging, timestamps, and certificates tied to verified identities. Non-repudiation is essential in legal, financial, and compliance contexts where it must be provable — not just believed — that a specific party took a specific action at a specific time.
Key trade-off
Non-repudiation requires strong identity binding — the signature or log is only non-repudiable if the underlying identity was properly verified. A digital signature from a certificate issued without rigorous identity proofing provides technical non-repudiation but legal uncertainty. The strength of non-repudiation is only as good as the certificate authority and identity verification process behind it.
Real-world example
In financial trading, non-repudiation of order instructions is legally required. When a rogue trader at a major bank places unauthorized trades and later denies the instructions, digital signatures on order messages — tied to the trader’s authenticated session — provide the non-repudiable evidence needed for legal and regulatory proceedings. Without it, the dispute becomes word against word.
Evaluate and apply security governance principles
Security governance is the system by which security decisions are made, authority is assigned, and accountability is maintained. Without governance, security becomes a collection of ad hoc technical controls with no connection to business objectives — defended by IT, invisible to leadership, and underfunded by design.
Alignment to business strategy
Security exists to enable the organization to achieve its objectives with acceptable risk — not to prevent all risk at all cost. A security function that cannot articulate its contribution to business goals will always lose budget arguments and always be treated as a cost center. Alignment means translating security decisions into business language: risk reduction, regulatory standing, customer trust, and operational resilience.
🌐 Real-world example
When Maersk was hit by NotPetya in 2017, the recovery cost was $300 million and required reinstalling 45,000 PCs and 4,000 servers in 10 days. Post-incident, Maersk’s CISO presented the board with a direct calculation: the cost of the controls that would have prevented the breach was a fraction of the recovery cost. This is security governance in practice — translating a security failure into financial terms the board can act on. After NotPetya, Maersk’s security budget increased significantly and the CISO gained board-level access.
Due care and due diligence
Due care
Doing what a reasonable person would do in the same circumstances. Implementing and operating security controls appropriately. The ongoing, operational obligation.
Due diligence
Investigating and verifying before acting. Researching risks before a decision, auditing vendors before engagement, assessing controls before relying on them. The investigative obligation.
Security control frameworks
Select a framework to see when and why to use it.
🌐 Real-world example — governance failure
The Equifax breach (2017) was fundamentally a governance failure before it was a technical one. A known Apache Struts vulnerability (CVE-2017-5638) had been publicly disclosed and patched two months before the breach. Equifax’s patching governance — the organizational process for applying critical patches — had failed. The CISO and CEO both resigned. The FTC settlement reached $575 million. A functioning governance process that enforced patch compliance on internet-facing systems would have prevented the entire breach.
Understand legal, regulatory, and compliance issues
Security professionals must understand the legal landscape in which their organization operates — not to practice law, but to recognize when legal obligations apply, ensure controls meet those obligations, and escalate appropriately when they don’t. Ignorance of applicable law is not a defense in regulatory proceedings.
Privacy regulations — select a jurisdiction
Each regulation below has distinct territorial scope, data subject rights, and penalty structures.
General Data Protection Regulation (GDPR)
Applies to any organization processing personal data of EU residents, regardless of where the organization is based. Grounded in seven principles: lawfulness, purpose limitation, data minimization, accuracy, storage limitation, integrity/confidentiality, and accountability. Grants data subjects rights including access, rectification, erasure, portability, and objection. Mandatory breach notification to supervisory authorities within 72 hours of discovery.
Penalties
Up to €20M or 4% of global annual turnover, whichever is higher. Fines are tiered by violation type — data transfer violations and processing without lawful basis attract the highest tier.
Real-world example
Meta fined €1.2 billion (2023) by Irish DPC for transferring EU user data to US servers without adequate safeguards following the Schrems II invalidation of Privacy Shield. The largest GDPR fine to date — and it was not triggered by a breach, but by a lawful transfer mechanism failure.
California Consumer Privacy Act (CCPA) / CPRA
Applies to for-profit businesses meeting any one of: $25M+ annual revenue; collecting data on 100,000+ consumers/households annually; or deriving 50%+ of revenue from selling personal data. Grants California residents rights to know, delete, opt-out of sale, and non-discrimination. Amended by CPRA (2023) to add correction rights and establish the California Privacy Protection Agency as an independent enforcement body.
Penalties
$2,500 per unintentional violation; $7,500 per intentional violation. Private right of action for data breaches: $100–$750 per consumer per incident — creating significant class action exposure for large breaches.
Real-world example
Sephora settled with California AG for $1.2M (2022) — the first major CCPA enforcement action — for failing to disclose it was selling consumer data and failing to honor opt-out requests via the Global Privacy Control signal. The case established that failure to recognize automated opt-out signals is a violation.
Personal Information Protection Law (PIPL) — China
Effective November 2021. Applies to processing of personal information of persons within China, regardless of where the processor is located. Requires explicit consent for most processing, separate consent for sensitive data, and mandatory data protection impact assessments. Cross-border data transfers require either government security assessment, certification by approved institution, or a standard contract filed with authorities.
Penalties
Up to ¥50M or 5% of prior year revenue for serious violations. Business operations may be suspended. Responsible individuals can be banned from serving as directors or senior management.
Real-world example
DiDi Chuxing was fined ¥8.026 billion ($1.2B) in 2022 for serious violations of PIPL and China’s cybersecurity law — including illegal collection of user data and serious security deficiencies. Regulators had flagged the risks before DiDi’s US IPO; the company proceeded anyway. The fine was accompanied by suspension of new user registration for over a year.
Protection of Personal Information Act (POPIA) — South Africa
Fully effective July 2021. Applies to any organization that processes personal information of South African data subjects. Based on eight conditions for lawful processing: accountability, processing limitation, purpose specification, further processing limitation, information quality, openness, security safeguards, and data subject participation. Established the Information Regulator as the supervisory authority.
Penalties
Fines up to R10 million (~$540K). Imprisonment of up to 10 years for certain offenses. The Information Regulator can also issue enforcement notices and compliance notices independently of fines.
Real-world example
The 2020 Experian South Africa breach exposed data on 24 million individuals and 793,000 businesses to a fraudster posing as a legitimate client. The Information Regulator issued an enforcement notice requiring Experian to notify affected data subjects and improve security. POPIA’s accountability condition was central to the regulatory response: Experian had processed data without adequate verification of the requester’s identity.
Key legal concepts
Cybercrimes
Unauthorized access, computer fraud, identity theft, and ransomware are criminal offenses in most jurisdictions. Computer Fraud and Abuse Act (CFAA) in the US; Computer Misuse Act in the UK. Security practitioners must understand the legal boundaries of authorized testing.
Intellectual property
Copyright, patents, trademarks, and trade secrets are legally protected. Unauthorized use of licensed software, reverse engineering, and disclosure of trade secrets all carry legal liability. License compliance is a security and legal obligation.
Import/export controls
Cryptographic technology is regulated as a dual-use export under US EAR (Export Administration Regulations). Strong encryption products may require export licenses. Violations carry significant criminal penalties.
Transborder data flow
Transfer of personal data across national borders is regulated. GDPR requires adequate safeguards; PIPL requires government assessment or certification. Cloud deployments must account for where data is physically stored and processed.
🌐 Real-world example — authorized testing boundary
In 2021, a security researcher discovered a vulnerability in a hospital’s patient portal and accessed a small number of records to demonstrate the impact. Although no data was shared publicly, the researcher was prosecuted under the CFAA because they had accessed systems without explicit written authorization. Proof of vulnerability is not a defense for unauthorized access. Every penetration test, red team engagement, and vulnerability research activity must have a written scope and authorization document before any testing begins.
Understand requirements for investigation types
Different investigation types have different legal standards, evidence requirements, and outcomes. Security professionals must understand these distinctions before collecting evidence — the wrong collection procedure can invalidate evidence, expose the organization to liability, or obstruct legitimate legal proceedings.
Select an investigation type to understand its scope, standards, and evidence requirements.
Administrative investigation
Conducted internally by the organization to determine whether policy was violated. Typically triggered by HR issues, insider threat suspicion, or policy non-compliance. The goal is to determine facts and reach an organizational outcome — termination, retraining, demotion — not criminal prosecution. Evidence standards are lower than legal proceedings but evidence must still be collected and preserved carefully in case the matter escalates to civil or criminal proceedings.
Standard of proof
Preponderance of evidence (more likely than not). The lowest standard of the five types — but don’t let that suggest sloppiness in collection.
Real-world example
An employee is suspected of exfiltrating customer data before leaving for a competitor. HR initiates an administrative investigation. The security team images the employee’s laptop and reviews DLP logs. The investigation concludes the employee transferred 15,000 records to a personal USB drive — a policy violation. The employee is terminated. The evidence collected is later used to support a civil lawsuit for trade secret misappropriation.
Criminal investigation
Conducted by law enforcement (FBI, national cybercrime units) to determine whether a crime was committed and to support prosecution. Security professionals play a supporting role: preserving evidence, maintaining chain of custody, and cooperating with investigators. Once law enforcement is involved, the organization should not independently conduct forensic analysis on the same systems without coordination — improper handling can contaminate evidence.
Standard of proof
Beyond reasonable doubt — the highest standard. Evidence must be collected with strict chain of custody. Digital forensics must follow validated methodologies (write-blockers, hash verification of forensic images).
Real-world example
The 2014 Sony Pictures hack was investigated by the FBI as a criminal matter. North Korean state actors were attributed. Sony’s internal security team had to coordinate evidence preservation with FBI agents while simultaneously trying to restore operations. The tension between forensic preservation (leave systems intact) and operational recovery (restore systems quickly) is a defining challenge of criminal investigations involving the organization’s own infrastructure.
Civil investigation
Conducted to support litigation between private parties — typically a breach of contract, negligence claim, or trade secret misappropriation. Discovery in civil litigation can compel the organization to produce emails, logs, security policies, audit reports, and forensic evidence. E-discovery obligations activate as soon as litigation is reasonably anticipated — a legal hold must be issued immediately to suspend normal data destruction schedules.
Standard of proof
Preponderance of evidence. But the scope of discovery is broad — opposing counsel can demand virtually any document, log, or communication relevant to the claim. Security records, incident reports, and internal audit findings are all discoverable.
Real-world example
After the 2013 Target breach, Target faced hundreds of civil lawsuits from banks seeking to recover card reissuance costs. Discovery required Target to produce internal security assessments, Trustwave QSA reports, and FireEye alert logs. Internal documents showing Target had received security warnings it did not act on were central to the civil liability argument. Security documentation that seems routine becomes litigation evidence in civil proceedings.
Regulatory investigation
Conducted by a regulatory authority (FTC, SEC, ICO, HHS OCR) following a reported breach, complaint, or routine audit. Regulators have subpoena power and can compel document production. The organization must cooperate fully and cannot destroy potentially relevant records once a regulatory inquiry begins. Regulatory investigations often run in parallel with civil litigation, creating complex legal obligations.
Standard of proof
Varies by regulator and jurisdiction. Regulators typically need to establish a violation of specific regulatory requirements — negligent security, failure to notify, inadequate safeguards. The burden is often on the organization to demonstrate it met the standard.
Real-world example
Following the Anthem breach (2015), HHS OCR opened a regulatory investigation under HIPAA. The investigation found Anthem had conducted an inadequate risk analysis — the foundational HIPAA Security Rule requirement. Anthem settled for $16 million. Critically, the settlement was not because Anthem was breached, but because the risk analysis process that should have identified and addressed the vulnerability had not been performed adequately. The breach was the trigger; the regulatory violation was the underlying failure.
Industry standards investigation
Conducted by industry bodies or their designated assessors (QSAs for PCI-DSS, auditors for SOC 2) following a suspected standards violation. PCI-DSS forensic investigations, for example, are conducted by PCI Forensic Investigators (PFIs) — qualified third parties who follow specific methodologies and report findings to the card brands. These investigations can result in fines from card brands, increased compliance requirements, or loss of ability to process card payments.
Standard of proof
Contractual and standards-based — not a legal standard. The question is whether the organization met the requirements of the standard at the time of the incident and maintained appropriate documentation.
Real-world example
Following a card breach at a restaurant chain, Visa initiates a PCI forensic investigation through a PFI. The PFI determines the POS systems were running out-of-date software and cardholder data was stored unencrypted after authorization — violations of PCI-DSS Requirements 3 and 6. The card brands levied fines and placed the chain in a remediation program with quarterly QSA assessments. The restaurant faced both the standards investigation and concurrent civil suits from issuing banks.
Develop, document, and implement security policy, standards, procedures, and guidelines
Security policy documentation creates the formal, enforceable framework within which all security activities operate. Each tier of the hierarchy serves a different purpose and targets a different audience. Conflating them — writing procedures into policy, or guidelines into standards — creates governance dysfunction.
High-level, mandatory, long-lived
Defines what must be done and why. Approved by senior leadership. Rarely changes. Technology-agnostic. Creates legal and compliance obligations for the organization.
Example: “All organizational data must be classified according to the Data Classification Policy and handled in accordance with the requirements for its classification level.”
Mandatory, specific, measurable
Defines how policy must be implemented. Specifies required technologies, configurations, and minimum baselines. More specific than policy; less operational than procedures.
Example: “All data classified as Confidential must be encrypted at rest using AES-256. All data in transit must use TLS 1.2 or higher.”
Step-by-step, operational, role-specific
Defines exactly how tasks are performed. Written for practitioners. Includes specific system names, tool configurations, and sequenced steps. Changes frequently as systems evolve.
Example: “To encrypt a file for secure transmission: (1) Open VeraCrypt. (2) Create a new volume… (3) Verify encryption with the following command…”
Recommended, flexible, advisory
Provides best-practice recommendations where mandatory requirements would be too restrictive. Not enforceable — but non-compliance should be documented and risk-accepted.
Example: “When working remotely, it is recommended to use a privacy screen filter to prevent shoulder surfing in public locations.”
🌐 Real-world example — policy without procedure
A financial services firm had a clear policy: “All sensitive data must be encrypted before transmission to third parties.” In a 2019 breach investigation, it emerged that a business analyst had been sending unencrypted customer files to an outsourcing partner for months. The analyst wasn’t malicious — there was simply no procedure explaining how to encrypt files for external transmission. The policy stated what; no document stated how. Policy without procedure creates a compliance gap that human judgment fills inconsistently.
Identify, analyze, assess, prioritize, and implement Business Continuity (BC) requirements
Business Continuity planning ensures the organization can continue critical operations during and after a disruption — whether a ransomware attack, natural disaster, or critical supplier failure. BC is distinct from Disaster Recovery: BC is about maintaining operations during a disruption; DR is about restoring systems after one. Both are required; they are not interchangeable.
Business Impact Analysis (BIA)
The BIA is the foundation of all BC planning. It identifies which business processes are critical, quantifies the impact of their disruption, and establishes two key metrics that drive all subsequent recovery architecture decisions.
Recovery Time Objective (RTO)
The maximum acceptable time a business process can be unavailable. Drives redundancy and failover architecture decisions. RTO of 1 hour requires different infrastructure than RTO of 24 hours.
Recovery Point Objective (RPO)
The maximum acceptable data loss measured in time. RPO of 4 hours means backups must run at least every 4 hours. Drives backup frequency and replication strategy.
Maximum Tolerable Downtime (MTD)
The absolute maximum time before the business process failure becomes unrecoverable — customers leave, regulatory penalties trigger, contracts default. RTO must always be less than MTD.
Single Point of Failure (SPOF)
Any component whose failure alone causes the entire system or process to fail. BIA identifies SPOFs; BC architecture eliminates or mitigates them through redundancy.
External dependencies
Modern organizations depend on external parties — cloud providers, SaaS vendors, payment processors, ISPs — whose availability is outside the organization’s direct control. BC planning must account for these dependencies explicitly: what happens if AWS us-east-1 goes down? What if the payment processor’s API is unavailable for 6 hours?
🌐 Real-world example
On December 7, 2021, AWS us-east-1 experienced a major outage lasting several hours. Organizations whose BC plans treated AWS as infinitely reliable discovered that they had no fallback. Airlines couldn’t check in passengers (airport kiosks ran on cloud APIs), delivery services couldn’t route drivers, and streaming platforms went dark. Organizations that had multi-region architectures or tested their failover procedures were operational within minutes. Those that had never tested failover discovered their DR plans didn’t work under real conditions. The lesson: BC planning without testing is documentation, not preparedness.
Contribute to and enforce personnel security policies and procedures
People are simultaneously the most valuable asset and the most common attack vector in any organization. Technical controls can be circumvented through social engineering; privileged insiders can cause damage no firewall can prevent. Personnel security creates the human governance layer that surrounds technical controls.
Candidate screening
Background checks, reference verification, employment history, criminal record checks, and credential verification. For high-privilege roles, financial background and social media screening may apply. Scope must comply with employment law in each jurisdiction.
Employment agreements
NDAs, acceptable use policies, IP assignment agreements, and conflict of interest declarations signed before access is granted. These establish contractual obligations that support enforcement and legal action if violated.
Onboarding
Security awareness training, role-based access provisioning under least privilege, and policy acknowledgment before any system access. Access granted at onboarding must match the current role — not the previous employee’s permissions.
Transfers
Role changes trigger access recertification. Permissions from the previous role must be revoked before the new role’s permissions are granted. Failure to manage transfers creates access accumulation — the gradual build-up of permissions across multiple roles.
Termination
Immediate revocation of all access at the moment of separation — not after notice period, not after equipment return. Exit interviews, return of assets, NDA reminder, and a litigation hold assessment (for involuntary terminations). Hostile terminations require security escort and accelerated revocation.
Vendor / contractor controls
Third parties with system access must sign security agreements, undergo background checks appropriate to their access level, and operate under least privilege. Contractor accounts must be time-limited and tied to specific engagements — not open-ended.
🌐 Real-world example — termination failure
In 2020, a former Cisco engineer pleaded guilty to computer fraud after deleting 456 virtual machines in Cisco’s WebEx Teams infrastructure — two months after his resignation. His cloud administrator credentials had never been revoked following his departure. The deletion caused approximately $2.4 million in damages and affected 16,000 WebEx Teams accounts for up to two weeks. Immediate access revocation at the point of separation is not an IT formality — it is a security control with direct financial consequences.
Understand and apply risk management concepts
Risk management is the systematic process of identifying, analyzing, and responding to risks so that the organization pursues its objectives with acceptable uncertainty. It is not the elimination of all risk — that is impossible and unaffordable. It is the informed, documented acceptance or mitigation of risk at a level the organization’s leadership has consciously approved.
Core formula
Risk = Threat × Vulnerability × Impact
Threat — any circumstance or event with potential to cause harm (threat actor, natural disaster, human error).
Vulnerability — a weakness that could be exploited by a threat. Vulnerabilities without threats are low priority; threats without vulnerabilities cannot cause harm.
Impact — the consequence if the threat exploits the vulnerability: financial loss, reputational damage, regulatory penalty, operational disruption.
Risk management works by reducing vulnerability (patching, hardening), reducing impact (segmentation, backup), or reducing threat likelihood (threat intelligence, law enforcement cooperation). You cannot eliminate threats — you can only reduce your exposure to them.
Risk response options
Mitigate (Reduce)
Implement controls to reduce likelihood or impact to an acceptable level. Most common response.
Deploy MFA to reduce credential theft risk.
Transfer (Share)
Shift financial consequence to a third party. Does not eliminate the risk — only the financial exposure.
Purchase cybersecurity insurance. Outsource payment processing to a PCI-compliant provider.
Avoid
Eliminate the activity that creates the risk. Most effective but often impractical — may mean not pursuing a business opportunity.
Decide not to store payment card data at all — use a payment tokenization provider instead.
Accept
Acknowledge the risk and choose to operate with it. Must be formally documented and signed off by an authorized risk owner. Risk acceptance without documentation is negligence.
Accept the residual risk of an EOS legacy system pending a 12-month replacement project, with compensating controls documented.
Control types
Preventive
Stop an incident before it occurs. Firewalls, access controls, encryption, security awareness training. Most cost-effective when applicable.
Detective
Identify incidents in progress or after the fact. IDS/IPS, SIEM, audit logs, DLP alerts. Essential for identifying failures in preventive controls.
Corrective
Restore systems to normal operation after an incident. Incident response procedures, backup restoration, patch deployment following exploitation.
Deterrent
Discourage potential attackers from attempting an attack. Warning banners, visible security cameras, publicized prosecution of violators.
Compensating
Alternative controls used when the primary control cannot be implemented. Must provide equivalent or greater protection. Must be documented as temporary with a remediation timeline.
Directive
Guide or mandate behavior through policy, training, or procedure. Security awareness training, acceptable use policies, mandatory procedures.
🌐 Real-world example — risk acceptance failure
In 2017, the WannaCry ransomware spread globally through an unpatched SMBv1 vulnerability (EternalBlue). NHS hospitals in the UK were among the hardest hit, with 80 of 236 trusts affected. Investigation found that many had been aware of the vulnerability and the available patch for months, but had not applied it due to concerns about system compatibility. The risk was not formally accepted — it was simply not acted upon. 19,000 appointments were cancelled. The informal, undocumented non-action of risk “acceptance” had no compensating controls, no timeline, and no authorization from senior leadership. That is not risk acceptance — it is neglect.
Understand and apply threat modeling concepts and methodologies
Threat modeling is a structured process for identifying potential threats to a system, analyzing how they could be realized, and determining which controls are most effective in addressing them. Done early in the design phase, it is far cheaper to address findings than post-deployment. Done well, it prevents entire categories of vulnerability from being built in.
Major threat modeling methodologies
STRIDE
Developed by Microsoft. A mnemonic for six threat categories used to systematically analyze each component of a data flow diagram. For each component, the analyst asks: can each STRIDE threat be realized against this element? The output is a list of threats mapped to specific system components, each associated with a mitigating control.
The six categories
Spoofing — impersonating another user or system. Tampering — unauthorized modification of data. Repudiation — denying having performed an action. Information Disclosure — exposing data to unauthorized parties. Denial of Service — making a resource unavailable. Elevation of Privilege — gaining higher permissions than authorized.
Real-world example
A development team building a REST API applies STRIDE to each endpoint. For the /users/{id} endpoint, they identify: Spoofing (unauthenticated requests), Tampering (malicious payloads in request body), Information Disclosure (returning more user data than the caller is authorized to see). Each finding drives a specific control: OAuth 2.0 for authentication, input validation for tampering, and field-level authorization for disclosure. STRIDE surfaces design flaws before code is written.
PASTA — Process for Attack Simulation and Threat Analysis
A risk-centric methodology in seven stages: define business objectives → define technical scope → decompose the application → threat analysis → vulnerability and weakness analysis → attack modeling → risk and impact analysis. PASTA explicitly ties technical threat analysis to business risk — making it particularly suitable for organizations that need to present threat modeling outputs to non-technical stakeholders.
Key advantage
Business-aligned output. The final stage produces a risk-prioritized list of threats with business impact quantification — directly usable in board-level risk reporting and security investment decisions.
Real-world example
A financial services firm uses PASTA when onboarding a new customer-facing payments application. Stage 3 (application decomposition) reveals a data flow between the mobile app and a legacy back-end processor that was not in the architecture diagram. Stage 5 identifies that this undocumented flow lacks encryption. The finding is prioritized in Stage 7 as high-risk (business impact: PCI-DSS violation, cardholder data exposure). It is remediated before go-live. Without PASTA, the undocumented flow might not have been discovered until post-launch audit.
DREAD
A quantitative risk rating model used to prioritize identified threats. Each threat is scored 1–10 across five dimensions, and an average score drives prioritization. Originally developed by Microsoft but since deprecated in favor of STRIDE for design-phase use; DREAD is now more commonly used for scoring and prioritizing a list of already-identified vulnerabilities.
The five dimensions
Damage potential — how much harm if exploited? Reproducibility — how easily can the attack be repeated? Exploitability — how much skill/resources are required? Affected users — how many users are impacted? Discoverability — how easily can the vulnerability be found?
Real-world example
A penetration testing team identifies 23 vulnerabilities in a web application. The client needs a prioritized remediation plan with limited budget. DREAD scoring on each finding produces a ranked list: an unauthenticated SQL injection affecting all users scores 9.2 (critical); a reflected XSS requiring user interaction affecting single sessions scores 4.8 (medium). Budget goes to the top 5 findings. DREAD makes prioritization explicit, auditable, and defensible to management.
Attack trees
A graphical, hierarchical representation of ways a goal (root node) can be achieved by an attacker. Sub-goals branch downward, with AND nodes (all children must be achieved) and OR nodes (any child is sufficient). Attack trees are valuable for communicating complex attack paths to non-technical stakeholders and for identifying which defenses break the most attack paths simultaneously.
Key advantage
Visual and intuitive. A single attack tree for “attacker achieves unauthorized admin access” makes the full range of attack vectors visible in one diagram — helping decision-makers understand why controlling a specific chokepoint is high-value.
Real-world example
A bank’s security team builds an attack tree for “attacker transfers funds without authorization.” The root has two major branches: compromise customer credentials (OR) and compromise internal banking system. The customer credentials branch has sub-nodes: phishing, credential stuffing, SIM swapping, malware. Analyzing the tree reveals that multi-factor authentication (MFA) breaks every credential sub-branch simultaneously — making it the highest-value single control in the tree. The tree made the investment case for MFA unambiguous to the board.
Apply Supply Chain Risk Management (SCRM) concepts
Modern organizations depend on hardware, software, and services they do not build or control. Every component sourced from a supplier carries the risk that the supplier — or someone who compromised the supplier — has introduced vulnerabilities, backdoors, or counterfeit components. Supply chain risk is not a theoretical concern: several of the most damaging breaches of the past decade were supply chain attacks.
Threat categories
Product tampering
Malicious modification of hardware or software during manufacturing, shipping, or distribution. An adversary inserts functionality (backdoor, keylogger) before the product reaches the customer.
Mitigation: hardware attestation, tamper-evident packaging, verified delivery chain.
Counterfeits
Fake hardware or software that lacks the security properties of the genuine product. Counterfeit network hardware may not implement encryption correctly; fake chips may behave unpredictably under load.
Mitigation: authorized supplier programs, part serialization verification, grey market sourcing prohibition.
Implants
Hardware or software components inserted specifically to enable surveillance or sabotage. May be inserted by nation-state actors at the manufacturing or logistics stage.
Mitigation: silicon root of trust, physically unclonable functions (PUF), hardware security modules.
Compromised updates
Malicious code delivered through legitimate software update mechanisms. The attacker targets the supplier’s build or distribution system rather than the end customer directly.
Mitigation: software bill of materials (SBOM), code signing verification, update integrity checking.
Key mitigations
Software Bill of Materials (SBOM)
A machine-readable inventory of all components in a software product — including third-party libraries and their versions. Enables rapid identification of affected systems when a vulnerability is disclosed in a component (e.g., Log4Shell).
Silicon Root of Trust
Hardware-based cryptographic verification that a device’s firmware and boot sequence have not been tampered with. The trust chain begins in immutable hardware — not software that could itself be compromised.
Physically Unclonable Function (PUF)
A hardware function that produces a unique, unclonable fingerprint based on manufacturing variation. Used to authenticate hardware components — a counterfeit chip cannot replicate the PUF of a genuine component.
Third-party assessment
Regular security assessments of critical suppliers — questionnaires, on-site audits, penetration testing. Minimum security requirements and SLAs codified in contracts, with right-to-audit clauses.
🌐 Real-world example — SolarWinds
In 2020, Russian state actors compromised SolarWinds’ build pipeline and inserted malicious code (SUNBURST) into a software update for the Orion network monitoring platform. The update was digitally signed by SolarWinds, passed all standard integrity checks, and was installed by approximately 18,000 organizations — including US government agencies, Fortune 500 companies, and security vendors. The attackers did not breach the customers directly; they compromised the supplier. An SBOM and continuous monitoring of build pipeline integrity are among the controls that would have made this attack harder to execute undetected. The attack directly led to US executive orders mandating SBOM adoption across the federal supply chain.
Establish and maintain a security awareness, education, and training program
The most sophisticated technical controls can be bypassed by a single employee who clicks a phishing link, reuses a password, or shares credentials over the phone. Security awareness programs address the human layer — converting employees from a vulnerability into a detection and prevention asset. The program must be ongoing, measured, and updated to reflect current threats.
Awareness vs. training vs. education
Awareness
Recognition. All staff. Ongoing. “You should know this exists and matters.” Phishing simulations, security tip emails, posters. Low depth, high reach.
Training
Skills. Role-specific. Periodic. “You should be able to do this.” Secure coding training for developers, incident response drills for SOC analysts. Moderate depth, targeted reach.
Education
Understanding. Security professionals. Deep curriculum. “You should understand why.” CISSP, SANS courses, university degrees. High depth, low reach.
Effective methods and techniques
Phishing simulations
Controlled phishing campaigns sent to employees. Click rates measure baseline susceptibility. Repeat offenders get targeted training. Monthly campaigns are more effective than annual awareness training alone.
Security champions
Embedding security advocates within business units or development teams. Champions bridge the gap between the security function and operational teams — creating local expertise and a peer-to-peer security culture.
Gamification
Points, leaderboards, badges, and competitions applied to security training. Increases engagement and completion rates. Capture the Flag (CTF) events for technical staff develop real skills in a competitive format.
Social engineering scenarios
Realistic simulations of pretexting calls, tailgating attempts, and USB drops. Builds visceral recognition of attack patterns that awareness slides cannot convey. Results are measurable and drive targeted remediation.
Metrics and measurement
Phishing click rates, training completion rates, policy acknowledgment rates, incident report rates (more reports = more aware staff). Program effectiveness is only demonstrable through measurement.
Emerging topics
Content must evolve with the threat landscape: AI-generated phishing and deepfakes, cryptocurrency scams and business email compromise, blockchain contract security. Annual content reviews are insufficient — quarterly updates are better practice.
🌐 Real-world example
The 2022 Twilio breach began with SMS phishing messages sent to Twilio employees impersonating the IT department. The messages were highly targeted — using employees’ real names and referencing actual Twilio systems. Multiple employees clicked the link and submitted credentials. Twilio’s standard security awareness training had not covered SMS phishing specifically. Post-incident, Twilio implemented: (1) explicit SMS phishing scenarios in awareness campaigns, (2) out-of-band verification procedures for all credential requests, and (3) hardware security keys replacing TOTP for employee authentication. The breach demonstrated that awareness programs must be updated faster than attackers change tactics.
The security and risk management chain
Every gap in this chain is a place where a governance failure, legal violation, or security incident will reveal something was assumed rather than decided.
Establish ethical foundations
Adhere to (ISC)² canons in priority order. Society first, employer second. Document and enforce organizational code of ethics.
Apply the five security pillars
CIA + Authenticity + Non-repudiation. Every control decision maps to one or more pillars. Understand the trade-offs between them.
Align security to business governance
Security reports to the board, not just IT. Decisions documented as due care and due diligence. Controls mapped to a recognized framework.
Understand legal and compliance obligations
Know which regulations apply to your data, your jurisdiction, and your customers. Build compliance into controls — not as an audit exercise.
Build and test policy hierarchy
Policy → Standards → Procedures → Guidelines. Each tier serves a different audience. All four must exist; policy without procedure creates human gaps.
Manage risk formally
Identify, analyze, respond. Every acceptance must be documented and authorized. Continuous monitoring detects when risk posture changes.
Secure the supply chain
Threats enter through suppliers. SBOM, third-party assessments, silicon root of trust, and verified update chains are non-optional for critical systems.
Train the human layer
Awareness + Training + Education for every role. Measure behavioral change, not just completion rates. Update content faster than attackers change tactics.
By profession, a CloudSecurity Consultant; by passion, a storyteller. Through SunExplains, I explain security in simple, relatable terms — connecting technology, trust, and everyday life.
Leave a Reply