Control Categories

There are 4 contol categories:

Technical -> implemented using techonogies -> firewall, antivirus, IPS ( If it keeps working at 3 a.m. with nobody watching, it is probably technical.)

Managerial -> administritive decisions -> security policies (governance level)

Operational -> implemented by people (day-to-day) -> awareness training, log reviews. ( If a human has to perform the task for the protection to exist, it is operational.)

Physical -> objects in the real world -> security camera, locks, fences

[!NOTE] Exam tip: On the exam, a question may describe a badge reader on a door. The reader itself is a technical control, but the door and lock are physical - read carefully to see which element the question is really asking about.

Control Types

Controls types are the relationship to the timeline. Some controls exist to stop, while others to simply discourage, and others to prevent.

There are six control types:

Preventive -> Blocks the event from occurring at all -> Firewall, door lock

Deterrent -> discourages the attacker -> Warning signs, login banners

Detective -> Identifies and records events -> IDS, log review, CCTV footage

Corrective -> reverses or reduces damage -> backups, patching

Compensating -> Substitute protection when main is not feasible -> network segmentation (alternate safeguard adopted because the primary control cannot be implemented - often for cost, compatibility, or legacy reasons)

Directive -> Direct or mandate desired behaviour -> 'authorized personnel only' procedures

[!NOTE] A deterrent works on the attacker's decision (a sign saying 'premises under surveillance' stops nobody physically); a preventive control works on the attack itself (the locked gate stops entry even if the attacker is undeterred). A real camera that records is detective, its visible housing is deterrent, and the fence beside it is preventive.

detective vs. corrective straight: detection only tells you something happened; correction changes the state back.

Exam tip: A quick memory aid: directive says 'do this,' deterrent says 'don't you dare,' preventive says 'you shall not pass,' detective says 'something happened,' corrective says 'let's fix it,' and compensating says 'plan B provides equivalent protection.'

Combining Control Category and Type

Every control has both a category and type. Onde control may have more that one type depending on how it is used (a CCTV deters when visible and detecs when reviewed)

Control	Category	Type
Firewall deny rule	Technical	Preventive
Login warning banner	Technical	Deterrent
SIEM alert on failed logins	Technical	Detective
Restoring files from backup	Operational	Corrective
Security awareness training	Operational	Preventive (also directive in intent)
Bollards in front of the lobby	Physical	Preventive
Guard dog warning sign	Physical	Deterrent
Risk assessment program	Managerial	Preventive

Answer based on the FUNCTION described in the scenario, not the device name. On the exam, they may give options that are types when asking for categories

Defense in depth

Dephense in depth layers multiple different controls so that the failure of any one layer leaves the other still standing. Each layer buys time, raises the attacker's cost, and creates another chance to detect the intrusion.

Managerial layer - a data classification policy defines who may access customer records.
Operational layer - quarterly access reviews and administrator training keep permissions honest.
Technical layer - firewall segmentation, least-privilege ACLs, encryption at rest, SIEM alerting.
Physical layer - the database server sits in a locked, badge-controlled data center.

[!NOTE] Defense in depth - A design strategy that layers multiple overlapping controls - ideally drawn from different categories and types - so that no single point of failure exposes the asset. Also called layered security.

Exam tip: On the exam, phrases like 'multiple overlapping controls,' 'layered security,' or 'no single point of failure' signal defense in depth. The best answers usually add a DIFFERENT kind of layer, not a second copy of the one that just failed.

Selecting controls

Knowing the classification grid is step one; choosing WHICH control to deploy is the real job. Selection is risk-driven: identify what you are protecting, what threatens it, and how much loss is tolerable, then pick controls whose cost and friction are proportionate.

[!NOTE] Security control - Any safeguard or countermeasure - technical, managerial, operational, or physical - implemented to reduce risk to an asset by protecting its confidentiality, integrity, or availability.

On the exam the correct answer is the APPROPRIATE control, not the strongest one.

Classification drills and exam keywords

discourage, warn, visible → deterrent
block, stop, prevent, deny → preventive
identify, alert, log, notify, discover → detective
restore, recover, repair, quarantine → corrective
policy requires, mandate, instruct → directive
instead of, not feasible, alternative → compensating

