Episode 4 — CIA and AAA: The Core Security Models (1.1)
In this episode, we start with two security models that will help you organize a lot of what you learn from here forward: Confidentiality, Integrity, and Availability (C I A), and Authentication, Authorization, and Accounting (A A A). These models may sound formal at first, but they are actually very practical. C I A helps you understand what security is trying to protect. A A A helps you understand how access is granted, controlled, and recorded. When you are new to cybersecurity, it is easy to feel like every term is separate from every other term. These two models give you a way to connect the pieces. When you hear about encryption, passwords, backups, logs, permissions, outages, or account misuse, you can bring the idea back to one of these models and ask what is really being protected or controlled.
Before we continue, a quick note. This audio course is part of our companion study series. The first book is a detailed study guide that explains the exam and helps you prepare for it with confidence. The second is a Kindle-only eBook with one thousand flashcards you can use on your mobile device or Kindle for quick review. You can find both at Cyber Author dot me in the Bare Metal Study Guides series.
C I A starts with confidentiality. Confidentiality means keeping information away from people, systems, or processes that should not have it. You already understand this idea in everyday life, even if you have never used the security term before. You would not want your bank account details, private messages, medical information, or personal documents available to anyone who happens to be curious. In an organization, confidentiality protects things like customer records, employee information, business plans, passwords, legal files, and sensitive technical details. Controls that support confidentiality include encryption, access control, data classification, and careful sharing practices. When confidentiality fails, the main problem is exposure. Someone has seen, copied, received, or accessed information that should have stayed protected. That exposure can harm people, damage trust, violate rules, and create long-term risk.
Confidentiality is not only about hiding secrets from outside attackers. It also applies inside an organization, where people should only see information that matches their role and need. A payroll employee may need access to salary records, but a receptionist may not. A doctor may need access to a patient chart, but another employee in the same building may not. A support technician may need to reset an account, but not read every confidential file owned by the user. This is where confidentiality connects to access control. You are not just asking whether the system is locked from the outside. You are asking whether access is limited properly on the inside as well. Many data exposures happen because information is shared too broadly, stored in the wrong place, or left available to accounts that do not truly need it.
Integrity is the second part of C I A, and it is about trust in accuracy. Information has integrity when it is complete, correct, and changed only in approved ways. You can see why that matters by thinking about a bank balance, a medical dosage, a school grade, a software update, or a shipping address. If any of those values are changed without permission, the result can be harmful even if the information was never stolen. Integrity failures can be quiet and dangerous because the data may still be available and may still look normal. The problem is that you can no longer trust it. Security controls that support integrity include permissions, hashing, digital signatures, logging, change management, and version control. They help protect information from unauthorized or accidental changes.
Integrity also applies to systems and processes, not only to data sitting in a file. If a software update is altered before installation, you may install something harmful while believing it is safe. If a log record is changed, an investigation may be misled. If a configuration setting is modified without approval, a system may behave in a way nobody expected. Integrity is about confidence that something is what it claims to be. That confidence matters because security decisions depend on trustworthy information. If you cannot trust the data, the logs, the settings, or the software, then your decisions are built on weak ground. When you study integrity, keep the word trust in your mind. You are protecting the reliability of information and the reliability of the systems that use it.
Availability is the third part of C I A, and it focuses on whether systems and information can be used when needed. This may sound less dramatic than data theft, but availability is often the part people notice first. If a banking site is down, customers cannot use it. If a hospital system is unavailable, patient care may be delayed. If a school learning system fails during finals, students and instructors may be stuck. If a business cannot access its order system, revenue may stop. Availability is harmed by attacks like ransomware and Distributed Denial of Service (D D O S), but it can also be harmed by equipment failure, bad updates, power problems, overloaded systems, and human mistakes. Security protects usefulness, not just secrecy.
Availability connects strongly to resilience. You want systems to stay working when possible and recover quickly when they do fail. That is why backups, redundancy, monitoring, incident response, disaster recovery, and maintenance planning all support availability. A backup can help restore data after damage. Redundant systems can keep a service running if one part fails. Monitoring can reveal a problem before users feel the full impact. Recovery planning can help people respond calmly instead of improvising under pressure. You should not think of availability as separate from security just because it sounds like an operations topic. If an attacker prevents people from using a system, that is a security problem. If a bad change takes a critical service offline, that is also a security concern. Secure systems need to be usable systems.
The parts of C I A often pull on each other, and real security decisions have to balance them. Strong confidentiality controls can sometimes make access less convenient. Strong integrity checks can sometimes slow down a process. Strong availability requirements can sometimes push organizations to keep extra systems online, which then need to be protected too. The goal is not to choose only one part of C I A and ignore the others. The goal is to understand which part is most at risk in a given situation and choose controls that fit the need. For example, a public website cares a lot about availability because people must reach it. A password database cares deeply about confidentiality and integrity because exposure or tampering would be serious. A payment system needs all three because the data must be private, accurate, and available.
A A A shifts your attention from what security protects to how access is handled. Authentication is the process of proving an identity. Authorization is the process of deciding what that identity is allowed to do. Accounting is the process of recording activity so actions can be reviewed later. These three ideas are closely related, but they are not interchangeable. You can sign in successfully and still be denied access to a file. You can have permission to perform an action and still have that action logged. You can also have logs that show someone tried to access something they were not allowed to use. A A A gives you a clean way to think about access from beginning to end: prove who you are, receive the right level of permission, and leave a record of important activity.
Authentication is usually the first part you experience as a user. When you enter a password, unlock a phone with a fingerprint, approve a sign-in prompt, or use a smart card, you are taking part in authentication. The system is trying to decide whether the identity claim should be accepted. A password is one form of proof, but a password alone can be stolen, guessed, reused, or tricked out of someone through phishing. Multi-Factor Authentication (M F A) strengthens the process by requiring more than one kind of proof. That might include something you know, something you have, or something you are. Authentication does not mean the system trusts you with everything. It only means you have passed the identity check needed to move to the next decision.
Authorization comes after authentication and answers a different question. Once the system accepts who you are, it still has to decide what you can do. You may be allowed to read one file but not edit it. You may be allowed to use an application but not change its settings. You may be allowed to view your own account but not someone else’s. Authorization is where permissions, roles, groups, policies, and privileges matter. This connects directly to least privilege, which means you should have only the access needed for your role or task. Extra access may seem convenient, but it increases risk. If your account is misused, every extra permission becomes extra damage that could happen. Good authorization keeps access narrow, purposeful, and easier to review.
Accounting is the part that records what happened. In security, this usually means logs, audit trails, access records, and activity history. Accounting helps answer questions after the fact. Who signed in? When did the sign-in happen? What file was accessed? What setting changed? Which account deleted the record? Were there repeated failed attempts before the successful sign-in? Without accounting, an organization may have no reliable way to understand events, investigate incidents, prove that a policy was followed, or show that a rule was violated. Accounting also supports accountability. If people know that important actions are recorded, there is a stronger connection between identity and responsibility. You do not log everything for curiosity. You log important activity because evidence matters when something goes wrong.
C I A and A A A work together more often than they appear separately. Authentication protects confidentiality by keeping unknown users out. Authorization protects confidentiality and integrity by limiting what accepted users can see or change. Accounting supports integrity and accountability by creating records of activity. Availability can also depend on A A A because weak access controls may allow someone to disrupt a system, delete data, or misuse administrative functions. Picture a school grade system. C I A tells you that grades should be private, accurate, and available when needed. A A A tells you that users must prove who they are, receive only the access their role requires, and have important actions recorded. The two models are different, but they support the same overall goal: safer, more controlled use of systems and information.
One common mistake is treating these models like vocabulary that only matters for exam definitions. They are much more useful than that. When you read a scenario, try to identify which part of C I A is being threatened. Is private data being exposed? That points to confidentiality. Is information being changed or made unreliable? That points to integrity. Is a service down or unreachable? That points to availability. Then look for A A A issues. Did someone fail to prove identity properly? That points to authentication. Did someone have too much or too little access? That points to authorization. Is there no record of what happened? That points to accounting. This habit helps you slow down and reason through questions instead of jumping at the first familiar term.
The conclusion is that C I A and A A A are two of the best mental models you can carry into Security Plus. C I A helps you understand what security is trying to protect: privacy, trustworthiness, and usability. A A A helps you understand how access works: proving identity, granting permission, and recording activity. These models are simple, but they are not shallow. They show up in cloud security, identity management, incident response, encryption, logging, governance, and almost every other topic you will study. When a concept feels confusing, bring it back to these questions. What needs to stay private? What needs to stay accurate? What needs to stay available? Who is trying to access it? What should they be allowed to do? What record should exist afterward? Those questions will make the rest of security easier to understand.
