Why this section?

This course is full of terms like "security," "vulnerability," "threat model."

We assume you know none of them.

Let's define every one of them one at a time first.

What is security?

• Security: protecting a system against someone who wants to harm it.
• An ordinary bug: happens by accident.
• Security: there is a deliberate attacker.

What is an asset?

• Asset: anything worth protecting (data, a key, a function).
• Example: a password, a credit card, a license, user data.
• Security begins with "what are we protecting?"

Threat and vulnerability

• Threat: a bad event that could happen (data being stolen).
• Vulnerability: the weak point that makes it possible (unvalidated input).
• Threat + vulnerability + attacker = risk.

Threat · vulnerability · asset — diagram

The CIA triad

The three core goals of security:

• Confidentiality (C): only authorized parties can see it.
• Integrity (I): cannot be changed without authorization.
• Availability (A): works when it needs to.

Attacker model

• Attacker model: "what can the attacker see/do?"
• Are they connecting over the network, or do they own the device?
• We design the defence accordingly.

White-box / MATE

• MATE (Man-At-The-End): an attacker who owns the program.
• Reads the code, sees the memory, modifies it.
• The real situation for mobile/desktop applications (this course's main theme).

Threat modelling

• Threat modelling: systematically answering "what will we protect, against whom, and how?"
• It lists assets, threats, and countermeasures.
• Today we'll do it with STRIDE and attack trees.

STRIDE

• A method that classifies threats with six letters:
• Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege.
• It asks "which threat?" for every element.

Attack tree

• Attack tree: a tree that breaks a goal (e.g. "steal the key") into sub-steps.
• Root: the attacker's goal.
• Branches: the ways to achieve it.

Data flow diagram (DFD)

• DFD: a diagram showing how data flows through the system.
• Process, data store, external entity, flow, trust boundary.
• A map for finding threats.

Defence in depth

• Defence in depth: not a single countermeasure, but many.
• If one is bypassed, another stops it.
• A "security shell" is the combination of these layers.

Secure design principles

• Saltzer & Schroeder (1975): least privilege, secure default, economy, open design…
• Still valid today.
• The backbone of this course.

Trade-off

• Every protection carries a cost: speed, complexity, expense.
• Security is not "infinite protection," it is balanced protection.
• We write the remaining risk down explicitly.

Now we're ready

Terms:

security · asset · threat/vulnerability · CIA · attacker model · MATE · threat modelling · STRIDE · attack tree · DFD · defence in depth · design principles · trade-off

Now: what security is, in depth.

Today's plan (3 hours)

Demos: code/week-01 — Windows .\demo.ps1 · WSL / Linux sh demo.sh · Visual Studio: Open Folder → code

The five decisions of secure programming — diagram

How the course runs

• One term project: a C/C++ application + a security guide written "as if it were going through certification"
  • Midterm check: week 7 demo · Final check: week 15 demo
• Two quizzes: week 8 (1–6) · week 16 (9–14)
• Grade: Midterm = 0.6·Project1 + 0.4·Quiz1 · Final = 0.7·Project2 + 0.3·Quiz2
• Every week: buggy code → attack → fix

⚠️ Ethics: Only try these techniques on your own computer and on the demos provided.

The Vault analogy

Security's three goals: CIA

+ Authentication · Authorization · Non-repudiation

Question: A banking app writes the balance unencrypted → ? · The recipient IBAN changes in transit → ? · It crashes on a holiday night → ?

The CIA triad — diagram

Answer to the question: balance unencrypted → C; IBAN changes in transit → I; crashes on a holiday night → A.

The CIA triad — typical countermeasures and related concepts

+ Authentication: are you really who you say you are? · Authorization: do you have permission to do this? · Non-repudiation: who did this, and can they deny it afterward?

Bug ≠ vulnerability, but…

A very large share of security vulnerabilities are ordinary software bugs.

Heartbleed (2014, CVE-2014-0160)

• Client: "Send me 64 KB back" — but sends only a few bytes
• The server never checks the length → sends back neighboring memory (passwords, keys)
• A single missing length check → a significant part of the internet was affected

Who is the attacker, what can they reach?

What's different about this course: what do we do if the program runs on the attacker's device?

Attacker models — diagram

Attackers — real-world examples

Apply each row to your own project: which one is your attacker?

Saltzer and Schroeder's principles — diagram

Why a single countermeasure is not enough

➡️ Each layer closes the previous one's gap; the attacker must defeat all of them at once

The security shell: where the layers meet

A sensitive key is carried inside several layers at once:

1. Stays encrypted on disk
2. Decrypted only at the moment it's needed, only as much as needed
3. The code section where it is decrypted is obfuscated and integrity-checked
4. The process has debugger detection running

➡️ In week 3 we'll build a four-shell design step by step

⚠️ Obfuscation is not a substitute for correct code

• Obfuscation slows the attacker down, it does not fix the bug
• An obfuscated overflow is still an overflow
• Outer layers only make sense once the inner layers are solid

The server never trusts the client. Even an obfuscated client can send inconsistent data to the server.

The cost of protection

➡️ Every countermeasure is written with its justification: this asset, against this attacker, at this cost

An evaluator reads the table backward

1. String scan → is a key, URL, error message visible?
2. Opening the binary → is the logic readable?
3. Attaching a debugger → does the program notice?
4. Modifying the code → does the integrity check catch it?
5. Memory dump → is a secret found?

Every step that isn't stopped becomes a finding in the report

Try it yourself (3 min)

1. What is the attacker model for an offline password manager? Which layers matter?
2. "It runs on the server, no need to obfuscate" — when is this true, when is it false?
3. In a game that uses only obfuscation, which attack path stays open?

Application protection plan: 7 steps

1. Scope — What are we protecting? Which binary, which version, which hash?
2. Architecture and interfaces — Who talks to whom, over which channel?
3. Assets — Where does it live, when is it erased, C or I?
4. Threats — Who is the attacker, by which path do they reach the asset?
5. Countermeasures — Which layer, which countermeasure?
6. Verification — How is it proven that it works?
7. Residual risk — What was accepted, and why

→ In certification this plan becomes a security guide hundreds of pages long. You will write a 20–30 page version of it for the project.

Step 1 detail: Scope

Question: What are we evaluating?

• Saying "version 2.1" alone is not enough
• Which binary, which source code, which hash value?
• In certification this is called the target of evaluation

Step 2 detail: Architecture and interfaces

Question: What are the components, how do they talk?

• What are the components?
• Which channel do they talk to each other over?
• How is identity verified on each channel?

Step 3 detail: Assets

Question: Where and when is the protected data?

• Every piece of data to be protected is listed one by one
• Where does it live, when is it created, when is it erased?
• Does it need confidentiality (C) or integrity (I)?

Step 4 detail: Threats

Question: Who is the attacker, how do they reach it?

• Who is the attacker? (see attacker models)
• By which path can they reach each asset?
• STRIDE and the attack tree come in here

Step 5 detail: Countermeasures

Question: Which countermeasure, in which layer?

• One countermeasure is chosen for each threat
• Which of the seven layers does the countermeasure belong to?
• An unjustified countermeasure is in the wrong place or unnecessary

Step 6 detail: Verification

Question: How is it proven that it works?

• A test is written for each countermeasure
• A unit test, or a bypass attempt?
• A countermeasure with no test does not exist in an evaluator's eyes

Step 7 detail: Residual risk

Question: What did we knowingly accept?

• Risks that can't be closed, or are knowingly accepted
• The reason for each (e.g. performance, usability)
• The plan never ends: as the product changes, step 1 is revisited and it is updated

The protection plan — diagram

STRIDE

Draw the data flow diagram → ask the six letters for every arrow that crosses a trust boundary.

Attack tree: "Capture the payment key"

GOAL: Payment key — OR (one is enough)

1. Break the database — AND (all required): gain root privilege + find the database key
2. Read from memory — OR: attach a debugger | take a memory dump | hook a function
3. Eavesdrop on the traffic — AND: break TLS + break message-level encryption

Attack tree — the "Break the database" branch

AND node (all required):

1. Gain root privilege
2. AND find the database key

This path is expensive because both are needed.

This is proof that defence in depth works.

Attack tree — the "Read from memory" branch

OR node (one is enough): three alternatives

1. Attach a debugger
2. OR take a memory dump
3. OR hook a function

Three alternatives = the weakest point: the key in memory.

→ This week's Demo 2 · Week 6 runtime protection · Week 11 white-box

Attack tree — the "Eavesdrop on traffic" branch

AND node (all required):

1. Break TLS
2. AND break message-level encryption

Both layers must be broken at once → an expensive path.

The defender's goal: force the attacker into as many AND nodes as possible.

Conclusions from the attack tree

• The "eavesdrop on traffic" path requires breaking two layers at once → expensive → defence in depth is working
• The "read from memory" path has three alternatives → the weakest point is the key in memory
  • This week: Demo 2 (a secret left in memory)
  • Week 6: runtime protection (debugger, hook detection)
  • Week 11: white-box cryptography (the key is never exposed in memory)
• The defender's goal: force the attacker into AND nodes

Data flow diagram: five symbols

➡️ Color every arrow that crosses a trust boundary red: start your review there

Data flow diagram and trust boundary — diagram

Risk score: likelihood × impact

• Likelihood: physical access, or over the internet? Expertise needed? Can it be automated?
• Impact: which asset, how many users, financial/legal consequence?
• More detailed: CVSS (week 2), attack potential (week 13)

Four responses to a threat

1. Mitigate — add a countermeasure (most common)
2. Eliminate — never write the feature at all (strongest)
   If there's no "remember my password" feature, there's no disk-password threat either
3. Transfer — don't store card data, leave it to the payment provider
4. Accept — write it into the residual risk list, with a reason

⚠️ A risk not written into the plan is not accepted, it has been overlooked

Step 0–1: Application and scope

Vault: a C++ desktop password vault

• Master password → derived key → records encrypted in a single file
• Copy to clipboard · optional cloud backup · auto-update

Vault architecture — diagram

Step 5 (continued): T7 and T9 countermeasures

The T9 example matters: not every threat needs a countermeasure added, sometimes accepting it is the right call.

Step 6–7: Verification and residual risk

Residual risk: malware running with the same user while the vault is open · shoulder surfing · a very weak password

⚠️ A countermeasure with no test doesn't exist in an evaluator's eyes

Common mistakes

• Forgetting assets: keys, tokens, counters, configuration, the code itself
• Drawing the trust boundary wrong: treating your own client as "trusted"
• Not matching a countermeasure to a threat: "we use TLS" — which threat does it close, which doesn't it?
• A countermeasure with no test: saying "we erase it" without noticing the compiler removed the erasure (Demo 2)

Class exercise (15 min)

Student grading system: the instructor enters grades, the student sees them, the data lives on a server.

1. Data flow diagram + trust boundaries
2. One threat from each STRIDE letter
3. Attack tree for "raise my grade from 45 to 85" — which is the cheapest path?

How a secret leaks from memory — diagram

A program doesn't start with a blank page

What it inherits from whoever launched it:

• Environment variables: PATH, LD_PRELOAD, IFS…
• Open file descriptors, working directory, umask
• Resource limits, crash dump settings

If the program trusts these, whoever controls them controls the program.
Book: Viega & Messier, Recipes 1.1–1.9

Demo 1 — Fooling via PATH (CWE-426)

int durum = system(KOMUT);  /* Linux: "date"  Windows: "hostname" */
                            /* HANGİSİ çalışacak? */

.\demo.ps1 (Windows) · sh demo.sh (WSL / Linux)

ADIM 2 — PATH="$PWD/sahte:$PATH" ./bin/linux/rapor
Rapor tarihi:
  !!! SAHTE 'date' calisti !!!
ADIM 3 — ./bin/linux/rapor_guvenli  ->  Rapor tarihi: Sat Sep 19 ...

Fooling via PATH — diagram

Fix: three rules

char *const arguman[]     = { "date", NULL };
char *const temiz_ortam[] = { "PATH=/usr/bin:/bin", "LANG=C", NULL };
posix_spawn(&pid, "/bin/date", NULL, NULL, arguman, temiz_ortam);

1. Absolute path → no PATH search
2. No shell (posix_spawn / execve) → no special characters, no IFS
3. Clean environment → a known, small environment

Windows: CreateProcessW + System32\hostname.exe + only SystemRoot

Best: avoid needing another program at all → strftime(), GetComputerNameW()

What a program inherits — diagram

All together: guvenli_baslat()

int main(int argc, char **argv)
{
    tanitici_duzenle();   /* 1. tanıtıcılar  */
    ortami_temizle();     /* 2. ortam        */
    umask(077);           /* 3. izinler      */
    dokumu_kapat();       /* 4. döküm        */
    yetkiyi_birak();      /* 5. yetki        */
    /* ... asıl iş ... */
}

Order matters: before doing anything else

Demo 2 — Password left in memory (CWE-14)

char parola[64];
n = dosya_oku(fd, parola, sizeof(parola) - 1);
anahtar = anahtar_turet(parola, n);
memset(parola, 0, sizeof(parola));         /* sürüm 2 */
explicit_bzero(parola, sizeof(parola));    /* sürüm 3, Linux */
SecureZeroMemory(parola, sizeof(parola));  /* sürüm 3, Windows */

Hiç silmeyen   -> parola dökümde BULUNDU
memset (-O2)   -> parola dökümde BULUNDU      ← !!!
explicit_bzero -> parola dökümde bulunamadı

Process memory

C does not check the end of an array. A 17th byte into ad[16] → overwrites the next variable.

The structure in memory

struct oturum { char ad[16]; int yonetici; };

 ofset:  0 ............................ 15 | 16  17  18  19
        [ a  y  s  e \0  .  .  .  .  .  . ][ 00  00  00  00 ]   yonetici = 0

 "AAAAAAAAAAAAAAAAB" (17 karakter) kopyalanınca:
        [ A  A  A  A  A  A  A  A  A  A  A ][ 42  00  00  00 ]   yonetici = 66 (!)
                                              'B'  '\0'

Little-endian: the lowest byte sits at the lowest address.

Structure in memory and overflow — diagram

What is a buffer overflow?

Writing more data than allocated into an array → the overflowing bytes land over neighboring variables

Why does C overflow so easily?

1. An array doesn't know its own size
2. Only the starting address goes to the function
3. A string = an array ending in '\0'; strcpy never asks the target's size
4. The compiler adds no bounds checking

CWE-787 "out-of-bounds write": always near the top of the CWE Top 25

Heartbleed (2014): nothing was written

• Client: "I'm sending 1 byte, but reporting 64 KB"
• Server: sent 64 KB back without checking the declared length
• Leaked: passwords, sessions, even the server's private key
• CVE-2014-0160 · CWE-125 · Fix: a single length check

➡️ An out-of-bounds read is as dangerous as a write; it doesn't crash, leaves no trace

C++: the type carries the size — but be careful

void selamla(const std::string &ad) {
    if (ad.size() > 15) throw std::invalid_argument("ad cok uzun");
    std::cout << "Merhaba " << ad << '\n';
}

• vector::operator[] does not check bounds → at() does
• Writing through a pointer taken with c_str() → all of C's problems come back

Demo 3 — Privilege escalation via overflow (CWE-121)

.\demo.ps1 (Windows) · sh demo.sh (WSL / Linux)

Fix: validate, then copy with a bound

/* İzin listesi: 1–15 karakter, harf/rakam/_/- */
static int ad_gecerli_mi(const char *s)
{
    size_t n = strnlen(s, 16);
    if (n == 0 || n >= 16) return 0;
    for (size_t i = 0; i < n; i++) {
        unsigned char c = (unsigned char)s[i];
        if (!isalnum(c) && c != '_' && c != '-') return 0;
    }
    return 1;
}
struct oturum o = { .yonetici = 0 };           /* güvenli varsayılan */
snprintf(o.ad, sizeof(o.ad), "%s", argv[1]);   /* boyutu bilen kopya */

Canary, NX, ASLR (week 4) make exploitation harder, they don't fix the bug.

Integers: when does -1 become huge?

int is signed · size_t is unsigned · negatives are two's complement

int    -1  =  0xFFFFFFFFFFFFFFFF
size_t     =  18 446 744 073 709 551 615

if (uzunluk > 16) return -1;   /* -1 bu denetimi GEÇER */
memcpy(hedef, kaynak, uzunluk); /* int -> size_t */

Demo 4 — Signed length (CWE-195)

ADIM 0  GCC -Wall -Wextra: sessiz · -Wsign-conversion: uyarı
        MSVC (C): sessiz · aynı kod C++ olarak: C4365
ADIM 1  kopya 8     -> Kopyalandi: ORNEK-KA
ADIM 2  kopya 100   -> Reddedildi
ADIM 3  kopya -1    -> Linux: SIGSEGV (139) · Windows: 0xC0000409
ADIM 4  ASan        -> negative-size-param: (size=-1)
ADIM 5  kopya_guvenli -1 / 12abc -> Reddedildi

Rule: sizes in size_t · lower and upper bound · strtol · turn on warnings

The signed length bug — diagram

The lifecycle of dynamic memory

Allocate → validate → use → erase secret → free once → forget the pointer

The lifetime of memory and its CWEs — diagram

Protected code partitioning: shrink the TCB

Trusted Computing Base (TCB): all the code where "if it's buggy, security collapses"

• A 200,000-line application, a 2,000-line protected core
• Review, obfuscation, integrity checking only for the core → cost stays there too

Masking in memory — code example

typedef struct {
    uint8_t maske[32];    /* açılışta rastgele üretilir */
    uint8_t ortulu[32];   /* anahtar XOR maske */
} OrtuluAnahtar;

static void anahtari_ac(const OrtuluAnahtar *o, uint8_t gecici[32])
{
    for (size_t i = 0; i < 32; i++)
        gecici[i] = o->ortulu[i] ^ o->maske[i];
}

What sits in memory is not the key itself, but two meaningless pieces; combined only when used.

Window of exposure — diagram

Change management: seven steps

1. Baseline → 2. Change request → 3. Classification → 4. Approval and planning → 5. Development and testing → 6. Release → 7. Verification

• Between 3 and 4, a security impact analysis: which asset, interface, threat, countermeasure?
• Reviewing only the changed part = delta assessment (week 13)
• Repository: protected branches · at least one reviewer · signed tag · MFA

Change management — diagram

This week's toolbox — diagram

Project: this week's tasks

1. Team (individual or up to 4 people) and topic
2. GitHub repository + project plan (work packages, timeline) → get it approved
3. Security guide draft:
   • S0 cover and version history · S2 product overview
   • S3 architecture and interface table
   • S4 attacker model · STRIDE · attack tree

Try it yourself (not graded)

1. The PATH trap: repeat with ls (Linux) / whoami (Windows), fix with a full path
2. In Demo 2, MOD optimize → MOD korumasiz: does memset work now?
3. In Demo 3, 16, 17, 18, 19, 20 characters: a table of yonetici values
4. Add bakiye to struct oturum: push it above 1000 with an overflow, then prevent it
5. A STRIDE table for your own project (≥ 8 threats + countermeasures)
6. Read the Heartbleed report: which check was missing? Which CWE?

Details and hints: course site → Week 1 → "Try it yourself"

Self-check

1. Difference between asset, threat, vulnerability?
2. The recipient IBAN changing in transit — which CIA property?
3. What does a white-box attacker do differently?
4. STRIDE "E" — which demo?
5. AND / OR node — which is good for defence?
6. Why is system("date") dangerous? Three fixes?
7. Why did memset disappear?
8. Why didn't ASan catch the 17 characters?
9. What happens when -1 reaches memcpy?
10. Defence in depth — an example from the mobile payment architecture?

Self-check (continued)

1. Why is S never asked of a data flow?
2. What are the four responses to a threat? Give an example of "eliminate"
3. Why is the group dropped first in a setuid program?
4. Why isn't strncpy a safe strcpy?
5. Why did Heartbleed leak data without anything crashing?

Self-check — answers (continued 1–5)

1. S is not asked of a data flow: a flow has no identity (spoofing is asked of endpoints/assets).
2. Mitigate · eliminate · transfer · accept. "Eliminate" example: never offering a "remember my password" feature at all.
3. In setuid, the group is dropped first; if the user is dropped first, there's no privilege left to change the group.
4. strncpy doesn't add a terminator on a long source → an unterminated string.
5. Heartbleed only read; the memory it read was the process's own valid memory → it leaked without crashing.

Self-check (continued)

6. What does a canary do when it catches an overflow? Why is it still a problem?
7. What does free(p); p = NULL; prevent, and not prevent?
8. What does mlock prevent, and not prevent?
9. What is a "decryption oracle"? A countermeasure?
10. The three components of unique version identity?

Self-check — answers (continued 6–10)

6. When a canary is corrupted it terminates the program (denial of service); it does not see the overflow into the neighboring variable.
7. free(p); p=NULL; prevents double free/UAF; it does not protect against aliases (another pointer to the same address).
8. mlock prevents memory from being written to swap; it does not prevent it from being read, or a secret from staying unerased.
9. Decryption oracle: the ability to decrypt without the key. Countermeasure: context/integrity checking, a call limit, binding to the device.
10. Unique version: semantic version + git id + binary SHA-256.

Example system

A mobile banking application:

• user login
• balance display
• money transfer

Let's apply every STRIDE letter to this system.

S · Spoofing

• Threat: acting as someone else (a fake user/server).
• Example: a fake server, a stolen session.
• Countermeasure: strong authentication, TLS + certificate checking.

T · Tampering

• Threat: modifying data/code without authorization.
• Example: changing the transfer amount.
• Countermeasure: integrity (MAC/signature), integrity checking (RASP).

R · Repudiation

• Threat: denying what you did.
• Example: "I didn't make that transfer."
• Countermeasure: secure log, signature, audit trail.

I · Information disclosure

• Threat: confidential data leaking.
• Example: a balance/password leak.
• Countermeasure: encryption, least privilege, leak-free error messages.

D · Denial of service

• Threat: making the service unavailable.
• Example: excessive requests, resource exhaustion.
• Countermeasure: rate limiting, resource quotas, input limits.

E · Elevation of privilege

• Threat: gaining unauthorized privilege.
• Example: an ordinary user becomes administrator.
• Countermeasure: least privilege, privilege checking, secure default.

STRIDE · summary application

Root · goal

The attacker's ultimate goal. Now let's break down the paths.

Branches · how?

The question to ask after the root: "By which paths is this goal reached?"

• Every branch is one way to reach the goal
• AND: all of the branch is needed · OR: one is enough
• Next step: break the most likely branch into sub-branches

Sub-branches · read from memory

Read from memory — three ways:

• Attach a debugger
• Take a memory dump
• Catch it with a hook

Every leaf is one attack step.

Prioritising from the tree

• The easiest leaf is the biggest risk.
• Close it first (e.g. RASP + short lifetime).
• The tree shows the defence priority.

Mapping the tree to countermeasures

Least privilege

• Every component can only do what's needed.
• Excess privilege = a larger attack surface.
• Example: a DB user with only SELECT.

Secure default (fail-safe)

• If something goes wrong, fall to the safe side.
• Error → access is denied (fail-closed).
• Default: closed, restricted.

Economy and open design

• Economy: a simple design, fewer bugs.
• Open design: security rests on the key, not secrecy (Kerckhoffs).
• Complexity is the enemy.

Complete mediation and separation of privilege

• Complete mediation: every access is checked (don't skip it by trusting a cache).
• Separation of privilege: more than one condition for a critical operation.
• The foundation of defence in depth.

Principles → this course

• These principles will repeat every week this term.
• Code, crypto, RASP, requirements — all rest on them.
• The principles don't change; the techniques do.

Appendix · summary

• STRIDE asks six questions of every element.
• An attack tree breaks the goal into paths and prioritizes them.
• Design principles are the compass for every decision.

Model the threat, then protect it with layers.

Question 1

Explain the CIA triad with an example.

Answer: Confidentiality: only the owner sees the password. Integrity: a bank balance can't be changed without authorization. Availability: the app works when needed.

Question 2

What is the difference between a bug and a vulnerability?

Answer: Every vulnerability is a bug, but not every bug is a vulnerability. A vulnerability is a bug an attacker can exploit.

Question 3

How does a MATE (white-box) attacker differ from a network attacker?

Answer: MATE owns the program: reads the code, sees the memory, modifies it. A network attacker only connects from outside.

Question 4

What does STRIDE provide?

Answer: A systematic search for threats in six classes: spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege.

Question 5

What is an attack tree for?

Answer: It breaks an attack goal into sub-steps; it shows the easiest/most likely path and helps prioritise.

Question 6

Why isn't a single countermeasure enough?

Answer: Every countermeasure can be bypassed; in layered defence, if one is bypassed, another stops it. Strength comes from combination.

Question 7

"Does obfuscation replace correct code?"

Answer: No. Obfuscation makes reading harder but doesn't fix the bug. Secure code first, then obfuscation.

Question 8

What is the principle of least privilege?

Answer: Every component should have only the necessary privilege; more than that enlarges the attack surface.

Question 9

What is a trust boundary?

Answer: The place where trusted and untrusted zones are separated; input validation is done here at the earliest point.

Question 10

Why is residual risk written down?

Answer: No system is 100% secure; known, accepted risks are documented explicitly.

Product · synthetic

A "password vault" application:

• stores passwords locally
• opens with a master password

Let's build a quick threat model.

Step · assets

• Master password (C/I)
• Stored passwords (C/I)
• Encryption key (C/I)

Step · threats (STRIDE)

• I (information disclosure): if the device is stolen, passwords can be read.
• T (tampering): the vault file is modified.
• E (privilege): memory access on a rooted device.

Step · countermeasures

• Passwords encrypted with AEAD (I → C).
• A key from the master password via KDF.
• An integrity tag (T).
• Short-lived memory + RASP (E).

Step · residual risk

• While the master password is being typed on a rooted device, it may be exposed in memory.
• Mitigation: fast erasure, device binding.
• Written down explicitly.

From this week to the project

• S2–S5: product, architecture, asset list, threat model.
• S1: scope, sources.
• Every asset labelled C/I/I+; a countermeasure for every threat.

Final word (week 1)

Security is not a "feeling," it's a process: know the asset, model the threat, protect with layers, write down the residual risk.

We'll use this framework all term.