Tricky control	Best classification	Why
IDS (intrusion detection system)	Technical, detective	It only alerts - it never blocks traffic
IPS (intrusion prevention system)	Technical, preventive	It sits inline and drops the malicious traffic
Visible CCTV camera	Deterrent when seen, detective when reviewed	Classify by the function described in the scenario
Security awareness training	Operational, preventive	People deliver and receive it, aiming to stop incidents before they start
Backup generator	Physical, compensating	Substitutes for utility power to preserve availability

[!NOTE] Exam tip: When two answers both seem right, re-read the scenario for what the control actually DID in the story

The CIA triad and non-repudiation

Every security decision ultimately protects one or more of three properties: confidentiality, integrity, and availability - the CIA triad.

Confidentiality - Keeping data readable only by authorized parties. Enforced with encryption, access controls, and data classification. A breach of confidentiality is a disclosure.

Integrity - Assurance that data has not been altered without authorization, accidentally or maliciously. Enforced with hashing, digital signatures, and version control. A breach of integrity is an unauthorized modification.

Availability - Assurance that systems and data are accessible when needed. Enforced with redundancy, backups, patching, and DDoS protection. A breach of availability is an outage or denial of service.

Non-repudiation - Proof that a specific party performed an action, such that they cannot plausibly deny it later. Digital signatures provide non-repudiation because only the signer's private key could have produced the signature.

[!NOTE] A digital signature provides both integrity and non-repudiation because it binds the hash to a specific private key.

Mechanism	Primary CIA property served
Encryption (AES, TLS)	Confidentiality
Hashing (SHA-256)	Integrity
Digital signature	Integrity + authenticity + non-repudiation
RAID, clustering, backups, generators	Availability
Access control lists	Confidentiality (and integrity of the data behind them)
Patching and DDoS protection	Availability

AAA: authentication, authorization, accounting

AAA describes the lifecycle of controlled access.

Protocols like RADIUS and TACACS+ exist specifically to centralize AAA for network devices and remote access. RADIUS is the widespread standard: UDP-based, it encrypts only the password field and combines authentication and authorization in one exchange. TACACS+ (TCP port 49) encrypts the entire payload and separates all three A's, which is why it is favored for granular network-device administration.

Authenticating people typically combines factors - something you know, have, or are - with multifactor authentication as the norm.

Authentication - 'Prove who you are' (password + authenticator app).
Authorization - 'Here is what you may do' (your role grants read access to the HR share).
Accounting - 'Here is what you did' (logs show you opened salary.xlsx at 14:02).

[!NOTE] Authorization model - The scheme a system uses to decide what an authenticated subject may access. Common models include role-based access control (RBAC), attribute-based access control (ABAC), discretionary (DAC), and mandatory (MAC). The model determines how permissions are assigned and evaluated.

Gap analysis

A gap analysis compares where your security program currently is against where it should be - the 'should' usually being a framework, regulation, or internal baseline such as NIST CSF, ISO 27001, or PCI DSS.

In practice a gap analysis is often the first project after adopting a new framework or before an audit.

[!NOTE] Exam tip: On the exam, keywords like 'compare current state to a desired framework' or 'determine what is missing before certification' point to gap analysis - not risk assessment, which measures likelihood and impact of threats rather than distance from a standard.

Gap analysis - A structured comparison of an organization's current security posture against a desired target state - a framework, regulation, or baseline - producing a prioritized list of missing or deficient requirements and a remediation roadmap.

Don't confuse: Keep the assessments straight: a gap analysis measures distance from a standard, a risk assessment measures likelihood and impact of threats, an audit formally verifies compliance (often by a third party), and a penetration test actively attempts exploitation. Exam stems tell you which one they want by naming the yardstick or the activity.

the output of a gap analysis is a prioritized remediation plan mapping missing requirements to owners and timelines

Zero Trust

Zero Trust replaces the assumption that everything inside the firewall was trustworthy with 'never trust, always verify'

SY0-701 frames Zero Trust using two planes borrowed from NIST SP 800-207: the control plane, which makes access decisions, and the data plane, which enforces them on actual traffic.

Plane	Role	Components and concepts
Control plane	Decides whether access is granted	Adaptive identity, threat scope reduction, policy-driven access control, policy engine, policy administrator
Data plane	Carries the traffic and enforces the decision	Implicit trust zones, subject/system, policy enforcement point
In the control plane, adaptive identity means authentication requirements change with context - a login from a managed laptop in the office may need only a password and token, while the same account from a new country triggers step-up verification. Threat scope reduction is the design goal of limiting how far any single compromise can spread, largely by shrinking implicit trust and minimizing each identity's reach. Policy-driven access control ties every decision to written, evaluable rules rather than network location.

