CIA, AAA and non-repudiation, stated precisely enough to be useful

Objective 1.2 in this course covers fundamental concepts — CompTIA's scope note for it summarises confidentiality, integrity and availability (CIA), non-repudiation, authentication, authorization and accounting (AAA), zero trust, and deception and disruption technology. This lesson takes the first half; zero trust and deception are the next lesson.

Why this matters

Everyone arrives at this exam already knowing what CIA stands for, which is exactly why it costs people marks. The acronym is easy. What the exam actually tests is whether you can look at a described failure and say which one of the three broke — and a surprising number of scenarios are ambiguous until you are precise about the definitions.

AAA has the same problem in a worse form, because the middle A is routinely misremembered and the third A is routinely forgotten. And non-repudiation is the concept most often answered wrong by people who could define it, because they reach for a log when the answer is a signature.

The lesson

Confidentiality, integrity and availability as three separate failures

Define each by the failure, not by the word:

• Confidentiality fails when someone who should not see the data sees it. Not when they change it, not when they delete it — when they read it. The controls are encryption, access control and classification.
• Integrity fails when data is changed in a way that was not authorised, or changed accidentally and not noticed. The controls are hashing, digital signatures, checksums, version control, and permissions that prevent writes.
• Availability fails when the data or service is not there when an authorised user needs it. Ransomware, a failed disk, a DDoS, a backhoe through a fibre run, an expired certificate. The controls are redundancy, backups, capacity and fault tolerance.

Now the cases people get wrong. Ransomware primarily attacks availability — the data is still confidential and still intact, you simply cannot get at it. If the gang also stole a copy before encrypting it, that second act is a confidentiality failure, and modern ransomware usually does both. A defaced website is integrity, not confidentiality. A stolen but encrypted laptop may be no failure at all, which is the point of the encryption.

Some material adds a fourth and fifth idea as "the Parkerian hexad". SY0-701 examines the three. Learn the three properly.

Authentication, authorisation and accounting, and the order they happen in

The order is the lesson:

1. Authentication — proving you are who you claim. Password, token, biometric, certificate.
2. Authorisation — deciding what that proven identity may do. Group membership, role, ACL, policy.
3. Accounting — recording what they did. Logs, session records, the audit trail.

The order matters because the exam builds scenarios on it. A user who logs in successfully and then gets "access denied" opening a share has passed authentication and failed authorisation — so the fix is a permissions change, not a password reset. A user who cannot log in at all has failed authentication. A question asking "we cannot prove who deleted the file" is an accounting failure, and the answer is logging, not stronger passwords.

AAA also names a family of protocols — RADIUS, TACACS+, Diameter — that do all three for network devices. You meet those properly in 4.6.

Identification versus authentication, a distinction the exam does test

Identification is the claim. Authentication is the proof.

Typing your username is identification: you have asserted an identity and proved nothing. Typing the password is authentication. A badge number is identification; the PIN you type after swiping it is authentication.

This matters in two exam contexts. First, in multifactor questions: a username is not a factor, because it is not a proof of anything. Second, in identity proofing (which you meet in 4.6), where the whole exercise is establishing that the person claiming an identity at enrolment really holds it — a step that happens before any authentication ever takes place.

Non-repudiation, and why it needs a signature rather than a log line

Non-repudiation means the originator of an action cannot credibly deny having taken it.

A log entry saying user alice deleted invoice 4471 is accounting. It is useful, and it is also something Alice can dispute: the log was written by a system other people administer, her session could have been hijacked, and nothing in that line was produced by anything only Alice controls.

A digital signature is different. It is produced with a private key that only Alice holds, and anyone with her public key can verify it. She cannot plausibly claim someone else produced it without also claiming her private key was compromised — which is a much harder thing to assert and has consequences of its own.

So: when a scenario asks for proof that someone sent a message and cannot deny it, the answer involves a private key. Hashing alone gives integrity, not non-repudiation, because anyone can compute a hash. Symmetric encryption alone does not give it either, because both parties hold the same key and either could have produced the ciphertext. Non-repudiation requires asymmetric cryptography. That single sentence answers a lot of questions.

Gap analysis: stating where you are against where the policy says you should be

A gap analysis compares the current state of your controls against a required state — a policy, a standard such as ISO 27001, a regulatory requirement, or a framework you have adopted — and produces a list of differences.

Three things make it useful rather than decorative:

• It names a target. "We are not very secure" is not a gap analysis; "we do not meet requirement 8.3.6 of the standard we have committed to" is.
• It produces per-item findings, each with an owner, so that the output is work rather than a mood.
• It feeds the risk register (Domain 5), where each gap is either remediated, accepted with a stated rationale, or covered by a compensating control.

On the exam, gap analysis usually appears as the correct first step when an organisation has just adopted a framework or is preparing for an audit. You cannot plan remediation before you know the gaps, and you cannot know the gaps without a stated target.

What to take into the exam

• Match the failure to the letter: read is confidentiality, change is integrity, cannot-reach is availability. Ransomware is primarily availability.
• Authentication proves identity, authorisation grants access, accounting records use — and a "logged in but denied" scenario is always authorisation.
• A username identifies; it does not authenticate and is not a factor.
• Non-repudiation needs a private key. If the options offer hashing, a log, or a shared secret, none of them is the answer.
• Gap analysis needs a named target standard, or it is not a gap analysis.