Info Scurity Priv

Security (definition)

Protecting assets from threats posed by adversaries; systems contain assets, adversaries want them, and they use attack surfaces to interact with the system.

Asset

What we are trying to protect (user data, systems/functionality, availability, physical resources). Not all assets are equally valuable (e.g., passwords > usernames, payment data > UI preferences).

Threat

A potential source of harm / what could go wrong (data theft, unauthorized access, service disruption, data manipulation).

Vulnerability

A weakness in a system.

Attack

Exploiting a vulnerability to realize a threat. Chain: threat -> vulnerability -> attack -> impact.

Adversary types

Casual attackers (script kiddies), cybercriminals, insiders, nation-state actors. They have different capabilities and goals.

Attack surface

Everywhere an attacker can interact with the system: login forms, APIs, network interfaces, user input fields. In threat modeling it = entry points for threats; every attack surface is a place to look for threats.

CIA triad

The core security goals: Confidentiality, Integrity, Availability.

Confidentiality

Only those who should have access do. Violations: exposed personal data, password leaks.

Integrity

Only those who should be able to change data/systems can. Violations: changing grades, modifying transactions.

Availability

The system remains available and usable when legitimate users need it. Violations: website outages, denial of service, ransomware.

A university website is down during registration. Which CIA property is hit?

Availability.

Equifax breach: summary and CIA impact

~147 million people's data (SSNs, birth dates, addresses) exposed. Attackers exploited an unpatched web app vulnerability (input handling). Asset: sensitive personal data. Impact: Confidentiality.

Colonial Pipeline attack: summary and CIA impact

Ransomware shut down a major US fuel pipeline for several days, causing fuel shortages. Asset: operational systems. Impact: Availability.

Risk formula

Risk = Likelihood x Impact.

What affects likelihood?

Known vulnerabilities, mitigation strategies in place, and difficulty to exploit.

What affects impact?

Financial cost, business operations, and users (harm to people).

Three ways to get risk to a manageable level

Reduce likelihood, reduce impact, or accept the risk.

Security tradeoffs

Security vs functionality, usability, performance, and cost. Security is about tradeoffs, not absolutes.

Why does security fail in the real world?

Complexity, human error, poor assumptions, misaligned incentives, and overtrust in tools.

Most vulnerabilities are… (secure dev mindset)

Not advanced zero-days. Common sources: missing input validation, incorrect assumptions about users, overly complex systems, misconfigured systems.

Threat modeling (definition)

A structured way to identify threats, understand risk, and design defenses; ideally done early in system design. Helps prioritize risks; many failures are predictable.

Five steps of the threat modeling process

1) Understand the system 2) Identify assets 3) Identify threats 4) Evaluate risk 5) Design mitigations.

Step 1: understanding the system - what do you identify?

Components (app, backend, DB, devices), data flows, and external dependencies (APIs, third parties). "You can't secure what you don't understand." Focus on how the system actually operates, not how it's supposed to.

Step 1 key questions

Who uses the system? What are the main features? Where does data enter and leave? What are the trust boundaries?

How do you prioritize assets?

Ask what attackers would want most and what would cause the most harm if compromised. Prioritization focuses effort.

STRIDE (what it is)

A threat modeling framework where each letter is a way a system can fail; it is a prompting tool: pick a component and ask what each category would look like there, then write down concrete threats.

STRIDE: Spoofing

Pretending to be someone else.

STRIDE: Tampering

Modifying data or systems.

STRIDE: Repudiation