Policy engine - The control-plane component that makes the grant/deny decision for each access request

Policy administrator - The control-plane component that communicates the policy engine's decision to the enforcement point

Policy enforcement point (PEP) - The data-plane component that sits in the traffic path between subject and resource, actually allowing or blocking the connection based on what the policy administrator tells it.

[!NOTE] Don't confuse: Exam trap: keep the planes straight. Deciding is control plane (policy engine, policy administrator, adaptive identity); enforcing on live traffic is data plane (policy enforcement point, implicit trust zones, subject/system). If the question says a component 'blocks the packet,' it is the PEP, never the policy engine.

Physical security

Physical security is the outermost layer of defense in depth: if an attacker can touch your server, most logical controls can eventually be bypassed.

Bollards - short, sturdy posts that stop vehicles from ramming an entrance while letting pedestrians pass.
Access control vestibule - two interlocking doors where the first must close before the second opens, defeating tailgating; formerly called a mantrap.
Fencing - defines the perimeter and delays intruders; height and topping (e.g., anti-climb) set its seriousness.
Video surveillance - cameras that deter when visible and provide detective evidence when footage is reviewed; modern systems add motion detection and object recognition.
Security guard - a flexible control that can verify identity, challenge suspicious behavior, and respond in real time - the only control on this list with judgment.
Access badge - a credential (often a smart card or proximity card) that both authenticates the holder to badge readers and creates an entry log.
Lighting - well-lit approaches deter intruders and make cameras and guards effective at night.

Sensor	How it detects	Typical use
Infrared	Senses body heat (changes in IR radiation)	Indoor motion detection in rooms and hallways
Pressure	Senses weight on a surface	Floor pads at entry points, protected floor zones
Microwave	Emits microwaves and measures reflection changes	Large or outdoor areas; penetrates some walls
Ultrasonic	Emits high-frequency sound and reads reflections	Enclosed spaces; detects motion and presence

Each layer is individually beatable; together they force an intruder to defeat many controls in sequence, with every attempt adding delay, noise, and evidence.

Access control vestibule - A physical anti-tailgating chamber of two interlocking doors: the outer door must close and lock before the inner one opens, typically with authentication in between, so exactly one authorized person passes per cycle.

[!NOTE] Don't confuse: Match the threat precisely: vehicles are stopped by bollards, tailgating by a vestibule, climbing by fencing, and only a guard can exercise judgment - challenge a stranger, verify a story, adapt to the unexpected. If a question asks which control can respond to something unanticipated, the human beats every sensor and camera.

Deception and disruption technology

Deception technologies plant attractive fakes in your environment so attackers reveal themselves.

Honeypot - A deliberately vulnerable-looking decoy system placed to attract attackers, observe their techniques, and alert defenders. It holds no production data.

Honeynet - An entire network of honeypots - fake servers, workstations, and services - simulating a realistic environment so attackers explore longer and expose more of their methods.

Honeyfile - A bait file with an enticing name such as passwords.xlsx placed on a share. Any access to it triggers an alert, revealing snooping insiders or intruders.

Honeytoken - Fake data - a bogus API key, database record, or set of credentials - seeded where attackers might steal it. When the token is ever used, you know exactly which system was breached

[!NOTE] Exam tip: On the exam, scale is the clue: one decoy system is a honeypot, a whole decoy network is a honeynet, a decoy file is a honeyfile, and decoy data or credentials are honeytokens. If the scenario says 'detect when stolen credentials are used,' pick honeytoken.

Don't confuse: Decoys must be isolated and disposable. Never store genuine data on deception systems.

Business processes impacting security operations

A formal process forces every change through approval, assigns clear ownership, involves the right stakeholders, and analyzes impact before anything touches production. Most organizations run this through a Change Advisory Board (CAB) that reviews requests on a regular cadence.

