Security+ SY0-801 Security Controls: Categories, Types, CIA, AAA and Zero Trust

Defense in depth is the practice of protecting an asset with several layers of independent, diverse controls so that the failure of any one control does not expose the asset. It is the umbrella idea for CompTIA Security+ objective 1.1: CIA, AAA, non-repudiation, Zero Trust and least privilege are the principles the layers serve, and the control categories and types are how you describe each layer.

A layer only counts if it still protects the asset when the layer in front of it fails. Two tests decide whether an addition really adds depth:

• Is it a separate layer? Tuning, hardening, duplicating or monitoring an existing control makes that control better, but everything still depends on it. Ask: if an attacker got completely past this control, what would still stand between them and the asset? For an internal wiki protected only by its sign-in page, a stricter password rule improves the one layer it has; network segmentation that limits who can reach the wiki, and protections close to the data itself (such as encryption of the stored pages or tokenization of sensitive fields), still work if sign-in is bypassed.
• Does it share the failure's cause? Two layers that rely on the same detection engine, the same credentials, the same administrator or the same building fail together. Two antivirus products licensed from one engine miss the same new variant; a backup stored in the same administrative domain as production can be deleted by the same stolen admin account. This is control diversity: vary vendors, technologies, locations and control categories so one weakness cannot defeat every layer.

A layered design for a branch office file server might combine a badge-controlled server room, a network firewall, host-based firewall rules, disk encryption, endpoint detection, documented access policies and staff training: physical, technical, managerial and operational layers, each able to stand when another falls. Defense in depth is often confused with Zero Trust: Zero Trust is about removing trust based on network location and verifying every request, while defense in depth is about stacking controls so no single one is decisive. Good designs use both.

The CIA triad names the three properties security protects: confidentiality (only authorized parties can read the data), integrity (data and systems are accurate and unaltered) and availability (authorized users can reach data and systems when they need them). To classify an incident, ask what actually happened to the data: was it disclosed, changed, or made unreachable?

Several distinctions decide close questions:

• Ransomware is first an availability attack. Encrypting files denies their owners the use of them. Unless evidence shows data was copied out, the impact is on availability; ransomware that also steals data (double extortion) adds a confidentiality impact. Data that was exposed but not changed is not an integrity incident, and data that was changed but not exposed is not a confidentiality incident.
• Reading is not tampering. An eavesdropper who only reads traffic has violated confidentiality; integrity is affected only if the data is actually changed.
• Cryptography is not automatically confidentiality. Encryption makes data unreadable. Hashes and digital signatures leave content readable; they prove it was not changed (integrity) and, for signatures, who produced it.
• Encryption does not prove integrity on its own. Anyone holding the key can decrypt, alter and re-encrypt. Proving that a record was never changed after it was created takes a signature or a protected hash chain, kept somewhere the writer cannot rewrite, such as write-once (WORM) storage. This applies even to records that contain nothing secret.
• Redundancy is not recovery from tampering. Mirroring and replication copy every change, including malicious or accidental ones: a RAID 1 mirror survives a dead disk but faithfully mirrors a deleted folder. Recovering the original data needs point-in-time copies the attacker cannot alter or delete, such as immutable, versioned or offline backups.
• Private is not encrypted. A leased line, MPLS circuit or other dedicated link keeps traffic off the public internet, but the data still crosses the carrier's equipment as readable plaintext unless it is encrypted (for example with IPsec or TLS on top of the circuit). Isolation reduces who can reach the traffic; only encryption keeps it unreadable to whoever does. Where a requirement says data must stay encrypted in transit, a private circuit alone does not meet it.

The three CIA properties pull against each other, so strengthening one often weakens another, and the business requirement decides the right balance. Security+ scenarios describe a design and ask which property gained and which one paid for it; check each half separately.

• Confidentiality versus availability. Extra verification steps, short session timeouts and strict encryption all slow or block legitimate access. A shared terminal on a factory floor that demands a hardware token for every screen change protects data but stalls the line. Concentrating decryption keys in one person, one device or one location protects them, but if that single holder is lost the data is unreadable to everyone, which is an availability failure; protected recovery keys held elsewhere restore the balance.
• Integrity versus availability. A system that refuses work it cannot keep consistent favours integrity: a document system that locks a file while one editor has it open stops two versions diverging, but the second user has to wait. A system that keeps serving and reconciles conflicts later favours availability and accepts the risk of inconsistent records.
• Meeting both. When a requirement fixes one property (data must stay encrypted) and asks for another (service must resume quickly after losing a site), only an answer that satisfies both is correct. Eliminate anything that breaks the fixed requirement, then anything that misses the recovery need. Know the recovery speeds: a hot site runs current systems and takes over in minutes, a warm site needs hours of preparation, a cold site needs days, and redundancy inside one building does not survive the loss of that building.

