Controls, CIA, AAA, Zero Trust, and Change Management

Introduction

This lesson opens Domain 1, General Security Concepts, which carries 12% of the scored content of CompTIA Security+ SY0-701. Objective 1.1 (compare and contrast various types of security controls), 1.2 (summarize fundamental security concepts) and 1.3 (explain the importance of change management processes and the impact to security) are the vocabulary of the whole exam. Every later domain, from incident response to governance, assumes that you can tell a preventive control from a detective one, explain what authentication adds that authorization does not, and recognize when a design follows zero trust.

The questions are rarely definitions. Security+ prefers short scenarios: a company deploys a camera, a bank adds a second approval step, an engineer wants to patch a production server on a Friday afternoon. You must name the control type, the principle or the process that applies.

Learning objectives

After this lesson you will be able to:

• Classify any control by category (technical, managerial, operational, physical) and by type (preventive, deterrent, detective, corrective, compensating, directive).
• Explain confidentiality, integrity, availability and non-repudiation, and map a described failure to the right property.
• Distinguish authentication, authorization and accounting, and name the technologies that implement each.
• Describe the zero trust control plane and data plane, and the roles of the policy engine, policy administrator and policy enforcement point.
• Recognize deception technologies (honeypot, honeynet, honeyfile, honeytoken) and gap analysis.
• Walk a change request through approval, impact analysis, test, backout plan, maintenance window, and documentation.

1. Security controls

A security control is any safeguard that reduces risk. SY0-701 classifies controls along two independent axes. Mixing them up is the most common mistake on this objective.

1.1 Categories: who or what implements the control

A useful shortcut: ask "Can I touch it?" (physical), "Does software or hardware enforce it automatically?" (technical), "Is it a decision or document that steers the program?" (managerial), "Is it a routine that humans carry out?" (operational).

1.2 Types: what the control does in the attack timeline

Every control has one category and one (sometimes two) types. A security guard is an operational control that is preventive (blocks entry) and deterrent. A camera is a physical control that is detective and deterrent. A firewall rule is technical and preventive; the firewall log review that spots abuse is detective.

Example 1: classifying a retail chain's controls

A retailer with 120 stores adds four measures after a theft of card readers: (1) tamper-evident seals on every payment terminal, (2) a policy requiring store managers to inspect terminals each morning, (3) cameras pointed at the checkout counters, (4) a signed policy stating that tampering leads to dismissal.

• Seals: physical, detective (tampering becomes visible) and deterrent.
• Morning inspection: operational, detective.
• Cameras: physical, detective and deterrent.
• Written policy: managerial, directive and deterrent.

Example 2: a compensating control

A hospital runs an MRI console on an unsupported Windows version that cannot be patched without voiding the vendor's certification. The security team cannot apply the preventive patch, so it places the console in an isolated VLAN, allows only the imaging server through a firewall rule, and disables USB ports. These measures are compensating controls: they give an equivalent level of risk reduction through other means. The exam typically phrases it as "the primary control cannot be implemented".

2. The CIA triad and non-repudiation

The triad is the lens for every security discussion.

• Confidentiality: only authorized parties can read the data. Supported by encryption, access control, data masking, and classification. Failure: a laptop with unencrypted patient records is stolen.
• Integrity: data and systems are accurate and unaltered by unauthorized parties. Supported by hashing, digital signatures, file integrity monitoring, and version control. Failure: an attacker modifies a payroll file so that account numbers change.
• Availability: authorized users can access resources when needed. Supported by redundancy, backups, load balancing, and DDoS protection. Failure: ransomware encrypts the order-management database.
• Non-repudiation: a party cannot credibly deny having performed an action. Supported by digital signatures and tamper-resistant audit logs, often combined with timestamps. Failure: an executive claims "I never approved that wire transfer" and nothing proves otherwise.

Note that SY0-701 lists non-repudiation next to the triad because signing and logging provide something hashing alone cannot: proof of who. A hash shows that data changed; a digital signature proves that the holder of a specific private key produced it.

Example 3: mapping failures to properties

• A customer-service agent can view full credit card numbers when only the last four are needed: confidentiality.
• A web page defacement that replaces prices with zeros: integrity.
• A database server that is down for six hours because a single disk failed: availability.
• A supplier who denies having sent a purchase order that carries no signature: non-repudiation.

3. Authentication, authorization, and accounting (AAA)

AAA servers centralize the three functions. RADIUS and TACACS+ are the classic protocols: RADIUS (UDP, widely used for network access and Wi-Fi 802.1X) combines authentication and authorization, while TACACS+ (TCP, Cisco-originated) separates all three, which suits fine-grained device administration commands.

Authenticating people relies on factors: something you know, something you have, something you are, and also somewhere you are (location) and something you do (behavior). Using two different categories is true multifactor authentication; a password plus a security question is two "know" factors and is not.

Authenticating systems uses certificates, pre-shared keys, or device identity in a trusted platform module (TPM). Authorization models matter because the exam asks which one fits a scenario:

