Information Security

Introduction

Instructor · Course Overview · Security Properties · Threats & Attacks · Defence in Depth · Course Policies

Fall 2026 · Amirkabir University of Technology
@1995parham

Parham Alvani

1995parham.github.io

9 years building backend systems
4 of them on platform and infrastructure

How to Reach Me

parham [dot] alvani [at] gmail [dot] com

Start the subject with [IS], then say what it is about
Include your student ID — it is how anything about grades gets looked up
One question per email. Long threads get lost; short ones get answered

No instant messaging

Email is awesome

Searchable — you can find what I said three months ago
Asynchronous — neither of us owes the other an answer at 2am
On the record — “but you said the deadline moved” becomes checkable

This Course

Security is not a feature you add. It is a property of the whole system, and it is only as good as its worst part
Four questions we keep coming back to
- What are we protecting, and from whom?
- What could go wrong, and how badly?
- What does the defence cost — in money, and in usability?
- How do we know it is working?
Engineer's approach: understand the mechanism, then decide where to spend

What This Course Is Not

Not a list of tools to run against machines you do not own
- Every attack here is taught so you can defend against it — you cannot defend what you do not understand
Not a cryptography course. We use cryptography as a toolbox; we do not prove it secure
- The rule for this course: never invent your own
Not a product catalogue. Vendors and version numbers change; the failure modes do not

Prerequisites

Computer networks — you should be able to read an IP header and explain what a port is
Operating systems — processes, users, file permissions, the kernel/user split
Programming — enough to read C, Go and a little Python. You will not be asked to write much
Everything else is introduced here, including all the cryptography

What Are We Protecting?

Before any mechanism, name the property. Almost every requirement in this course is one of three.

Confidentiality	Only those authorized can read it
Integrity	Only those authorized can change it — and you can tell
Availability	Those authorized can actually use it, when they need to

The CIA triad. Every control we meet serves one of them.

The Same System, Three Failures

A university grade database:

Confidentiality — a student reads everyone else's grades
Integrity — a student changes their own grade from 12 to 20
Availability — nobody can submit grades on the day of the deadline

Which is worst? It depends on the system — and deciding that is called risk management (lecture 2).

Three Is Not Always Enough

Authenticity — this really did come from who it claims to
Non-repudiation — and the sender cannot later deny it
- Needs a digital signature: a check anyone can verify but only the sender could make (lecture 3)
Accountability — every action traces back to a responsible identity
Privacy — the subject keeps control over data about them, which is not the same as confidentiality

FIPS 199 defines confidentiality, integrity and availability; authenticity and accountability are added by NIST SP 800-33.

Integrity, in One Command

A hash function turns any input into a short fingerprint, the digest:


$ cat order.txt
transfer 100 USD to alice

$ shasum -a 256 order.txt
918e1e440fd83a713e79f2bcfcdecedb1145a7e94dba18ae71c9a9f886a7bb26  order.txt

$ sed -i '' s/100/900/ order.txt      # change one character

$ shasum -a 256 order.txt
73d418b01e29a3ec522895c90d805794864d516a5603644e426adbd21a3111d9  order.txt

One digit moved, and every digit of the digest moved with it. That is what "you can tell" means.

But Who Guards the Digest?

An attacker who can rewrite the file can rewrite the digest next to it
A hash gives integrity against accident; it takes a key to get integrity against an adversary
This pattern repeats all term: a mechanism only moves the problem, and the question is where it moved to

Security is not a product, but a process. — Bruce Schneier, 2000

Say It Precisely

These five words are used interchangeably in the press. Not here.

Asset	Something with value: data, a service, a reputation
Vulnerability	A weakness in the asset or its controls
Threat	A potential cause of harm — needs an actor and a motive
Attack	A threat that someone actually carried out
Risk	How likely, and how bad — the number we manage

A vulnerability with no threat is a curiosity. A threat with no vulnerability is noise.

Passive and Active

The oldest useful split. Lecture 2's standard, X.800, uses exactly these names:

Left: Eve copies the traffic between Alice and Bob and changes nothing; prevent it with encryption. Right: Mallory sits in the path and pretends to be Alice, replays an old message, modifies one, or blocks the line; detect it and recover.

