Security Policies, Procedures, Standards, and the Bell-La Padula Model

5.1 Recap: From the CIA Triad to Today's Topic

5.1.1 The Security Wheel

Have you ever wondered why companies lock down laptops, watch network traffic, and hire people whose only job is to respond when something goes wrong? The answer is that all of these are spokes of one wheel, and every security decision an organization makes sits somewhere on it.

Earlier sessions built the base for everything that follows. We started with the CIA triad, the three goals that every security control exists to serve:

Then we looked at the security wheel of an organization, the areas where these goals are actually implemented. Endpoint security protects laptops, desktops, and mobile devices — the machines people touch directly. Network security protects traffic between systems, so that data moving from one machine to another cannot be read or altered in transit. Cyber security is the umbrella discipline that covers the rest — the overall program that ties everything together. Application security protects software, from the code itself to the services it exposes. And when something actually goes wrong despite all of this, the incident response team steps in to contain the damage, recover, and learn from the event.

5.1.2 Core Terminology from Earlier Sessions

We also fixed the vocabulary, because security conversations are only precise when everyone means the same thing by the same word:

• A threat is anything that can cause harm — a person, a program, a natural event, anything with the potential to damage an asset.
• A vulnerability is a weakness that a threat can exploit — a missing patch, a weak password, an open port.
• A threat model is a structured way to think about which threats matter for which assets. You cannot defend against everything equally; the threat model tells you where to spend your effort.
• Threat intelligence is the information about threats and attackers, collected from many sources — including open sources that anyone can consult, such as vendor advisories, breach reports, and public threat feeds — and used to prepare the organization. The threat model helps the organization protect assets such as systems, laptops, gestures (devices), and networks.
• The attack surface is the total set of entry points an attacker can reach — every open service, every exposed interface, every human who can be tricked. Bigger surface, more risk.
• Adversary tactics, the "TTP" idea — tactics, techniques, and procedures — show how an attacker moves: the overall goal (tactic), the method used (technique), and the specific, repeatable way it is executed (procedure). Knowing the TTPs of your likely attackers tells you which parts of the attack surface they will try first.

5.1.3 The Roadmap for This Session

Today the focus narrows to one question: what controls help us achieve confidentiality, integrity, and availability? A control is anything — a rule, a tool, a process — that reduces risk. Specifically, we want to understand the key differences between policies, procedures, standards, guidelines, and frameworks — why we need them, when we need them, and how to draft them. Then we move to the different types of information security policies and the models that back them: the Bell-La Padula model for confidentiality, and the Biba and Clark Wilson models for integrity.

This session goes deep on the confidentiality side; the integrity models come next. Everything we build today — the access chain, least privilege, classification, the Bell-La Padula rules — is a way of answering the same question: how do you keep data private when people, processes, and systems all want to touch it?

5.2 The CIA Trade-Off: No Perfect Security

5.2.1 Why 100 Percent Is Impossible

What would "perfect security" look like? Data that can never be read by the wrong person, never be changed, and never be down. The uncomfortable truth this session opens with: you can never have all three at 100 percent at the same time.

If you want security controls that deliver 100 percent confidentiality, 100 percent integrity, and 100 percent availability, you can never have them. A trade-off is always necessary whenever we use an existing security system or propose a new one. The real question for an organization is which of the three matters most: is availability the priority, or confidentiality, or integrity? The need to balance the needs of these three is why every control, from the first design discussion to going live, keeps coming back to the CIA triad — the organization's data, and its clients' data, must stay confidential, stay intact, and be available when the client needs it.

5.2.2 The Uptime Reality

A concrete example: you cannot say a server is up 100 percent of the time. The honest claim is 99.999 percent, and there is always a small sliver where the server will not be up when you need it. In the lecture, that sliver was stated as 0.0001 percent, and the point is the same in either reading — the promised fraction and the unguaranteed fraction do not add up to 100:

$$99.999\%+0.0001\%\ne 100\%$$

The arithmetic confirms the professor's point from the other direction. Adding the two stated figures gives $99.9991\%$, which still falls short of $100\%$. And the exact accounting is even starker: if uptime is $99.999\%$, then the unguaranteed fraction is

$$100\%-99.999\%=0.001\%$$

so the server can be down for roughly five minutes per year. The professor's $0.0001\%$ figure is a smaller sliver than the true $0.001\%$ gap, but both readings land on the same lesson: there is always a remainder that no promise can cover.

Applying a control always reduces risk; it never eliminates risk. Keep that sentence. Everything later in this session — policies, procedures, standards, models — is an attempt to shrink the risk, not to make it vanish.

This is also where this session's subject matters in practice: real service providers quote their availability in nines precisely because the number is a quantified promise. Cloud providers publish availability commitments per region and per service, and a customer's contract, budget, and risk appetite decide how many nines they are willing to pay for. The five-nines budget above is the same calculation cloud architects do when choosing between a single region and multi-region redundancy.

5.3 Confidentiality Means Controlling Access

5.3.1 What Confidentiality Means

Confidentiality is preventing unauthorized access to data. The name says it: you are controlling access. The goal is that only the right people have the right access to the data — authorized people (employees, whether full-time staff or contractors) get in, and unauthorized people never see any data at all.

The key phrase is "preventing unauthorized access." Confidentiality is not about secrecy for its own sake — it is about the boundary of who is allowed in. That control can sit at many different layers at once:

• the system level — operating-system login controls,
• the application level — the rules inside a specific software product,
• the database level — which records and columns a role may query,
• the network level — which traffic is allowed into and out of the organization,
• the file and folder level — per-user permissions on stored data.

5.3.2 The Everyday Example: Logging In

This is not rocket science; it is your daily routine. When you open your company laptop, you type a username and a password. The IT administrators could have simply handed you the machine — instead they restrict access to the company's assets (laptops, mobile devices, email — anything with value to the organization) to legitimate people only.