• Discretionary (DAC): the owner decides who has access, as with file sharing in a typical operating system.
• Mandatory (MAC): the system enforces labels such as Secret or Confidential; users cannot override it.
• Role-based (RBAC): permissions attach to job roles.
• Attribute-based (ABAC): decisions use attributes of user, resource and context, such as department, device compliance and time.
• Rule-based: access is driven by rules that apply to everyone, such as a firewall ACL or a "no login after 20:00" rule.

Worked example: choosing authentication and authorization controls step by step

Scenario. A regional bank gives call-center agents a web application. Requirements: only employees reach the app, agents see only the customers assigned to their region, supervisors can approve refunds above 500 euros, and the auditors must reconstruct who approved each refund.

1. Identify the three functions. Employees reaching the app is authentication. Region limits and the supervisor privilege are authorization. Reconstruction of approvals is accounting.
2. Authentication. Use single sign-on with the bank's identity provider and require MFA, since the application handles financial data. Something you know (password) plus something you have (authenticator app or hardware key).
3. Authorization. Roles alone say "agent" or "supervisor" but do not express the region. An attribute-based model, with the attribute region on both the user and the customer record, expresses the rule directly. The supervisor privilege can still be an RBAC role.
4. Accounting. Log each refund approval with user ID, timestamp and amount, and ship it to a central log store the agents cannot edit. Combined with digital signatures or write-once storage, this also provides non-repudiation.
5. Why other choices are weaker. A shared supervisor account fails accounting and non-repudiation because many people use the same identity. Pure RBAC with one role per region creates dozens of near-identical roles that are hard to maintain. Discretionary access lets each manager grant rights informally and breaks consistency.

4. Gap analysis

A gap analysis compares the current state of controls to a desired state, such as a framework, a regulation, or an internal target, and lists what is missing. It can be technical (which systems lack EDR) or business-focused (which ISO 27001 clauses have no evidence). The output is a prioritized remediation plan. On the exam, "compare the current security posture to a standard to find missing controls" is a gap analysis.

5. Zero trust

Traditional security trusted whatever sat inside the network perimeter. Zero trust assumes breach: no user, device or network location is trusted by default, and every access request is verified continuously against policy. The motto is "never trust, always verify".

5.1 Planes and components

SY0-701 describes two planes.

Control plane: decides.

• Adaptive identity: authentication strength adapts to context (a login from a new country triggers extra verification).
• Threat scope reduction: limit the blast radius by narrowing who and what can reach each resource.
• Policy-driven access control: policies, not network position, grant access.
• Policy administrator: establishes or removes the communication path to a resource, based on the policy engine's decision.
• Policy engine: evaluates the request using policy and signals such as identity, device health and threat intelligence, and grants, denies or revokes access.

Data plane: enforces and carries the traffic.

• Subject/system: the user or device requesting access.
• Policy enforcement point (PEP): the gateway or agent that allows or blocks the connection.
• Implicit trust zones: areas, such as the segment behind the PEP, where the connection is assumed trustworthy once approved; the goal is to keep them small.

The flow: a subject asks for a resource; the PEP forwards the request to the policy administrator; the policy engine decides; if allowed, the administrator configures the PEP to open the path.

Example 4: zero trust for a contractor

A consulting firm gives a contractor access to a project wiki. In the old model a VPN would place the contractor's laptop on the corporate network, exposing file servers and printers. In the zero trust model the contractor authenticates with MFA, the policy engine checks that the laptop has disk encryption and current EDR, and the PEP exposes only the wiki, for a limited session. If the EDR reports an infection mid-session, the policy engine revokes access immediately. This is adaptive, least-privilege and continuous.

6. Physical security

Though listed with security concepts, physical controls often appear in scenarios.

7. Deception and disruption technology

These tools detect attackers by offering bait.

No legitimate user has a reason to touch these items, so any interaction is highly suspicious. They are detective controls and give security teams intelligence on techniques.

8. Change management and its security impact

Uncontrolled change causes outages and opens vulnerabilities. A formal change management process answers: who requested what, why, what could go wrong, who approved it, and how do we undo it.

Business processes impacted by change

• Approval process: a change advisory board or an authorized manager signs off. Emergency changes follow an expedited route with retroactive documentation.
• Ownership: each asset or service has an owner accountable for approving changes.
• Stakeholders: affected teams are informed (application owners, service desk, customers).
• Impact analysis: what systems, data, compliance obligations and users are touched, and what is the risk if the change fails.
• Test results: evidence from a non-production environment that the change works.
• Backout plan: the tested steps to return to the previous state.
• Maintenance window: an agreed time with minimal business impact.
• Standard operating procedure (SOP): the documented steps for pre-approved routine changes.

Technical implications

• Allow lists and deny lists: a firewall or application control change can block critical traffic.
• Restricted activities: during the change, certain actions are limited.
• Downtime: planned service interruptions.
• Service and application restarts, legacy applications that may not tolerate the change, and dependencies that fail in sequence.

Documentation and version control

