Chapter 1: General Security Concepts

What you will learn

By the end of this chapter you will be able to:

• Classify any security control by category (technical, managerial, operational, physical) and by type (preventive, detective, corrective, compensating, deterrent, directive)
• Explain the zero trust model, including the control plane, the data plane, the policy engine, the policy administrator, and the policy enforcement point
• Define the CIA triad (confidentiality, integrity, availability) and give a real-world example of a failure of each leg
• Describe the AAA framework (authentication, authorization, accounting) and explain how it differs from plain identification
• Compare threat actor types by resources, sophistication, and motivation
• Explain symmetric and asymmetric encryption, and state where AES, RSA, and ECC are each used
• Describe how Diffie-Hellman key exchange lets two parties agree on a secret over an untrusted network
• Explain hashing, why MD5 is broken, what salting does, and how digital signatures combine hashing with asymmetric cryptography
• Walk through the life of a digital certificate: CSR, CA, RA, X.509, DV/OV/EV validation, wildcard and SAN certificates, self-signed certificates, certificate pinning, and key escrow
• Explain obfuscation, steganography, tokenization, and data masking, and choose the right one for a given scenario

Reading

Why security starts with concepts, not tools

Every security tool you will ever configure — a firewall, an endpoint agent, an encryption library — exists to enforce an idea. If you do not understand the idea, you will misconfigure the tool, and a misconfigured control is often worse than no control at all because it creates confidence without protection. This chapter builds the vocabulary of those ideas. CompTIA weights this domain at 12% of the SY0-701 exam, but its real weight in your career is much higher: control classification, zero trust, and cryptography appear inside almost every question in the other four domains too.

A security control is any safeguard or countermeasure that reduces risk to an asset. Controls are not only products. A written password policy, a locked server-room door, a trained employee, and an intrusion prevention system are all controls. The exam expects you to sort controls along two independent axes: the category, which describes how the control is implemented, and the type, which describes what the control is trying to do. A single real-world safeguard has one category and usually one primary type, and exam questions love to test whether you can keep the two axes separate.

Security control categories

The four categories describe the mechanism of the control.

Technical controls (also called logical controls) are implemented in hardware or software. Operating system permissions, firewall rules, encryption, antivirus software, and multi-factor authentication apps are technical controls because technology enforces them without a human making a judgment call in the moment.

Managerial controls (also called administrative controls) are the policies, procedures, and governance decisions that direct the organization. A risk assessment, an acceptable use policy, a vendor review process, and a security awareness program's plan are managerial controls. They are created by decision-makers and they tell everyone else what must happen.

Operational controls are carried out by people performing day-to-day tasks. Reviewing logs each morning, running backups, onboarding and offboarding users, conducting phishing-awareness training sessions, and performing change-management approvals are operational controls. The distinction from managerial controls is subtle but testable: managerial controls decide, operational controls do. The policy that says "logs are reviewed daily" is managerial; the analyst who actually reviews them is performing an operational control.

Physical controls affect the tangible environment. Fences, gates, locks, badge readers, security cameras, bollards, Faraday cages, and cable locks are physical controls because they interact with the physical world rather than with data or decisions.

Security control types

The six types describe the control's intent — its relationship to an incident in time and purpose.

Preventive controls stop an incident before it happens. A firewall blocking a port, an application allow list refusing unknown software, and encryption making stolen data unreadable are preventive. This is the type organizations want most, because preventing an incident is cheaper than responding to one.

Detective controls identify an incident while it is happening or after it has occurred. Log monitoring, intrusion detection systems (IDS), security cameras recording a hallway, and file-integrity monitoring are detective. A detective control does not stop anything by itself; it creates the signal that triggers a response.

Corrective controls fix a system after an incident and restore normal operations. Restoring from backup after ransomware, patching the vulnerability that was exploited, and re-imaging a compromised workstation are corrective. Corrective controls close the loop: detect, respond, repair.

Compensating controls are substitutes used when the primary control cannot be implemented. If a legacy application cannot support multi-factor authentication, you might place it behind a jump server that does support MFA and restrict it to a dedicated VLAN. You have not fixed the application; you have compensated for its weakness with a different control that achieves a similar risk reduction. Compensating controls appear frequently in compliance work, where a standard demands a control that is technically impossible on a particular system.