The property being strengthened is rarely the one being lost. In a trade-off question, the control's purpose names the winner, and the business harm described (delays, outages, inability to recover) names the loser.

AAA is the sequence that controls access: authentication proves a claimed identity, authorization decides what that identity may do, and accounting records what it actually did. It is preceded by identification, the claim itself.

Reading the order correctly settles most scenario questions:

• Until something is proven, only identification has happened. Stating a name, ID or email is a claim.
• A refusal after a successful sign-in is authorization. Authentication has already succeeded; the permissions decided the outcome. Accounting may record the refusal, but it does not make it.
• Legitimate users reaching data their job does not need is an authorization failure. Strong sign-in and complete logs mean authentication and accounting worked; the fix is narrowing the account's permissions.
• Authorization is decided per request and per object, not once at sign-in. An application must check, every time a record is requested, that this identity may see this particular record. If a patient portal returns any lab report whose number is placed in the address, it has authenticated the user but never authorized the request: an insecure direct object reference. The fix is an ownership or permission check on every request, so a valid link alone never grants access.
• Activity the real owner could not have performed means authentication was defeated. The records showing it are accounting doing its job. Accounting records what an identity did; it cannot tell the real user from someone holding working credentials.

Systems and devices authenticate too. A hardware (MAC) address only identifies a device, and it is easy to spoof. Proving a device is genuine takes something it cannot simply copy, typically a machine certificate whose private key the device holds, checked by 802.1X (for example EAP-TLS) at the switch port or wireless access point before the device joins the network.

Accounting must be outside the subject's control. Accounting is only meaningful when each person has a unique identity and the records cannot be altered by the people they describe. If a network engineer's commands are logged only on the routers he administers, he can erase the trail; forwarding records to a separate log server or SIEM that he cannot administer keeps them trustworthy.

Non-repudiation is the assurance that a specific person performed an action, backed by evidence strong enough that they cannot credibly deny it. It needs two things together: the action is bound to one individual, and the record of it cannot be changed afterwards.

• Digital signatures provide it. A signature is created with a private key that only the signer holds and is verified by anyone with the matching public key, so it ties the signed item to that person and also reveals any later change. A signed contract, code release or approval can be checked by a third party long afterwards.
• Hashes do not. A plain hash proves integrity but carries no identity.
• Keyed hashes (HMACs) with a shared secret do not. If both parties hold the same secret, either one could have produced the value, so neither can prove to an outsider which of them did. Only a key the sender alone holds, such as the private key behind a digital signature, gives proof a third party can verify.
• Shared accounts defeat it. When several people use one account (a shared "operator" login on a lab instrument, say), records can only show what the account did, not which person did it. Protecting the shared account better does not help; attribution needs one identity per person.

Encryption and replication do not provide non-repudiation: they serve confidentiality and availability. Non-repudiation is related to accounting but stronger: accounting records activity, while non-repudiation proves who was responsible for it.

Zero Trust is a security model that grants no implicit trust based on network location: every request to every resource is authenticated and authorized using the identity, the device and the context, and access is re-evaluated continuously. NIST SP 800-207 describes it as moving defenses from static network perimeters to users, assets and resources.

The principles that Security+ scenarios test:

• Never trust by location. Being on the corporate network, a particular VLAN or a VPN is not a reason to grant access. A contractor's laptop plugged into a meeting-room port is no more trustworthy for being inside the building. Controls that make the network harder to enter or watch it more closely can still help, but if a connected device is trusted once inside, the design is still perimeter-based.
• Verify explicitly, per request and per resource. Access is granted to one application at a time, based on who the user is and the health of the device they are using, not to the network.
• Continuous verification. A decision is not permanent. If risk changes during a session (the device falls out of compliance, the user appears from a new country, behaviour turns unusual), the session is re-evaluated and can be stepped up or ended.
• Adaptive identity. The strength of verification adapts to risk signals such as location, device health, time and behaviour.
• Least privilege and microsegmentation. Grant only the access needed and limit how far an attacker can move. These support Zero Trust but do not by themselves remove location-based trust.
• Assume breach. Design as though an attacker is already inside, so each access decision stands on its own.

The engine decides, the administrator executes, the enforcement point enforces. How these pieces are deployed (device management, application access control) is security architecture, covered with Security+ objective 3.2.

