class: big, middle

# ECE 7420 / ENGI 9823: Security

.title[
  .lecture[Lecture 0:]
  .title[Goals]
  
  
]

---

# Overview

### Background

### Goals for the course

### Goals for computer security

---

# Background

### What's your background?

* academic program
--

* security background/interest/practices

### My background

* education
???

I did my undergraduate degree here at Memorial; I know (and care about!)
the program deeply.
Then I went off to the University of Cambridge for my PhD, where I looked into
some of the privacy problems with online social networking (TL;DR: there are a
lot) and approaches by which we could build something better.

* privacy and security research

???

My graduate students and I work in privacy and security for real systems,
very broadly defined.
Specifically, we've done work in:

* [security protocols](https://dx.doi.org/10.1007/978-3-662-45921-8_16)
 * operating systems
   * [application sandboxing](https://dl.acm.org/doi/abs/10.1145/2093548.2093572)
   * [cryptographic filesystems](https://link.springer.com/chapter/10.1007/978-3-030-57043-9_17)
   * [security-enhanced hardware](http://cheri-cpu.org)
 * privacy and social networks ([PhD](https://doi.org/10.48456/tr-825),
   [IEEE Security & Privacy summary](https://ieeexplore.ieee.org/iel7/8013/5210089/06482125.pdf))
 * applications:
   * [full-motion video integrity](https://dx.doi.org/10.1007/978-3-030-98883-8_3)
   * health privacy
   * [marine systems](https://www.eventbrite.com/e/cybersecurity-of-autonomous-surface-ships-registration-324004083937)

---

# Course goals

### To pass! &#x1F600;

???

To learn how to pass, please consult the
[course outline](../../resources/outlines)!

### What are you looking for in this course?

### My goal: give an introduction to fundamental ideas.

* "what every computer engineer should know about security"
--

* **not** a rigorous treatment of all aspects of computer security
--
: foundation for further study with **some** in-depth exploration

???

You won't come out of this course being an expert in computer security.
Specificially, you should **not** call yourself a:

* cryptographer
* network defender
* penetration tester
* protocol designer
* secure "coder"

After completing this course, you should at least have the **vocabulary** with
which to discuss security issues that come up in computer engineering.

---

# Course content

### Introduction

### Software security

### Host security

### Network security

### Web security

???

The four content modules of the course will be approximately similar in length,
although they may not be exactly the same in breadth or depth.
We will be able to go deeper in some areas than in others.

---

# Course resources

???

Everything that I'll expect you to know will be discussed in the lectures.
Thus, I suggest that you **take notes** in these lectures of what we discuss
and **review them** immediately afterwards.
Make sure that you **understand** these ideas and, where possible, can
**apply** them.

In addition to the lecture materials, further reading is definitely encouraged!
Rather than scouring YouTube, however, where you can find anybody to say
anything, I'll point you at a couple of excellent (but still free) resources.

### _Tools and Jewels_ (van Oorschot)

* Hardcover from [Springer](https://link.springer.com/book/10.1007/978-3-030-83411-1)
 * Free PDFs from [PVO's website](https://people.scs.carleton.ca/~paulv/toolsjewels.html)

???

I am recommending a "textbook" for this course, but we won't be following it
very strictly.
It's a good book, though, so I'd definitely recommend checking it out.
You can buy a hardcover version (which looks great on a shelf!)
[from Springer](https://www.springer.com/us/book/9783030336486),
but Prof. Van Oorschot publishes PDFs of the book's chapters for free
[on his website](https://people.scs.carleton.ca/~paulv/toolsjewels.html).

### _Security Engineering_ (Anderson)

* Third edition is current
 * Second edition
   <a href="https://www.cl.cam.ac.uk/~rja14/book.html">
   still available as free PDFs
   </a>

???

_Security Engineering_ by Ross Anderson
(no relation, apart from our
[academic family tree](https://academictree.org/computerscience/peopleinfo.php?pid=878673))
is the most fun you'll ever have reading 1,000 pages.
We'll use it as a reference, and it's another one to keep handy on your shelf.

---

# Course evaluation

### Assignments: _individual_ work
--
 ("I did this")

???

From the course outline:

> Academic integrity means taking full responsibility for the academic work you
> submit in this course, so that I can evaluate you on the basis of
> *your own knowledge and effort*.
> When you submit work, you must *acknowledge sources* of both facts
> (references) and their presentation (authorship).
> It is an academic offence to claim work as original when it has been
> substantially derived from another source without attribution, whether that
> source is another person or a generative artificial intelligence tool.
> If GAI is permitted in a deliverable, you must reference any GAI tools you
> use and provide the sequence of prompts in an appendix.

### Labs: done in pairs

### Case study or project: _self-directed_ investigation

???

The [case study (for undergrads) or project (for graduate students)](/project)
should be a self-directed investigation of a security topic:
an attack, a vulnerability, a defensive technique, etc.
Undergraduate case studies should be **descriptive** in nature.
Graduate projects need to include an element of **demonstration**
and/or **quantitative evaluation**.

### Midterm and exam

???

We will also have traditional written exams: a midterm and a final exam.

---

# Overview

### ~~Background~~

### ~~Goals for the course~~

### Goals for computer security

---

# Security goals

### Big question:

## Is my system/network/data "secure"?

???

Question asked by the ignorant: "bottom line, is it secure?"

### Big answer:

## No!

???

If we want a more meaningful **answer**,
we must ask a more meaningful **question**.

---

# Security questions

### Typical SE question:

## Can the system do X for me?

### Typical security question:

## Can the system do X _against_ me?

### We'll do some negative thinking...
???

Negative thinking in two senses:

1. thinking about negative things,
2. thinking _in the negative_ about what is _not_ possible.

--
 but not always!

???

We won't _always_ be thinking negatively: proper privacy and security practices
can **enable** amazing and even beautiful things!
A secure system is one that can be extended in new and originally-unintended
ways.

---

# Thinking about security

### Security properties: CIA[AAA]

### Security policies

### Security mechanisms

### Security violations

### Security activities

---

# CIA[AAA] properties

* Confidentiality
* Integrity
* Availability
???

Confidentiality is often the first goal that people think of, but it's not
always the most important.
For example: believe it or not, I don't care all that much about the
confidentiality of my bank account (maybe if I had more money than student debt,
but that's not the case!).
However, I care very much about the **integrity** of my bank balance and about
the **availability** of the banking system.

* Authentication
--

* Authorization
--

* Accountability

???

Understanding the security **properties** we might want to have enables us
to think clearly about...

---

# Security mechanisms

* Techniques
???

We'll be introduced to lots of techniques in this course:
stack smashing, memory safety, fuzzing, ASLR, ROP gadgets,
DAC, MAC, ciphers, hashes, John the Ripper, biometrics,
compartmentalization, digital signatures, protocols,
double-ratcheting private messaging, VPNs, cross-site scripting,
SQL injection, Onion sites...

--
, systems
--
, products
--
, SOCs&ast;.footnote[&ast; See: https://taosecurity.blogspot.com/2018/06/why-do-socs-look-like-this.html]... whee!
???

Big screens make for exciting television.

* Do your mechanisms give the **right properties**?
--

* Don't be vendor-led.
???

Being vendor-led is OK if your goal is, "we want things that look shiny that
are at least as expensive as what our competitors have."
Speaking cynically, that's actually what some people's goal is: to show that
they've put enough money or work into their system that they can't be fired if
things go South.
However, that's not a security goal: it's a job security goal!

* Don't be mechanism-led.
--

* Start with the **policy**!

???

Policy talks about what we **want**... how do we talk about what we
**don't want**?

---

# Security policy

## Separable from mechanism

???

e.g., "no lone access" vs cryptography, two-factor authentication...

Mechanism is "cool" (everyone loves words like **encryption** and
**blockchain**), but mechanism is not our first priority!

### What should happen

### What should not happen

???

e.g., an integrity policy: video evidence is what was taken, wasn't altered

---

# Security violations

## _What's the worst that could happen?_

### Threat

???

**Threat:**
"combination of circumstances and entitites inclined to harm assets,
i.e., cause security violations" (Oorschot)

### Vulnerability

???

**Vulnerability:**
weakness that could allow a threat to be realized by an...

### Adversary

???

**Adversary:**
a **person** or **group** (not a **force**!) that wants to violate your policy
via an...

### Attack

???

**Attack:**
an adversary _exploits_ one or more vulnerabilities (the _attack vector_)
in order to bring the threatened harm about

---

# Security activities

### Proactive:

???

This course will focus on the **proactive** elements of this problem.
How have attackers exploited vulnerabilities, and how can we use that knowledge
to **build better systems** that are **less vulnerable** to attack?

* Threat modeling and risk assessment
--

* Prevention and mitigation

### Reactive:

???

Reactive elements of computer security are also important, but they aren't the
focus of this course.
Somebody absolutely needs to do **forensic analysis of computer images**,
to identify **how a threat actor broke in** and **who did it**.
However, those things are mostly of interest to engineers insofar as they
help us **build better systems**.

* Incident response and post-attack mitigation
--

* Attribution
--
... and response

---

# Next time...

### Threat modeling

### Adversarial thinking

---
class: big, middle

The End.