Update diagrams, configuration inventories, policies and procedures after changes. Version control (for code, infrastructure definitions and configuration) records every revision with author and timestamp, supports review, and allows rollback.

Worked example: a Friday firewall change

Scenario. An administrator wants to replace a firewall rule allowing the whole 10.0.0.0/8 range to the database tier with a rule allowing only the application subnet 10.20.5.0/24. It is Friday at 15:00 and the company ships orders until 18:00.

1. Request and impact analysis: identify which systems currently use the broad rule. The analysis finds that a reporting server in 10.30.1.0/24 also queries the database.
2. Test: apply the new rule in the staging environment and run the reporting job; it fails, confirming the dependency.
3. Design adjustment: add an explicit rule for the reporting server.
4. Approval: the change advisory board approves with the amended rule list.
5. Backout plan: keep the old rule disabled but not deleted, with a script to re-enable it.
6. Schedule: choose the Sunday 02:00 maintenance window rather than Friday afternoon.
7. Implement, verify, document: apply, run smoke tests, update the network diagram and the ticket, and commit the firewall configuration to version control.

Skipping steps 1 to 3 would have broken reporting; skipping step 5 would have lengthened the outage; changing at peak time would have magnified the impact.

Comparison: commonly confused pairs

Common pitfalls

• Treating category and type as the same axis. "Technical" is not a type, and "preventive" is not a category.
• Calling a policy "preventive". A policy is managerial and directive; the technical enforcement of the policy is what prevents.
• Believing that two passwords are MFA.
• Forgetting that audit logs support accounting, not authentication.
• Assuming that zero trust is a product. It is an architecture and strategy.
• Ignoring the backout plan in change scenarios; many questions hinge on the missing rollback.

Exam tips

• When a scenario says "a control that cannot be implemented because of technical limits, so an alternative is used", the answer is compensating.
• "Discourage" or "warning sign" points to deterrent; "alert", "log review" or "camera recording" points to detective.
• In zero trust questions, the policy engine decides and the policy enforcement point enforces. The policy administrator is the link between them.
• If the question involves proving who performed an action, think non-repudiation, not integrity.
• For change management, the best answer usually includes testing and a backout plan before production deployment.

Mini case study

Case. Northwind Logistics (800 employees) suffered an incident: a former employee's account was used for three weeks after departure to download route-optimization files. The audit shows that account removal depended on a manual email from HR, that file downloads were not monitored, and that the data had no integrity or authenticity protection. Management wants three improvements.

Questions.

1. Which CIA property was primarily breached, and what additional property is hard to prove?
2. Classify these proposed measures by category and type: (a) automated deprovisioning triggered by the HR system, (b) a SIEM alert for bulk downloads, (c) a quarterly access-review procedure performed by managers.
3. The deprovisioning change touches the identity system. What change-management elements are required?

Solution.

1. Confidentiality was breached (unauthorized disclosure). Non-repudiation is also weak because the account activity cannot be tied to a specific person without strong authentication and reliable logs.
2. (a) Technical, preventive. (b) Technical, detective. (c) Operational (a human procedure), detective; it is also a directive if backed by policy.
3. Impact analysis (applications that rely on the account directory), testing in a non-production directory, an approval from the identity system owner and HR, a backout plan to switch back to manual removal, a maintenance window, communication to stakeholders, and updating documentation and version-controlled automation scripts.

Key terms

• Control category: technical, managerial, operational, physical.
• Control type: preventive, deterrent, detective, corrective, compensating, directive.
• CIA triad: confidentiality, integrity, availability.
• Non-repudiation: proof that prevents denial of an action.
• AAA: authentication, authorization, accounting.
• Zero trust: architecture that verifies every request; uses a policy engine, policy administrator and policy enforcement point.
• Honeypot, honeynet, honeyfile, honeytoken: deception assets.
• Gap analysis: comparison of current and desired control state.
• Backout plan: tested rollback procedure for a change.

Summary checklist

• I can state the four control categories and six control types and classify a given control on both axes.
• I can match a failure scenario to confidentiality, integrity, availability or non-repudiation.
• I can separate authentication, authorization and accounting and name RADIUS and TACACS+ roles.
• I can choose DAC, MAC, RBAC, ABAC or rule-based access for a scenario.
• I can name the zero trust components and their order in a request.
• I can identify the deception technology that fits a description.
• I can list the steps of a safe change: impact analysis, test, approval, backout plan, window, documentation.

Sources

• CompTIA Security+ (SY0-701) overview: https://www.comptia.org/en-us/certifications/security/v7/ (opens in a new tab)
• CompTIA Security+ SY0-701 exam objectives, domain 1.0 General Security Concepts: https://www.comptia.org/en-us/certifications/security/v7/exam-objectives/ (opens in a new tab)
• NIST SP 800-207, Zero Trust Architecture: https://csrc.nist.gov/pubs/sp/800/207/final (opens in a new tab)
• NIST SP 800-53 Rev. 5, security and privacy controls: https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final (opens in a new tab)