Passive changes nothing, so there is nothing to notice: you prevent it. Active you cannot always prevent: you detect it and recover.

Traffic Analysis Is Not Nothing

Encryption hides what was said. It does not hide that it was said
Who talked to whom, when, how often, how much — the metadata
A phone that contacts an oncology clinic weekly has leaked something, and every byte was encrypted
Countermeasures are expensive: traffic padding, cover traffic, mixing. This is why they are rare

Metadata, in One Command


$ openssl s_client -connect example.com:443 -servername example.com \
      -msg </dev/null 2>&1 |
    awk '/ClientHello/{p=1;next} /^[<>]/{p=0} p' | xxd -r -p |
    xxd | grep -B1 -A1 example

00000080: 3c00 3500 2f01 0005 78ff 0100 0100 0000  <.5./...x.......
00000090: 0010 000e 0000 0b65 7861 6d70 6c65 2e63  .......example.c
000000a0: 6f6d 000b 0002 0100 000a 0012 0010 11ec  om..............

The first packet of the connection, sent before any key exists. Every byte of the request that follows is encrypted; the name of the site is not, because the server must know which site you want before it can answer. Metadata is not a leftover — it is structural.

Who Is the Attacker?

A threat model names who attacks and what they can spend. "A hacker" is not one.

Opportunist	Automated scanning. Takes whatever is unpatched and reachable
Insider	Already authenticated, already inside. Hardest to stop
Organized crime	Ransomware, fraud. Follows the money and is patient
State actor	Buys unknown bugs (zero-days), attacks your suppliers, will not give up

Defending against all four to the same standard is how budgets are wasted.

Attack Surface

Every place untrusted input can reach your system: open ports, HTTP parameters, file uploads, USB slots, help desk staff
The first and cheapest defence is always to make it smaller
- Turn the service off · close the port · remove the feature
- Code that is not there has no vulnerabilities
Attack tree: put the goal at the root, the ways to reach it beneath, and keep asking "how?" until the leaves are things a person could actually do

STRIDE

A checklist for "what could go wrong here", one letter per property:

Spoofing	pretending to be someone	→ authenticity
Tampering	changing data	→ integrity
Repudiation	denying you did it	→ non-repudiation
Information disclosure	reading what you should not	→ confidentiality
Denial of service	taking it away	→ availability
Elevation of privilege	becoming admin	→ authorization (who may do what)

Draw how data moves through the system, and ask all six wherever it crosses from one owner to another.

No Single Wall

Every control fails eventually — it is misconfigured, out of date, or simply bypassed
Defence in depth: arrange controls so that no single failure is fatal
The castle analogy is popular and slightly wrong: a moat only helps if the attacker comes by the gate. Most arrive by email

Assume the outer layer is already broken. What does the next one do?

The Layers

Physical	Locks, racks, guards. Console access beats every other control
Network	Zoning, firewalls, VPN, segmentation — lecture 7
Host	Hardening, patching, anti-malware, host IDS — lecture 5
Application	Authentication — lecture 4. Input handling, sessions — lecture 6
Data	Encryption at rest and in transit, key management — lecture 3
People	Training, policy, process. The layer that is always attacked

Four Kinds of Mechanism

Whatever the layer, a control does one of four jobs. A programme with only the first is not a programme.

Prevent — stop it happening. Access control, encryption, input validation
Detect — notice that it happened. Logs, intrusion detection (IDS), file-integrity monitoring
Respond — contain it. Isolate the host, revoke the key, block the address
Recover — get back to normal. Backups, failover, the rebuild you have actually rehearsed

Prevention is preferred, detection is mandatory, recovery is survival.

Principles Worth Memorizing

Least privilege	every subject gets the rights it needs, and no more
Fail-safe defaults	deny unless explicitly allowed — default deny
Economy of mechanism	a simple design is one you can actually check
Complete mediation	check every access, not just the first
Open design	security must not depend on the design being secret
Separation of privilege	two keys are better than one
Least common mechanism	every part users share is a path between them
Psychological acceptability	if the secure way is hard, people take the other way

Saltzer and Schroeder, 1975. They have not needed revising.

The Awkward Truths