Deterrent controls discourage an attacker from trying in the first place. Warning banners on login screens, visible security cameras, guard dogs, and the credible threat of prosecution are deterrent. They work on the attacker's decision-making rather than on the attack itself, which is why the same camera can be both deterrent (people see it and behave) and detective (its recordings identify what happened). The exam classifies by the purpose stated in the scenario.

Directive controls tell people what they must or must not do. Policies, procedures, standards, signs ("Authorized Personnel Only"), and mandatory training are directive. A directive control has no technical enforcement behind it; compliance depends on people reading, understanding, and obeying — which is why directive controls are usually paired with preventive or detective controls that verify obedience.

Consider a small clinic rolling out a new patient-records system. The team encrypts the database (technical, preventive), writes a policy requiring unique accounts (managerial, directive), has the help desk verify identity documents before resetting passwords (operational, preventive), installs a badge reader on the records-room door (physical, preventive), enables login auditing (technical, detective), and schedules quarterly restore tests from backup (operational, corrective). One project, many controls — and the exam will hand you exactly this kind of mixed list and ask you to classify individual items. Practice naming both axes for every control you meet in daily life and this section of the exam becomes free marks.

Zero trust: never trust, always verify

Traditional network security drew a hard boundary — the perimeter — and trusted everything inside it. That model collapsed for three reasons: employees work from anywhere, applications live in the cloud rather than in your building, and attackers who breach the perimeter once can then move sideways (laterally) through a soft, trusting interior. Zero trust is a security model built on the opposite assumption: no user, device, or network location is trusted by default, and every request for access must be authenticated, authorized, and continuously evaluated — even requests coming from inside the office.

Three principles define zero trust. Verify explicitly: use every available signal — identity, device health, location, behavior — to decide each request. Use least-privilege access: grant the minimum permissions needed, ideally just in time and for a limited duration. Assume breach: design as if attackers are already inside, so you segment aggressively, encrypt everywhere, and monitor everything, limiting the "blast radius" of any single compromise.

Architecturally, zero trust implementations are described with two planes. The control plane is the decision-making layer: it evaluates policies and signals and decides whether a request should be allowed. The data plane is where the actual traffic flows: users, devices, applications, and the resources they access. Separating the planes matters because the control plane's components can be reasoned about (and tested on the exam) individually.

The control plane contains three logical components. The policy engine (PE) is the brain: it takes the request, the identity information, device posture, threat intelligence, and the organization's access policies, and it makes the trust decision — allow, deny, or allow with restrictions. The policy administrator (PA) carries out the engine's decision: it generates or updates the credentials, tokens, or session configurations needed to establish the connection, and it instructs the enforcement point to open or close the path. The policy enforcement point (PEP) sits in the data plane, in front of each resource (or group of resources): it is the gatekeeper that forwards the request, permits the session once the administrator tells it to, and can terminate the session if trust changes. A typical flow: a user requests a database; the PEP intercepts and asks the policy administrator; the administrator consults the policy engine; the engine evaluates the signals and decides; the administrator provisions the session; the PEP allows the flow and keeps monitoring it.

In real products these components are rarely three separate boxes — they are logical roles inside an identity-aware proxy, a ZTNA (zero trust network access) service, or a cloud access broker — but the exam tests the roles, not the packaging.

Zero trust also leans on supporting capabilities you will meet in later chapters: strong identity and MFA, device certificates and posture checks, micro-segmentation, and continuous logging. Its companion concept is the zero trust control plane's opposite number in legacy designs — implicit trust based on network location — and exam questions often present a flat network with a hard firewall and ask what is wrong with it. The answer they want: everything inside is trusted, so a single breach exposes all of it.

The CIA triad

The CIA triad is the oldest model in security, and it defines what "secure" means for information:

• Confidentiality — information is accessible only to those authorized to see it. Encryption, access control lists, and classification schemes protect confidentiality. A leaked customer database is a confidentiality failure.
• Integrity — information is accurate and has not been altered without authorization. Hashing, digital signatures, and file-integrity monitoring protect integrity. An attacker quietly changing account balances is an integrity failure, even if nothing was "stolen."
• Availability — information and systems are usable when authorized users need them. Redundancy, backups, load balancing, and DDoS protection protect availability. Ransomware that encrypts a hospital's systems is an availability failure (and usually a confidentiality one too).