Least privilege means giving each user, service and process only the rights its task requires, and only for as long as it requires them. It limits what an attacker can do with any one stolen credential or compromised account.

• Scope the rights. A payroll clerk who views payslips does not need to edit salary tables; a reporting tool that reads a database needs read-only access, not ownership of it. Broad administrative rights given for convenience violate the principle even if they are never misused.
• Scope service accounts. Services are subjects too. Give each service account exactly the rights it uses, on exactly the systems it touches: a monitoring agent that reads performance counters does not need local administrator rights on every server. Remove only the rights the task does not use; a right the task genuinely needs stays, or the service breaks.
• Limit the time. Just-in-time (JIT) elevation grants privileged access only when it is approved for a specific task or window and removes it afterwards. A database administrator who changes schemas once a quarter has no reason to hold that right on the other days. A right that exists only during the approved window cannot be used by someone who steals the credentials outside it.

Least privilege is not separation of duties. Least privilege trims what one subject can do; separation of duties splits a sensitive process (such as creating and approving a payment) between different people so no one person can complete it alone. A user with excessive rights violates least privilege even if no process is being split.

A control's category describes how it is implemented and who or what carries it out: technical controls are enforced by systems, managerial controls are governance decisions, operational controls are performed by people, and physical controls protect facilities and hardware. Security+ SY0-801 names them technical/logical, managerial/administrative, operational and physical/environmental.

Three boundaries cause most mistakes:

• Managerial versus operational. Deciding or defining the requirement is managerial; performing it, each time it runs, is operational. A policy requiring quarterly access recertification is managerial; the managers who carry out each recertification are performing an operational control. Following a written document does not make an activity managerial, and using a tool to do it does not make it technical: ask who performs the control each time it runs.
• Technical versus operational. People configure an automatic screen lock, but once deployed the system enforces it without anyone acting, so it is technical.
• Physical versus technical. A badge reader on a door uses electronics, but its job is controlling physical entry, so it is physical. Generators and climate control protect equipment from the environment, which is why the category is physical/environmental.

A control's type describes what it does relative to a security event: it prevents the event, deters the attempt, detects it, corrects its effects, compensates for a control that cannot be used, or directs people what to do. The objectives list deterrent controls as "deterring".

A quick test: does the control block (preventive), warn (deterrent), find (detective), fix (corrective), stand in (compensating) or instruct (directive)?

• Same trigger, different effect. Three DLP rules can fire on the same sensitive file: one blocks the transfer (preventive), one alerts the security team (detective), one shows the user a warning about consequences (deterrent). Classify by what happens, not by what triggers it; only a control that actually stops the next attempt is preventive.
• Directive versus deterrent. Both rely on people's choices. A directive control prescribes the behaviour (a clean-desk procedure); a deterrent makes misbehaviour look risky or costly (a sign warning that the area is under surveillance and trespassers will be prosecuted). If nothing actually blocks the behaviour, the control is not preventive.
• Deterrent versus preventive. A "guard dogs on patrol" sign or a dummy camera cannot stop or record anything; it works only through the intruder's perception of risk. A lock or barrier stops the attempt whatever the intruder believes.
• Speed does not make a control preventive. A configuration tool that reverts an unauthorized setting on its next run, however quickly, is corrective, because the change already happened. Only stopping the event from occurring is preventive.
• Backups are corrective when used. Taking backups is preparation; restoring from them after an incident is the corrective action.
• Compensating is defined by why the control exists. A compensating control may work in a detective or preventive way, but its type in the exam's sense comes from the reason it was adopted: it stands in for a required safeguard that cannot be implemented, and reduces the same risk.
• Decoys are detective. A fake administrator account or file that no one legitimately uses, with alerting on any access, stops nothing; its value is the alert that reveals an intruder. (Deception technology itself is covered with objective 4.1.)

Every control has both a category (how it is implemented) and a type (what it does relative to the event), and the two are decided independently. Scenario questions often ask for the pair, with distractors that get one axis right.

Two rules keep classification honest:

• Classify the function asked about, not the product. One product often does several things. An email security service that flags a malicious message is detecting; when it later pulls that message back out of every inbox, it is correcting. Read which capability the question singles out.
• Classify the current configuration, not the name. A product's name describes what it can do, not what it is doing. A web application firewall left in detection-only (monitoring) mode blocks nothing, so it is detective; switched to blocking mode, the same device becomes preventive. The same applies to any "prevention" system set to alert only.