The attacker only has to be right once. You have to be right every time — but you also get to watch, and they do not
Security is a trade-off. A control that makes the job impossible will be worked around, and then you have neither security nor the control
Complexity is the enemy. Every feature, dependency and integration is more surface
There is no perfect. The goal is to make the attack cost more than the asset is worth

The Grade Service

Everything in this lecture, on one program. A grade service with a single endpoint; who the caller is comes from the login layer in front of it, and today we trust that header.


var grades = map[string]int{"4001": 12, "4002": 17}

func setGrade(w http.ResponseWriter, r *http.Request) {
	user := r.Header.Get("X-User") // filled in by the login layer in front
	if user == "" {
		http.Error(w, "login first", http.StatusUnauthorized)
		return
	}
	id := r.FormValue("id")
	grade, _ := strconv.Atoi(r.FormValue("grade"))
	grades[id] = grade
	log.Printf("grade %s=%d by %s", id, grade, user)
	fmt.Fprintf(w, "%s is now %d\n", id, grade)
}

The Attack, in One Request


$ curl -H 'X-User: parham' -d 'id=4002&grade=18' localhost:8080/grade
4002 is now 18

$ curl -H 'X-User: 4001' -d 'id=4001&grade=20' localhost:8080/grade
4001 is now 20

$ tail -1 server.log
2026/10/06 01:01:23 grade 4001=20 by 4001

Student 4001 just gave themselves a 20. The property that broke is integrity
The vulnerability is the if: it asks "are you logged in?", never "are you allowed to set grades?"
The threat is anyone with a student login. The attack is this one request, and it is active: something changed
The risk is how often this happens and what it costs. Lecture 2 puts a number on it

The Fix, and the Log


var roles = map[string]string{"parham": "instructor", "4001": "student"}

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


$ curl -H 'X-User: 4001' -d 'id=4001&grade=20' localhost:8080/grade
forbidden

$ head -1 server.log
2026/10/06 01:01:25 DENIED grade 4001=20 by 4001

The check prevents, at the application layer. The log detects, and it lives on the host, where no student can reach it
The reader on the lab wifi is a passive attack; no check stops it. That needs encryption: the primitives are lecture 3, TLS is lecture 6
No single wall: the check can be wrong again. The log is the layer that says so. Lecture 2 picks up this same program

Syllabus

Introduction — concepts, threats, attacks, layers
Security Architecture — X.800, policy, risk, incidents
Cryptography — symmetric, public key, signatures, PKI
Access Control — the four A's, DAC/MAC/RBAC, passwords, second factors, biometrics
System & Software Security — file systems, malware, host defences, virtualization
Web Security — server side, sessions, client side, TLS
Network & Transport Security — zoning, edge, VPN, VLAN

Lectures 1–2 build the vocabulary, 3–4 the tools, 5–7 spend them on real systems.

Grading

35%	Midterm exam
35%	Final exam
30%	Homework and hands-on assignments

A 40% minimum on each exam, independent of the total
The hands-on work is where the material actually lands. Do it

The Lab Rule

Only ever attack a system you own, or one whose owner has given you written permission.

Every exercise in this course runs against your own machine or a target we provide
Scanning, probing or exploiting university, ISP or third-party systems is not coursework — it is a criminal offence, and it will be treated as one
Unsure whether something is in bounds? Ask before you run it, not after

Academic Honesty

Discuss ideas freely. Write your own answers and your own code
Cite what you used — a source, a tool, a model. Citing costs nothing; hiding it costs the assignment
Copied work scores zero for everyone involved, including whoever shared it

The subject of this course is trust. It would be strange to start by breaking it.

Check Yourself

Student 4001 set their own grade to 20. Which property broke, and which line of the grade service was the vulnerability?
Why does a digest stored next to a file not stop an attacker who can edit the file?
Encryption hides the request. Name one thing it does not hide, and say why.
The role check prevents and the log detects. Why keep both?

Where This Leaves Us

Name the property — confidentiality, integrity or availability. The grade service lost integrity
Name the threat — who attacks, with what budget, through which part of the attack surface
Then pick the mechanism — and expect it to fail, so layer it: prevent, detect, respond, recover

Next: lecture 2 turns this vocabulary into a standard one — X.800 — then writes it down as policy, prices it with risk management, and plans for the day it goes wrong.

Name the property. Name the threat. Then pick the mechanism.