Two things happen in that single login, and keeping them separate matters:

• The username is your identity claim: "I am this user." On its own it proves nothing — anyone can type any username.
• The password is the secret you know and never disclose, because if the password leaks, anyone can log in with that username and password. The claim becomes believable only when it is backed by the secret.

From here we build the full authentication story: something you know, something you have, and something you are, combined to authenticate a user and then grant the required level of access based on the business requirement.

The same idea scales to the real world in a direct way: every organization that holds customer data — a bank, a hospital, an e-commerce site — runs its whole access-control program on this single concept. The controls differ in name and sophistication, but the question each of them answers is the same one from the login screen: is this person allowed to see this data?

5.4 How Security Controls Are Classified

5.4.1 Physical, Administrative, and Technical Controls

A control is any measure that reduces risk. The first way to classify controls is by type: what the control is made of. Remember the three classic categories:

• Physical controls are things you can touch — motion detectors, thermal sensors, locks, gates. They protect the physical world: the building, the server room, the hardware itself.
• Administrative controls are organizational practices — hiring policies, security awareness sessions, screening behavior, job rotation, and reviewing audit records. They govern how people behave, who gets hired, and how duties are separated.
• Technical controls are technology-driven — access control mechanisms, encryption, monitoring tools. They are implemented in hardware and software.

There are also operational controls, such as the rule that repeated passwords must not be used — day-to-day practices that keep the operation running according to policy.

5.4.2 Prevent, Detect, Deter, and Recover

The second way to classify controls is by what they do — their function, not their material:

• A control can prevent an incident — stop it from happening in the first place (an authentication mechanism, a firewall rule).
• A control can detect an incident — notice it while or after it happens (an intrusion detection system, audit log review).
• A control can deter a threat actor — discourage the attack before it starts (a visible camera, a warning banner, the knowledge that logs are kept).
• A control can recover from an incident that already happened (backups, disaster recovery procedures).

The two classification schemes are independent dimensions, not competing lists. Any single control has both a type and a function, and real confidentiality designs mix them deliberately.

This two-way classification is the same structure used by formal control frameworks in industry: standards such as NIST SP 800-53 and ISO/IEC 27002 organize hundreds of specific controls into families (management, operational, technical) whose members prevent, detect, deter, and recover. When a compliance team asks "which control covers this risk?", they are answering exactly this type-and-function question.

5.5 Identification, Authentication, Authorization, and Accountability

5.5.1 The Four Steps of Access

To control access you need four distinct steps, and each one answers a different question:

• Identification is the claim "I am this user" — the username. It answers: who do you say you are?
• Authentication is proving that claim — the password, PIN, or other credential. It answers: prove it.
• Authorization is the level of access you get once your identity is proven — what you may read, write, change, or delete. It answers: what are you allowed to do?
• Accountability is the ability to trace actions back to the person who performed them, so that when something goes wrong the organization can find out who did it. It answers: who will we blame?

The four steps build on each other like a ticket counter: you first state who you are, then you prove it, then the system decides what you may do, and only then do your actions become attributable to you.

5.5.2 The Shared-ID Problem

Accountability is why most organizations insist on unique user IDs. Some teams share IDs — the same login handed to three people on a team. If somebody then enters a wrong command on a server, tracing who did it becomes impossible, because the ID maps to three people.

Where a shared ID is unavoidable, organizations use tools with a check-in / check-out option: the shared ID is checked out by one user at a time, and the logs show which user held the ID in which time window. With those logs you can say "this command execution happened in this time frame, and this specific user held the shared ID then."

Everything here — identification, authentication, authorization, accountability — exists to protect confidentiality.

5.5.3 Non-Repudiation

Non-repudiation means a user cannot deny having done a transaction. If someone enters transactions or commands with a unique user ID and password, they cannot later claim "I did not do this." In the online world, digital signatures and digital certificates provide this non-repudiation — the electronic equivalent of a signed receipt that cannot be disowned.

Non-repudiation extends the access chain into the legal world: a digital signature binds the transaction to the signer with cryptographic evidence, so that later denial can be disproven. This is why banking transactions, contract signing portals, and government filings all rely on signatures backed by certificates — the signed receipt is the audit trail that survives even when the user changes their story.

5.6 Least Privilege, Need-to-Know, and Defense in Depth

5.6.1 Least Privilege

Least privilege means giving each user the minimum privileges required to do the job. You start from a small default and the level of access grows only as tasks and assigned projects demand it.

Think of it as a hotel key card: a guest's card opens only their room and the gym, not the staff offices. If the card is lost or stolen, the damage the thief can do is bounded by what the card legitimately opens. Least privilege does not make compromise impossible — it makes each compromise cheap.

5.6.2 Need-to-Know

Need-to-know goes one step further than least privilege. Least privilege asks "how much access does the job need?" Need-to-know asks "does this person have a valid reason to access this specific file, folder, or server?" Access is granted only when there is a legitimate business purpose for that particular resource.

The two usually work together: least privilege sets the ceiling of what the role can hold, and need-to-know decides which individual resources sit under that ceiling.

5.6.3 Defense in Depth

When you implement multiple controls at different layers — access controls at several zones and levels — that is defense in depth (also called layered defense). Defense in depth does not eliminate a threat; it reduces the attack surface, and if something does happen, it reduces the impact to an acceptable level.

A typical layered stack for a single protected database: a physical door on the server room (physical), a firewall at the network edge (technical), host hardening and endpoint protection on the server (technical), authentication before any query (technical/administrative), and audit-log review (administrative). An attacker who defeats any one layer still faces the others.

5.6.4 Mechanisms for Availability