Approval process - a documented request is reviewed and authorized before work begins, creating accountability and a paper trail.
Ownership - one named person or team is responsible for the change end to end; when something goes wrong at 2 a.m., everyone knows who owns it.
Stakeholders - everyone affected (application owners, security, help desk, business units) is identified and consulted so surprises are caught in review, not in production.
Impact analysis - an assessment of what could break, who is affected, and how severe the risk is; this drives scheduling and rollback planning.
Test results - evidence from a lab or staging environment that the change works as intended before it is approved for production.
Backout plan - the documented, rehearsed steps to return to the previous working state if the change fails.
Maintenance window - the pre-agreed low-impact time slot (often nights or weekends) when disruptive changes are performed.
Standard operating procedure (SOP) - the step-by-step instructions that make a routine change repeatable and consistent regardless of who performs it.

[!NOTE] Backout plan - A predefined procedure for reversing a change and restoring the last known-good configuration. A change request without a tested backout plan should not be approved, because hope is not a rollback strategy.

Exam tip: On the exam, if a change failed at 3 a.m. and the question asks what should have been prepared in advance to restore service, the answer is the backout plan. If it asks when the change should have been scheduled, it is the maintenance window.

In most organizations these elements come together in a change advisory board (CAB): a recurring meeting where each requested change is walked through its impact analysis, test results, schedule, and backout plan before receiving approval

Technical implications of change

Security tooling is often the first casualty: a new application will not run until its executable is added to the allow list, or keeps running when it should have been added to a deny list. Change tickets should explicitly call out which security lists, rules, and policies need updating, or the change either fails or silently weakens protection.

Allow lists / deny lists - application control, firewall, and email filtering lists must be updated in step with the change, or legitimate software is blocked (or malicious software permitted).
Restricted activities - some actions are forbidden outside the change process entirely, such as modifying production databases directly or disabling security agents.
Downtime - many changes require taking a service offline; the impact analysis must state how long and who is affected, and high-availability designs may allow rolling changes with zero downtime.
Service restart - configuration changes to daemons like a web server often only take effect after a restart, briefly interrupting connections.
Application restart - client applications may need restarting to pick up new settings, certificates, or libraries.
Legacy applications - old software with no vendor support is fragile; a routine OS patch can break it, so legacy systems often need compensating controls and extra testing.
Dependencies - systems rely on other systems; upgrading a database can break every application that queries it, so dependency mapping belongs in the impact analysis.

Allow list - A default-deny control listing exactly what IS permitted with everything else blocked. More secure but higher-maintenance

Deny list - A default-allow control listing what is explicitly blocked, while permitting everything else. Weaker but easier to operate

Security prefers failing closed, which is why application allow listing is the stronger posture and why change tickets in such environments carry an explicit 'security lists to update' section.

Documentation and Version Control

A change is not finished when the system works - it is finished when the paperwork matches reality

Stale documentation slows incident response and causes audits to fail.

Version control - A system that tracks every revision of files or configurations, records who changed what and when, and allows rollback to any earlier state. Tools like git apply this to code, firewall rule sets, and infrastructure-as-code templates alike.

Version control is itself a security control. It provides accountability (every change is attributed), integrity (unauthorized edits are visible in the history), and recoverability (any previous version can be restored - a built-in backout mechanism).

Updating diagrams means network maps, data-flow diagrams, and architecture drawings reflect the new state, so the next incident responder is not troubleshooting from a fictional map. Updating policies and procedures means runbooks, SOPs, and security policies are revised to match the new configuration.

[!] Exam tip: On the exam, if responders wasted time because the network diagram showed the wrong topology after a migration, the failed step is updating diagrams - a documentation failure within change management, not a technical control failure.

git log shows exactly what changed and when - and reverting to the last known-good state is a single command, so the backout plan is built into the tooling itself.

Network and architecture diagrams - so responders troubleshoot reality, not history.
Runbooks and SOPs - so the next operator follows steps that still work.
Asset inventories and configuration baselines - so scanners and audits compare against the new normal.
Policies and procedures - so the rules reference systems and processes that still exist.

The change request lifecycle

Every governed change moves through the same arc, whatever tool tracks it. It begins as a request for change (RFC) describing what, why, and how; gains an impact analysis and test evidence; is reviewed and approved; is scheduled into a maintenance window; is implemented following the SOP; is verified working; and is closed with documentation updated. Skipping any stage creates a specific, predictable failure - no approval means no accountability, no verification means silent breakage, no closure means documentation drift.