Every security decision is a trade among the three. Encrypting everything with keys stored in one place strengthens confidentiality but creates an availability risk if that place fails. Publishing data openly maximizes availability and destroys confidentiality. When a scenario asks which leg of the triad a control or an incident concerns, anchor on the harm: Was data seen by the wrong people? Confidentiality. Was data changed? Integrity. Could legitimate users not get to it? Availability.

AAA: authentication, authorization, and accounting

Where CIA describes goals for data, the AAA framework describes the process of controlling access for a subject (a user or a device):

1. Authentication — proving you are who you claim to be, using factors such as something you know (password), something you have (token or smart card), and something you are (fingerprint). Authentication answers "who are you, really?"
2. Authorization — deciding what the authenticated subject is allowed to do: which files, which applications, which privilege level. Authorization answers "what may you do?" Giving a verified employee access to systems their role does not need is an authorization failure, not an authentication one.
3. Accounting — recording what the subject did: logons, commands, files accessed, times, and source addresses. Accounting (sometimes called auditing in AAA contexts) creates the trail used for investigations, billing, and compliance. RADIUS and TACACS+, which you will study in depth later, are AAA protocols.

Do not confuse authentication with identification. Identification is merely claiming an identity ("I am user jdoe"); authentication is proving the claim ("...and here is my password and my hardware key"). A username alone identifies; it never authenticates.

Threat actors: knowing who attacks you

Defenses are designed against someone. A threat actor is any person or group that causes or can cause harm to systems or data, and actors differ enormously in resources, skill, and motive — which is why "a hacker did it" is never a sufficient analysis. The exam expects you to recognize the major actor types and the attributes used to describe them: level of sophistication/capability, resources/funding, whether they are internal or external to the organization, and their intent/motivation.

Nation-state actors are sponsored by governments. They have the highest resources and sophistication, pursue espionage, intellectual-property theft, and positioning inside critical infrastructure, and can sustain campaigns for years. Groups operating at this level are often called advanced persistent threats (APTs) — "advanced" for their tooling, "persistent" for their patience.

Organized crime groups are financially motivated and increasingly run like businesses, with ransomware-as-a-service franchises, call centers that pressure victims, and specialists for initial access, negotiation, and money laundering. Their sophistication ranges from moderate to very high, and their funding — paid by previous victims — can rival legitimate companies.

Hacktivists attack for ideological, political, or social causes: defacing websites, leaking documents, or launching denial-of-service attacks to draw attention to a cause. Resources vary widely; motivation, not money, is the defining trait.

Insider threats are people with legitimate access — employees, contractors, business partners — who misuse it, whether maliciously (a disgruntled database administrator copying customer lists) or through negligence and manipulation. Insiders are dangerous because they start inside the perimeter with valid credentials and knowledge of where the valuable data lives. Closely related is the unintentional insider: the employee who plugs in a found USB drive or approves a fake MFA prompt. They are not actors by intent, but they are the channel through which external actors operate.

Shadow IT is not an actor but an exam-tested adjacent concept: technology adopted by staff without approval — personal cloud storage for work files, an unapproved messaging app for a project team. Shadow IT creates unmanaged attack surface and data leakage paths that no control covers, because security does not know it exists.

Lower on the capability scale are individual hackers and "script kiddies," who run tools written by others with limited understanding. They are noisy and usually opportunistic, but an unpatched internet-facing server does not care how sophisticated the person scanning it is.

Cryptography fundamentals

Cryptography is how we protect data mathematically. You do not need to be a mathematician for SY0-701, but you must know what each primitive does, where it is used, and what breaks it. Start with the vocabulary: plaintext is readable data; ciphertext is scrambled data; encryption converts plaintext to ciphertext using an algorithm and a key; decryption reverses it. Modern security obeys Kerckhoffs's principle: the algorithm is public and all secrecy lives in the key. If your security depends on nobody knowing how the cipher works, you do not have security — you have a secret waiting to leak.

Symmetric encryption uses one shared key to both encrypt and decrypt. It is fast, handles large volumes of data efficiently, and is what protects data at rest and bulk data in transit. Its weakness is logistical: both parties need the same key, and distributing that key safely — without an eavesdropper copying it — is hard. If the key is compromised, everything it ever protected is exposed.