Availability gets its own toolkit. To keep systems up and keep client impact minimal, organizations adopt availability policies, procedures, and technical controls:

• Storage mechanisms: the lecture lists RAID 0, RAID 1, RAID 2, and RAID 3 — the classic RAID levels, where multiple disks cooperate so that a single disk failure does not take the data down. (The source listing is partially garbled; the canonical RAID family is described below.)
• Redundancy: primary and secondary lines, a primary server with a backup, and cluster mechanisms — when one unit fails, another takes over.
• Cloud equivalents: in the cloud, the same goal appears as cross-region and cross-zone concepts — Amazon, Google, and Microsoft Azure each use their own terminology (availability zones, regions, region pairs), but the objective is identical.
• Fault tolerance and the FCAPS idea: the professor names fault, configuration, and availability management; the full FCAPS set also includes accounting, performance, and security management.

Real-world: cloud providers (AWS, Google Cloud, Azure) build availability into regions and zones, and you choose how much redundancy your budget can pay for. An availability SLA quoted in nines (Section 5.2) is only achievable when the underlying architecture actually has the redundant disks, lines, servers, and zones to back it up.

5.7 Authentication Factors and Multi-Factor Authentication

5.7.1 Something You Know

The classic authentication factor is something you know. Examples:

• a static password — a fixed secret you type each time;
• a passphrase — a longer phrase chosen to be memorable ("correct horse battery staple");
• a cognitive password — answers to personal questions ("What was your first school's name?").

The risks of this factor are well known: an attacker can read the password file (if passwords are stored weakly), run a brute force attack (trying many combinations systematically), run a dictionary attack (trying common words and previously leaked passwords), or use social engineering (tricking the user into revealing it — phishing). Because a single factor can be stolen this easily, single-factor authentication is always risky.

5.7.2 Something You Have

The second factor is something you have: a physical token you own. The classic example is an RSA token, which can be:

• synchronous — the token and the server both generate the same time-based code from the same clock; the user types the current code;
• asynchronous — the token uses a challenge-response mechanism: the system sends a challenge and the token computes the response from it.

Security questions work the same way as knowledge-based fallbacks — "what is your favorite place?", "where were you born?" — and some systems fall back to them after, say, three incorrect password attempts.

5.7.3 Something You Are

The third factor is something you are: physical attributes of the user — biometrics such as an iris scan or a fingerprint scan, or an ID scan. These attributes are collected when the user registers (enrollment) and used later to verify identity. Because they are part of the body itself, they cannot be "forgotten" like a password — but they also cannot be changed if compromised.

5.7.4 Multi-Factor and Dual-Factor Authentication

Combine factors and you get multi-factor authentication (MFA): in addition to username and password you also enter an OTP — the one-time token number generated on your device. When exactly two factors are used — say password plus iris scan or fingerprint — it is called dual-factor authentication.

The factors are categories, not just items: password + a second password is still single-factor (two items of "something you know"); password + OTP on your phone is genuinely multi-factor (know + have).

5.7.5 The Missing-Step Check

The instructor showed a flow that listed identification, then authorization, then the password scheme, PIN, and access control matrix — and asked the class to spot the problem.

The exchange matters because the same confusion shows up in real designs: people merge identification and authentication into one step, then wonder why the access control matrix seems to grant access without proof of identity. The password and PIN are not the authorization step — they are the proof-of-identity step that must come before authorization.

In practice, MFA is the single most effective control against stolen-password attacks: banking apps, corporate logins, and cloud consoles all require a second factor because the history of credential leaks is too long to ignore. The OTP on your device exists precisely because passwords alone have failed too many times.

5.8 Information Security Governance

5.8.1 The Oversight Team

Who decides what the policies say, and who makes sure the processes actually run the way management expects? That layer is information security governance — the layer that decides, directs, and oversees. In most organizations a dedicated team, the information security governance team, ensures that the processes defined and developed run as the management expects.

Governance is the difference between "we have a security idea" and "we have a security program": the team does not just suggest policies — it makes sure the policies get written, approved by management, communicated, and followed.

5.8.2 Inputs from Regulations and Laws

Policies get their inputs from several places, and regulations are among the strongest. A policy is rarely invented from nothing; it is usually a response to a requirement that the organization cannot opt out of.

5.8.3 Program-Level, Issue-Specific, and System-Specific Policies

Policies can live at different altitudes — and a mature organization has policies at all of them:

• Some are program-level, covering the whole organization — the security program's umbrella rules that apply to everyone, everywhere.
• Some are issue-specific: suppose an employee copied all the data from a company laptop onto a USB pen drive; the organization then drafts a policy restricting data access via USB drives, enforces it (by disabling USB ports), and grants exceptions only for specific scenarios.
• Others are system-specific, attached to a particular system's needs — the rulebook for the customer database server, the payment gateway, or the backup infrastructure.

In industry, this is why compliance teams exist: a bank's security policies are almost entirely shaped by regulations and client contracts, and auditors later verify that the policies exist and that practice matches them (Section 5.15). Governance is the bridge between legal requirements on one side and operational documents on the other.

5.9 What Is a Policy?

5.9.1 The Working Definition

A policy is the decision taken by management — the governing body of the organization. It says how each function should work. Formally, a policy is a formal statement that must be followed by all of its intended audience (the employees, contractors, or vendors the policy refers to; the audience is deliberately left open because it changes from policy to policy).

The word "decision" carries the weight: a policy is not a suggestion, not a technical configuration, and not a hint — it is management's chosen rule, in writing, with a defined audience.

5.9.2 Why Every Organization Needs Policies

How can employees and individuals inside a business use technology in the manner the organization expects? That is the first job of a policy. When you join a company you sign an acceptable use policy (AUP), which states the do's and don'ts: this laptop is for these purposes, the company internet is for these purposes, your browsing activity stays within these bounds.