1. Submit the RFC - what will change, why, and the risk of NOT doing it.
2. Analyze - impact analysis, dependency mapping, and test results from staging.
3. Approve - the CAB or a delegated approver authorizes (or rejects) the change.
4. Schedule - assign the maintenance window and notify stakeholders.
5. Implement - the owner executes per the SOP, with the backout plan on standby.
6. Verify - confirm the change works AND that dependent services still function.
7. Close - record the outcome, update diagrams and procedures, and review anything that went wrong.

Change advisory board (CAB) - The cross-functional group - IT, security, and business representatives - that reviews, prioritizes, and approves change requests, weighing the benefit of each change against its risk and timing.

[!NOTE] Exam tip: Exam questions about the lifecycle usually name a failure and ask which stage would have prevented it. Map the failure to its stage: unauthorized change → approval; surprise outage → impact analysis or scheduling; cannot roll back → backout planning; wrong documentation later → closure.

Standard, normal, and emergency changes

changes are triaged: standard changes are low-risk, routine, and pre-approved (adding a user to an established group, monthly patching through a tested pipeline); normal changes follow the full RFC-and-CAB path; emergency changes fix an active outage or critical exposure immediately, with expedited approval and the full review completed after the fact.

Change class	Approval	Example
Standard	Pre-approved template; no per-instance CAB review	Deploying the routine monthly OS patch set through the tested pipeline
Normal	Full review and CAB approval before any work begins	Migrating the ERP database to new hardware
Emergency	Expedited approval now; full documentation and review afterward	An emergency firewall rule to cut off an active intrusion

Emergency change - A change that must be executed immediately to restore service or stop active harm, using a shortened approval path. It is still authorized, still documented, and still reviewed - just after the fact rather than before.

[!] Don't confuse: 'Emergency' is not a loophole. An emergency change skips the WAIT, not the process: it still requires authorization (however expedited), a record of exactly what was done, and a retrospective review. A scenario where an admin quietly fixes something and tells no one describes an unauthorized change, not an emergency change.

Unauthorized change and configuration drift

configuration drift: a growing distance between what systems are documented and approved to be, and what they actually are. Drift is a security problem because every undocumented change is untested, unreviewed, and invisible to the people defending the system - while attackers actively hunt for the forgotten port and the disabled agent.

Configuration drift - The gradual, unplanned divergence of a system's actual configuration from its approved, documented baseline, caused by ad-hoc changes made outside the change management process

Detection closes the gap. Configuration baselines define the approved state; automated compliance scans and file integrity monitoring compare reality against the baseline; and every detected difference should reconcile to an approved change ticket

Baseline - define the approved configuration for each system class.
Scan - regularly diff reality against the baseline.
Reconcile - match every difference to an approved change ticket.
Remediate and investigate - unmatched differences get fixed AND examined, because some 'drift' is intrusion.

[!] Exam tip: On the exam, 'settings no longer match the documented baseline and no change records exist' is configuration drift caused by unauthorized change - and the process-level fix is enforcing change management, not just correcting the one server.

Public key infrastructure and key pairs

Public key infrastructure (PKI) is the collection of hardware, software, policies, and procedures that create, distribute, and revoke digital certificates - the machinery that lets strangers on the internet trust each other's keys. At its heart is asymmetric cryptography: every participant holds a mathematically linked key pair, and what one key encrypts only the other can decrypt.

Public key - The half of an asymmetric key pair that is shared freely, typically inside a certificate. Others use it to encrypt messages to you or to verify signatures you created.

Private key - The half of the key pair that must never leave the owner's control. It decrypts what the public key encrypted and creates digital signatures. A leaked private key means the identity itself is compromised and the certificate must be revoked.

Key escrow - Storing a copy of a private or decryption key with a trusted third party (or an internal escrow system) so the organization can recover encrypted data if the key holder leaves, dies, or loses the key. It trades some confidentiality risk for guaranteed recoverability.

In the workplace, PKI shows up everywhere: the padlock in the browser, smart-card logon, signed emails, code-signing on software updates, and machine certificates for 802.1X. When an employee encrypts files with a personal certificate, key escrow is what saves the company's data after that employee departs.

Goal	Key used	Who can perform it
Encrypt a message to Alice	Alice's public key	Anyone - public keys are public
Decrypt that message	Alice's private key	Only Alice
Sign a document as Alice	Alice's private key	Only Alice
Verify Alice's signature	Alice's public key	Anyone

Notice the symmetry the table exposes: public-key operations (encrypting TO someone, verifying THEIR signature) are things anyone may do, while private-key operations (decrypting, signing) are things only the owner can do. Every PKI exam question resolves by asking two things - what is the goal (secrecy or proof of origin), and whose key pair is involved.

