9.1 Access Control & Authentication

Defensive security starts with a deceptively simple question: who are you, and what are you allowed to do? On the Cyber Test, access control and authentication questions test whether you can separate identity proof from permission decisions, name the classic authentication factors correctly, and apply models such as DAC, MAC, and RBAC under pressure. These ideas show up in every USAF cyber environment — from a workstation login with a Common Access Card (CAC) to role-based permissions on a mission system.

Authentication vs. Authorization

Authentication is the process of verifying a claimed identity. When a user types credentials, presents a smart card, or scans a fingerprint, the system answers: "Is this person (or process) who they claim to be?" Authorization happens after successful authentication. It answers a different question: "Given that we accept this identity, what resources and actions are allowed?"

Exam trap: a user can authenticate successfully and still be denied access. That is not an authentication failure — it is an authorization (access control) decision. Conversely, a wrong password fails authentication before authorization is even considered.

A related term is accounting (or auditing): recording who did what, when, and from where. Together, authentication, authorization, and accounting are often summarized as AAA. For the Cyber Test, focus first on cleanly separating authentication from authorization; AAA vocabulary reinforces that logging and accountability complete the control picture.

The Three Authentication Factors

Security textbooks group authentication into three classic factor types. Memorize the categories and at least one concrete example of each:

Something you know is convenient but vulnerable to phishing, shoulder-surfing, reuse, and offline cracking of stolen password hashes. Strong passwords and unique credentials help, but knowledge alone is weak against modern attacks.

Something you have proves physical or device possession. Military networks commonly rely on CAC/smart-card authentication: the card holds cryptographic credentials, and the user typically supplies a PIN (knowledge) to unlock the card — already multi-factor when both are required together.

Something you are uses biometric characteristics. Biometrics are hard to "forget" or hand to a coworker, but they raise privacy, spoofing, and revocation issues (you cannot easily rotate a fingerprint the way you rotate a password). On the exam, classify biometrics as "something you are," not as a possession factor.

Some materials mention a fourth idea — somewhere you are (geolocation or network location) — as an additional contextual signal. Treat location as a useful policy input, but when a question asks for the three classic factors, stick to know / have / are.

Multi-Factor Authentication (MFA)

Multi-factor authentication (MFA) requires the user to present at least two different factor types. Password + SMS code (know + have), CAC + PIN (have + know), or fingerprint + token (are + have) all qualify. Two passwords, or a password plus a security question, do not qualify as MFA — both are knowledge factors.

Why MFA matters: compromising one factor is no longer enough. An attacker who steals a password still needs the token or biometric. That sharply raises attacker cost and buys time for detection. Cyber Test items often test the definition more than product brand names — if the options do not span two categories, it is not MFA.

Access Control Models: DAC, MAC, and RBAC

Once identity is established, the system needs a policy model for permissions.

Discretionary Access Control (DAC)

Under DAC, the owner of a resource decides who else may access it. Classic examples include file permissions on many desktop operating systems, where a user can share a folder with coworkers or change mode bits. DAC is flexible and user-friendly, but it depends on owners making good decisions. Accidental oversharing and malware running as the user (inheriting that user's rights) are common failure modes.

Mandatory Access Control (MAC)

Under MAC, a central policy — not the resource owner — enforces access based on labels, clearances, and formal rules. Users and objects carry sensitivity classifications (for example, Unclassified, Confidential, Secret, Top Secret in government contexts). The operating system or security kernel enforces "no read up / no write down" style rules (Bell–LaPadula is the classic confidentiality model you may see referenced in deeper study). Owners cannot casually override labels. MAC is stricter and less discretionary — appropriate for high-assurance and classified environments.

Role-Based Access Control (RBAC)

Under RBAC, permissions are assigned to roles (job functions), and users are assigned to roles. A "network admin," "help-desk tech," or "mission planner" role carries a predefined permission set. When someone changes jobs, administrators move them between roles instead of editing dozens of individual file ACLs. RBAC scales well in enterprises and aligns with the principle of least privilege when roles are narrowly scoped.

Quick comparison for exam recall:

• DAC — owner decides; flexible; risk of oversharing
• MAC — system/policy decides via labels/clearances; rigid; high assurance
• RBAC — permissions via job roles; scalable administration

Least Privilege and Related Principles

Least privilege means granting each user, process, or service only the access required to perform its authorized tasks — no more. A help-desk account should not have domain-admin rights "just in case." A web service should not run as root if a limited service account suffices.

Closely related ideas:

• Need to know — even with a clearance, access is limited to information required for the duty
• Separation of duties — split critical tasks so no single person can complete a sensitive action alone (for example, one person requests a change, another approves it)
• Privilege creep — over time, users accumulate unused permissions; periodic access reviews reclaim excess rights

When an account is compromised, least privilege limits how far an attacker can move laterally. That is why defensive architectures pair strong authentication (often MFA) with tightly scoped authorization.

Putting It Together in a Cyber Context

Imagine an airman authenticating to a cyber operations workstation with a CAC and PIN (possession + knowledge = MFA). After authentication, RBAC maps the airman to an analyst role that can query certain logs but cannot alter firewall rules. Sensitive mission data may also sit under MAC-style labeling so that even an authenticated analyst without the required clearance cannot open it. Audit logs record the session for later investigation. That stack — strong auth, role-based authorization, mandatory constraints where needed, and accounting — is the practical picture the Cyber Test expects you to reason about, not just memorize definitions.

Master the vocabulary first: factors, MFA, DAC/MAC/RBAC, least privilege. Then practice classifying scenario questions quickly — the exam rewards precise category recognition under time pressure.