The more stringent the business, the more complicated the policy document you sign. Doing business is one task; doing business in a secure manner is another challenge entirely. Organizations do business with assets — servers, laptops, desktops — and the transactions flowing through those assets must happen securely. That is what the information security policy achieves.

5.9.3 Simple Examples of Policies

A health-and-safety policy addresses the safety of the enterprise and of the employees who work there. A simple, clean example: "Legal services will review all third-party contracts." That one sentence is a policy — the management decision is that only the legal team reviews third-party contracts; no other department has the permission to do it. It spells out roles and responsibilities.

Another example, publicly available: an acceptable encryption policy — the skeleton of that policy shows the standard structure every policy follows.

5.9.4 The Anatomy of a Policy Document

The acceptable encryption policy has these default sections, and they form the skeleton of most policy documents:

1. Purpose — "the purpose of this policy is to provide guidance that limits the usage of encryption": which algorithms you should use and which you should not.
2. Overview — background and what the policy is about.
3. Scope — to whom this applies: the company name, and optionally a specific business unit.
4. Policy — the rules themselves: the encryption algorithms (RSA, AES — advanced encryption standard), the recommended key size, and the rule that any key length below 256 is not acceptable, with the allowed key length and key generation requirements.
5. Compliance — who verifies adherence: the infosec team or the compliance team checks how many people implement the policy effectively and efficiently; units that cannot comply are tracked as exceptions.

In the real world, this skeleton is why two organizations' encryption policies look alike even though the contents differ: the sections are standard, while the choices inside (which algorithms, which key sizes, who complies) belong to each organization's management. Templates from standards bodies and public policy libraries follow exactly this shape.

5.10 Exceptions and Non-Compliance

5.10.1 The Exception Process

Not every unit can always comply. Suppose the policy says AES with a 256-bit key, but a legacy application can only support 128-bit keys — forcing a larger key would break the application's business functionality. The architect team has no authority to change the key size on its own; instead the organization opens an exception. The exception document states, in writing:

• which policy the unit is not adhering to, and the issue,
• the risk to the organization,
• the mitigation controls or compensatory controls proposed instead, so that even without implementing the policy the remaining risk sits inside the organization's acceptable level — its risk appetite.

The architect cannot unilaterally weaken the encryption rule — the exception turns a "violation" into a "documented, risk-accepted, time-boxed deviation."

5.10.2 Tracking and Periodic Review

Exceptions are tracked manually or with governance tools — real-world example: Archer, a popular GRC (governance, risk, and compliance) platform. A specific team, the GRC team, periodically reviews the exceptions. When the risk is high, the policy may say the exception must be reviewed every six months by business information risk officers — the exact title varies by company, but the review team is generally a combination of the business side, the technology side, and the compliance side. All of them together take the decision on each exception.

5.10.3 Non-Compliance

Non-compliance is simply violating a policy or standard. The gate example: everyone must swipe in when entering the organization, but people do piggybacking (following an authorized person through) and tailgating (holding the door for an unauthorized person) — both are non-compliance with the access policy.

The distinction matters: an exception is a documented, approved deviation; non-compliance is an undocumented violation. The same act (not following the policy) is either a managed risk or a breach of the rules depending on whether it went through the exception process.

In industry, the exception workflow is exactly how standards certifications stay honest: an ISO 27001 auditor accepts that a legacy system deviates from the policy only when the exception document, risk assessment, and compensating controls prove the residual risk is accepted by management. GRC platforms such as Archer exist to make that proof auditable.

5.11 Security Policies Across the CIA Triad

5.11.1 Confidentiality Policies and the NDA

A security policy considers all aspects of the CIA triad. The confidentiality policy identifies the states in which information could leak to people not authorized to receive it.

Take a contractor: a contractor working for a company may be authorized to access proprietary information during the contract's lifetime, but only after signing an NDA — a non-disclosure agreement. NDAs exist with contractors and also with vendors who provide support.

Real-world: this is exactly how the banking outsourcing model works — the client's proprietary data leaves the bank's premises, so the bank substitutes legal binding (NDA) for physical control, and the vendor's compliance with the NDA is itself auditable.

5.11.2 Integrity Policies

The integrity policy identifies the authorized ways in which information may be altered, and who is authorized to alter it.

The log example is the cleanest: logs are the evidence trail of everything that happened on a system, so an integrity policy exists to answer two questions — who may change log records and how (the defined process). A log that anyone can edit is worthless as evidence; the policy is what keeps the logs trustworthy.

5.11.3 Availability Policies

The availability side is covered by policies that describe which services must be provided. The business continuity policy and the disaster recovery policy exist to provide availability — keeping systems available to the client even when something disrupts normal operations.

In industry, this mapping is visible in every certification: an ISO 27001 information security policy suite typically contains dedicated documents for data classification (confidentiality), change and log management (integrity), and business continuity/disaster recovery (availability) — the same three-way split taught here.

5.12 Procedures

5.12.1 What a Procedure Is

A procedure is the step-by-step process defined so engineers can achieve compliance with a policy. Procedures are often documented as SOPs — standard operating procedures. A procedure provides detailed mandatory steps, sometimes in the form of a checklist, that someone follows to complete a recurring task or to comply with a policy.

The relationship to the previous section is the key one: the policy is the what (the management decision), the procedure is the how (the steps to comply). Where the policy says "encrypt with AES-256", the procedure says exactly which command to run, in which order, and how to verify the result.

5.12.2 Examples of Procedures

Where the legal-services example was a policy, its procedure would be the steps the legal team follows when reviewing a third-party contract. More examples of tasks that procedures help with: granting access, asserting privileges, who can run backups and how, and who can update the firewalls and how.