Encryption: levels, transport, and algorithms

Encryption can be applied at many granularities, and each level answers a different threat. Full-disk encryption (like BitLocker or FileVault) protects everything on a lost or stolen laptop, but once the machine is booted and unlocked it protects nothing from a logged-in attacker. Partition and volume encryption protect one section of storage; file-level encryption protects individual documents even as they are copied around; database encryption protects a whole data store, while record-level encryption protects individual rows or fields - so a breached table leaks only ciphertext for the sensitive columns.

Level	Protects	Typical threat addressed
Full-disk	Entire physical drive	Lost or stolen device
Partition	One partition of a drive	Isolating sensitive areas of storage
Volume	A logical volume (may span disks)	Protecting a mounted data set
File	Individual files	Files copied, shared, or backed up
Database	The whole database	Stolen database files or backups
Record	Individual rows/fields	Limiting exposure inside a live database

Data must also be protected in motion - transport/communication encryption. TLS secures web and API traffic (HTTPS on port 443), IPSec secures traffic at the network layer for VPN tunnels, and SSH on port 22 replaces cleartext remote administration. Data-at-rest encryption does nothing once the bytes leave the disk, which is why both are required.

Property	Symmetric	Asymmetric
Keys	One shared secret key	Public/private key pair
Speed	Fast - suited to bulk data	Slow - suited to small payloads
Key distribution	Hard: the secret must be shared safely	Easy: public key is public
Examples	AES, ChaCha20, 3DES (legacy)	RSA, ECC, Diffie-Hellman (exchange)
Typical role	Encrypting the actual data	Exchanging keys and signing

[!NOTE] Key exchange - The process of establishing a shared symmetric key over an untrusted channel. Diffie-Hellman (and its elliptic-curve form, ECDHE) lets two parties derive the same secret without ever transmitting it - the standard opening move of a TLS handshake, after which fast symmetric encryption takes over.

Exam tip: On the exam, real systems are hybrid: asymmetric crypto authenticates the parties and exchanges a session key, then symmetric crypto (AES) encrypts the bulk traffic. If a question asks why both are used, that division of labor - secure exchange plus speed - is the answer.

Don't confuse: Encryption at rest and encryption in transit answer different threats, and one never substitutes for the other.

Algorithm choice and key length together determine strength. AES with a 128- or 256-bit key is the modern symmetric standard; RSA needs 2048 bits or more, while ECC achieves comparable strength with far shorter keys - which is why phones and IoT devices favor it. Longer keys are exponentially harder to brute-force but cost more compute; deprecated algorithms like DES and hash functions like MD5 remain wrong answers no matter the key length.

Cryptographic hardware and key management

Keys are only as safe as the place they live. Storing a private key in a file on the same disk it protects is like taping the safe combination to the safe

Trusted Platform Module (TPM) - A dedicated security chip on a single computer's motherboard. It stores keys, generates random numbers, and holds platform measurements for secure boot. BitLocker uses the TPM to seal the disk-encryption key so the drive only unlocks in its own machine with an untampered boot chain.

Hardware security module (HSM) - A tamper-resistant network appliance (or PCIe card) that generates, stores, and uses cryptographic keys at enterprise scale - protecting a certificate authority's root key or a bank's transaction keys. Keys are created inside and designed never to leave in plaintext.

Key management system (KMS) - Software (often cloud-based, backed by HSMs) that manages the full key lifecycle: generation, distribution, rotation, revocation, and destruction, with per-key access policies and audit logs. Essential once an organization has thousands of keys across services.

Secure enclave - An isolated coprocessor or protected region inside a main processor that handles secrets - biometric templates, device keys - walled off from the operating system, so even a fully compromised OS cannot read them. Apple's Secure Enclave is the canonical example.

[!NOTE] Exam tip: On the exam, scope is the differentiator: TPM protects one machine, HSM serves an enterprise or application, a KMS manages key lifecycles at scale, and a secure enclave isolates secrets inside a device's processor (think smartphones).

Obfuscation: steganography, tokenization, and masking

Obfuscation hides or substitutes data rather than mathematically locking it. These techniques complement encryption: sometimes you need data to remain usable in its normal format (tokenization), partially visible (masking), or simply not noticeable at all (steganography).