Denying actions (claiming you didn't do something).

STRIDE: Information disclosure

Exposing data.

STRIDE: Denial of service

Making systems unavailable.

STRIDE: Elevation of privilege

Gaining more access than allowed.

Map: data theft / unauthorized changes / service disruption to CIA

Data theft -> confidentiality; unauthorized changes -> integrity; service disruption -> availability.

Other threat modeling frameworks besides STRIDE

Risk-based frameworks (prioritize by impact) and privacy-focused frameworks (data collection, tracking, consent: what is collected, who can access it, how long it is stored). There is no single correct framework.

Risk-based thinking in threat modeling

After finding threats ask: how likely is it? What is the impact? Prioritize what matters; don't try to fix everything; focus on high-risk threats first.

Good mitigations are…

Specific, practical, and tied to a threat.

Key ideas of threat modeling

It maps attack surfaces to possible threats; more features = larger attack surface; more complexity = more risk; it is iterative.

Smart home example: attack surfaces

Mobile app, backend API, IoT devices, network connections.

Defense in depth

Use multiple, redundant defenses and assume some will fail, so one failure doesn't break everything. Layers reduce risk; no single defense is perfect.

Defense in depth example: logins

Input validation, authentication, rate limiting, logging and monitoring.

Security vs usability (human factors)

Stronger security can reduce usability; users reuse passwords, ignore warnings, and bypass controls. Humans are part of the system, and security failures often involve both technical and human factors.

Automation bias

Overtrust in automated tools (e.g., blindly accepting AI suggestions, ignoring system warnings). Tools aren't perfect and AI can introduce vulnerabilities, so developers must verify, question, and think critically.

Secure development mindset

Assume attackers will interact with your system (unexpected input, bypassing checks, edge cases). Ask "how will someone abuse this?" in design, implementation, and testing.

Secure SDLC phases

Requirements, design, implementation, testing, deployment (and maintenance). Security is integrated throughout.

Why is security a design problem?

Many issues originate in architecture and feature decisions; code cannot fix a bad design.

Abuse case

Like a use case but describes how the system can be misused. Example: use case = upload a profile picture; abuse cases = upload a malicious file or an extremely large file. Ask "what could go wrong here?"

Principle of least privilege (secure design)

Give users/components only the access they need; limits damage if compromised (e.g., user shouldn't be admin; service only accesses required data).

Fail securely

Systems will fail, so plan to fail in a way that reduces risk (e.g., an error should not expose sensitive information).

Key secure design ideas

Assume adversarial behavior; design for misuse, not just use; reduce trust in inputs and users; limit damage when things go wrong; security is a way of thinking.

OWASP Secure Coding Guidelines

A practical developer checklist focused on common vulnerabilities and prevention techniques; bridges theory and practice. There is no universal secure code recipe (context: language, system type).

Code review (what and limits)

Manual inspection of code, ideally by someone other than the author, to catch bugs/vulnerabilities. It is imperfect: reviewers miss context-dependent and multi-file vulnerabilities, find simple bugs more than complex ones, and more experience did not mean better detection.

Static analysis: definition, pros, cons

Analyzes code without running it. Pros: scalable, finds known issues. Cons: false positives, limited coverage, may miss context-dependent issues.

Dynamic analysis: definition, pros, cons

Tests the running system. Pros: realistic behavior, finds runtime issues. Cons: complex setup, resource intensive, incomplete coverage.

AI-assisted security tools: risks and benefits

Use ML/LLMs to detect vulnerabilities and suggest fixes. Fast and scalable, but can generate insecure fixes/vulnerabilities with confidence. Useful as a first pass but requires serious verification.

Why developers don't use security tools

Complex setup, hard-to-interpret output, too many false positives, organizational barriers. Tools are not automatic security.

Vulnerability management / routine testing

Organizations track many systems and vulnerabilities: identify, prioritize, fix. Uses vulnerability scanners, mailing lists, API/dependency notifications. Software supply chain is an increasing problem.

Types of vulnerability databases

Commercial (companies sell scanning software and notify orgs), public (crowdsourced), and government (managed by agencies).

CVE

Common Vulnerabilities and Exposures: catalog that identifies, defines, and catalogs publicly disclosed vulnerabilities. Operated by MITRE on behalf of DHS. A CNA assigns/publishes the CVE ID.

CVSS

Common Vulnerability Scoring System: a measure of severity used to prioritize which vulnerabilities to fix first.

NVD

National Vulnerability Database: repository of standard vulnerability data that receives CVEs and enriches them (CVSS scores, impact metrics, product names) to enable automation of vulnerability management.

Process memory layout (high to low)

Kernel, stack (local vars and function control data), free space, heap (global vars, dynamically allocated memory), program code.

Stack frame contents

Local variables, arguments, saved registers, plus the old EBP (base of previous frame) and the return address (Return IP).

Why do return addresses matter?

The return address determines where the program executes next; corrupting it lets an attacker redirect execution flow.

Buffer overflow (definition)

Writing beyond the limits of a fixed-size buffer, overwriting adjacent memory.

Why are buffer overflows dangerous?

They can corrupt program data, crash the program, or give arbitrary code execution (by overwriting the return address/control data).

What causes buffer overflows?

Unsafe functions (strcpy, gets), no automatic bounds checking in C, which puts validation on the developer; assumptions about input size.

How do attackers exploit buffer overflows?

Overwrite the return address or other control data to redirect execution to injected code or to existing code.

Return-to-libc attack

Instead of injecting malicious code, reuse code already in memory (standard libraries/system functions), e.g., system("/bin/sh").

Use-after-free

Accessing memory after it was freed. The memory may be reused by something else, so reads/writes via the dangling pointer hit another object: unpredictable behavior, crashes, or exploitation.

Mitigation for use-after-free

Set pointers to NULL after free and check for NULL before use.

Double free

Freeing the same memory twice; can cause crashes and heap corruption because the memory manager gets confused and allocations can overlap/overwrite each other.

Integer overflow

Integers have a limited range (depends on language/architecture), and values wrap around at the end of the range.

Uninitialized variables

Using a variable without initializing it takes whatever junk was left in memory: undefined, hard-to-reproduce behavior, crashes, information leakage/manipulation.

Out-of-bounds access

Buffer overflow is an out-of-bounds write; you can also read out of bounds (info leak).

Heartbleed

Famous OpenSSL out-of-bounds read vulnerability that leaked passwords, encryption keys, and other sensitive memory.

Code: char *buf = malloc(8); free(buf); printf("%s", buf); What's wrong?

Use-after-free: reading freed memory. Dangerous because the memory may have been reused (leaks/corrupts data, undefined behavior). Fix: set buf = NULL after free and check it.

Four categories of memory-safety defenses

Secure development practices, safe functions, runtime defenses, memory-safe languages.

Secure development practices for memory safety

Validate input sizes, check bounds carefully, avoid unsafe assumptions.

Safe vs unsafe C functions

gets/strcpy have no bounds checking and assume input fits the buffer. fgets/strncpy require a size from the developer and copy only up to that size.

Stack canary

A random value placed on the stack before the return address; checked before returning to detect stack corruption.

ASLR

Address Space Layout Randomization: randomizes locations of memory regions (stack, heap, etc.) so attackers can't predict addresses; wrong guesses crash the program.

Non-executable memory (NX)

Marks regions like stack/heap as read/write only (not executable), preventing attackers from running code they placed there.

Runtime defenses purpose

Stack canaries, ASLR, and non-executable memory make buffer overflow exploitation harder (not impossible).

Memory-safe languages

Garbage-collected languages avoid these problems but are heavy and can't replace C everywhere. Rust is not garbage collected but enforces memory safety rules at compile time.

Injection attack (core idea)

Software treats data as instructions: the app expects data, the attacker supplies instructions, and the interpreter can't tell developer commands from attacker commands.

Most important rule of input

Never trust input. Everything outside your application is untrusted.

Sources of untrusted input

Users (forms), web traffic (URLs, cookies, HTTP headers, network packets), files, databases, APIs, environment variables, AI-generated content.

Memory safety vs injection: what is trusted?

Memory safety bugs trust input size/memory boundaries; injection trusts that user input is only data.

Input validation: what do we validate?

Length, type, format, range, characters. Define expectations early, be specific, and think about how input could be abused. (e.g., age = integer 0-120, zip = 5 digits.)

Why is validation necessary but not sufficient?

We might forget it, it may have bugs, or miss an edge case. It improves reliability, reduces attack surface, prevents errors, enforces business rules, but is NOT a substitute for separating code from data.

SQL injection (how it works)

App builds a query by concatenating user input into SQL (e.g., "… WHERE username = '" + username + "'"). Input like ' OR 1=1 changes the query logic so the attacker's input is executed as SQL.

What can an attacker do with SQL injection?

Bypass authentication, read sensitive info (password hashes, financial records, PII), modify data (balances, grades), delete data. Impact depends on DB permissions.

Injection family: interpreter and attacker goal

SQL (DB) -> SQL code; OS command -> shell commands; LDAP -> LDAP filters; XPath/XML -> XPath expressions; NoSQL; template engine -> template code (server-side code execution); AI system -> new instructions (prompt injection). Same mistake: untrusted input changes the meaning of an instruction.

Command injection

App passes user input into an OS command (e.g., "ping " + userInput) and attacker supplies shell commands. Impact: execute OS commands.

LDAP injection impact

Bypass authentication (attacker manipulates LDAP queries/filters).

Template injection impact

Execute server-side code.

AI prompt injection

AI apps combine info from multiple sources into one prompt; an attacker places instructions in user input or retrieved content to influence the model (e.g., "ignore all previous instructions…").

Primary defense against injection

Separate code from data so the interpreter knows which is which: prepared statements/parameterized queries for SQL; command APIs with separate arguments for OS commands. Good design makes it impossible for input to change instructions.

Safe APIs: avoid vs prefer

Avoid SQL built with strings, shell commands from strings, manual escaping, writing your own security logic. Prefer prepared/parameterized queries, APIs that pass arguments separately, framework parameter binding/encoding, well-tested library functions.