Cyber Security

Integrity Policies and Introduction to Networks

Published: 2026-08-16

Level: postgraduate

Audience: Postgraduate students and working IT professionals studying Cyber Security

Prerequisite Knowledge

This lecture builds on the following concepts from earlier lectures. If any feel unfamiliar, review the linked notes before proceeding.

Previously Covered in This Subject

Bell-LaPadula and its three confidentiality rules — covered in Lecture 5
Subjects and objects in access control — covered in Lecture 5
The CIA triad: confidentiality, integrity, availability — covered in Lectures 1 and 2
Security models as architecture-level reference models — covered in Lectures 1 and 5
OSI seven layers and TCP/IP four layers — covered in Lectures 1 and 2
Network types and devices — covered in Lecture 2

6.1 Bell-LaPadula Recap: Confidentiality as the Goal

6.1.1 Subjects, Objects, and Classification Labels

This session opens with a review of the three confidentiality rules of the Bell-LaPadula model, because confusion from the previous session showed that these rules deserve a second look. Bell-LaPadula is a subject-object model: every subject — a person or a program trying to access something — carries a label, and every object — the database or the data being accessed — carries a label too. It is a military model, so it uses the military's own classification of security levels: top secret, secret, confidential, and unclassified. A person tagged with a particular label can reach only the data at that security level: a user at the secret level reads data labeled secret. That part is straightforward. The model exists for one goal — confidentiality — and it protects that goal through three rules. Two of the three are easy to get; one of them is the one everyone keeps tripping on.

Hook: Why review rules we already covered? Because one of the three Bell-LaPadula rules feels backwards when you first meet it — the star rule lets a secret user write into a top secret database, and forbids writing into a lower one. Almost everyone in the previous session argued with that rule before seeing the reasoning behind it. By the end of this section, the rule should feel obvious.

To state the rules precisely, we need two pieces of notation, both taken from the way the model was designed. Let $L (S)$ stand for the security clearance of a subject $S$ (the person or process), and let $L (O)$ stand for the security classification of an object $O$ (the data or database). The four levels are ordered: unclassified is the lowest, then confidential, then secret, then top secret at the top. We write $L (O) \leq L (S)$ when the object's level is at or below the subject's level.

Formalize — the label order. The military levels form a single ordered list, from most sensitive to least sensitive:

$top secret \geq secret \geq confidential \geq unclassified$

A subject's clearance and an object's classification are both drawn from this list. Every rule below is a condition that compares these two values: may this subject read or write this object? Bell-LaPadula never looks at the content of the data — only at the two labels. That is why the model is called a label-based (mandatory) policy.

Visual intuition: draw a four-rung ladder with top secret at the top and unclassified at the bottom. Put the subject on one rung (say secret) and the object on another. Every one of the three rules is just an arrow between two rungs: an arrow that is allowed, and an arrow with an X through it. The whole model reduces to three such arrows, which is why the lecture's diagram is a simple set of arrows — and why the state-machine assignment in the next section can redraw these same arrows as states and transitions.

Scope: Bell-LaPadula protects exactly one goal: confidentiality — keeping data from people who must not see it. It says nothing about whether data is correct (integrity) and nothing about whether services stay available (availability). The model also assumes the labels are assigned and trusted: if a mislabeled object sits at the wrong rung, every rule below computes the wrong answer. Finally, Bell-LaPadula is a mandatory policy: users cannot change their own labels or an object's classification at will, because that would let them grant themselves access.

Real-world connection: this is the model behind government and military multilevel-secrecy systems, where documents carry markings such as top secret and users carry clearances checked before every access. Versions of it survive today in multilevel-secure operating systems that keep classified and unclassified workloads on one machine without mixing them.

6.1.2 Simple Confidentiality Rule: Read Only, Read Down

The simple confidentiality rule governs read operations only. A user tagged secret can read data at the same label, and can read data at any label below it — confidential, unclassified. The one thing the rule forbids is reading data at a label above the user's own: a secret user cannot read top secret data. Walk through the diagram the way it was explained: top secret at the top, secret in the middle, unclassified at the bottom. The secret user reads secret — allowed. The secret user reaches for top secret — the model says no. The secret user reads confidential or unclassified — allowed. Since this rule concerns the read operation alone, it is called the simple confidentiality rule — "simple" meaning read-only, not easy.

Formalize — the simple confidentiality rule. A subject $S$ may read an object $O$ only when the object's classification is at or below the subject's clearance:

$S can read O ⟺ L (O) \leq L (S)$

Reading at the same level is allowed, reading downward is allowed, and reading upward is forbidden. A shorthand used across the literature and in exams: "no reads up."

Why "no reads up"? If a secret-cleared user could read top secret data, then a lower-cleared user (or a malicious program acting for them) could take that top secret information and pass it to someone who is not cleared for it. The rule stops the flow of information from higher labels to lower ones at its source — the read itself. In the three-rule table below, this rule covers the read column; the star rules cover the write column.

6.1.3 Strong Star Confidentiality Rule: Read and Write at One Level Only

The strong star confidentiality rule covers both read and write operations, and it is stricter: the user may perform read or write operations only at the exact label the user has been tagged to — neither above nor below. A user tagged secret reads and writes secret data, and nothing else. That is why it is called strong: it locks the user to a single level for every operation.

Formalize — the strong star rule. A subject $S$ may read or write an object $O$ only when the two labels are equal:

$S can read or write O ⟺ L (O) = L (S)$

Under this rule a secret user cannot even read the unclassified phone list and cannot write a note into the confidential bucket. Everything happens at the one level the user was tagged with. The strong star rule is the strictest of the three: it is the union of the other two rules taken to the extreme.

The model keeps three separate rules because real systems need flexibility: sometimes a policy wants to allow read-down (so senior staff can still see lower-level material) while strictly controlling writes. The strong star rule exists for environments where even that is too risky, and every operation must stay inside a single compartment.

6.1.4 Star Confidentiality Rule: the Tricky Write Rule

The star confidentiality rule is the rule that always raises doubts: it allows a user at a lower label to write into a database at a higher classification level, and it forbids writing into a database at a lower level. That seems backwards at first — how can a secret user be allowed to write into a top secret database? The answer is in the model's goal. The whole point of Bell-LaPadula is confidentiality. Suppose a user at the secret label writes entries into an unclassified bucket. Now imagine who that user is: say the head of HR, whose access covers highly confidential information about the entire organization. If that person mistakenly writes confidential data into the unclassified bucket — the one visible to all employees — the data loses confidentiality, because everyone in the organization can see it. If the same user writes onto a higher classification instead, the write adds more security: the data sits at a level that fewer people can reach, so confidentiality is not lost. From the confidentiality viewpoint, writing upward is harmless and writing downward is a leak. That is the entire logic of the rule: never let a high-tag user drop data into a lower bucket; mark an X on the lower bucket and allow the upper bucket.

Formalize — the star confidentiality rule. A subject $S$ may write an object $O$ only when the object's classification is at or above the subject's clearance:

$S can write O ⟺ L (O) \geq L (S)$

Writing at the same level is allowed, writing upward is allowed, and writing downward is forbidden. Shorthand used everywhere: "no writes down."

Intuition — the leak test. Think of each bucket as a room, and of a write as carrying a document into a room. A write down puts the document into a room with more people in it — anyone at that lower level can now read it, so the set of possible readers grows. A write up puts the document into a room with fewer, more trusted people — the set of possible readers shrinks. Confidentiality asks only one question: does this action grow the audience? Writing down grows the audience, so it is banned; writing up shrinks it, so it is allowed. That is the whole rule in one sentence: never move data toward a wider audience.

The point that trips people up: Bell-LaPadula is not judging the data's quality or whether the write is a good idea — it is only judging the direction of information flow. A secret user writing incorrect notes into a top secret file is bad for integrity but harmless for confidentiality, and this model only enforces the confidentiality side. The next topic (Biba) will build the mirror-image rule that handles exactly that concern.

6.1.5 Working Examples: The CEO and the Patent

The suggested way to make the diagram behave: pick a role and act it out. Choose a person, give them a label, choose a destination bucket, and ask whether the write is a leak. Working two scenarios by hand makes the rule stick far better than re-reading the definition.

Worked example 1 — the head of HR writes into the unclassified bucket.

Setup: The head of HR is a subject tagged secret. Their job gives them access to highly confidential information about the entire organization — salaries, appraisal results, disciplinary records. An unclassified bucket is a shared space visible to all employees.

Action: The head of HR writes entries into the unclassified bucket.

Check against the star rule: the destination (unclassified) is below the writer's label (secret), so $L (O) \leq L (S)$ holds — the write is downward. The star rule forbids it.

Consequence if allowed: every employee in the organization can open the bucket and read whatever confidential data the HR head dropped there. The data loses confidentiality — once placed in the visible bucket, it cannot be taken back. The rule exists precisely to block this failure: the write is forbidden, and confidentiality is protected.

Sense-check: the rule rejects exactly the action that leaks data, so the outcome matches the model's goal of confidentiality.

Role-play the same scenario in the other direction: the head of HR wants to place the same entries into a top secret bucket. Fewer people can reach top secret material, so the audience shrinks and confidentiality is preserved — the star rule allows it.

Worked example 2 — the CEO posts quarterly figures on a public site.

Setup: A CEO enters the organization's quarterly profits, losses, and exact expenses into a publicly available site — data visible to anyone on the internet, which sits at the bottom of the ladder: unclassified.

Action: the CEO writes this sensitive financial data into the unclassified bucket.

Check against the star rule: the destination is below the writer's effective label (executive financial data is at least confidential), so the write is downward — forbidden.

Consequence: quarterly profits, losses, and exact expenses are now public; competitors and the market see figures the organization wanted private. Confidentiality is lost the moment the publish button is pressed.

Sense-check: high-value data was placed where lower-tag people (in this case, everyone) can see it — the same failure pattern as the HR example, so the rule rejects it.

The same pattern repeats with a third role-play: a user holds patent information and enters the whole patent data into a lower bucket — confidential technical details become readable by staff without clearance, and confidentiality is lost again. In all three cases the failure is identical: high-value data placed where lower-tag people can see it. These role-play scenarios are how the model stops being confusing — act out the role, check the direction of the write, and the answer appears.

Pitfalls (some called out in the lecture):

Confusing "allowed" with "good idea." The star rule allows writing up because it cannot leak; it is not an endorsement. A wrong or harmful write upward is still possible — it just does not hurt confidentiality, which is the only thing this model checks.
Forgetting that the simple rule is read-only. The simple confidentiality rule never says anything about writes. A secret user is still barred from reading top secret data even though the star rule lets them write into it — the two rules are independent and both must hold.
Using the strong star rule where a plain star rule is asked. Strong star locks read and write to one level; the star rule only locks writes. Scenario questions usually test exactly which operations each rule covers.
Mixing up "no reads up" with "no reads down." The simple rule bans reading up; the star rule bans writing down. Memorize the pair with the leak test: reads leak when they go up, writes leak when they go down.

6.1.6 Recap of the Three Rules

So Bell-LaPadula achieves confidentiality in three ways: the simple confidentiality rule restricts read operations (no read above your label), the star confidentiality rule restricts write operations (no write below your label), and the strong star rule restricts read and write together (only at your own label). The table below places all three side by side — this is the exact comparison to keep in mind for scenario questions.

Rule	Operations covered	Allowed	Forbidden	Shorthand
Simple confidentiality	read only	same level and below	reading above your label	no reads up
Star confidentiality	write only	same level and above	writing below your label	no writes down
Strong star	read and write	only your own label	any other level	one-level lock