Steganography - Concealing data inside an innocent-looking carrier - extra bits in an image, audio file, or even network packet timing. The goal is secrecy of EXISTENCE: an observer does not realize a message is present at all.

Tokenization - Replacing sensitive data with a meaningless surrogate token, while the real value sits in a secure token vault. A payment processor stores tok_8f3k2 instead of the card number; a thief who steals the database gets tokens that are useless without the vault. Unlike encryption, there is no mathematical relationship to reverse.

Data masking - Hiding part or all of a value while preserving its format - showing ****-****-****-4821 on a receipt, or replacing production names with realistic fakes in a test database. The masked version is intended for display or non-production use, not for recovery.

[!NOTE] Don't confuse: Tokenization vs. encryption is a favorite trap: encryption is reversible with the key; a token has NO mathematical link to the original and can only be exchanged for it via the vault. If the scenario mentions credit cards, PCI compliance, and format-preserving substitutes, the answer is tokenization.

Exam tip: On the exam, 'data hidden inside an image file' is steganography, 'card number replaced by a random surrogate' is tokenization, and 'last four digits visible on screen' is masking. Match the mechanism, not just the word 'hide.'

Technique	Reversible?	Typical use
Encryption	Yes - with the key	Protecting data anywhere secrecy is required
Tokenization	Only via the secure token vault	Payment card data; shrinking PCI DSS scope
Data masking	No - masked output is display-only	Receipts, support screens, test databases
Steganography	Yes - extract the hidden payload	Covert communication; also watermarking

Hashing, salting, digital signatures, and key stretching

A hash function takes input of any size and produces a fixed-length fingerprint (digest). It is one-way - you cannot compute the input from the digest - and any change to the input, even one bit, produces a completely different digest. That makes hashing the integrity tool: verify a downloaded ISO with sha256sum, detect tampered files, and store passwords without storing the passwords themselves. Modern choices are the SHA-2/SHA-3 families; MD5 and SHA-1 are broken for security use.

Salting - Adding a unique random value to each password before hashing. Two users with the same password now have different hashes, and precomputed rainbow tables become useless because every salt would need its own table.

Key stretching - Deliberately slowing password hashing by iterating it thousands of times or making it memory-hard, using algorithms such as PBKDF2, bcrypt, or Argon2. A login that takes 200 ms is unnoticeable to a user but devastating to an attacker attempting billions of guesses.

A digital signature combines hashing with asymmetric keys: the sender hashes the message and encrypts that hash with their private key. The recipient recomputes the hash and verifies the encrypted one with the sender's public key. A match proves both integrity (content unchanged) and authenticity/non-repudiation (only that private key could have signed). This is how software updates, e-mail signing (S/MIME), and certificates themselves are protected.

Hashing alone - integrity only; anyone can hash.
Hash + salt + stretching - safe password storage.
Hash + sender's private key - digital signature: integrity, authenticity, non-repudiation.

[!NOTE] Exam tip: On the exam, if the question says two identical passwords produced identical hashes and asks what was missing, the answer is a salt. If it says attackers brute-forced hashes too quickly, the missing piece is key stretching.

Collision - Two different inputs producing the same hash digest. Because digests are fixed-length, collisions must exist in theory; a hash function is considered broken when attackers can CREATE them on demand - as they can with MD5 and SHA-1, which is why both are retired from security use.

Blockchain and the open public ledger

A blockchain is a distributed ledger in which transactions are grouped into blocks, and every block contains the cryptographic hash of the block before it. Altering any historical record would change that block's hash, breaking every subsequent link - and because thousands of independent nodes each hold a full copy and must agree via consensus, a forger would need to overpower most of the network simultaneously. The chain's integrity therefore rests on hashing plus decentralization, not on any trusted administrator.

Open public ledger - A blockchain ledger that anyone can read, join, and verify - no permission required. Cryptocurrencies like Bitcoin use one: every transaction ever made is publicly auditable, which provides transparency and makes retroactive tampering evident to all participants.

For the exam, know the security value beyond cryptocurrency: tamper-evident supply-chain records, audit logs that no single insider can rewrite, and smart contracts. The recurring theme is integrity through immutability - blockchain does not make data confidential (a public ledger is the opposite of confidential); it makes history very hard to falsify.

[!NOTE] Exam tip: On the exam, if asked which CIA property blockchain primarily provides, answer integrity (with availability from replication). It is a wrong answer for confidentiality scenarios.