The ticket example is the most concrete: to close an incident ticket you follow the documented steps — update these entries, mark the status as this, send an email to these people, and then close the ticket. To deactivate an active user ID, a defined process says what must be done, step by step.

In industry, procedures are where audits actually happen: auditors do not re-verify every action, they check that documented procedures exist and that the practice matches them (Section 5.15). A mature organization's SOP library is one of its most valuable compliance assets.

5.13 Standards

5.13.1 What a Standard Is

A standard specifies the uniform use of technologies or configurations. It can be an internal standard or an external standard the organization chooses to follow. Standards are already predefined — there can be no alterations to them. If you want a certification for your organization, you must adhere to what the standard lists.

The simple example given: in a legal contract document, the font and the font size are fixed — you follow those rules. Because the same standard applies identically to a BPO, a service-based company, or a pharmaceutical company, it is called a standard: it is the same for every organization that adopts it.

5.13.2 The ISO 27000 Family

The clearest example is the ISO 27000 suite — 27001, 27002, 27003 — where every standard in the family has its own requirements.

Real-world: BPOs, service companies, and pharma companies all go through this same ISO journey — the certificate is the internationally recognized proof that the organization's security management meets a fixed, uniform bar.

In the real world, "ISO 27001 certified" is a badge clients ask for by name — which is why entire service industries (BPOs, IT services, pharma vendors) treat the certification journey as a business requirement rather than an option.

5.14 Guidelines and Baselines

5.14.1 Guidelines Are Non-Mandatory

A guideline provides general guidance or extra support while you draft policies, standards, or procedures. The name says it: it guides. It assists the policy maker in explaining the policy in simpler terms. The key difference from a policy: a guideline is non-mandatory — not compulsory — while a policy is mandatory and must be adhered to.

5.14.2 Baselines

A baseline is the minimum set of requirements you commit to meet. Real-world: companies say "we are in line with CIS benchmarks" — meaning the minimum requirements they follow come from the CIS benchmarks — or they point to NIST standards and benchmarks.

Baselines and guidelines sit on the discretionary side: you may adopt them as references, while policies and standards are mandatory. This mandatory-versus-discretionary split is the clean way to tell the four documents apart.

5.14.3 The Four-Document Comparison

The instructor summarized all four on one chart, using one example topic — protecting the confidentiality and integrity of personally identifiable information (PII):

• Policy (mandatory): "Protect the confidentiality and integrity of PII by hardening your systems."
• Procedure: step one, step two, step three — the hardening steps in order.
• Standard: "Use this laptop" — the mandated device configuration.
• Guideline (discretionary): "Automate patch installation using a script; refer to the CIS benchmarks or NIST for baselines."

The difference between policy, procedure, standard, guideline, and baseline is not just exam material — the instructor stressed it is career-critical: in professional conversations, you must know whether someone is talking about a policy, a procedure, a standard, a guideline, or a baseline, because each carries a different weight.

Try this yourself: the business owner's module goes live in a couple of weeks using open-source software (OSS). Employees are downloading open-source software onto office laptops, and the instructor asked for help: draft any one of the following for the business case — a policy, a procedure, a standard, or a guideline/baseline reference. Which standard or control in ISO talks about open-source software? Which baseline tells you whether an OSS package is safe? Which procedure would you develop, or which policy would you draft? Pick one and write it — that is the test of whether the four-document distinction is clear.

In industry this distinction shows up daily: compliance teams enforce policies and standards, security engineers follow procedures, and advisory material (like CIS benchmark recommendations or NIST guidance documents) shapes both — without binding the organization the way policy does.

5.15 Why Policies Matter: Audits and Client Trust

5.15.1 No Written Policies, No Security

Why does a cyber security student study policies, procedures, standards, and frameworks? Because if an organization has none of them written down, there is no security at all — everything runs in an ad hoc position, where anyone says anything and someone does it. With well-drafted policies and procedures, when something happens, one refers to the policy and to the procedure laid down by the right team, and works accordingly.

5.15.2 Audits Prove the Security Posture

When a client wants confidence about the organization's security posture — how secure the organization really is — they look at audits performed by an independent third-party company.

Security, privacy, and legal teams are enablers: by showcasing the security posture they make clients confident that their data — leaving a trusted source and entering an untrusted area, our organization's network, whether in the cloud or in our data centers — will be processed and stored safely. The client's trust is built on "this organization is ISO certified, this organization is SOC certified, this organization has enough policies and processes in place."

The commercial reality is simple: a bank will not hand its customer data to a vendor that cannot show certification. That is why the NDA example (Section 5.11), the ISO journey (Section 5.13), and this audit picture form one continuous story: documents create trust, audits prove it, and business flows through the trust.

5.16 Access Control Fundamentals: Subject and Object

5.16.1 Access as the Flow of Information

To achieve confidentiality, the first step is controlling access, and controlling access comes down to one idea: access is the flow of information between two points. The controls determine how users and systems can communicate and interact with other systems and resources.

5.16.2 Subjects and Objects Defined

Access control involves two entities, and every model in this session uses the same two roles.

• A subject is the active entity that requests information — it can be a user, but it can also be a programmer, a process, or a program. The subject is the actor: it initiates the access.
• An object is the entity that contains the information the subject wants — a database, a file, a program, or another resource such as a printer. The object is the passive container: it holds the data.

If I am a subject accessing a database server to fetch information, I am the subject and the database is the object. Controlling the subject-object access is access control. Every model we meet — Bell-La Padula, Biba, Clark Wilson — uses this same subject-and-object concept: subject is the requester, object is the information or asset requested.

5.16.3 Roles Can Switch Between Requests

The roles are not fixed. The entity that serves as the object in one access event can serve as the subject in another.

The subject-object distinction is the standard vocabulary of the field: reference monitors, access control matrices, and formal models all phrase their rules as "subject S may perform action a on object O." When you read any access control literature, this pair is the first thing to identify.