One deeper point ties the rules to the next topic: a system built on these rules is a state machine. Each moment of the system — who is reading what, who is writing what — is a state, and each rule decides which moves between states are allowed. If the system starts in a secure state and every allowed move preserves the rules, then every state the machine reaches stays secure. That is the state-machine foundation that integrity models in the next sections reuse.

Q: Why does the star confidentiality rule allow a secret user to write into a top secret database, but reject writing into a lower classification? A: The goal is confidentiality, nothing else. Take the head of HR scenario: a user tagged secret writes entries into the unclassified bucket. That user holds highly confidential information about the whole organization; if those entries land in the unclassified bucket, visible to all employees, confidentiality is lost. Write upward into the higher classification instead and the write adds security — fewer people can reach the data, so confidentiality is not lost. The rule blocks writing downward and allows writing upward because downward writes grow the audience and upward writes shrink it.

Exam note: scenario questions are the expected form — a subject with a given label performs given operations; decide whether that is correct, or what the ideal operations would be. The depth tested is the rules themselves, nothing deeper. For each of the three rules, be ready to name which operation it covers (read, write, or both) and which direction it blocks (up or down).

Recap + bridge: Bell-LaPadula = confidentiality, enforced by three label-comparison rules — no reads up, no writes down, and the one-level lock of strong star. The model says nothing about integrity, so the lecture now turns to integrity policies and to the state machine that both families of models share.

Real-world connection: the label scheme itself comes from military and government classification — top secret, secret, confidential, unclassified — and the same ladder of labels appears wherever organizations mark documents by sensitivity. The role-play scenarios are not academic: data-leak incidents in real companies usually look exactly like the CEO example — sensitive numbers published to a wider audience by someone with the power to publish. Bell-LaPadula-style rules are the formal version of the common-sense rule "keep the audience small."

6.2 Integrity Policies: Goals and the State Machine Foundation

6.2.1 What Integrity Means

The CIA triad — confidentiality, integrity, availability — is the frame. With confidentiality covered by Bell-LaPadula, this session turns to the second pillar. Integrity ensures that only legitimate people can modify data or a database. Notice the difference in emphasis: most commercial and industrial firms are more concerned with the accuracy of their data than with its disclosure, so integrity policy gets the focus there. The emphasis on integrity in commerce differs from that of military standards, where confidentiality came first and labels plus mandatory access controls did the job.

Hook: A bank can survive a leaked interest rate, but it cannot survive a customer's account balance being silently changed by an attacker. In commerce, wrong data damages business directly — that is why integrity, not confidentiality, is the commercial priority, and why an entire family of models exists for it.

Integrity, in the sense used here, means data is modified only by legitimate people and stays accurate and consistent. The term legitimate matters: the threat model for integrity is not the outsider stealing secrets, but the wrong person (or the right person doing the wrong thing) changing data that other people will rely on.

Formalize — what a policy must protect. An integrity policy governs three things at once:

who may modify data (only legitimate, authorized subjects),
how data may be modified (only through allowed operations),
what state data must stay in (consistent, accurate, and never silently corrupted).

Compare with Bell-LaPadula, which governed only who may read what. The mirror-image structure is deliberate: confidentiality is about the flow of information outward (who can see), integrity is about the flow of changes inward (who can modify).

Scope: Integrity says nothing about secrecy. A file with perfect integrity may be readable by everyone — its value is that it has not been tampered with. Equally, a file that is perfectly secret may be full of errors. The two goals are orthogonal, and models must be chosen by which goal the system needs. This is exactly the point the lecture makes when separating confidentiality from integrity in the site-operations-manager example of the next section.

Real-world connection: commercial and industrial systems — banking ledgers, inventory control, payroll — care more about accuracy than disclosure. An inventory control system keeps working even if its data is released, but breaks if its data is randomly changed. That single observation motivates every integrity model in this lecture: Biba, the Lipner integrity matrix, and Clark-Wilson.

6.2.2 The State Machine Concept

Both Bell-LaPadula and Biba rest on the state machine concept. A state machine is a way to analyze how a system operates from user input: based on the inputs we provide, the system responds differently, and the state machine traces every state the machine passes through — how the machine responds to every different input — so we can see the flow of the sequence. A state is a snapshot of a particular instance: what the current permissions are, and which instance of the object is currently being accessed. From an information security perspective, we want to ensure confidentiality, integrity, and availability, so we develop models that system designers can use while designing a system to achieve one of the three goals. A new model appears when the previous model has drawbacks: Bell-LaPadula supports only confidentiality, so to support integrity the Biba model came into existence. Both Bell-LaPadula and Biba use the state machine as a reference model: they watch how subject and object permissions change at each instant, identify all the states, and work out which final states keep the system safe. The typical way to build one: if a user of this category accesses that object, what happens; if the user tries to access this other one, what happens; write out all the combinations of state movements, then develop the model. That is why we call these models state-machine models.

Formalize — a state machine for access control. Picture the system as a machine that moves between states. One state is one complete snapshot of the system at an instant. For an access-control model, a state records at least:

the set of subjects and objects,
the current permissions (which subject can currently access which object, and how),
which object instance is being accessed.

A transition is one action by a user — "subject $S$ requests read access to object $O$ " — and the transition either is allowed or is denied. The model's rules decide which transitions are legal. The security question becomes: if we start in a secure state and only take legal transitions, do we ever reach an insecure state? The answer is what the model is built to guarantee.

Intuition — the snapshot camera. A state is like a single photograph of the machine: the camera captures who is logged in, what permissions are currently granted, and which file is open at that instant. The next user action moves the machine to a new photograph. The security policy is the director standing next to the camera, rejecting any move that would produce a bad photograph. Analyze a system by listing all reachable photographs and checking each one against the goal — that enumeration is exactly the "write out all the combinations of state movements" step.

The Basic Security Theorem, which the reference model gives us, states the guarantee precisely: if the initial state of the system is secure, and every allowed transition preserves the security rules, then every state the machine can reach is secure. This is why the rules matter so much: the model does not need to inspect the entire future; it only needs to check each individual transition, because secure rules composed in sequence produce secure states.

6.2.3 Secure State Transitions and the Weekly Assignment

When you develop a system with these reference models, the most important factor is how the state variables change. When do we call a state movement a secure state — when it moves from lower to upper, or from lower to bottom? Which state transitions happen? You test to verify that the overall machine state is not compromised. When Bell-LaPadula is designed on the state machine, the designers ensure confidentiality is maintained at all times; when Biba is designed on it, they ensure integrity is maintained — input integrity is why we say integrity is maintained.

Worked trace — a two-state read scenario. Take a machine with two subjects, $S_{1}$ (cleared secret) and $S_{2}$ (cleared confidential), and two objects, $O_{1}$ (secret file) and $O_{2}$ (confidential file).

State A: $S_{1}$ is reading $O_{1}$ , $S_{2}$ is idle. Under the Bell-LaPadula simple rule, $L (O_{1}) = L (S_{1})$ , so the read is legal — State A is secure.
Proposed transition: $S_{2}$ requests read access to $O_{1}$ . Compare labels: $L (O_{1}) = secret > L (S_{2}) = confidential$ , so the transition is denied; the machine stays in State A.
Proposed transition: $S_{1}$ requests read access to $O_{2}$ . Compare labels: $L (O_{2}) \leq L (S_{1})$ , so the transition is allowed, and the machine moves to State B.

Sense-check: every proposed move was checked against the label rule before being accepted, exactly as the state-machine method prescribes — secure rule, secure transitions, secure machine.

Assignment for this week: take either Bell-LaPadula or Biba and produce a small diagram that represents the three rules — simple, star, strong star — as a state machine model. The simple arrow diagram (arrow up, arrow down, cross mark) was already shown in class; the task is the same content expressed as states and transitions. Nothing critical to write; it is a small diagrammatic representation.

Exam note: quizzes 1 and 2 happen in March; each quiz carries 5% of the total weight and contains 25 multiple-choice questions. Quiz 1 covers chapter 1 through chapter 2 up to section 2.1.1 (confidentiality policies) — everything covered up to the previous session. The slides are the reference set and are more than enough; no textbook is prescribed.

Recap + bridge: integrity means only legitimate people can modify data and the data stays accurate; state machines model systems as snapshots and transitions; a model is trusted when secure rules guarantee secure states. With the state-machine foundation in place, the lecture next applies it to the first pure integrity model — Biba.

Real-world connection: state-machine thinking is not just academic. Reference monitors in operating systems, firewall state tracking, and formal security verification of critical systems all work the same way: define the states, define the legal transitions, and prove that no legal sequence of transitions reaches a forbidden state. The weekly assignment — redrawing Bell-LaPadula's three rules as states and transitions — is the first step toward that kind of reasoning.

6.3 Biba Integrity Model

6.3.1 Biba: The Inverted Bell-LaPadula

Biba was designed after Bell-LaPadula because Bell-LaPadula supports only confidentiality and not integrity. Biba is the inverted version, which rules the exact opposite of Bell-LaPadula: whichever way Bell-LaPadula rules, Biba rules the reverse way. Like Bell-LaPadula, it is built on the state machine concept. It was designed to address three issues: prevent modification of objects by unauthorized subjects; prevent unauthorized modification of objects by authorized subjects; and prevent internal and external object inconsistency — maintaining consistency means keeping the accuracy of the data, both internal and external. Biba also has three rules — simple integrity, star integrity, and strong star integrity — mirroring the Bell-LaPadula set. As with Bell-LaPadula, two of the three rules are easy and one is complicated in every model; the complicated one this time is the simple integrity rule.

Hook: If integrity is the goal, what is the dangerous direction? For confidentiality, reading up was the danger. For integrity, the danger flips: writing up — a less trustworthy person placing unvalidated data where everyone else will trust it. Biba's rules are exactly Bell-LaPadula's rules with up and down swapped, and the swap happens because the leak direction changed.

Formalize — integrity levels and the three goals. Biba gives every subject and every object an integrity level, written $i (S)$ for a subject $S$ and $i (O)$ for an object $O$ . A higher integrity level means more trustworthy data: it has been validated, comes from a trusted source, and can be relied on. A lower level means unvalidated or untrusted data. With that scale in place, Biba enforces three things:

no modification of an object by an unauthorized subject,
no unauthorized modification of an object by an authorized subject (even authorized people must not make changes they are not permitted to make),
no internal or external inconsistency — data must stay accurate and consistent, both inside one system and across systems.

The reference formalization also adds a fourth relation: a subject may invoke (execute) another subject only when the invoked subject's integrity level is not higher than the invoker's — otherwise a low-trust process could control a high-trust one and corrupt it.

The reason Biba inverts Bell-LaPadula is visible in the trust idea: data at a higher level is more trustworthy than data at a lower level, and integrity is preserved only when trustworthy data is never contaminated by untrustworthy data. The next three subsections apply that idea to reads, to writes, and to both together.

6.3.2 Simple Integrity Rule: Do Not Read Down

The simple integrity rule blocks reading a bucket at a lower integrity level; reading at the same level is fine, and reading at an upper level is allowed. Why would reading downward harm integrity, when in Bell-LaPadula reading downward was harmless? The analogy says: integrity levels are like a purity level of air. You would not pump air from the smoking section into the clean room environment; in the same way, whenever integrity matters you do not want unvalidated data read into a validated document. The reasoning: data at a lower classification level carries no guaranteed accuracy, while data at the same or a higher level is assumed accurate. If a person at the higher level reads the lower data, the accuracy is not there, and that directly impacts integrity.

Formalize — the simple integrity rule. A subject $S$ may read an object $O$ only when the object's integrity level is at or above the subject's:

$S can read O ⟺ i (O) \geq i (S)$

Reading at the same level is allowed, reading upward is allowed, reading downward is blocked. Shorthand: "no reads down." The direct mirror of Bell-LaPadula's "no reads up."