Everything on an open public ledger is readable by everyone, forever. Pick blockchain on the exam only when the scenario needs a tamper-evident shared record with NO trusted central authority - most other problems are solved better by a signed, replicated database.

Certificates and the trust ecosystem

A digital certificate binds a public key to an identity (a domain, person, or device) and is signed by a certificate authority (CA). Your browser trusts a small set of root CAs; anything those roots sign - directly or through intermediate CAs - inherits trust. This chain from a trusted root down to the server's certificate is the root of trust: compromise the root and everything below it collapses, which is why root CA keys live offline in HSMs.

Certificate signing request (CSR) - The file an applicant generates and sends to a CA to obtain a certificate. It contains the public key and identifying details, and is signed with the applicant's private key - which itself never leaves the applicant. The CA validates the request and returns a signed certificate.

A certificate revocation list (CRL) is a CA-published, signed list of revoked serial numbers that clients download periodically. The Online Certificate Status Protocol (OCSP) instead lets a client query the status of one certificate in real time; OCSP stapling has the web server fetch its own signed status and attach it to the TLS handshake, saving the client the lookup and improving privacy.

Certificate concept	What it means	When you see it
Third-party certificate	Issued by a public CA the world already trusts	Public websites, customer-facing services
Self-signed certificate	Signed by its own key, no CA involved - browsers warn by default	Internal labs, appliances, testing; requires manual trust
Wildcard certificate	Covers one domain level with ``, e.g. `.example.com`	Many subdomains under one cert; convenient, but one key compromise affects them all
Root of trust	The anchor (root CA, or hardware like a TPM) from which all trust chains derive	Browser trust stores, secure boot

[!NOTE] Don't confuse: Wildcard scope trips students up: *.example.com covers mail.example.com and shop.example.com, but NOT the bare example.com and NOT deeper levels like a.b.example.com. Also weigh the risk trade-off - one leaked wildcard key exposes every subdomain it covers.

Exam tip: On the exam, distinguish revocation-checking methods by their behavior: CRL is a periodically downloaded list (can be stale), OCSP is a real-time query per certificate, and stapling moves the OCSP proof into the server's handshake. 'Reduce load on the CA and speed up checking' points to stapling.

Certificate authority (CA) - The trusted organization or internal service that verifies an applicant's identity and signs certificates binding that identity to a public key. Its root certificate lives in browser and OS trust stores, and its signature is what makes an issued certificate trustworthy.

A certificate's life runs in a loop: generate a key pair, submit the CSR, the CA validates and signs, the certificate is deployed - and then it either expires naturally at the end of its validity period or is revoked early because the key was compromised or the system retired. Modern practice automates renewal (the ACME protocol behind Let's Encrypt) because forgotten expirations remain one of the most common causes of self-inflicted outages.

Choosing the right cryptographic solution

Requirement in the scenario	Appropriate solution
Protect data on a lost or stolen device	Full-disk encryption (sealed by a TPM)
Protect data crossing a network	Transport encryption: TLS, IPSec, SSH
Verify a file was not altered	Hashing (SHA-256)
Prove who sent it AND that it was unaltered	Digital signature
Store passwords safely	Hash + salt + key stretching (bcrypt, Argon2)
Keep card data out of scope but usable in workflows	Tokenization
Show partial values to support staff	Data masking
Recover encrypted data if the key holder leaves	Key escrow
Shared record no single party can rewrite	Blockchain / open public ledger

Real deployments layer several rows of that table at once. A payments platform tokenizes card numbers (storage), carries traffic over TLS (transit), keeps its signing keys in an HSM (key protection), stores staff passwords salted and stretched (authentication), and masks all but the last four digits in its support console (display). Each mechanism answers one specific threat; none of them substitutes for another.

[!NOTE] Don't confuse: Three families get confused under exam pressure: encoding (Base64) is reversible by anyone and protects nothing; encryption is reversible only with the key and protects confidentiality; hashing is one-way and protects integrity. Any answer that uses one where another is required - 'hash the file so we can decrypt it later' - is wrong by definition, no matter how plausible it sounds.

Exam tip: When two crypto answers both look right, re-read for the recovery requirement. If the original value must come back (billing needs the real card number), hashing and masking are out. If nothing ever needs recovering (password verification), reversible encryption is the WRONG choice - one-way hashing is safer.