Security Architecture

Why a Standard Vocabulary?

• Lecture 1 ended on: name the property, name the threat, then pick the mechanism. Two engineers can still mean different things by "the channel is authenticated"
• ITU-T X.800 — the Security Architecture for OSI, published 1991, identical in substance to ISO 7498-2
• Lecture 1's passive and active attacks were already its words. Old, and still how requirements get written down: a requirement names a service, a design names a mechanism

Three Definitions

• A service is what you promise; a mechanism is how you deliver it
• "Confidentiality" is a service. "AES-256-GCM" is a mechanism. Never write the second where the first belongs
• A control is a mechanism put in place in a real system — the word risk management uses

The Five Service Categories

Availability is treated as a property of the system in X.800 rather than a service of its own — the one place the standard shows its age.

Specific Mechanisms

Eight, each sitting at a particular protocol layer:

• Encipherment — the maths of lecture 3
• Digital signature — unforgeable, and verifiable by anyone
• Access control — enforcing rights
• Data integrity — detecting modification
• Authentication exchange — a handshake that proves identity
• Traffic padding — filler, so the volume says nothing
• Routing control — choose a path you trust
• Notarization — a third party vouches for the exchange

Pervasive Mechanisms

Five more that belong to no layer, because they apply to the whole system:

• Trusted functionality — the part that is correct by assumption, so keep it small
• Security labels — the resource carries its own sensitivity
• Event detection — noticing that something security-relevant happened
• Security audit trail — the record you read afterwards
• Security recovery — what the system does in response

The last three are lecture 1's detect · respond · recover, thirty years earlier.

Services Are Built From Mechanisms

Read the bottom row: non-repudiation is the one service encipherment cannot provide. Only a signature binds a message to a single party.

The Same Code, Two Mechanisms

Lecture 1's fix, read with this lecture's eyes:

	if roles[user] != "instructor" {              // access control
		log.Printf("DENIED grade %s=%d by %s", id, grade, user)
		http.Error(w, "forbidden", http.StatusForbidden)
		return
	}
	grades[id] = grade
	log.Printf("grade %s=%d by %s", id, grade, user)  // security audit trail
    

• The if is a specific mechanism: access control, at one layer, in one place
• The log is a pervasive one: the audit trail, which belongs to no layer and watches every request
• The check protects data integrity by blocking unauthorized writes; the audit trail records decisions for detection and investigation
• Nothing here helps the reader on the lab wifi. That service is confidentiality, its mechanism is encipherment, and it is lecture 3

From Vocabulary to Architecture

• X.800 tells you what to call things. An enterprise security architecture says where they go in your organization
• It answers, on one page each:
  • What are the assets, and who owns each one?
  • What are the zones, and what crosses between them?
  • Which control enforces which requirement, and who operates it?
• Without it you get point solutions: nine products, six of them overlapping, and one gap nobody owns

You Cannot Protect What You Cannot List

• Asset inventory is unglamorous and it is the control that fails first
• Every breach report has the same sentence in it somewhere: "the server was not in the inventory"
• Each asset needs an owner, a classification, and a location
  • Classification — public · internal · confidential · restricted
  • The label decides which controls apply, so it must be a short list
• The CIS Controls, a priority list we meet below, put hardware and software inventory first and second — on purpose

Zones and Boundaries

• A zone is a set of assets with the same trust level and the same policy. A boundary is where trust changes
• Draw them once and the firewall rules and the audit scope fall out of the same picture — lecture 7 builds this properly

A Boundary You Have Walked Through

The checkpoint controls passage between areas. In our grade service, the write endpoint is where permission must be checked.

Layers of an Architecture

SABSA (Sherwood Applied Business Security Architecture) looks at one system from six views. Here, the grade service:

Requirements flow down. Assurance — evidence that each layer does its job — flows back up.

The Standards You Will Meet

They overlap heavily. Pick one as the spine and map the others onto it.

Four Documents, Often Confused

We have assets and boundaries. Now state what is allowed and who owns the decision.

• Here, a standard is an organization's mandatory rule; external standards such as ISO 27001 can inform those rules

What a Policy Has to Contain

• Scope — who and what it binds
• Statement — the requirement, in the imperative
• Roles — who owns it, who enforces it, who may grant an exception
• Consequences — what happens when it is broken
• Review date — a policy with no review date is a historical document

The ISMS Loop

• An Information Security Management System is the machinery that keeps policy connected to reality

An organization can be certified and still be badly defended.

Why Policies Fail

• Nobody read it. Forty pages, once, at onboarding
• It forbids the job. If the rule blocks the work, the work wins — every time
• No exception process. Without a legitimate way to say "not here", people take the illegitimate one
• Never measured. An unaudited policy describes intentions, not systems

The best policy is the one that is enforced by a mechanism, so following it is the path of least resistance.

You Cannot Fix Everything