Intuition — the air purity analogy. Think of integrity levels as air quality. A clean room keeps its air pure; a smoking section is full of polluted air. You would not pump air from the smoking section into the clean room, because the clean room would stop being clean. Same with data: a validated document is a clean room, and unvalidated input is smoking-section air. Reading lower-level data into a higher-level document drags the pollutant in — the document's accuracy is no longer guaranteed, so integrity drops.

Worked example — the manager and the department heads.

Setup: A manager must take inputs from various people and make decisions on them. The people come from different levels of trust. Department heads sit at the manager's level or above; team members sit below.

Action: the manager receives a figure from a department head and a figure from a below-level team member, and wants to base a decision on both.

Check against the simple integrity rule: reading from the department head is at the same level or above — allowed, because that data carries guaranteed accuracy. Reading from the team member is downward — blocked, because there is no clarity about that data's integrity.

Consequence: the manager can make decisions on department-head inputs but cannot make decisions on team-member data. In the same spirit, email from the CEO is a trusted one; discussion among same-level peers can be evaluated; data received from team members and used for further action cannot be considered.

Sense-check: the rule admits only data whose accuracy is guaranteed, so decisions based on admitted data inherit that guarantee — integrity is preserved.

This is why the lecture's diagram marks an X on the lower bucket for the read operation: in Bell-LaPadula the X was on the upper bucket (no reads up), and in Biba the X moves to the lower bucket (no reads down).

6.3.3 Star Integrity Rule: Do Not Write Up

The star integrity rule is the easy one: a subject cannot write to a bucket at a higher classification level, but can write at the same level or a lower level. This is the mirror of Bell-LaPadula's star rule: writing down spreads accurate data to more places, while writing up would let a lower-integrity subject pollute a higher-integrity object. That way integrity is achieved.

Formalize — the star integrity rule. A subject $S$ may write an object $O$ only when the object's integrity level is at or below the subject's:

$S can write O ⟺ i (O) \leq i (S)$

Writing at the same level is allowed, writing downward is allowed, writing upward is blocked. Shorthand: "no writes up."

Why writing up is the danger: a lower-integrity subject writing into a higher-integrity object injects unvalidated data into a place where everyone trusts the contents. From then on, readers of the object cannot tell which parts are validated and which are not — the object's integrity level becomes a lie. Writing down into a lower bucket is safe: the data is accurate, and it lands where readers already expect lower trustworthiness.

6.3.4 Strong Star Integrity Rule: One Level for Everything

For stronger control, the strong star integrity rule restricts the user to read and write operations at the same level only — the same single-level lock as Bell-LaPadula's strong star, applied to integrity.

Formalize — the strong star integrity rule. A subject $S$ may read or write an object $O$ only when the two integrity levels are equal:

$S can read or write O ⟺ i (O) = i (S)$

Neither reads down nor writes up survive: everything happens at exactly one level. Reading upward is still allowed in the simple rule, but the strong star rule removes even that, leaving the subject locked to its own integrity level.

Taken together, the three rules give a clean pattern: reads are restricted by the simple rule, writes by the star rule, and the strong star rule is the union of both restrictions at maximum strictness. Notice what the two simple/star pairs imply: if a subject is allowed both to read and to write an object, the only way both rules hold is $i (O) = i (S)$ — the levels must be equal.

6.3.5 Q&A: A Site Operations Manager Example — Integrity or Confidentiality?

A student proposed the site operations manager example. The answer separates confidentiality from integrity.

Q: For integrity, could we say a site operations manager should not access project details, because he may leak project data to the outside world? A: That reasoning leans toward confidentiality, not integrity. Restricting a manager to only this level of data prevents leakage — that is the confidentiality view. Integrity is about legitimate people modifying data: who is allowed to change it, and whether the data stays accurate. Keep a clear segregation: confidentiality is about who can see the data; integrity is about who can modify the data.

Why the student's example felt plausible: both policies restrict access, and both can be stated as "the manager may reach only this level of data." The correction is that the reason for the restriction differs. Leakage is an information-flow problem — someone who should not see data sees it — which is confidentiality's job. Tampering is an accuracy problem — someone changes data who should not, or changes it wrongly — which is integrity's job. When answering scenario questions, first decide which of the two goals the scenario is about, then apply the matching model's rules.

6.3.6 Requirements and Drawbacks of Biba

Biba requires all subjects and objects to have a classification label — a continuation of the DoD model that produced Bell-LaPadula. Data integrity protection so depends on the data classification model, which is itself the drawback. Biba has drawbacks, like: it addresses only integrity, not confidentiality, and not availability; it always focuses on the objects from the external perspective, assuming internal threats are handled by programs automatically; it does not address access control management; and it provides no way to assign or change an object's classification level. That last point connects to the earlier discussion of discretionary access control: with discretionary access control (DAC), the power lies with the manager — classification levels can be changed at the owner's discretion — whereas Bell-LaPadula and Biba are completely mandatory access control (MAC): labels are fixed by policy, not by the user. Biba also does not prevent covert channels — channels that transfer data in a different way, violating the organization's policy; criminals typically use these channels to carry out cyber attacks.

Assumptions & scope — where Biba applies and where it breaks:

Assumption: every subject and object carries an integrity label, and the labels are correct. If labels are missing or wrong, the rules compute the wrong verdicts.
Assumption: integrity, not confidentiality or availability, is the goal. Biba cannot stop a secret from being read and cannot keep a service running.
Scope limit — no label management: Biba provides no mechanism to assign or change an object's classification level. Under discretionary access control an owner could change levels at will; under Biba's mandatory control the labels are fixed by policy, so changing a label requires an outside (unmodeled) process.
Scope limit — no internal threat handling: Biba looks at objects from the external perspective and assumes internal threats are handled automatically by programs.
Scope limit — covert channels: Biba does not prevent covert channels, which smuggle data through side paths that the model never sees — a real gap that attackers exploit.

Recap + bridge — why new models appeared: Biba gives integrity but leaves confidentiality, availability, label management, and covert channels unhandled. Each later model in this lecture closes one of these gaps: Lipner adds commercial requirements like separation of duties and auditing, and Clark-Wilson replaces labels with programs and well-formed transactions.

6.3.7 Model Identification Exercise

A slide presented three points: a subject cannot write data to an object at a higher integrity level; a subject cannot read data from a lower integrity level; a subject cannot request service of a higher integrity level. Which model does that describe — Bell-LaPadula or Biba?

Worked trace — identifying the model from the rules.

Point 1: a subject cannot write to a higher level. "No writes up" is the Biba star integrity rule; Bell-LaPadula's star rule is "no writes down." Biba matches.

Point 2: a subject cannot read from a lower level. "No reads down" is the Biba simple integrity rule; Bell-LaPadula's simple rule is "no reads up." Biba matches again.

Point 3: a subject cannot request service of a higher integrity level. This is the invocation restriction — a low-integrity subject must not execute or request service from a higher-integrity one, because the lower one could corrupt the higher one's work. Again Biba.

Conclusion: the slide describes the Biba model. All three restrictions point the same direction — untrusted data and untrusted processes must never contaminate trusted ones — which is the Biba signature.

Sense-check: each of the three points violates the "don't pollute the clean room" principle, and the model built on that principle is Biba, so the identification is consistent.

This is the second assignment: decide which model the slide refers to, and justify with the rules.

6.3.8 Exam Note: Scenario Questions on the Models

These models matter from the concept perspective. In examinations, expect scenario questions: a subject with a given label performs given operations to achieve confidentiality or integrity — decide what is correct, or what the ideal operations are. That is the level the questions are asked at; beyond the three rules of each model there is not much depth needed. Know that Bell-LaPadula supports confidentiality and Biba supports integrity. Integrity is achieved when the accuracy of received data can be confirmed: the lower level cannot be trusted, the same level and above are fine. Remember which of the three rules governs read, which governs write, and which governs both.

Exam note: keep the two rule trios side by side — Bell-LaPadula: no reads up, no writes down, strong star locks one level; Biba: no reads down, no writes up, strong star locks one level. The exam asks which model matches a described scenario, so practice by converting each described operation into a rule name and a direction.