5.17 Transitive Trust: When Chains Leak

5.17.1 The Chain of Requests

Here is where the confidentiality problem appears. In the previous example, A requests data from B, and B does not have the data, so B requests it from C. Now C is directly providing the information to A.

That is transitive trust: you are trusting in a transitive nature — if A trusts B and B trusts C, then automatically A trusts C, by the transitive property. The instructor drew this from arithmetic:

$$A=B,B=C⟹A=C$$

"If A equals B and B equals C, then A equals C — that is true," the explanation runs. In trust terms: A trusts B, B trusts C, so A ends up trusting C.

The formal reason the inference fails in security is that trust is not equality. Equality is a symmetric, transitive relation: $A=B$ means A and B are the same thing, so anything true of B transfers to A. Trust is a directed, partial relation: A trusts B tells us about A's willingness to rely on B — it says nothing about whether C may hand data to A. When A is restricted to receiving information only from B, and C hands the data straight to A because B already asked, the restriction is bypassed and confidentiality is lost.

5.17.2 The HR Salary Example

The concrete example: A is an HR employee. It is performance-review time, and A wants the records of all employees with their salaries and grades.

That is the biggest concern, and it is the failure that confidentiality models exist to prevent.

5.17.3 Why This Motivates Security Models

So the chain of requests is the motivation: access between subjects and objects must be governed by explicit rules, not by trusting that a chain of requests stays inside its restrictions. This is precisely why the security models in the next sections exist.

In the real world, this is why zero-trust architecture exists: modern networks assume that a chain of trust is not trust at all, and require every request — even between services that "know" each other through a third party — to be authenticated and authorized explicitly. The HR salary example is the same lesson in a pre-network setting: middlemen do not create permission.

5.18 Confidentiality Controls in Practice

5.18.1 Encryption

Encryption is one of the classic controls for achieving confidentiality. Encryption takes plain-text data, feeds it to an encryption algorithm, and converts it into a non-readable format — the encrypted data (ciphertext). Only the person with the key can decrypt and read the plain text inside.

The pairing matters: encryption is the mechanism, and the encryption policy is the rule that decides which mechanism is acceptable — which algorithms, which key sizes, how keys are generated. Mechanism without policy is chaos; policy without mechanism is wishful thinking.

5.18.2 Physical and Logical Access Controls

Physical access control: some projects — banking projects, for example — isolate the entire project team in one closed, restricted zone, physically separating the project people so that only members of that project can enter. (The instructor asked the class for the standard term for this restricted zone; the discussion did not settle on a name.)

Logical access control: some companies classify their networks into zones — blue, red, green — where red is the client-specific network and blue is accessible to all employees.

Physical, logical, and technical controls together, each backed by its own policy (encryption policy, logical access policy, physical access control policy), and each policy backed by its procedures, achieve confidentiality.

5.18.3 Data Classification and Labeling

The most important step comes before all of these controls: data classification. If the data itself is not classified appropriately — or is classified wrongly — the controls will be misplaced and the organization faces risk.

The ordering is the lesson: classify first, label second, then choose controls. Get the classification wrong and every downstream choice — which encryption, which zone, which DLP rule — is misplaced.

5.18.4 The Demilitarized Zone

The web-server example shows classification driving architecture. A public-facing website such as hdfcbank.com carries public content, so it must not sit at the same high level of logical controls as internal resources. That is why organizations use a DMZ — a demilitarized zone.

5.18.5 Cost-Benefit Analysis

Once you know the data's classification — highly confidential, confidential, internal, or public — the next step is the level of controls to implement, and that is a cost-benefit analysis: you define how much the control costs and what benefit the organization gets. More sensitive data buys more expensive controls; public data does not need them.

The banking architecture example mirrors real deployments: every major bank runs its public portal from a DMZ, and DLP products like WebSense sit at the email boundary watching for classification-tagged content. Classification is the business-side input that makes all the technical controls meaningful.

5.19 Access Control Types: DAC, MAC, and Non-DAC

5.19.1 Discretionary Access Control

Discretionary access control (DAC) — the name says it: it is the discretion of the manager. The manager decides whether to upgrade or downgrade a user's access. The person approving the access holds the choice.

5.19.2 Mandatory Access Control

Mandatory access control (MAC) is the opposite: you are mandated to follow it, and no manager has the privilege to update or modify the level of access a user holds. If a user is labeled at one level, even the manager who thinks the user deserves a privileged level of access cannot grant it. MAC fixes the labels — top secret, secret, highly confidential, confidential — and a person holding a particular clearance hat can only access the data that label allows.

MAC is employed in military communication networks, roughly 99.9 percent of the time (also stated as 99.99 percent in the discussion), and is very rarely applied in commercial or IT organizations.

The two labels "military" and "mandatory" are the same idea: in a military system, the classification rules come from the organization, not from any individual's preference — because a manager's opinion is exactly the kind of judgment call that must not decide who sees classified data.

5.19.3 Non-Discretionary Access Control

Non-discretionary access control (non-DAC) sits in the middle: a central authority determines what subjects can access, based on the policy. The decision does not belong to the individual manager — it comes from the center, per policy.

The subject-and-object idea you keep in mind here is the same one every model uses: subject is the person (or process) accessing, object is the information being accessed.

5.19.4 Rule-Based, Role-Based, and Entity-Based Controls

Controlling access can be done in many ways:

• Rule-based: you define a rule in the firewall and, based on the rule, allow or reject traffic.
• Role-based: you define a role — "this category can access this."
• Entity-based: you define parameters on the entity — "people after 7 p.m. cannot access the firewall site."

Add attribute-based and user-identity-based controls, and you have the full menu: physically, administratively, and technically, with rule-based, role-based, attribute-based, discretionary, user-identity-based, or MAC-based controls.