The dominant symmetric algorithm is AES (Advanced Encryption Standard), used with 128-, 192-, or 256-bit keys. AES-256 protects everything from full-disk encryption (BitLocker, FileVault) to TLS session traffic to classified government data. Older symmetric algorithms such as DES (56-bit key, brute-forceable in hours) and 3DES are legacy and should be avoided; you may still see them named as wrong answers.

Asymmetric encryption (public-key cryptography) uses a mathematically linked key pair: a public key shared freely and a private key kept secret. Data encrypted with the public key can only be decrypted with the private key, which solves the distribution problem — you can publish your public key to the world. The cost is speed: asymmetric operations are far slower than symmetric ones, so real systems are hybrid: asymmetric cryptography is used to authenticate parties and exchange a symmetric session key, then AES does the heavy lifting.

RSA is the classic asymmetric algorithm, based on the difficulty of factoring the product of two large prime numbers. Keys of 2,048 bits are the current minimum; 3,072 or 4,096 bits are used for longer-lived protection. ECC (elliptic curve cryptography) achieves equivalent security with much smaller keys — a 256-bit ECC key is roughly comparable to a 3,072-bit RSA key — because it rests on the elliptic-curve discrete logarithm problem, which falls more slowly to attack. Smaller keys mean less computation and bandwidth, which is why ECC dominates on mobile devices and in modern TLS certificates. Diffie-Hellman (DH) is not an encryption algorithm at all; it is a key exchange protocol that lets two parties who have never met compute an identical shared secret while exchanging only public values over a channel an attacker fully observes. TLS uses ephemeral variants (DHE/ECDHE) so that each session gets a fresh key — providing forward secrecy: stealing the server's private key later does not decrypt sessions recorded earlier. The elliptic-curve variant, ECDH, does the same job with ECC math and smaller values.

Hashing, salting, and digital signatures

A hash function converts input of any size into a fixed-size output (a digest or fingerprint) with three essential properties: it is one-way (you cannot reconstruct the input from the digest), deterministic (the same input always produces the same digest), and collision-resistant (finding two inputs with the same digest should be computationally infeasible). Hashing provides integrity, not confidentiality — a digest reveals nothing about the content but changes completely if one bit of the input changes, so comparing digests detects tampering. File downloads publish SHA-256 digests so you can verify the file you received is the file the author released.

SHA-2 (SHA-256, SHA-512) is the current standard family. MD5 produces a 128-bit digest and is broken: researchers can manufacture collisions — two different files with the same MD5 digest — cheaply, so MD5 must never be used where collision resistance matters, such as verifying software or storing passwords. It survives only for non-security checksums, and exam questions treat "MD5" as the wrong answer whenever integrity or password storage is the goal. SHA-1 is likewise deprecated for collisions.

Storing passwords as plain hashes is still not enough, because identical passwords produce identical digests and attackers precompute rainbow tables — giant lookups of password-to-hash pairs — to reverse stolen databases instantly. Salting defeats this: the system generates a unique random salt for each password, stores the salt alongside the hash of (salt + password), and verifies by repeating the computation at login. Now identical passwords hash differently per user, rainbow tables are useless (the attacker would need a table per salt), and cracking must proceed one password at a time. Slow, deliberately expensive password hashing functions (bcrypt, PBKDF2, Argon2) add key stretching — thousands of iterations that cost a legitimate login a fraction of a second but make billions of guesses impractical.

A digital signature proves both integrity and authenticity — that data came from a specific sender and was not altered. The sender hashes the message, then encrypts the hash with their private key; that encrypted hash is the signature. Anyone can verify it with the sender's public key: decrypt the signature to recover the original hash, hash the received message, and compare. If they match, the message is unchanged and only the private-key holder could have signed it — which also gives non-repudiation: the signer cannot credibly deny signing. Note the direction, because the exam tests it: signatures sign with the private key and verify with the public key, the opposite of confidentiality encryption.

Digital certificates and PKI

Asymmetric cryptography raises a trust question: a public key is just a number — how do you know the key claiming to belong to your bank really does? Digital certificates answer this by binding an identity to a public key, with the binding vouched for by a trusted third party. The system of parties, processes, and standards that does this is PKI (public key infrastructure).