Real-world connection: Biba-style integrity levels appear in practice where data trustworthiness must be enforced mechanically. Multilevel-secure operating systems (for example, FreeBSD's Biba implementation) grade processes and files and refuse operations that would let untrusted data pollute trusted data — the same clean-room rule. Biba's weakness with covert channels is also a live issue: real attackers use timing and side channels to move data across security boundaries in ways label rules never see.

6.4 Lipner Integrity Matrix

6.4.1 Why Another Integrity Model

Bell-LaPadula supports confidentiality; Biba supports integrity; but both depend on data classification and data labeling. The Lipner integrity matrix is the next model, built for situations that need integrity beyond labels. During its development, the requirements that emerged: users will not be able to write their own programs but will use existing production programs or databases; programmers will develop and test on a non-production system; if they need actual data, they are given production data through a special process, used on their own development system; a special process must be followed to install a program from development to production — the process must be controlled and audited; and managers and auditors must have access to both the system state and the logs that have been generated. The Lipner integrity matrix uses three concepts to meet those requirements: separation of duties, separation of functions, and auditing.

Hook: A label can say who may touch data — but labels cannot stop a developer from testing their own buggy code directly on the production database. Commercial systems need process controls, not just label controls: who writes code, who tests it, who moves it to production, and who checks the logs. That is the gap the Lipner model fills.

Formalize — the five commercial requirements. Lipner started from five requirements that real commercial environments impose:

Users will not write their own programs; they use existing production programs and databases.
Programmers develop and test on a non-production system; if they need real data, they receive production data through a special process and use it on their development system.
A special process must be followed to install a program from the development system onto the production system.
That special process must be controlled and audited.
Managers and auditors must have access to both the system state and the system logs.

Requirements 1–4 are about keeping development separate from production; requirement 5 is about oversight. Labels alone cannot express "who may install this program" or "was this installation audited" — those are questions about process, and the three Lipner concepts answer them.

The Lipner integrity matrix uses three concepts to meet those requirements: separation of duties, separation of functions, and auditing. Each concept covers one family of the requirements above, and the three together convert the five requirements into enforceable behavior.

6.4.2 Separation of Duties

Separation of duties means: if two or more steps are required to perform a critical function, at least two separate persons should perform the steps — the four-eyes principle, where one person reviews and another person approves. Moving a program from development to production is the classic example. In organizations this shows up as segregation of duties: the development team, the testing team, the pre-production team, and the support team all have defined roles — who writes the code, who tests it, who migrates it from the development environment to production, and whether the migration takes code directly from the developer or from the source code repository. The intention behind all this role separation: the code that finally moves to production must be the code that has been tested and integrated with the rest of the modules successfully. That is how the segregation protects the integrity of the code.

Formalize — the principle. If two or more steps are required to perform a critical function, at least two different people should perform those steps. In the four-eyes form: one person reviews, another person approves. The requirement is about persons, not roles — one person holding two roles still violates the principle, because that single person controls both steps.

Why two people? If the developer who wrote a program is also the person who certifies it, a buggy or malicious assumption in the code passes unnoticed — the developer sees the code the way they intended it, not the way it behaves. A separate certifier catches the error because they read the code without the author's blind spot. And if the developer genuinely wants to corrupt production data, a single dishonest person is enough only when there is no separation: with two people, both must collude.

Separation of duties in a real organization: the development team writes the code, the testing team validates it, the pre-production team rehearses the deployment, and the support team runs the production system. The migration step asks its own question: does the code move directly from the developer's machine, or from the source code repository — the tested, integrated version? Production must receive the tested version, and the separation of roles is what makes that enforceable. The code that finally moves to production must be the code that has been tested and integrated with the rest of the modules successfully.

6.4.3 Separation of Functions and the Small-Company Problem

Separation of functions: the same person should not perform two or more different functions in the same system. A developer who is also the tester and also the one who deploys code to production creates most of the issues. This is practically possible in big organizations with large human resources — but what about a ten-employee company? You cannot have a separate development team, a separate testing team, and a separate production deployment team. You still want to achieve integrity while the same one person does everything. Question to the class: with no separation of functions possible, what compensating controls can you deploy — with existing resources, no hiring — so the risk of one person doing everything is minimized and integrity is achieved? List three compensating controls. These controls are needed when roles cannot be separated: process gates, review checklists, or external approvals that do not add people.

Formalize — separation of duties vs separation of functions. The two concepts look alike but protect different seams:

Separation of duties: different people perform the different steps of one critical process (write, then certify, then install).
Separation of functions: one person does not perform two or more different functions in the same system (developer, tester, and deployer all in one person).

In a big organization both are achievable with staff. The small-company problem: with ten employees there may be exactly one person who can write, test, and deploy code. Separation is structurally impossible, yet the integrity goal remains — so compensating controls must fill the gap.

The small-company problem — three compensating controls. When roles cannot be separated and no hiring is possible, the risk of one person doing everything must be reduced by other means. Three classes of compensating controls that do not add people:

Process gates — force the workflow through checkpoints that one person cannot skip: the change must pass through a defined release checklist, an approval step in a ticket system, or a freeze window before deployment.
Review checklists and recorded evidence — require the developer-tester-deployer to produce artifacts (test results, sign-off logs) that make their own work reviewable later, so errors surface at audit time even without a second pair of eyes.
External approvals or periodic audits — a senior manager, the owner, or an external auditor reviews and approves critical releases; the review is a separate step in time even if the same person executed the work, and audit logs provide accountability.

The point of the exercise: integrity is achieved through controls, and when one control dimension (separation) is unavailable, the others (gates, evidence, review) must compensate.

6.4.4 Auditing and Logs

The third concept is auditing: logs and locks determine who has performed which actions and when, which gives accountability and supports recovery — if the deployed code fails, a change reversal brings back the previous version of the code. These three controls — separation of duties, separation of functions, and auditing — are how the Lipner model fulfills the production-program requirements.

Intuition — the audit trail as the memory of the system. Separation of duties and functions reduce the chance of a bad change; auditing covers the case where a bad change happens anyway. Logs record who did what and when; if the deployed code fails, the logs point at the responsible step and a change reversal restores the previous version. Auditing is in some ways external to the model — it does not stop actions, it records them — but without it, neither accountability nor recovery is possible.

The three concepts map onto the five requirements: separation of duties and functions satisfy requirements 1–3 (users use production programs only; programmers stay on non-production systems; installation follows a special process), the controlled-and-audited process satisfies requirement 4, and auditing plus manager/auditor access to logs and system state satisfies requirement 5. The model also assigns security levels and categories to users and objects — for example, ordinary users at system low, and managers and auditors at the audit-manager level — arranged in the matrix layout that gives the model its name.

6.4.5 Q&A: Why Is It Called a Matrix?

Q: Why is this model named a matrix? Where is the matrix in it? A: Like an access control matrix, where you have a two-by-two or two-by-four table listing users and their privilege levels. The earlier topics classify subjects, their level of access, and the level of data they can fetch from the system — that arrangement of users against levels is the matrix. One axis holds the users (ordinary user, developer, tester, manager, auditor, system controller), and the other axis holds the levels and categories of data they may reach; each cell records the access allowed for that user at that level.

Visual intuition: draw a table with users as rows and privilege levels as columns. The cell where a user's row meets a level's column is either checked (access allowed) or empty (no access). Every user gets a clearance — a set of levels they may reach — and every object gets a classification; the grid of users against levels is the matrix the name refers to.

Recap + bridge: Lipner adds process control where labels alone fail: separation of duties (different people for different steps), separation of functions (one person does not do everything), and auditing (logs + recovery). The small-company scenario shows the principles in action under constraint. The next model — Clark-Wilson — pushes the idea further: not just who does the steps, but that every change happens through a controlled program.

Real-world connection: the dev-to-prod release pipeline of any modern software company is a Lipner-shaped process: developers cannot push straight to production, changes pass through test and pre-production environments, deployments require approval, and every release is logged. The four-eyes principle shows up in banks (two signatories), in code review (reviewer + author), and in change-management boards. Small organizations that cannot staff separate teams implement exactly the compensating controls above — checklists, approval gates, and external audits.

6.5 Clark-Wilson Model

6.5.1 Subject, Program, Object: The Triple Relationship

Clark-Wilson also supports data integrity, but with a different mechanism. Biba is a state machine model; Clark-Wilson allows data modification only through a controlled intermediate program or interface. It does not use the traditional lattice structure at all; instead it uses a three-party relationship: a subject requests a change in an object, but the change cannot happen directly — it happens through a program. Subject, program, object: this is why it is called a triple access control triplet. Subjects never have direct access to objects; objects can be accessed only through programs. To protect integrity, the model says, deploy two principles: well-formed transactions and separation of duties.

Hook: Biba says who may touch data (by label). Clark-Wilson asks a different question: through what may data be touched? If every change to a bank account must pass through a program that enforces the rules of accounting, then even a legitimate user cannot perform an illegitimate change — the program simply refuses. That is the idea that replaces labels with programs.

Formalize — the triple relationship. The model's core structure is the triplet (subject, program, object):

a subject (a person or process) requests a change,
the change is carried out by a program (an interface, an access portal, a transformation procedure),
the object (the data) is modified only by that program.

A subject never touches an object directly. If the subject tries an operation the program does not support, the program blocks it. Every access is filtered through the program, so the program's rules become the integrity policy. This replaces the lattice structure of Biba: instead of comparing labels, the model checks the program.

The two principles complete the design: well-formed transactions guarantee that every change is a complete, consistent series of operations, and separation of duties guarantees that the people involved cannot collude to abuse the programs. The rest of this section works out both principles, then names the model's technical vocabulary (CDI, IVP, TP).

6.5.2 Well-Formed Transactions

Well-formed transactions take the form of programs: a subject can access an object only by using a program, an interface, or an access portal, and each program has limitations on what it can and cannot do to an object such as a database. In simple terms, a well-formed transaction is a complete series of operations — transitions from one state to another. Only when the entire series of operations has been completed can the transaction be tagged as well-formed; if anything is pending in between, the data is inconsistent, and inconsistency leads to compromised integrity.

Formalize — consistency and well-formedness. A system's data is in a consistent state when it satisfies the properties the system requires. For a bank, a standard consistency property ties today's activity to yesterday's balances. Let $D$ be the amount deposited so far today, $W$ the amount withdrawn so far today, $Y B$ the amount in all accounts at the end of yesterday, and $T B$ the amount in all accounts so far today. Then consistency requires:

$D + Y B - W = T B$

A well-formed transaction is a series of operations that takes the system from one consistent state to another consistent state. Individual operations inside the transaction may leave the data temporarily inconsistent — the rule is that the transaction as a whole preserves consistency.

Worked example — the money transfer.

Setup: a depositor transfers ₹10,000 from account A to account B. The transaction consists of two operations: a deduction from account A and an addition to account B.

Trace with real numbers: before the transfer, A holds ₹50,000 and B holds ₹20,000 (total ₹70,000 — consistent). Operation 1 debits A: A = ₹40,000, B = ₹20,000 (total ₹60,000 — temporarily inconsistent, the ₹10,000 is "missing"). Operation 2 credits B: A = ₹40,000, B = ₹30,000 (total ₹70,000 — consistent again).

Check: each single operation left the data in an inconsistent state, but the complete transaction preserved consistency: the total before equals the total after. The transaction is well formed.

Sense-check: if the transfer had stopped after operation 1 — debited but not credited — the total would stay at ₹60,000 and the ledger would not balance; that is not a well-formed transaction, and the model refuses to call it complete.

The key sentence to remember: only when debited and credited together does the model say consistency is preserved and integrity achieved. A transaction that ends part-way through is not well formed, and the system must roll back or complete it — never leave it hanging.

6.5.3 Separation of Duties in Clark-Wilson

The second feature relevant to the integrity policy: the integrity of the transactions themselves — who examines and certifies that transactions are performed correctly? The invoice process needs separate people for the payment steps.

Worked example — paying an invoice needs separate people.

Setup: a company receives an invoice, and the purchasing office requires several steps to pay for it: (1) someone must have requested a service and determined the account that would pay for that service; (2) someone must validate the invoice — was it right or not; (3) the account authorized to pay for the service must be debited; (4) the check must be written and signed.

If one person performs all four steps: that person could easily pay phony invoices — request the service, approve the request, validate the fake invoice, and sign the check, all alone.

If at least two different people perform the steps: paying a phony invoice now requires both to conspire to defraud the company. The probability of fraud drops sharply, and an accidental error in one step is more likely to be caught by the other person's review.

Sense-check: the control works by raising the cost of dishonesty — two honest people are needed to authorize a fraudulent payment, and the principle is separation of duty.

The effect of separation of duty is to limit the capabilities of the subject: on any portal, a user-level access differs from an admin-level access, which differs from a manager-level access. If the program is properly designed, the triple relationship provides a means to protect the integrity of the object.

6.5.4 Terminology: CDI, IVP, and Transformation Procedures

Some terminology is defined in the model. A constrained data item (CDI) is data whose integrity is protected by the security model — protected by Biba or any other model that guards integrity. Data that has not been validated — any input that has not been validated, or any output — is an unconstrained data item. Once input is provided, some verification must ensure it conforms to integrity: an integrity verification procedure (IVP) scans the data items and confirms their integrity. Think of a web form: you define what the user may enter — alphabets or numbers only — as data input validation; the IVP is the list of procedures that perform the same checking. A transformation procedure (TP) is the only kind of procedure allowed to modify a CDI, so the constrained data item is modified only through transformation procedures. In a restricted database, only defined procedures can modify the data; for example, when an API modifies data during a transaction on a payment app, the ledger entries change — the app defines how, when, and who is allowed to modify data classified as constrained. Limited access to the CDI through transformation procedures forms the backbone: you whitelist the list of APIs or requests that can modify the data inside the protected database. That restricting of access to the constrained data item is the backbone of the Clark-Wilson integrity model.

Formalize — the vocabulary.

Constrained data item (CDI): data whose integrity the model protects. In a bank, account balances are CDIs — their integrity is critical to the bank's operation.
Unconstrained data item (UDI): data not subject to the integrity controls. In the same bank, the gift an account holder chose when opening the account is a UDI — its integrity is not critical.
Integrity verification procedure (IVP): a procedure that checks that CDIs satisfy the integrity constraints — a validation rule, like "the web form accepts alphabets or numbers only."
Transformation procedure (TP): the only kind of procedure allowed to change a CDI — deposit, withdraw, transfer, or an API that updates the ledger.

The central rule: a CDI is modified only through transformation procedures. The set of TPs is whitelisted in advance, so the data inside the protected database can only change in ways the whitelist defines.

The reference formalization adds certification and enforcement rules that make the model complete. Certification rules (set by a security officer, external to the system) include: an IVP must verify that all CDIs are in a valid state; a TP must transform valid states into valid states; certified relations must respect separation of duty; TPs must log enough information to reconstruct operations; and a TP taking a UDI as input may perform only valid transformations. Enforcement rules (built into the system) include: only TPs certified for a CDI may manipulate it; a user must be associated with each TP and CDI set it touches; and the system must authenticate every user executing a TP. The two families differ in an important way: certification is a human judgment (is this procedure correct?), while enforcement is a machine guarantee (only certified procedures run).

6.5.5 Restriction Interface and Real-World Examples

Clark-Wilson uses labels to grant access to subjects — but only to the transformation procedures. The restriction interface model uses classification-based restrictions to offer only subject-specific authorized information and functions: one subject at one classification level sees one set of data and has one set of functions; a subject at a different level sees a different set.

Worked example — credit card agents see only the last four digits.

Setup: on a credit card toll-free number, an agent looks up a customer's card. The full card number has sixteen digits; the agent's access level allows viewing only the last four.

Behavior: the agent sees •••• •••• •••• 1234 — enough to identify the card in conversation, not enough to use the card for fraud. The card owner, at a higher access level, can see more data and more functions.

Sense-check: the interface restricts both what is shown (data) and what can be done (functions), so even a legitimate agent's session cannot leak the full number — the restriction is enforced by the program, not by the agent's honesty.

Real-world — Workday: a business user can see the number of leaves, apply for leave, apply for resignation — but cannot approve leave or see the CTC; the manager can approve or reject and see the CTC; the Workday admin has full access; a manager of one team can access only the data related to his team, not other managers' teams. The different functions may be implemented either by showing all functions to all users and disabling the unauthorized ones — you see the icons, greyed out — or by showing only the functions granted to a specific user. Through these mechanisms Clark-Wilson ensures data is protected from unauthorized changes by any user; in effect it enforces separation of duties, and it is the most common model in the commercial applications we use daily. The access control triplet — subject, object, and the intermediary interface program limiting what can be done — can just as easily be programmed to limit what objects are shown to a subject, so the concept can also protect confidentiality.

Worked example — the ATM withdrawal that debits without dispensing.

Setup: a customer withdraws money from an ATM. The withdrawal is a transaction made of a series of operations — say four: authenticate, check balance, debit the account, dispense cash.

Failure: the machine debits the amount, but the cash drawer jams — the money is not dispensed. Yet the message says the delivery was successful.

Check: the transaction's series of operations did not complete: one of the four steps failed. The whole thing is not a well-formed transaction, so the banking system rolls it back — the debit is reversed — and the data stays consistent.

Sense-check: the failure shows the well-formed rule in action: a partial series of operations must not be accepted as a transaction, because accepting it would leave the ledger inconsistent (money deducted that was never paid out). Rollback restores the consistent state, which is how the banking system achieves the integrity of the data.

Q: How does a banking transaction at an ATM map to well-formed transactions? A: An ATM withdrawal that debits without dispensing money shows a failed series of operations. The transaction is a series of steps, say four; if any one of the four has failed, the whole thing is not a well-formed transaction, so the banking system rolls it back and the data stays consistent. The amount debited without the money being dispensed is the canonical example of a transaction that is not well formed.

6.5.6 Summary of Integrity Models

The models so far for integrity: the Biba model, the Lipner integrity matrix, and the Clark-Wilson model. The remaining piece — trusted models such as the TCB (trusted computing base) and the availability policy — is postponed to the next session.

Recap + bridge: three integrity models, three different answers to "how do we keep data accurate?" Biba says: keep untrusted data away by label rules (no reads down, no writes up). Lipner says: control the process around data — separation of duties, separation of functions, auditing. Clark-Wilson says: put a program between every subject and every object, require well-formed transactions and separation of duty, and whitelist the transformation procedures. The next session extends the picture with trusted computing bases and availability policies.

Real-world connection: payment apps such as PhonePe and Google Pay change ledger entries only through whitelisted APIs — transformation procedures protecting constrained data items; a failed payment is rolled back exactly like the ATM example. Enterprise platforms such as Workday implement the restriction interface with role-based views, and banks run well-formed transactions on every ledger. Clark-Wilson is the most common integrity model in commercial applications used daily — the account balances, the payments, and the employee records are all CDIs behind TPs.

6.6 Introduction to Networks: Addressing Basics

6.6.1 What a Network Is

A network connects different systems together for the exchange of information — data, emails, whatever we want to exchange — using wired or wireless methods. In any exchange there are two machines: the source, which sends the data, and the receiver, which receives it. The network basics discussion starts with identifying a source machine: how do we know which machine is the sender? By its IP address and by its MAC address. Before the slides, the goal was to clear the basics of networking first.

Hook: When a message arrives at a server, how does anyone know which machine sent it? The surprising answer is that every machine carries two different addresses — one fixed at the factory (MAC) and one assigned by the network (IP) — and the two solve completely different problems.

Visual intuition: picture a letter in the postal system. The envelope needs both a street address (where in the city the house is) and the house's identity (who actually receives it). Networks need the same pair: one address that describes the machine's place in the network (IP) and one that identifies the machine itself (MAC). Both are needed because a machine can change place without changing identity, and the same place can be reached by different machines at different times.

6.6.2 Q&A: How Do You Identify a Source in a Network?

Q: How can we identify a source machine in a network? What is it called? A: By its IP address and by its MAC address. Several students answered firewall, packet capture, network scanning tools, or server logs too, but those do not identify the machine — they observe traffic or filter it, they do not name the sender. Two corrections on the wording: the correct term is IP address, not "up address"; and the correct term is MAC address, not "IAM address".

The vocabulary correction matters for exams: the term is IP address (Internet Protocol address) and MAC address (media access control address). Devices like firewalls and tools like packet captures tell you a machine is communicating, but the only things that name the source machine are its two addresses.

6.6.3 Q&A: Why Two Addresses for One Machine?

Q: Why does one machine need two addresses — a MAC and an IP? Would one name not be enough? A: The two serve different scopes. MAC stands for media access control; it is the physical address — static, bound to the network card at manufacture — and it is enough for communication within the LAN: within your local area network, the MAC address is enough. The IP address is the logical address; it is dynamic and network-specific, and you need it when communication crosses two different networks. MAC for the local network, IP for across networks.

MAC is enough inside the LAN, while IP is needed across networks. The intuition: inside your house, calling a family member by name works; to reach someone in another city, you need their address. A MAC address never changes — it is burned into the network card — so it is perfect for naming a machine inside the local network. An IP address changes as the machine moves between networks, which is exactly what an internet-scale addressing system needs: the address describes where the machine is, not just what it is.

6.6.4 Q&A: When Are Two Networks Different?

Q: When do we say two networks are different? A: When the network IDs are different — in IP terms, when the IP values themselves are different. That is why the class A, class B, class C, class D classification exists: it identifies networks by how many systems they hold within the LAN. You may hear the 192.168 series mentioned; that is a private range, discussed below.

An IP address is not a single number: part of it names the network, and the rest names the machine inside that network. Two machines belong to the same network when the network part of their addresses matches; they belong to different networks when the network parts differ. The class system below decides how the split between network part and host part is made.

6.6.5 IPv4 Addresses, Exhaustion, and Public vs Private

An IPv4 address has the form A dot B dot C dot D — four octets, each octet 8 bits, so 32 bits in total:

$32 = 4 \times 8$

An octet (a group of 8 bits) can hold 256 values, from 0 to 255, so each of the four parts of an address lies between 0 and 255. The full IPv4 range runs from 0.0.0.0 (all zeros) to 255.255.255.255 (all ones). The IPv4 address space holds $2^{32}$ — two to the power 32 — addresses:

$2^{32} = 4, 294, 967, 296 \approx 4.3 billion$

and the lecture's version extends IPv6 to $2^{64}$ (two to the power 64). The standard form, from the reference material, is even larger: IPv6 uses 128-bit addresses, so its address space is $2^{128}$ — a number so large that running out is not a practical concern. Whichever form you use, the point stands: IPv6 is astronomically larger than IPv4.

Formalize — the structure of an IPv4 address. An IPv4 address is four octets written in dotted decimal notation:

$8 bits A . 8 bits B . 8 bits C . 8 bits D total: 4 \times 8 = 32 bits$

Each octet independently spans 0 to 255, so a part like 256 or −1 is invalid. Every symbol is defined: A, B, C, D are the four octets; each is 8 bits; together they make the 32-bit address that the whole internet uses to find a machine.

The problem: the number of systems connected to the internet is far larger than $2^{32}$ — think of companies with hundreds of thousands of employees, each with a PC. Service providers cannot assign a unique address to every connected system. The technique: public and private addresses solve the shortage. A public IP address is assigned by the ISP — the internet service provider. A private IP address circulates inside the LAN: when machines communicate within the LAN they use private addresses, and the LAN as a whole presents one public address to the internet.

Intuition — the office-building analogy. Private IP addresses are like office numbers: 305 must be unique inside the building, but another building may also have a 305 — the two never collide because they live in different buildings. Public IP addresses are like postal addresses: they must be unique worldwide, because a letter must find one specific building on the planet. Inside your network you talk to others with private addresses; to reach the outside world, your gateway uses the building's public address.

Worked example — why companies exhausted the IPv4 space.

Setup: a company has hundreds of thousands of PCs, and every one of them needs to reach the internet.

The arithmetic problem: the whole IPv4 space holds about 4.3 billion addresses — and that must cover every device on the planet: phones, laptops, servers, routers, printers, smart TVs. A single large company with hundreds of thousands of PCs cannot even hope to reserve a unique public address per machine.

The solution in practice: the company assigns each PC a private address from the reserved ranges, and the whole LAN reaches the internet through one public address, translated at the gateway router (network address translation, NAT — the gateway rewrites the outgoing packet's source to its own public address and remembers which private machine each connection belongs to).

Sense-check: millions of private machines share far fewer public addresses, so the $2^{32}$ space serves far more than 4.3 billion devices — the shortage is solved without shrinking the network.

6.6.6 IP Classes and the Private Ranges

The four octets of an address split into two parts: the network ID, which identifies the network, and the host ID, which identifies the machine in that network. Take 10.2.1.1: some octets identify the network, the rest identify the system. The network administrator picks the class by the number of systems in the LAN.

Formalize — the classes and the network/host split.

Class A: the first octet is the network ID and the remaining three octets identify hosts. The private range reserved by IANA (the Internet Assigned Numbers Authority — the body that assigns these ranges) is 10.0.0.0 to 10.255.255.255. Class A fits the largest organizations.
Class B: the first two octets are the network ID; two octets remain for hosts. The private range is the 172.16 series — 172.16.0.0 to 172.31.255.255. Class B fits large corporate and government networks.
Class C: the first three octets are the network ID; one octet remains for hosts. The private range is the 192.168 series — 192.168.0.0 to 192.168.255.255. Class C fits the smallest networks and is the range home routers use.

IANA has published these private ranges so all organizations use the same reserved blocks; the reference table also adds class D (224–247, reserved for multicasting) and class E (248–255, reserved for experimental use), and notes that 127.x.x.x is reserved for loopback testing (127.0.0.1 is the machine itself).

Each octet is 8 bits, so three host octets give $255 \times 255 \times 255 = 16, 581, 375$ combinations — which is why class A fits large organizations. The lecture's version is $255 \times 255 \times 255$ (each host octet capped at 255); the standard arithmetic is a touch different: each octet can actually hold 256 values (0 through 255), so three host octets give $25 6^{3} = 16, 777, 216$ theoretical combinations, and subtracting the two reserved addresses — the network address and the broadcast address — leaves 16,777,214 usable host addresses.

Worked example — how many machines fit in a class A network?

Setup: class A uses the first octet as the network ID and the remaining three octets as the host ID.

Count the host combinations — professor's version: three host octets, each contributing 255 values:

$255 \times 255 \times 255 = 16, 581, 375 combinations$

Standard form: each octet holds 256 values (0 to 255), and the all-zeros and all-ones addresses are reserved (network address and broadcast address):

$25 6^{3} - 2 = 16, 777, 214 usable host addresses$

Interpretation: either way, a single class A network can hold about 16.6–16.8 million machines — large enough for the biggest organizations, which is exactly why class A was designed for them.

Sense-check: the count of host combinations rises with the number of host octets — three octets give millions of combinations, two give tens of thousands, one gives hundreds — which matches the class sizes below.

For class B, the lecture's version stated two power eight; the standard form is different because class B keeps two host octets — two octets of 8 bits each, for 16 host bits:

$2^{16} = 65, 536 addresses per class B network$

(with the two reserved addresses deducted, 65,534 usable). Class C keeps one host octet, giving $2^{8} = 256$ addresses per class C network (254 usable after the same deduction). The class choice is a size decision: pick the class whose host capacity matches the LAN's machine count.

Pitfalls:

Treating 255 as the only allowed octet value. Every octet can be anything from 0 to 255; the number 255 is simply the maximum (all eight bits set). An address like 10.2.1.1 is perfectly normal.
Forgetting the two reserved addresses. In every network, the all-zero and all-ones host addresses are set aside for the network itself and for broadcast, so usable hosts are $2^{host bits} - 2$ , not $2^{host bits}$ .
Confusing the class ranges. Class A starts at 10, class B at 172.16, class C at 192.168 for the private ranges — and the exam asks for exactly these three.
Thinking one octet count fits all classes. The network/host split changes with the class: one network octet in class A, two in class B, three in class C — the class is chosen by the number of systems in the LAN.
Mixing up network ID and host ID. Two machines are on the same network when their network IDs match; the host ID is what distinguishes one machine from another within that network.

Exam note: know the private ranges — 10.x, 172.16.x, 192.168.x — and which class fits which size of LAN. Expect questions that give an address and ask for its class, or that ask which private range a home router uses (192.168.x is the everyday one).

Recap + bridge: every machine is named twice — MAC (physical, fixed, works inside the LAN) and IP (logical, dynamic, works across networks); IPv4 is four octets, 32 bits, $2^{32}$ addresses; the private ranges 10.x, 172.16.x, 192.168.x plus public addresses assigned by ISPs solve the shortage. Next comes the hardware that moves data between these machines: hubs, switches, routers — and the routing that picks the path.

Real-world connection: every home and office network is a live example — the router's LAN side hands out private addresses from 192.168.x (or 10.x), and its WAN side holds the single public address assigned by the ISP. Internet service providers and IANA administer the public space; a failure in the address plan (two machines with the same IP in one LAN) is one of the most common real-world network faults.

6.7 Network Devices, Topologies, and Routing

6.7.1 Traffic Patterns and Topologies

Three traffic patterns: unicast is one-to-one communication; multicast is one-to-a-group — an HR manager with a team of ten wants to share a job drive only with the HR department, that is multicast; broadcast is one-to-all — the same HR manager wants to share with all employees, that is broadcast. Topology means the way the systems are connected — the diagrammatic arrangement: bus, star, tree, single ring, dual ring, or mesh. The choice depends on the number of systems and the requirement. Mesh topology is used when high availability matters: if one link goes down, alternative links still reach the other node. Ring topologies — single or dual ring — serve fault tolerance and redundancy; the dual-ring concept appears in FDDI, the fiber distributed data interface.

Hook: How does one machine decide who receives a message — one person, a whole team, or everyone in the building? And when the machine does reach out, which cables carry the message? The answers — unicast/multicast/broadcast for the first, topology for the second — set the stage for the devices that do the forwarding.

Formalize — traffic patterns and topologies.

Traffic patterns (who receives):

Unicast — one sender, one receiver: a student downloads a file from a server. The normal case in daily networking.
Multicast — one sender, a group: the HR manager shares a job drive only with the ten-member HR department. Only members of the group receive the data.
Broadcast — one sender, everyone: the same manager shares with all employees. Every machine on the network sees the data.

Topologies (how the machines are wired):

Bus — all machines share one cable; simple but a single cable fault can split the network.
Star — every machine connects to a central device; the common home/office layout.
Tree — stars connected hierarchically; scales to larger buildings and campuses.
Single ring — machines form a loop; data travels around the ring.
Dual ring — two counter-rotating rings; if one breaks, traffic switches to the other — fault tolerance.
Mesh — every node has multiple links to other nodes; if one link goes down, alternative links still reach the other node — used when high availability matters.

The choice depends on the number of systems and the requirement: mesh when availability is critical, dual ring for redundancy (the dual-ring concept appears in FDDI, the fiber distributed data interface), star for ordinary offices.

6.7.2 Q&A: Switch vs Router

Q: When do we use a switch and when do we use a router? Are both the same? A: Switches connect devices within a single network — your LAN; routers connect multiple networks and route data between the LANs. Switch for the devices inside the LAN, router for joining two different networks or reaching the internet. A layer 3 switch has switching capability and routing capability, so yes, a layer 3 switch can connect to the internet.

The two devices are often drawn identically in diagrams, which is why the question comes up. The division of labor: the switch keeps one network talking to itself efficiently; the router connects that network to other networks — and to the internet. The layer 3 switch blurs the line by adding routing capability to a switch, which is why it can take over the router's job in a LAN.

6.7.3 The Device Chain: Hub, Bridge, Switch, Router, Gateway

To connect systems you need connecting devices, typically in a chain: hub, then switch, then router — and the last device in the router chain is the gateway. The hub is the first device and it is completely unintelligent — plug and play, no table, no references: whatever comes in, it throws to all the systems connected in the network. The bridge performs almost the same operation as a switch; when a big LAN needs connecting, you go for bridges. The switch keeps a MAC address table: each port connects by an Ethernet cable; when a frame enters a port, the switch looks up the destination MAC address in its table and switches the frame out of the correct port — switching, not routing, from one port to another. The router does both: it switches and it routes the packet to the destination along the best available path. Naming of data: at layer 1 the data is bits and bytes, at layer 2 it is frames — the Q&A below fixes the term.

Formalize — the device chain, from dumb to intelligent.

Hub — completely unintelligent: whatever comes in, it throws to all the systems connected in the network. No table, no references, plug and play. Every packet is copied to every port, wasting bandwidth.
Bridge — performs almost the same operation as a switch; used when a big LAN needs connecting.
Switch — keeps a MAC address table: each port connects by an Ethernet cable; when a frame enters a port, the switch looks up the destination MAC address in its table and switches the frame out of the correct port — switching, not routing, from one port to another.
Router — does both: it switches and it routes the packet to the destination along the best available path. Routers are programmable and can choose paths by policy.
Gateway — the last device in the router chain: the exit point from the LAN to the outside world, where private addresses meet public ones.

Data naming by layer: at layer 1 the data is bits and bytes; at layer 2 it is frames; the term packet is reserved for the network layer.

Pitfalls:

Calling layer-2 data a packet. Layer 1 carries bits and bytes, layer 2 carries frames, and only layer 3 (the network layer) carries packets. The exam may ask for the exact term.
Treating hub and switch as the same. A hub floods everything to every port; a switch learns MAC addresses and forwards only to the right port. A "hub" sold today is usually really a switch.
Using a switch to join two networks. A switch works inside one network; joining networks is the router's job.
Forgetting the gateway's role. The gateway is the LAN's door to other networks — without it, private addresses never reach the internet.

Q: At layer two, should we call the data a packet? What is the correct term? A: Frame. Layer 1 carries bits and bytes; layer 2 carries frames; packet is the term used at the network layer. Layer 1 is the physical medium — the cable and the signals — where data moves as individual bits and bytes; the frame is the unit that carries the MAC addresses between devices on the same network.

6.7.4 Routing: Static and Dynamic Protocols

Routing is the router's intelligence: when a packet enters the router interface, the router finds out where the packet wants to reach and picks the best path. Real-world: a drive from one campus to another has four possible paths — via one junction, via another station route, via the ring road, or a fourth option. The choice of the best path is decided by a metric, and the routing protocols pick the best path using a metric — a protocol being a predefined way an operation is performed. Static routing: the administrator designs the path himself; it is predefined, and the packet follows the same route even when traffic is heavy or absent. As the number of systems grows, managing static routes gets hard, so dynamic routing protocols appeared: they change according to the scenario — what is happening in the network traffic. The first dynamic protocol was RIP — the routing information protocol, versions 1 and 2 — using hop count as its metric: from source A to destination D, count how many routers the packet must cross, and the path with fewer routers wins. The drawback of RIP v1 and v2: when the number of routers exceeds 15 or 16, the protocol no longer supports the route. Later protocols — IGRP, EIGRP, OSPF, BGP — use different metrics: one follows availability, another follows bandwidth. The routing engine consults the entries in the routing table and, based on source and destination, routes the packets. This background was context-setting only; the routing detail is not in the syllabus.

Worked example — the drive between two campuses.

Setup: a drive from one campus to another has four possible paths — via one junction, via another station route, via the ring road, or a fourth option. Think of the router as the driver and each path as a sequence of intermediate routers.

The decision: the driver picks the best path by a metric. With hop count as the metric, the best path is the one crossing the fewest routers: path 1 via the junction crosses 3 routers, path 2 via the station crosses 4, path 3 via the ring road crosses 5, path 4 crosses 6. The router chooses path 1 — fewest hops.

With a different metric: if the metric is bandwidth or availability, the fewest-hops path may lose: a 3-hop path over a congested link can be slower than a 5-hop path over fiber. The metric defines what "best" means.

Sense-check: the router's choice is the outcome of the metric, not a guess — change the metric and the chosen path changes, which is exactly how routing protocols behave.

Formalize — static vs dynamic routing.

Static routing: the administrator designs the path himself; the route is predefined and the packet follows the same route even when traffic is heavy or absent. Simple and predictable, but managing static routes gets hard as the number of systems grows.
Dynamic routing: routing protocols choose and update paths automatically according to what is happening in the network traffic.

The first dynamic protocol was RIP — the routing information protocol, versions 1 and 2 — using hop count as its metric: from source A to destination D, count how many routers the packet must cross, and the path with fewer routers wins. A route with 4 hops is better than one with 7 hops. RIP's drawback: when the number of routers exceeds 15 or 16, the protocol no longer supports the route — the hop count ceiling stops it from scaling to large networks. Later protocols — IGRP, EIGRP, OSPF, BGP — use different metrics: one follows availability, another follows bandwidth.

How a router works internally: the routing engine consults the entries in the routing table and, based on source and destination, routes the packets. The routing table is the router's map: each entry pairs a destination with the interface and next-hop to use. Dynamic protocols build and update this table automatically; static configuration fills it by hand.

Scope: this routing material is context-setting only — the routing detail is not in the syllabus. Know the idea (metrics decide paths, RIP uses hop count, RIP stops working beyond 15–16 routers), but do not expect deep routing questions on the exam.

6.7.5 Cables, NIC, and Wireless

Physical connection uses cables: UTP — unshielded twisted pair — or STP — shielded twisted pair — with speeds improving across generations. The machine side connects through the NIC — the network interface card, also called the Ethernet card or network adapter card — where the MAC address is bound at manufacture. MAC address size: $48$ bits, or $6$ bytes:

$48 bits = 6 bytes since 48 = 6 \times 8$

Part of those 48 bits references the manufacturer of the network interface card — the organizationally unique identifier (OUI), the first 24 bits, is assigned to the maker — and the rest identifies the specific card.

Q: What is the size of a MAC address? A: 48 bits — 6 bytes. The 48 bits reference the manufacturer of the network interface card and identify the specific card: the first 24 bits name the manufacturer and the remaining 24 bits name the individual card, which is why every NIC in the world gets a unique address.

Real-world: wireless access works through access points or base stations — on mobile networks the BTS, the base transmission station (mobile transmission station). Generations of wireless standards follow the 802.11 series — 802.11a, 802.11g, 802.11h — with increasing speeds; you connect to an access point using security methods such as WEP — wired equivalent privacy — the same way you connect to home Wi-Fi.

Recap + bridge: traffic flows one-to-one (unicast), one-to-a-group (multicast), or one-to-all (broadcast); topologies from bus to mesh trade simplicity against availability; the device chain runs hub → bridge → switch → router → gateway with frames inside the LAN and packets across it; routing protocols choose paths by metric (RIP counts hops, capped at 15–16 routers). The next topic zooms out from one network to the whole internet — its three-tier structure and the layered model that organizes all of this hardware.

Real-world connection: every device in this section is one you touch daily — the home router plus its built-in switch, the Wi-Fi access point (802.11 series, WEP in older networks), the NIC burned into every laptop. On the internet scale, ISP routers run OSPF and BGP with availability and bandwidth metrics to choose paths between networks, and the MAC address burned into your phone's card is what the local Wi-Fi access point sees first when you connect.

6.8 Internet Structure and the Layered Model Preview

6.8.1 The Three-Tier Internet Structure

The internet connects through a three-tiered approach. The top tier is the core layer: the tier-1 ISP service providers, where the actual ISPs are interconnected. The middle tier is the distribution layer: the tier-2 service providers, who pay the tier-1 providers. The bottom tier is the access layer — also called the edge network or access network: the local ISP delivers the connection over the last mile to your laptop or desktop. Routing protocols play their role from source to the local network; once the packet reaches the local network, routing protocols step out of the picture and delivery happens by MAC address. On diagrams: the circle is the router, the arrow mark is the switch, and the wall symbol is the firewall.

Hook: Your laptop's packet crosses the world through other people's networks — but it only ever "belongs" to three tiers of them: the core at the top, the distribution in the middle, and the access network at the bottom that actually hands you the connection. Understanding which tier does what explains why the internet keeps working while individual ISPs fail.

Formalize — the three tiers.

Core layer (tier 1): the tier-1 ISP service providers, where the actual ISPs are interconnected. These operators run the high-capacity backbones of the internet.
Distribution layer (tier 2): the tier-2 service providers, who pay the tier-1 providers for the right to carry traffic over the core. Tier 2 providers sell connectivity onward to smaller networks.
Access layer (edge network / access network): the local ISP delivers the connection over the last mile to your laptop or desktop — the link that actually reaches the user.

Where the protocols act: routing protocols play their role from source to the local network — the router decisions happen across the tiers. Once the packet reaches the local network, routing protocols step out of the picture and delivery happens by MAC address — the switch in the LAN takes over and forwards frames to the exact machine, using the addressing covered in section 6.6.

Visual intuition: on network diagrams the symbols matter: the circle is the router, the arrow mark is the switch, and the wall symbol is the firewall. When you read a network diagram, identify the devices by their symbols first — routers at the network edges, switches inside the LAN, firewalls at the boundary.

6.8.2 OSI and TCP/IP: Why Layers

The syllabus for this chapter covers: what networks are, the basics, how the internet works, the history, network utilities, then the OSI model with its seven layers from physical to application, then network protocols — TCP/IP, how it works, and the three-way handshake. OSI model has seven layers; TCP/IP has four (some say five). Why do we need layers at all? The answers collected: a standard reference model, abstraction, protocols and understanding, interoperability, separation of responsibilities — and the one that was highlighted: the modular approach. The layered approach helps the administrator debug the issue: is the failure at the application layer, the network layer, the data link layer, or the transport layer?

Formalize — the two stacks.

The OSI (Open Systems Interconnection) model has seven layers, from bottom to top:

OSI layer	Role
7 Application	the interface the application uses — email, web, file transfer
6 Presentation	data representation and syntax (how the bytes are formatted)
5 Session	managing the dialogue between applications
4 Transport	end-to-end communication control — where TCP and UDP live
3 Network	routing the information across the network — where IP lives
2 Data link	moving frames between devices on one network — where MAC lives
1 Physical	the actual cable, NIC, and electrical signals — bits and bytes

The TCP/IP protocol suite condenses these seven into four layers (some count five): application, transport, internet, and link — the seven OSI layers map into the four-layer TCP/IP model.

Q: Why do we need the OSI layers at all? A: The collected answers: a standard reference model, abstraction, protocols and understanding, interoperability, separation of responsibilities — and the one that was highlighted: the modular approach. The layered approach helps the administrator debug the issue: is the failure at the application layer, the network layer, the data link layer, or the transport layer? Each layer handles one job and talks only to the layers directly above and below it, so a fault can be isolated to one layer instead of hunting through the whole system.

Intuition — the modular approach: each layer is one department in a company. When an order fails, the company does not re-examine every department — it checks whether the failure is in sales (application), transport (delivery), or the warehouse (physical). Because each layer's job is separate, the administrator can ask "which layer failed?" and debug one layer at a time.

Worked trace — debugging by layer.

Symptom: a user cannot open a website.

Layer-by-layer walk: the application is working (other sites load), so the application layer looks fine. The transport check: the page request reaches the server but no reply comes back — a TCP timeout points at the transport layer. The network check: a traceroute shows packets stop at the third router — the fault is in the network layer, between networks. The administrator fixes the routing issue, and the site loads.

Sense-check: the same symptom could have been a cable fault (physical), a MAC forwarding problem (data link), or a server failure (application) — the layered model is what makes the diagnosis systematic instead of random.

TCP is the transmission control protocol, operating at the transport layer — layer four — and it is the guaranteed protocol: it delivers data reliably, in order, with acknowledgements and retransmission of lost segments. The same transport layer also carries UDP, the user datagram protocol, the non-guaranteed one: it sends datagrams with no acknowledgement and no retransmission, accepting possible loss in exchange for speed. Open question left for the next session: why is the suite named TCP/IP and not UDP/IP, when both protocols sit at the same layer? The LAN protocols themselves — Ethernet, token bus, token ring, CSMA/CD — are the subject of the next session, together with the four-layer stack working in depth.

Recap + bridge: the internet is three tiers — core, distribution, access — with routing above the LAN and MAC delivery inside it; the OSI model gives seven layers, TCP/IP condenses them into four; layers exist for modularity and debugging. The next session returns to the LAN protocols (Ethernet, token bus, token ring, CSMA/CD) and to the four-layer stack in depth — including why the suite bears TCP's name and not UDP's.

Real-world connection: the three-tier structure is what you experience as an internet user — your last-mile ISP is the access layer, national providers form the distribution, and the tier-1 backbones interconnect at internet exchange points. When your connection fails, the layered model tells you where to look: Wi-Fi shows up at the physical layer, the router at the network layer, and a stalled HTTPS site at the application layer — exactly the modular debugging the lecture highlighted.

Exam Guidance Summary

Quizzes and marks: quizzes 1 and 2 happen in the month of March; each quiz carries 5% of the weight. Each quiz is 25 MCQs — pure MCQs only. Quiz 1 covers chapter 1 through chapter 2 up to 2.1.1 (confidentiality policies) — everything covered up to the previous session; the reference set is the slides, which are more than enough. No textbook is prescribed: the content is built from the table of contents plus the latest happening around the world. There is no time bound and multiple sittings are allowed — the advised approach is to read and then attempt the questions; a student from a non-IT background pointed out that the extra time helps because the quiz prompts reading. The due date is 28 February, after which the quiz closes. Do not lose the 5 percent marks — complete it by then.

Security models: expect scenario questions on Bell-LaPadula and Biba — a subject labeled at a given classification performs given operations; decide whether that is correct, or what the ideal operations are. That is the level at which questions will be asked; beyond the three rules of each model there is not much depth. Know which model supports which goal: Bell-LaPadula supports confidentiality; Biba supports integrity. For each model know the three rules — simple, star, strong star — which operations they govern (read only, write only, or read and write together), and whether the restriction is upward or downward.

Assignments this week: (1) represent the three rules of either Bell-LaPadula or Biba as a state machine diagram; (2) identify which model the three-point slide describes — the answer is Biba; (3) list three compensating controls for a ten-employee organization where one person develops, tests, and deploys, without adding manpower.

Study approach: read and attempt; use multiple sittings; keep the segregation between confidentiality and integrity clear when answering. For scenario questions, first name the goal (confidentiality or integrity), then apply the matching model's rules, then state which operations are allowed or forbidden — the segregation between the two goals is the single most useful habit for this chapter.

Key Industry Applications

Real-world: military and government classification — top secret, secret, confidential, unclassified — is where Bell-LaPadula's label scheme originates. Commercial and industrial firms emphasize integrity over confidentiality because the accuracy of data matters more to business than disclosure. The four-eyes principle and dev-to-prod release gates — developer, tester, pre-production, support teams — are how organizations apply separation of duties; production deployments move only tested, integrated code. Banking systems use well-formed transactions: an ATM withdrawal that debits without dispensing is rolled back, keeping the ledger consistent. Payment apps such as PhonePe and Google Pay change ledger entries only through whitelisted APIs — transformation procedures protecting constrained data items. Credit card support agents see only the last four digits of a card; the card owner sees more — subject-specific access by classification. HR platforms such as Workday implement role-based restriction: business users, managers, and admins each see different functions and data. ISP-issued public IPs and LAN-internal private IPs (10.x, 172.16.x, 192.168.x) are how the world fits billions of devices into the $2^{32}$ IPv4 space. Routers on the internet run routing protocols — RIP with hop count, then IGRP, EIGRP, OSPF, BGP with availability and bandwidth metrics — to choose paths between networks. Wi-Fi security methods such as WEP and the 802.11 series generations appear in every home network; FDDI rings carry traffic in fiber backbones.

The lecture thread across both halves of this session: every model and every device exists to protect or to move data. The access-control models answer who may touch data and how (Bell-LaPadula for secrecy, Biba and Clark-Wilson for accuracy, Lipner for process control), and the networking half answers where data lives and how it travels (addresses, devices, topologies, layers). Together they form the base layer of cyber security: knowing what to protect, and knowing where the traffic flows — because the next sessions build on both, moving from LAN protocols into the layered internet stack in depth.

CS Lecture 6 notes · Integrity Policies and Introduction to Networks

Cyber Security· postgraduate· 2026-08-16

Sections Breakdown

1Bell-LaPadula Recap: Confidentiality as the Goal

Review of the three Bell-LaPadula confidentiality rules — simple, star, strong star — with the head-of-HR and CEO role-play examples showing why writing downward leaks data while writing upward adds security.

2Integrity Policies: Goals and the State Machine Foundation

What integrity means, the state-machine view of secure states and transitions, and the weekly assignment on drawing the model as a state machine.

3Biba Integrity Model

Biba as the inverted Bell-LaPadula: no reads down, no writes up, one-level lock, requirements and drawbacks, plus the site-operations-manager Q&A and a model-identification exercise.

4Lipner Integrity Matrix

The Lipner integrity matrix: why another model, separation of duties, separation of functions, the small-company problem with compensating controls, and auditing.

5Clark-Wilson Model

Clark-Wilson's subject-program-object triple, well-formed transactions, separation of duty, the CDI/IVP/TP terminology, and a summary comparing all integrity models.

6Introduction to Networks: Addressing Basics

Network basics: what a network is, identifying a source by MAC and IP, IPv4 octets and exhaustion, public versus private addresses, and the IP classes with private ranges.

7Network Devices, Topologies, and Routing

Traffic patterns and topologies, the hub-bridge-switch-router-gateway device chain, static and dynamic routing with hop-count metrics, and cables, NICs, and wireless.

8Internet Structure and the Layered Model Preview

The three-tier internet structure and a preview of the OSI seven-layer and TCP/IP four-layer models, and why layering helps administrators debug.

9Exam Guidance Summary

Quiz logistics and weights, scenario questions on Bell-LaPadula and Biba, and the three weekly assignments.

10Key Industry Applications

Where the lecture's models and devices show up in the real world: military classification, banking transactions, payment apps, HR platforms, routing, and Wi-Fi.

Postgraduate students and working IT professionals studying Cyber Security

Exam Revision Notes

Below is the distilled, exam-ready core. Every entry comes from the full explanation above. Use this section for rapid review; return to the main notes when a point needs more context.

Bell-LaPadula Recap: Confidentiality as the Goal

Must-know: Bell-LaPadula protects confidentiality only: simple rule = no reads up; star rule = no writes down; strong star = read and write only at your own label. Scenario questions give a subject label and operations; decide what is correct.

$S can read O ⟺ L (O) \leq L (S); S can write O ⟺ L (O) \geq L (S)$

⚠️ Top pitfall: Mixing up the directions: the simple rule bans reading up, the star rule bans writing down; the star rule allows writing up only because it cannot leak (it shrinks the audience).

Self-check: A secret-cleared user writes into an unclassified bucket visible to all employees — allowed or forbidden, and why?

Connects to: Integrity Policies: Goals and the State Machine Foundation; Biba Integrity Model

Integrity Policies: Goals and the State Machine Foundation

Must-know: Integrity = only legitimate people can modify data; both Bell-LaPadula and Biba are state-machine models where secure rules over transitions guarantee secure states. Quiz 1 (March, 5%) covers chapter 1 through 2.1.1.

⚠️ Top pitfall: Confusing integrity with confidentiality: integrity is about who can modify data and whether it stays accurate, not about who can see it.

Self-check: What is a state in the state-machine sense, and why do the rules matter for every transition?

Connects to: Bell-LaPadula Recap: Confidentiality as the Goal; Biba Integrity Model

Biba Integrity Model

Must-know: Biba supports integrity: no reads down (simple), no writes up (star), one-level lock (strong star); a subject may invoke another only if the invoked subject is not higher. Bell-LaPadula supports confidentiality; Biba supports integrity.

$S can read O ⟺ i (O) \geq i (S); S can write O ⟺ i (O) \leq i (S)$

⚠️ Top pitfall: Leak reasoning points at confidentiality, not integrity: integrity is about legitimate people modifying data, confidentiality about who can see it.

Self-check: The three-point slide (no write up, no read down, no service request upward) describes which model?

Connects to: Bell-LaPadula Recap: Confidentiality as the Goal; Integrity Policies: Goals and the State Machine Foundation; Lipner Integrity Matrix; Clark-Wilson Model

Lipner Integrity Matrix

Must-know: Lipner = separation of duties (four-eyes principle) + separation of functions + auditing, built to satisfy five commercial requirements (no self-written programs, non-production development, controlled audited install, manager/auditor log access).

⚠️ Top pitfall: In a ten-employee company separation is impossible — compensating controls (process gates, review checklists, external approvals) must be listed instead of pretending roles can be split.

Self-check: Why is a developer who also certifies their own code a separation-of-duties violation?

Connects to: Biba Integrity Model; Clark-Wilson Model

Clark-Wilson Model

Must-know: A CDI is modified only through transformation procedures; a well-formed transaction is a complete series of operations taking one consistent state to another; ATM debit without dispensing is not well formed and is rolled back; invoice payment needs separate people (separation of duty).

$D + Y B - W = T B$

⚠️ Top pitfall: Calling a partial series of operations a transaction: if any step fails, the whole thing is not well formed and must be rolled back to keep consistency.

Self-check: A transfer debits account A but never credits account B — well formed or not, and what must the system do?

Connects to: Biba Integrity Model; Lipner Integrity Matrix

Introduction to Networks: Addressing Basics

Must-know: IPv4 = 4 octets x 8 bits = 32 bits = 2^32 addresses (0.0.0.0 to 255.255.255.255); private ranges 10.x, 172.16.x, 192.168.x; class A/B/C network-host splits; usable hosts = 2^(host bits) - 2.

$32 = 4 \times 8; 2^{32} = 4, 294, 967, 296$

⚠️ Top pitfall: Forgetting the two reserved addresses (network and broadcast): usable hosts are 2^(host bits) - 2, and confusing the class ranges (10.x vs 172.16.x vs 192.168.x).

Self-check: Which private range does a home router typically use, and why does one machine need both a MAC and an IP address?

Connects to: Network Devices, Topologies, and Routing; Internet Structure and the Layered Model Preview

Network Devices, Topologies, and Routing

Must-know: Switch works inside one network, router joins networks; layer 1 = bits/bytes, layer 2 = frames, layer 3 = packets; MAC = 48 bits = 6 bytes (24 bits manufacturer OUI + 24 bits card); RIP uses hop count and fails beyond 15-16 routers.

$48 bits = 6 bytes, 48 = 6 \times 8$

⚠️ Top pitfall: Calling layer-2 data a packet (it is a frame) and treating hubs as smart (a hub floods every port; a switch forwards by MAC table).

Self-check: When do you use a switch, and when a router? What is the correct term for data at layer 2?

Connects to: Introduction to Networks: Addressing Basics; Internet Structure and the Layered Model Preview

Internet Structure and the Layered Model Preview

Must-know: Internet tiers: core (tier-1 ISPs), distribution (tier-2, pay tier-1), access (last mile); OSI 7 layers vs TCP/IP 4 layers; TCP is guaranteed at transport, UDP is not; layers exist for modularity and debugging.

⚠️ Top pitfall: Forgetting that routing stops at the local network — inside the LAN delivery happens by MAC address, not by routing protocols.

Self-check: Why do we need the OSI layers at all, and where does the packet switch from routing to MAC delivery?

Connects to: Introduction to Networks: Addressing Basics; Network Devices, Topologies, and Routing

Exam Guidance Summary

Must-know: Two quizzes in March, 5% each, 25 MCQs each, quiz 1 = chapters 1 to 2.1.1, due 28 February, slides are the reference; scenario questions on BLP/Biba ask which operation is correct for a labeled subject.

⚠️ Top pitfall: Losing the 5% by missing the 28 February deadline, and blurring confidentiality vs integrity when answering scenario questions.

Self-check: What is the coverage and weight of quiz 1, and what are the three weekly assignments?

Connects to: Bell-LaPadula Recap: Confidentiality as the Goal; Integrity Policies: Goals and the State Machine Foundation; Biba Integrity Model; Lipner Integrity Matrix; Introduction to Networks: Addressing Basics

Key Industry Applications

Must-know: Bell-LaPadula labels come from military classification; commercial firms favor integrity; banking rolls back failed well-formed transactions; PhonePe/Google Pay use whitelisted transformation APIs; Workday and credit-card systems use restriction interfaces.

⚠️ Top pitfall: Treating these applications as isolated facts — each is one of the lecture's models or devices operating in the real world.

Self-check: Which lecture model is a payment app's whitelisted API, and which is an ATM rollback?

Connects to: Bell-LaPadula Recap: Confidentiality as the Goal; Biba Integrity Model; Clark-Wilson Model; Introduction to Networks: Addressing Basics; Network Devices, Topologies, and Routing

Previous LectureLecture 05 · Security Policies, Procedures, Standards, and the Bell-La Padula Model

Next LectureLecture 07 · Network and Internet Fundamentals

Was this lecture useful?

Loading comments…

🤖

BitsNotes AI Assistant

Subject Notes Assistant

Configure AI Chat

Choose how to access the chatbot

Have your own API key?

Switch to "Bring Your Own Key" tab above for unlimited access with any OpenAI-compatible provider.

AI Provider Preset

API Endpoint URL (OpenAI-Compatible)

API Key

Model Name

🔑 Enter API key above to fetch live models from provider, or enter model name manually.

Remember key for this session (until tab closes)

OpenAI-Compatible API Support

Choose any provider preset (Gemini, DeepSeek, Kimi, GLM, MiniMax, Qwen, OpenAI, Groq, Ollama, etc.) or enter a custom endpoint URL.

Security & Privacy First

Your API key is sent directly from your browser to your specified provider. BitsNotes servers never store or see your key.

Prerequisite Knowledge

Previously Covered in This Subject

6.1 Bell-LaPadula Recap: Confidentiality as the Goal

6.1.1 Subjects, Objects, and Classification Labels

6.1.2 Simple Confidentiality Rule: Read Only, Read Down

6.1.3 Strong Star Confidentiality Rule: Read and Write at One Level Only

6.1.4 Star Confidentiality Rule: the Tricky Write Rule

6.1.5 Working Examples: The CEO and the Patent

6.1.6 Recap of the Three Rules

6.2 Integrity Policies: Goals and the State Machine Foundation

6.2.1 What Integrity Means

6.2.2 The State Machine Concept

6.2.3 Secure State Transitions and the Weekly Assignment

6.3 Biba Integrity Model

6.3.1 Biba: The Inverted Bell-LaPadula

6.3.2 Simple Integrity Rule: Do Not Read Down

6.3.3 Star Integrity Rule: Do Not Write Up

6.3.4 Strong Star Integrity Rule: One Level for Everything

6.3.5 Q&A: A Site Operations Manager Example — Integrity or Confidentiality?

6.3.6 Requirements and Drawbacks of Biba

6.3.7 Model Identification Exercise

6.3.8 Exam Note: Scenario Questions on the Models

6.4 Lipner Integrity Matrix

6.4.1 Why Another Integrity Model

6.4.2 Separation of Duties

6.4.3 Separation of Functions and the Small-Company Problem

6.4.4 Auditing and Logs

6.4.5 Q&A: Why Is It Called a Matrix?

6.5 Clark-Wilson Model

6.5.1 Subject, Program, Object: The Triple Relationship

6.5.2 Well-Formed Transactions

6.5.3 Separation of Duties in Clark-Wilson

6.5.4 Terminology: CDI, IVP, and Transformation Procedures

6.5.5 Restriction Interface and Real-World Examples

6.5.6 Summary of Integrity Models

6.6 Introduction to Networks: Addressing Basics

6.6.1 What a Network Is

6.6.2 Q&A: How Do You Identify a Source in a Network?

6.6.3 Q&A: Why Two Addresses for One Machine?

6.6.4 Q&A: When Are Two Networks Different?

6.6.5 IPv4 Addresses, Exhaustion, and Public vs Private

6.6.6 IP Classes and the Private Ranges

6.7 Network Devices, Topologies, and Routing

6.7.1 Traffic Patterns and Topologies

6.7.2 Q&A: Switch vs Router

6.7.3 The Device Chain: Hub, Bridge, Switch, Router, Gateway

6.7.4 Routing: Static and Dynamic Protocols

6.7.5 Cables, NIC, and Wireless

6.8 Internet Structure and the Layered Model Preview

6.8.1 The Three-Tier Internet Structure

6.8.2 OSI and TCP/IP: Why Layers

Exam Guidance Summary

Key Industry Applications

CS Lecture 6 notes · Integrity Policies and Introduction to Networks

Sections Breakdown

Exam Revision Notes

Bell-LaPadula Recap: Confidentiality as the Goal

Integrity Policies: Goals and the State Machine Foundation

Biba Integrity Model

Lipner Integrity Matrix

Clark-Wilson Model

Introduction to Networks: Addressing Basics

Network Devices, Topologies, and Routing

Internet Structure and the Layered Model Preview

Exam Guidance Summary

Key Industry Applications

Was this lecture useful?

BitsNotes AI Assistant

Configure AI Chat

Sign in to use AI Chat