Defence in depth: CIA, AAA and non-repudiation, stated precisely enough to be useful

Objective 1.1 in SY0-801 puts its core ideas under one frame: defence in depth. Confidentiality, integrity and availability, the three As of access, non-repudiation, zero trust and least privilege are all presented as parts of a layered defence rather than as separate facts. This lesson takes the frame itself, then CIA, AAA and non-repudiation. Zero trust and least privilege 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. 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.

Defence in depth is new as the heading over all of this in V8. It is less a fact to memorise than a way of judging designs, and questions use it that way: which option adds an independent layer, and which only makes one layer taller?

The lesson

Defence in depth as the frame: layers that fail independently, not one tall wall

Defence in depth means protecting something with several layers of control, arranged so that the failure of any one layer does not expose the asset. The attacker has to defeat all of them; you only need one to hold, or at least to notice.

The word that matters is independently. Three firewalls from the same vendor with the same rule set are not three layers -- one misconfiguration or one vulnerability defeats all of them at once. Real depth mixes kinds of control:

• different categories -- a technical control backed by an operational one (MFA, plus a helpdesk procedure that will not reset it on a phone call alone);
• different types -- preventive controls with detective ones behind them, so that when prevention fails, someone finds out;
• different places -- the network edge, the host, the application, the data itself (a stolen database file that is encrypted is one more layer the attacker still has to beat);
• different failure causes -- controls that would not all be defeated by the same mistake, the same stolen credential or the same unpatched flaw.

A useful way to read a defence-in-depth question: imagine the first control has already failed. What stops or detects the attacker now? If the answer is "nothing", there is no depth, however many products are listed.

Every idea in the rest of this objective is a layer, or a property a layer protects. CIA names what you are protecting. AAA is how access is controlled and recorded. Non-repudiation makes actions provable. Zero trust and least privilege, next lesson, limit how far one failure can spread.

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 cable cut, 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 criminals 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 data breach at all, which is the point of the encryption -- although the missing laptop is still an availability problem for the person who needed it.

Some material adds further properties, such as the "Parkerian hexad". SY0-801 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 scenario where "nobody can prove who deleted the file" is an accounting failure, and the answer is logging, not stronger passwords.

AAA applies to devices and services as well as people. A server presenting a certificate to a client is authenticating; a workload with an assigned role is being authorised; an API gateway's request log is accounting. Protocols such as RADIUS and TACACS+ exist to carry all three for network equipment, and identity and access management in Domain 4 builds on this vocabulary.

Each A is also a layer in the defence-in-depth sense. Strong authentication with weak authorisation lets a legitimate user reach far too much; strong authorisation with no accounting means misuse is never seen.

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 presenting 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 -- part of identity and access management in Domain 4 -- where the whole exercise is establishing that the person claiming an identity at enrolment really is that person, 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, and the cryptography lessons later in this domain show how a signature is made.

Logs still matter here, as a layer. Accounting records that are themselves protected from tampering -- written to a separate system, hashed or signed -- make it harder for anyone, including an administrator, to rewrite history. They support non-repudiation; on their own they do not deliver it.

What to take into the exam

• Defence in depth means independent layers: if one control fails, another still stops or detects. More of the same product is not depth.
• 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.