• Budgets are finite and vulnerabilities are not. Risk management is the discipline of deciding what not to fix
• Risk appetite — how much risk the organization agrees to carry. Above it, act; below it, accept

The loop, from ISO 27005 and NIST SP 800-30.

Qualitative or Quantitative?

• Qualitative — high / medium / low on a 5×5 matrix
  • Fast, needs no data, and everyone can join in
  • "High" is not a number — you cannot add two of them, or compare across teams
• Quantitative — money per year
  • Comparable, and speaks the language of the budget holder
  • Needs frequency data that most organizations simply do not have
• In practice: qualitative to triage, quantitative for the few decisions big enough to deserve it

Putting a Number On It

• SLE — single loss expectancy = asset value × exposure factor (the fraction of the value one event destroys)
• ARO — annualized rate of occurrence, how many times a year
• ALE — annualized loss expectancy = SLE × ARO

The control is worth buying when it costs less than the ALE it removes. That is the entire argument, and it can be written down.

So Do We Buy It?

Assume the control cuts breach frequency by 75%, from 0.40 to 0.10 per year. Loss per breach stays the same.

ALE after control              =       14,000 per year
value of the control          =       42,000 per year
cost of the control           =       60,000 per year
net                           =      -18,000 per year
    

• A control that works exactly as advertised, and it still loses money
• Now the argument is about the inputs — is the database really worth 400,000? — which is the argument worth having

Four Things To Do With a Risk

• What is left after treatment is residual risk, and someone senior has to sign for it
• Ignoring a risk is not accepting it. Accepting it has a signature on it

What the Numbers Cannot Do

• Frequency for a rare, deliberate event is not a frequency you can measure. An adversary is not weather
• Reputational and human impact resist pricing, and get left out of the model precisely because they resist pricing
• The model is a way to make assumptions explicit and arguable — not an oracle
• A wrong estimate and an accepted risk end the same way: one day, it happens

When It Happens Anyway

• Event — anything observable
• Alert — an event worth a look
• Incident — an event that actually harmed confidentiality, integrity or availability

Preparation Is the Whole Game

• A named team, reachable out of hours and out of band — if the corporate mail is compromised, do not run the response on corporate mail
• Logs that already exist, centralized, with a retention long enough to cover the gap between breach and discovery
• Decisions made in advance: who may disconnect production, who talks to the press, when law enforcement is called
• Rehearsed. A tabletop exercise finds the missing phone number before the night you need it

Practice Before the Emergency

A disaster-response exercise illustrates the same preparation problem: people, communications, and authority must work together before an incident.

Containment Is a Trade-Off

• Pull the plug and you stop the damage — and destroy the evidence, and tell the attacker they are seen
• Watch and learn and you keep the evidence — and the damage keeps running
• Short-term containment stops the bleeding; long-term containment is the clean rebuild
• Eradication means the cause is gone, not the symptom. Restoring a backup onto the same unpatched host is not eradication
• Preserve volatile evidence first: memory, then disk, then logs

Afterwards

• A post-incident review within two weeks, while people still remember
• Blameless. The question is what let a mistake become an incident, not who made it
  • Blame produces silence, and silence is how the next one goes undetected
• Output is a small number of dated actions with owners
• Feed it back into the risk register — the written list of risks, owners and decisions. An incident is measured frequency data, the thing the model was missing

Business Continuity

• Incident response saves the system. Business continuity keeps the organization running while the system is gone
• It starts with a Business Impact Analysis: which processes matter, and how long can each be down
• Two numbers per process, and they are not the same number
  • RTO — recovery time objective: how long until it is back
  • RPO — recovery point objective: how much data you can afford to lose
• An RPO of one hour means backups every hour. The number is the requirement

Backups, Honestly

• 3-2-1 — three copies, on two kinds of media, one of them off-site
• At least one copy offline or immutable — ransomware looks for the backup server first, and it is usually reachable with the same credentials
• An untested backup is not a backup. Restore one on a schedule, and time it — that measured time is your real RTO
• Encrypt them. A backup tape is a copy of everything, in a box, in a van

Storage Is Only One Part of Recovery

Tape makes the extra copy tangible. A cartridge inside a connected library is not automatically offline or off-site; recovery still needs a tested restore.

Names to Keep: X.800

Name the promise before choosing its implementation.

Names to Keep: Mechanisms

Specific mechanisms act at a layer; pervasive mechanisms support the whole system.

Names to Keep: Architecture

Locate the assets, trust boundaries, controls, and owners.

Names to Keep: Standards

Use this as a reference map when a name appears again.

Names to Keep: Policy

Turn a requirement into an owned, enforced, and reviewed rule.

Names to Keep: Risk

Make the assumptions explicit, then decide how to treat the risk.

Names to Keep: Incidents & Continuity

Prepare to respond, and keep the organization working during recovery.