In industry, most commercial systems mix these: operating systems use DAC-style permissions, enterprises use role-based access control on top, and government/military systems (and some secure Linux configurations) implement MAC with fixed labels. Knowing which type a system uses tells you who can change a permission — and who cannot.

5.20 Security Models: The Designer's Blueprint

5.20.1 From Front End to Back End

At the front end, we say "grant access to the users of this business role, not that one." At the back end, engineers and designers build the product that enforces that statement.

The division of labor is the point: the front end is what the user and the business see — roles, access grants, products like Microsoft Active Directory. The back end is the security model that tells the designers how to structure the authentication and access logic underneath. The product is the visible face; the model is the invisible blueprint.

5.20.2 The Model Catalogue

The well-known models include:

• TCB (the trusted computing base) — the set of hardware, software, and firmware components that enforce the security policy; everything outside the TCB is untrusted.
• The state machine model — security as a set of states and transitions, where a system is secure if it starts secure and every permitted transition preserves security.
• Information flow models — rules about how information may move between entities, preventing flows from high to low.
• The take-grant model — graph-based rules about how rights can be taken and granted between subjects and objects.
• The access control matrix — which most people know: users on one side, read/write privileges in the cells, and access granted where the matrix says so.

For our confidentiality goal, the model of interest is Bell-La Padula; for integrity it is Biba and Clark Wilson. The product developer for authentication picks whichever model matches the requirements they want to achieve.

In the real world, every authentication product you have used sits on one of these models: Active Directory implements access decisions through structures derived from the access control matrix and state-based security logic, and multilevel-secure operating systems implement the Bell-La Padula rules directly in the kernel's security reference monitor.

5.21 The Bell-La Padula Model

5.21.1 Origins: The Department of Defense in the 1970s

The Bell-La Padula model is the confidentiality model. It was developed by the Department of Defense in the 1970s, based on a multi-level security policy.

Why did the DoD need a model at all? Because the front-end statement was simple — "classified data must not reach people without clearance" — but building software that provably enforces it required a formal structure: a model with labeled subjects and objects and rules that every access must satisfy.

5.21.2 The Core Idea: Clearance Levels and Labels

The model says: a subject with any level of clearance can access resources at or below its clearance level. The model labels both users and data.

The formal notation used in the literature: write $L(S)$ for the security clearance of subject $S$, and $L(O)$ for the security classification of object $O$. The levels are ordered, $L_0<L_1<\cdots <L_k$, from least to most sensitive — for the military scheme, top secret $>$ secret $>$ confidential. Remember, this is specifically a military model: the data classifications are the military ones — top secret, secret, confidential — and the user's label decides what is reachable.

5.21.3 The Simple Confidentiality Rule: No Read Up

The simple confidentiality rule (also called the simple property, or the read-only operation) says: a subject can read files at the same layer of secrecy and at lower layers, but not above — no read up.

The intuition: reading is how information enters the subject's head (or the subject's process). If a confidential-cleared subject could read secret data, confidentiality would be over before any policy could act — the secret data would have crossed the boundary. Blocking the read is the only way to guarantee the data never reaches the lower-cleared subject.

5.21.4 The Star Confidentiality Rule: No Write Down

The star confidentiality rule (also called the star property, or the write-only operation) addresses writing. A subject can write to files at the same layer and at upper layers of secrecy, but cannot write to lower layers — no write down.

This is the rule that closes the "Trojan horse" hole in the simple rule: a top-secret-cleared process that reads secret data could, without the star rule, write it into a confidential file, where a confidential-cleared subject could read it. The star rule forbids that write-down, so the leaked data can never be placed where the lower level can reach it.

5.21.5 The Strong Star Confidentiality Rule: Same Level Only

The strong star confidentiality rule is the strictest option: the subject can read and write only at the same layer of secrecy — neither above nor below. No read up, no write down, no read down, no write up: you are restricted to view and update data at the level you have been tagged with.

The three rules form a tightening sequence: simple allows read down; star adds a write restriction (write up only); strong star locks both read and write to the same level. If simple is a corridor with a ceiling, star adds a floor on writing, and strong star is a single locked room.

5.21.6 What the Model Does and Does Not Cover

By design, the Bell-La Padula model prevents the leaking or transfer of classified information to less secure clearance levels, by blocking lower-classified subjects from accessing higher-classified objects. It focuses on maintaining confidentiality and does not address any other aspect — it will not address integrity or availability concerns.

That is the exam-ready one-liner: only Bell-La Padula supports confidentiality, and it does so through three mechanisms — simple (no read up), star (no write down), and strong star (no read or write up or down).

The model is employed almost entirely in military-based organizations — the professor quoted roughly 99.9 percent (and in discussion also said 99.99 percent; both figures express the same fact, that military use dominates) — and real-world product designers for the military build their authentication products on one of these three options.

In the real world, BLP-style rules live inside multilevel secure operating systems and military command-and-control products: the kernel's reference monitor enforces no-read-up and no-write-down on every file access, and commercial versions of the idea (such as SELinux in strict mode) apply label-based mandatory controls in civilian settings as well.

5.22 Bell-La Padula in Practice

5.22.1 The Manager Analogy

The instructor's analogy for strong star and the simple rule: a manager can see all the data of his reportees, but a manager cannot see the data of the senior manager above him.

5.22.2 Doubts About Who Can Write Where

The model produces two doubts that almost everyone raises. Both are answered by the strong star rule.

5.22.3 The In-Class Exercise: Tamra, Samuel, and Clary