A certificate follows the X.509 standard format and contains the subject's identity (such as a domain name), the subject's public key, the issuer's name, a serial number, validity dates, and the issuer's digital signature over all of it. The issuer is a certificate authority (CA) — an organization (DigiCert, Let's Encrypt, Sectigo, or your own internal CA) that your devices trust because its root certificate is pre-installed in their trust stores. When your browser connects over HTTPS, it validates the server's certificate chain up to a trusted root, checks the dates, checks the name matches the site, and checks the certificate has not been revoked (via CRL lists or OCSP). Any failure produces the warnings users are trained — usually in vain — not to click through.

The supporting roles and steps matter for the exam. A registration authority (RA) verifies the requester's identity and eligibility before the CA issues, offloading identity proofing from the CA. To request a certificate, the applicant generates a key pair and submits a certificate signing request (CSR) — a file containing the public key and identity details, signed with the corresponding private key — to the CA. The private key never leaves the applicant's system; if a process asks you to send your private key to a CA, something is deeply wrong.

Validation depth determines certificate class. DV (domain-validated) certificates prove only that the requester controls the domain; they are automated and cheap (Let's Encrypt issues only DV). OV (organization-validated) certificates additionally verify that a real organization exists and is the applicant. EV (extended validation) certificates require the most rigorous vetting of the organization's legal identity. All three encrypt identically — the difference is how much identity assurance stands behind the name in the certificate.

Certificate shapes also vary. A wildcard certificate (*.example.com) covers one level of subdomains — convenient, but one stolen private key exposes every covered host. A SAN (subject alternative name) certificate lists multiple specific names, possibly across different domains, in a single certificate. A self-signed certificate is signed by its own subject rather than by a CA: browsers do not trust it by default, so it suits internal systems, labs, and development — anywhere the operator controls both ends and can distribute trust manually — but it is inappropriate for public websites because visitors cannot distinguish it from an attacker's forgery. Certificate pinning hard-codes an expected certificate or public key inside an application (common in mobile apps), so the app rejects even a validly issued certificate if it is not the pinned one — a strong defense against compromised CAs and rogue certificates, at the cost of breaking the app if keys rotate without an app update. Finally, key escrow is the practice of storing a copy of a private key with a trusted third party so that encrypted data can be recovered if the owner loses the key or leaves the organization; it trades a measure of confidentiality for recoverability, and organizations often apply it to encryption keys while refusing to escrow signature keys, since a signature key held by two parties destroys non-repudiation.

One related technology deserves a mention: blockchain — an append-only, distributed ledger where records are chained together with hashes. Because each block commits to the previous block's hash, altering a historical record invalidates every later block, and the change is visible to all participants. PKI-adjacent uses include public, tamper-evident logs of issued certificates and software releases: the blockchain itself is not encryption, but it is a strong integrity and transparency mechanism.

Hiding data: obfuscation, steganography, tokenization, and masking

Four techniques protect data by transforming how it is represented, and exam scenarios hinge on picking the right one.

Obfuscation deliberately makes something hard to understand while keeping it functional or recoverable — obfuscated source code, packed malware, or a spreadsheet formula buried under nested functions. Obfuscation is not encryption: there is no key, and given time, a determined analyst can reverse it. It raises the attacker's cost; it does not provide cryptographic protection.

Steganography hides the existence of a message inside something innocuous — data embedded in the least significant bits of an image, text concealed in audio files, or payloads tucked into whitespace. Where encryption announces "there is a secret here that you cannot read," steganography whispers "there is nothing here at all." Attackers use it to smuggle data out past monitoring; defenders and watermarking systems use it to trace leaked copies.

Tokenization replaces a sensitive value with a random substitute — a token — that has no mathematical relationship to the original. The real value (say, a credit card number) is stored in a secure token vault, and business systems work with the token, which is useless if stolen because it cannot be reversed without the vault. Tokenization is a cornerstone of payment-card compliance because it removes real card numbers from most of the environment. Contrast it with encryption: an encrypted value can be decrypted by anyone holding the key; a token can only be resolved by querying the vault.

Data masking hides some or all of real data while preserving its format: a support screen showing ****-****-4242, a training database with names replaced by fictitious ones, or test data generated to look real without being real. Masking protects data in non-production use — training, development, display — where people need realistic-looking data but must never see the genuine values.

How the concepts combine: defense in depth

None of these concepts lives alone. Mature security programs deliberately layer controls of different categories and types so that the failure of any single control does not produce a breach — a strategy called defense in depth (or layered security). Imagine an attacker targeting the clinic from earlier in this chapter. The warning banner (deterrent) does not stop them. The firewall and allow listing (preventive) slow them. The badge reader (physical, preventive) keeps them out of the records room. Encryption (preventive) makes the database they copied unreadable. The IDS and log review (detective) reveal the attempt in time to respond, the backups (corrective) restore operations, and the incident report feeds a managerial review that improves the policy (directive) for next time. Remove any one layer and the others still provide protection; remove the variety — say, ten firewalls and nothing else — and a single firewall bypass defeats everything at once.

This layering is also why the CIA triad, AAA, zero trust, and cryptography in this chapter are not competing frameworks but complementary lenses. CIA tells you what you are protecting. AAA tells you how access is governed. Zero trust tells you where trust is placed — nowhere, by default. Cryptography provides the mathematical machinery that makes confidentiality, integrity, and authentication possible at all. When you reach the later domains — architecture, operations, governance — notice how often the correct answer is simply one of this chapter's concepts wearing a specific product's clothing. A question about a SIEM is a detective-control question. A question about a jump server in front of an unpatchable system is a compensating-control question. A question about an app that rejects a valid certificate is a certificate-pinning question. Learn to translate product language back into concept language and the whole exam becomes shorter than it looks.

Key terms

Exercises

Exercise 1: Control classification scavenger hunt (paper, 20 minutes)

1. Walk through your home, school, or workplace (mentally is fine) and list ten safeguards you can find. Examples to get you started: a deadbolt, a phone lock screen, a "no tailgating" sign, a smoke detector, a password manager, a guest Wi-Fi network.
2. For each safeguard, write down its category (technical, managerial, operational, physical).
3. Next to it, write its primary type (preventive, detective, corrective, compensating, deterrent, directive).
4. Pick the two safeguards that were hardest to classify and write one sentence explaining the ambiguity. (Hint: cameras are usually the hardest — deterrent or detective? Decide based on the purpose you wrote down.)
5. Check yourself: any safeguard whose category is "a person doing a task" must be operational; any safeguard that is a written rule must be managerial/directive.

Exercise 2: See hashing and the avalanche effect (home machine, 15 minutes)

1. Create a text file named hashlab.txt containing exactly the line Security+ is worth it (on Linux/macOS: echo "Security+ is worth it" > hashlab.txt; on Windows, use Notepad and save it).
2. Generate its SHA-256 hash:

• Linux: sha256sum hashlab.txt
• macOS: shasum -a 256 hashlab.txt
• Windows PowerShell: Get-FileHash hashlab.txt -Algorithm SHA256

1. Write the digest down. Now change one character in the file (for example, change the "S" to "s") and hash it again.
2. Compare the two digests character by character. Count how many characters are the same. (You should find the digests look completely unrelated — that is the avalanche effect.)
3. Re-save the original file and hash it a third time. Confirm the digest is identical to step 2 — hashing is deterministic.
4. On paper: explain in two sentences why this property lets a website prove that a downloaded file was not tampered with, and why a hash alone cannot be used to "decrypt" the file.

Exercise 3: Inspect a real certificate (browser, 15 minutes)

1. In your browser, open https://www.wikipedia.org.
2. Click the padlock/site-information icon in the address bar and open the certificate viewer ("Connection is secure" → "Certificate is valid" or similar, depending on browser).
3. Record: the issuing CA, the validity dates, the subject name, and the list of names in the Subject Alternative Name field.
4. Answer on paper: Is this a wildcard certificate, a SAN certificate, or both/neither? How can you tell?
5. Find the certificate's SHA-256 fingerprint and the signature algorithm. Which algorithm family is used — RSA or ECC? (Look at the public key type/size.)
6. In one paragraph, explain what would change in this inspection if the certificate were self-signed, and why your browser would warn you.

Exercise 4: Salting, demonstrated (paper or home machine, 20 minutes)

1. On paper (or with any hash tool from Exercise 2), take the password Sunshine2026!.
2. Compute or imagine its SHA-256 hash as User A, with no salt. Record it as H(password).
3. Now suppose User B chooses the same password. Without salt, what is User B's stored hash? What does an attacker who steals the database immediately learn from seeing two identical hashes?
4. Now add salts: User A's salt is 7f3a, User B's salt is c91d. The stored values are H(7f3a + password) and H(c91d + password). Explain why the two stored hashes now differ even though the passwords are identical.
5. Finish on paper: explain why a rainbow table built for unsalted SHA-256 is useless against this database, and state the one thing the attacker must now do for each user separately.

PBQ practice

Scenario

Print this page and complete the task by hand.

Meridian Accounting is a 40-person firm. Their current setup:

• All office computers sit on one flat LAN. Once any device is on the LAN (including the guest Wi-Fi, which shares the same network), it can reach the file server, the tax-software server, and the printers.
• The tax-software server is old. The vendor confirms it cannot support multi-factor authentication and cannot be patched against a known vulnerability until next year.
• Staff share one generic "office" login for the file server.
• Client tax records (names, national ID numbers, income) are stored in a database. The support team wants to show clients "only the last characters" of their ID numbers on screen.
• The firm is buying a certificate for its new client portal, portal.meridian.example, which will also serve upload.meridian.example and billing.meridian.example.

Your task

1. For each requirement below, write the control you would implement and classify it by category and type:

• (a) The old tax server must be protected despite having no MFA and an unpatched vulnerability.
• (b) Management wants a written rule that every employee uses a unique account.
• (c) Someone must notice if the tax server is attacked at 3 a.m.

1. A consultant proposes "zero trust" for the new portal. In the flow "employee → portal → client database," label where the policy enforcement point sits, and state which component decides access and which component configures the session.
2. Choose the certificate approach for the portal (wildcard, SAN, or three separate certificates) and justify your choice in one sentence.
3. Name the data-protection technique that matches the support team's "show only the last characters" requirement.

Model answer

Part 1 — control selection and classification

(a) The primary control (MFA on the tax server) is impossible, so this calls for a compensating control. A sound implementation: move the tax server onto its own restricted VLAN and require staff to reach it only through a hardened jump server that enforces MFA, with firewall rules permitting only the jump server to talk to the tax server. The jump-server/VLAN arrangement is a technical control (enforced by systems), and its type is compensating — on an exam, if they ask for the purpose served day to day you could also argue preventive, but the scenario's key facts ("cannot support MFA," "cannot be patched") are the textbook trigger for compensating. Patching next year, when possible, becomes the corrective/permanent fix.

(b) A written rule is a policy: managerial category, directive type. The policy directs behavior; it enforces nothing by itself, so pair it with the technical control of disabling the shared account and issuing unique accounts, plus an operational control (a quarterly account review) to verify compliance.

(c) "Notice an attack at 3 a.m." is detection: deploy an IDS/host monitoring with alerting on the tax server segment and forward logs to a monitored alerting service. The monitoring tooling is a technical control of the detective type. (The human who responds is performing an operational task, but the control that notices is technical/detective.)

Part 2 — zero trust flow

The policy enforcement point sits directly in front of the protected resource — here, in front of the client database (and typically also in front of the portal application), intercepting every request before it reaches the data. The policy engine makes the decision: it evaluates the employee's identity, MFA result, device posture, and the access policy, and returns allow or deny. The policy administrator acts on that decision: it establishes or tears down the session (issuing the token/configuration the PEP needs) and instructs the PEP to permit the flow. Engine decides, administrator configures, enforcement point enforces.

Part 3 — certificate choice

Choose a SAN certificate listing portal.meridian.example, upload.meridian.example, and billing.meridian.example. One certificate covers exactly the three named hosts; a wildcard (*.meridian.example) would also work, but it would cover every current and future subdomain with a single private key, so one key compromise would expose hosts that were never meant to share it. Three separate certificates are valid but triple the renewal and management work for no security gain over SAN here.

Part 4 — data protection technique

Data masking. Displaying only the last characters of an ID number while hiding the rest is the definition of masking: the format is preserved, the real value is partially concealed, and staff see only what their task requires. (If the firm instead replaced the ID numbers throughout its systems with random stand-ins resolved through a vault, that would be tokenization — but a display rule is masking.)

End-of-chapter test

1. A company requires all employees to read and sign an acceptable use policy during onboarding. Which control category and type is the policy itself?

A. Technical, preventive
B. Managerial, directive
C. Operational, deterrent
D. Physical, directive

2. A legacy application cannot support multi-factor authentication, so administrators place it behind a jump host that enforces MFA and restrict access to a dedicated VLAN. The jump host arrangement is best described as which control type?

A. Corrective
B. Detective
C. Compensating
D. Deterrent

3. In a zero trust architecture, which component evaluates identity, device posture, and policy to make the final allow/deny decision for a request?

A. Policy enforcement point
B. Policy administrator
C. Policy engine
D. Data plane

4. An attacker breaches a retailer and silently modifies prices in the product database for two weeks before anyone notices. No data was copied out. Which leg of the CIA triad was primarily violated?

A. Confidentiality
B. Integrity
C. Availability
D. Accounting

5. An employee signs in with a password and hardware key, but is then able to open payroll records that their role does not require. Which part of the AAA framework has failed?

A. Authentication
B. Authorization
C. Accounting
D. Identification

6. A security team must choose an algorithm to encrypt a 2 TB database at rest with the best performance. Which is the most appropriate choice?

A. RSA with a 4,096-bit key
B. AES-256
C. Diffie-Hellman
D. SHA-256

7. A user group with essentially unlimited funding has been conducting a quiet espionage campaign against a defense contractor for three years. Which threat actor does this describe?

A. Hacktivist
B. Organized crime
C. Insider threat
D. Nation-state actor (APT)

8. A developer verifies a downloaded update by comparing its hash to the value published by the vendor. Which statement about this process is correct?

A. MD5 is the best choice because its digests are shortest
B. The comparison provides integrity, because any change to the file changes its digest
C. Hashing the file encrypts it so it cannot be read in transit
D. A matching digest proves the vendor's server was not compromised

9. A messaging app needs to guarantee that a received message was sent by the claimed sender and was not altered. The sender will sign the message. Which key is used to create the signature, and which key verifies it?

A. Sign with the public key; verify with the private key
B. Sign with the private key; verify with the public key
C. Sign with the shared symmetric key; verify with the same key
D. Sign with the recipient's public key; verify with the recipient's private key

10. A payment processor replaces full card numbers in its business systems with randomly generated substitutes. The original numbers are kept in a hardened vault, and systems resolve the substitutes through the vault when needed. Which technique is this?

A. Data masking
B. Steganography
C. Tokenization
D. Obfuscation

Answer key

1. B — A written policy is a managerial control (it comes from governance decisions), and its type is directive because it instructs people on required behavior; it has no technical enforcement of its own.

2. C — When the primary control (MFA on the application) cannot be implemented, a substitute that achieves a similar risk reduction — here, MFA at a jump host plus segmentation — is a compensating control.

3. C — The policy engine is the decision-maker in the zero trust control plane. The policy administrator carries out the decision by configuring the session, and the enforcement point blocks or allows the actual traffic in the data plane.

4. B — Data was changed without authorization, which is an integrity violation. Nothing was disclosed (confidentiality) and the data remained accessible (availability).

5. B — Authentication succeeded (the user proved their identity), but the system granted access beyond the role's needs, which is an authorization failure.

6. B — AES-256 is a fast symmetric cipher designed for bulk data such as full databases. RSA is far too slow for bulk encryption, Diffie-Hellman only exchanges keys, and SHA-256 is a hash, not encryption.

7. D — Very high resources, high sophistication, and a long-running espionage campaign are the signature of a nation-state actor, also called an APT.

8. B — Hash comparison detects modification: any alteration produces a different digest. MD5 is collision-broken and unsuitable; hashing is one-way and provides no confidentiality; and a matching digest only shows the file matches the published digest, not that the publisher's infrastructure is safe.

9. B — Digital signatures are created with the signer's private key and verified by anyone using the corresponding public key, providing authenticity, integrity, and non-repudiation.

10. C — Replacing sensitive values with random substitutes that only a secure vault can resolve back to the originals is tokenization. Masking would merely hide part of the real value on display while the real value stays in place.