The instructor closed with an exercise on the slide. The setup: classifications top secret, secret, confidential, and unclassified; subjects labeled accordingly — Tamra is a top-secret subject, Samuel is tagged to the secret label, Clary is classified unclassified (the reference material uses the canonical names Tamara for top secret, Samuel for secret, Claire for confidential, and Ulaley for unclassified, with file objects such as personnel files, electronic mail files, and the telephone list — the recorded names are partly garbled, but the labels and operations are the same) — and a set of stated operations: Tamra can read all files; Clary cannot read personal or email files; Ally can read only the telephone list.

The question: are these operations correct under the Bell-La Padula model, or does any statement lose confidentiality?

The point of the exercise is to catch the statement that violates the model: in scenario-based questions, the trap is usually the write-down — the read statements look dangerous but pass the simple rule, while a single write-down operation silently leaks the data.

5.22.4 Exam Note: Scenario-Based Questions

The instructor stated the exam style explicitly: the questions on these models will be scenario-based. You will be given a scenario — "the user has done this, this, and this" — and asked to say, per the Bell-La Padula model, which actions are correct and which are wrong.

The manager analogy and the classification diagram are the two practice tools the instructor named: walk every combination of subject level and object level through all three rules until the pattern (reads go down, writes go up, strong star stays level) is automatic.

5.23 What Comes Next: Integrity and Availability Models

5.23.1 Integrity Models: Biba, Clark Wilson, and Lipner

The other two model families are the Biba model, the Clark Wilson model, and Lipner's integrity model — all aimed at integrity: making sure that only authorized persons can modify data, and unauthorized modification never happens.

The symmetry with the previous section is deliberate: Bell-La Padula blocks unauthorized reading (confidentiality); the Biba model is its mirror image, blocking unauthorized writing with its own no-read-down / no-write-up rules turned around for integrity. Clark Wilson adds the commercial structure — well-formed transactions and separation of duties. Lipner's model combines the two traditions.

5.23.2 Availability Models

The remaining models are more about the architectural view of availability — how availability can be achieved, what a deadlock situation is, and how to prevent denial of service (DoS). These are trickier and get their own session, because the instructor preferred to make each model clear rather than cover everything in one session. By the next class, chapter 2 is complete.

5.23.3 Syllabus Pacing and the Internal Exam

The syllabus pacing: the internal examination is scheduled for days 15, 16, and 17. Chapter 3 is the easiest topic — simple basics of networks — and can be covered in a single session. Chapter 4 covers the threat landscape, common cyber attack stages and patterns — already touched in earlier sessions, with more insight to come.

The pacing is a study hint: the next session's recap of the three rules is not a reason to delay learning them — it is the professor's signal that these rules are important enough to review twice.

Exam Guidance Summary

• Bell-La Padula model (high weight): questions will be scenario-based — given a scenario and the actions a user performed, decide which actions are correct and which are wrong under the model. Practice with all three rules and all level combinations (top secret, secret, confidential, unclassified).
• The three rules: simple confidentiality (read-only operation — no read up, read down implied), star confidentiality (write-only operation — no write down, write up allowed, read up stays allowed), strong star confidentiality (same level only — no read or write up or down).
• One-liner to memorize: only the Bell-La Padula model supports confidentiality; it does not address integrity or availability. Biba, Clark Wilson, and Lipner cover integrity; the availability models are architectural (deadlock, denial of service).
• The four-document distinction: policy (mandatory, management decision), procedure (step-by-step how-to), standard (uniform, predefined, no alterations), guideline (non-mandatory), baseline (minimum requirements). The instructor called this career-critical as well as exam-relevant.
• The access chain: identification, authentication, authorization, and accountability, plus non-repudiation — a favorite spot for a conceptual question.
• The exercise: Tamra, Samuel, and Clary — check each stated read against the labels and the three rules; be ready to say which statement loses confidentiality.
• Syllabus pacing: internal examination on days 15–17; chapter 2 completes by the next class; chapter 3 (basics of networks) is the easiest and fits one session; chapter 4 (threat landscape, common attack stages and patterns) adds depth to earlier material.
• Practice assignment: draft any one of policy, procedure, standard, or guideline for the open-source software business case — this directly tests the policy/procedure/standard/guideline distinction.

Key Industry Applications

• Regulatory drivers: HIPAA (US health insurance business) and GDPR (EU personal data, with controller/processor/sub-processor roles) force organizations to align every policy with legal requirements.
• Certification and audit: ISO 27001 (certificate), ISO 27002 (controls how-to), ISO 27003; SOC 1, SOC 2, and SOC 3 audits; independent audit firms EY, PwC, DNV, and BSI; client-specific audits. Clients trust data transfer to service providers only when the provider is ISO- or SOC-certified and the policies are documented and practiced.
• Outsourcing confidentiality: banks such as JP Morgan and Wells Fargo outsource development and testing to Infosys or TCS under NDAs running two to five years.
• DLP in practice: WebSense-style data loss prevention watches outbound email and allows or blocks traffic based on classification keywords.
• GRC tools: exceptions are tracked in platforms like Archer by GRC teams; high-risk exceptions are reviewed every six months by business information risk officers.
• Network architecture: the DMZ (demilitarized zone) keeps public-facing servers like hdfcbank.com segregated from internal networks; red/blue/green network classification separates client-specific traffic from general employee traffic.
• Authentication products: RSA tokens (synchronous/asynchronous, challenge-response), OTP-based MFA, biometrics; Microsoft Active Directory as the front-end product backed by security models underneath.
• Availability in the cloud: AWS, Google Cloud, and Azure implement cross-region and cross-zone redundancy with their own terminology; on-premises equivalents include RAID, primary/secondary lines, and clustering.
• Baselines: CIS benchmarks and NIST standards as the minimum configuration requirements organizations claim to meet.
• Military multilevel security: Bell-La Padula rules run inside multilevel secure operating systems and military command-and-control products, with label-based mandatory controls as the kernel's enforcement mechanism.