Introduction and Security Principles

CS 161 Summer 2026 - Lecture 1

Computer Science 161

First: Introductions and Logistics

• Course overview: What will you learn in this class?
• Course logistics
• What is security? Why is it important?

2

Computer Science 161

Course Overview

3

Computer Science 161

Learning Objectives

• How to think adversarially about computer systems
• How to assess threats for their significance
• How to build computer systems with robust security properties
• How to gauge the protections and limitations provided by today's technology
• How attacks work in practice

​

• What mistakes not to make!

4

Computer Science 161

Course Outline (OLD)

• Introduction to Security
• What are some general philosophies when thinking about security?
• Memory Safety
• How do attackers exploit insecure software? How do we defend against these attacks?
• Cryptography
• How do we securely send information over an insecure channel?
• Web Security
• What are some attacks on the web, and how do we defend against them?
• Network Security
• What are some attacks on the Internet, and how do we defend against them?
• Miscellaneous Topics
• Useful, interesting, or fun applications of topics.

5

Computer Science 161

Extra Tools and Skills

• Some extra non-security-related skills you can take away from this class:
• Low-level systems programming
• x86 assembly: A commonly-used assembly language
• Using GDB: Debugging C code
• Web systems speedrun
• Software engineering: Understanding how websites are built and how your web browser interacts with remote web servers (CS 169 preview)
• Networking speedrun
• Networking: How the Internet works (CS 168 preview)

6

Computer Science 161

Prerequisites

• CS 61B: Ability to work with large and complex codebases, data structures
• Relevant for Project 2 (500–1000 lines of Go code)
• CS 61C: Familiarity with low-level memory layouts and assembly
• We'll have a review section on C ~Tuesday
• Relevant for Project 1
• CS 70: Familiarity with basic mathematical notation and proof structures
• Relevant for Cryptography
• We’ll review CS 70 material as we encounter it during the cryptography lectures
• An ability to pick up new programming languages quickly
• Project 2 will be in Go

7

Computer Science 161

Course Logistics

8

Computer Science 161

Course Logistics

• All course logistics are available on our website: https://cs161.org
• Policies page: https://cs161.org/policies/
• FAQs page: https://cs161.org/resources/faqs/
• Won't cover logistics live during lecture, so please read those pages!
• We'll just do some quick reminders (copied from the pages above).
• See the course website or hidden slides for lots more.

9

Computer Science 161

Course Logistics

• Discussions and office hours start this week.
• You can attend any discussion section you want. Attendance is not taken.
• Exam dates are on the website (TBD).
• Only one alternate exam, in-person only, immediately after main exam.
• Stress management and accommodations:
• If you are registered with the Disabled Students' Program (DSP), please send us your letter of accommodations through the DSP portal as soon as possible.
• Your well-being is more important than this class. The website has a link to a form to request extensions.

10

Computer Science 161

Temptation

• In this class, you will learn a lot about attacks out of necessity
• To be able to defend against the attacker, you must learn the techniques that attackers use
• It is usually okay to break into your own systems
• This is a great way to evaluate your own systems
• It is usually okay to break into someone else’s systems with their explicit permission
• For this class, per the misconduct policy, please don't share test cases to break into others' systems
• It is grossly unethical and exceedingly criminal to break into someone else’s systems without their permission

11

Computer Science 161

Course Structure: Lectures

• MTWT, HFAX A1 12:30-2:00
• Attendance is not taken

12

Computer Science 161

Course Structure: Discussions

• Smaller sections led by a TA to practice with material
• Discussions start TBD; schedule: https://cs161.org/calendar
• Not mandatory but highly recommended!
• You can attend any discussion section you want (no need to enroll in a section)
• Attendance is not taken

13

Computer Science 161

Course Structure: Office Hours

• Space to ask questions about content, get help with projects, raise concerns with the course, etc. with a TA or instructor
• Schedule available at https://cs161.org/calendar; starts TBD
• Office hours are primarily in-person (but we might take a few online requests if TAs are idle)
• When you show up, add yourself to the office hours queue at https://oh.cs161.org/

14

Computer Science 161

Course Structure: Exams

• Midterm: TBD
• Final: TBD
• Alternate exam offered in-person only, immediately after the regular exam
• Forms to request alternate exams will be released closer to the exam

15

Computer Science 161

Resources

• Textbook: https://textbook.cs161.org/
• Free! There’s no textbook you need to pay for.
• Readings are optional, but past students have said the textbook is helpful
• Course website: https://cs161.org/
• Course schedule, lecture slides, assigned readings, and other resources are all posted here

16

Computer Science 161

Platforms

• Ed (https://edstem.org)
• Discussion forum
• Course-related communication should take place in Ed or happen in office hours
• For private matters, you can make a private post
• Please don’t post publicly about project spoilers!
• Gradescope
• All assignments are submitted and graded on Gradescope
• Email
• Post on Ed for most matters (a private post is fine).
• For private matters that you prefer to be limited to only a handful of course staff, you can email cs161-staff@berkeley.edu. Staff with email access are tagged as “Staff Email Access” on the staff page of the website.
• Ed response is faster, but staff will monitor the email if you’re more comfortable with that

17

Computer Science 161

Grading Structure

• Vitamins: 3%
• Homework: 7%
• Complete individually (no partners/groups)
• 7 homeworks in total, weighted equally
• Learn from your mistakes: If you get a question wrong, no worries, you can study the material and then submit again at no penalty, but make sure to answer the last question
• No credit for submitting late, unless you have an extension
• Projects: 40%
• P1 = 10%, P2 = 20%, P3 = 10%
• Completed individually or in groups of 2
• No credit for submitting late, unless you have an extension
• Midterm: 20%
• Final: 30%

18

Computer Science 161

Class Policies: Extensions

• We do not have slip days or assignment drops in this course!
• However, you can request extensions on any assignment for any reason:
• Extensions form linked on the website
• Extensions ≤3 days will be routinely approved if submitted before the deadline
• Longer extensions may be approved, but we’ll need to check in first to make sure you’re on pace to finish the class
• It is okay to request an extension if things come up! We’re here to support you!
• Life happens.
• You can always request an extension for any reason (e.g. stress, other classes, etc.)
• We want to keep deadlines to make sure you’re on track to finish, while reducing the associated stress

19

Computer Science 161

Class Policies: DSP

• Disabled Students’ Program (DSP)
• There’s a variety of accommodations UC Berkeley can help us set up for you in this class
• https://dsp.berkeley.edu/
• Are you facing barriers in school due to a disability?
• Apply to DSP!
• We maintain proper access controls on this information: Only the staff members with the "DSP Data" tag on the website can access any DSP-related info
• Our goal is to teach you the material in our course. The more accessible we can make it, the better.
• If you're registered/registering with DSP:
• Please send us your Letter of Accommodations (LOA) through AIM (the DSP portal) ASAP!
• We will be sending out onboarding materials to all DSP students who have sent us their LOA in AIM soon, please keep an eye out

20

Computer Science 161

Class Policies: Collaboration

• Asking questions and helping others is encouraged
• Discussing course topics with other is welcome!
• Limits of collaboration
• Don’t share solutions with each other (except project partners)
• You should never see or have possession of anyone else’s solutions—including from past semesters
• If you're not sure, see the policies page on the website, or ask us first
• Staff is not responsible for partnerships
• If you work in a group, the penalties apply for all group members, even if only one group member engaged in misconduct, or if the other group member was unaware of the misconduct.

21

Computer Science 161

Class Policies: Academic Honesty

• We’re here to help! There are plenty of staff and resources available for you
• You can always talk to a staff member if you’re feeling stressed or tempted to cheat
• Academic dishonesty policies
• Negative points on the assignment (e.g. if the midterm is worth 150 points, you'd receive a score of -150 on the midterm)
• Referral to the Center for Student Conduct

22

Computer Science 161

Class Policies: Academic Honesty

• As a computer security class, we view potential cheaters as “attackers.”
• Our threat model assumes “rational” attackers.
• A rational attacker will only launch an attacker if (expected benefit) > (expected cost)
• (expected cost) = (cost of launching attack) + (cost of getting caught) * (probability of getting caught)
• Two-fold approach to academic integrity:
• Detection: Use our tools to analyze and detect instance of academic dishonesty.
• You will learn that “security through obscurity” is bad, but obscurity can help. We have ways.
• Response: At minimum, you will receive negative points on the assignment.

23

Computer Science 161

Stress Management and Mental Health

• We want to reduce your stress where we can
• Project 2 (mid-semester) is going to be the most intensive part of this class, but we’ve made things lighter towards the end (when every other class has stuff due)
• Your health is more important than this course
• If you feel overwhelmed, there are options
• Academically: Ask on Ed, talk to staff in office hours, set up a meeting with staff to make a plan for your success this semester (see "student support" on the policies web page)
• Non-academic:
• Counselling and Psychological Services (CAPS) has multiple free, confidential services
• Casual consultations: https://uhs.berkeley.edu/counseling/lets-talk
• Crisis management: https://uhs.berkeley.edu/counseling/urgent
• Check out UHS’s resources: https://uhs.berkeley.edu/health-topics/mental-health

24

Computer Science 161

Course Climate

• Please respect each other! This includes but is not limited to:
• Treat others with respect and kindness
• Post appropriate content on Ed
• Use the chosen pronouns of your fellow students & staff members
• I encourage you to help and support others! We learn from each other, and we're stronger together.
• If you feel as though you have been impacted by a poor course climate, we have an anonymous feedback form on the website.

25

Computer Science 161

Case Studies and Blue Slides

• Security is often best taught through real-world case studies and stories
• Lectures will sometimes use real-world examples to demonstrate concepts
• Slides with a blue background are case study slides

26

Computer Science 161

Example Case Study: Stuxnet

• Stuxnet: Discovered July 2010, released approximately March 2010
• Malicious code designed to only activate under very specific circumstances
• For most computers, do nothing
• For computers connected to the Iranian nuclear program, run centrifuges a little too fast so they self-destruct
• Researchers later deduced that Stuxnet was created by the United States and Israel to target Iran’s nuclear program
• Is it ethical that the US and Israel are the "attackers" in this scenario?
• Who decides what is "legal" and ethical in this scenario?

27

Computer Science 161

What is security?

28

Computer Science 161

What is security?

Enforcing a desired property in the presence of an attacker

​

​

data confidentiality

user privacy

data and computation integrity

authentication

availability

…

29

Computer Science 161

Why is security important?

• It is important for our
• physical safety
• confidentiality/privacy
• functionality
• protecting our assets
• successful business
• a country’s economy and safety
• and so on…

30

Computer Science 161

Why is security important?

• Consider: Physical Safety

31

Computer Science 161

Why is security important?

• Consider: Privacy/Confidentiality

32

Computer Science 161

Why is security important?

• Consider: National security

33

Computer Science 161

What is hackable?

• Every software!
• Especially things connected to the Internet
• Assume that every system is a target
• A casino was hacked because a fish-tank thermometer was hacked within the network

34

Computer Science 161

Security Principles

Textbook Chapter 1

35

Computer Science 161

First Module: Security Principles

• Security principles
• Know your threat model
• Consider human factors
• Security is economics
• Detect if you can’t prevent
• Defense in depth
• Least privilege
• Separation of responsibility
• Ensure complete mediation
• Don’t rely on security through obscurity
• Use fail-safe defaults
• Design in security from the start

36

Computer Science 161

Sending a message (Cryptography preview)

Create a system to transmit a secret message.

• After you make a system, we'll pick one group to be the senders and receivers (together defenders). Everyone else will be attackers.
• I'll provide a message (composed of two English words) to the sender. The sender will use their system to type anything on screen for the entire class to see.
• The defenders win if the receivers get the message without any attackers getting the message. The attackers win if they figure out the message, or if the defenders fail to recover the message.

37

Computer Science 161

Principle: Know Your Threat Model

Textbook Chapter 1.1 & 1.12

38

Computer Science 161

The Parable of the Bear Race

“I don’t have to outrun the bear. I just have to outrun you.”�Takeaway: You often just need to have “good enough” defense to make attackers turn somewhere else.

39

Reminder: blue slides are case studies. Remember the takeaway, not the story!

Computer Science 161

Security Principle: Know Your Threat Model

• Threat model: A model of who your attacker is and what resources they have
• Why do people attack systems?
• Money
• Politics
• Retaliation
• Fun, watching the world burn
• "Fort Knox" security vs "arms race" security

40

Computer Science 161

Security Principle: Know Your Threat Model

• Consider: Personal security
• Who and why might someone attack you?
• Criminals might attack you for money
• Teenagers might attack you for laughs or to win online games
• Governments might spy on you to collect intelligence
• Intimate partners might spy on you

41

Reminder: blue slides are case studies. Remember the takeaway, not the story!

Computer Science 161

Threat Model: Common Assumptions for Attackers

• Assume the attacker…
• Is knowledgeable and motivated
• Knows general information about target system (what software version is being used, etc.)
• Can get lucky
• If an attack only succeeds 1/1,000,000 times, the attacker will try 1,000,000 times!
• Has more resources than you

​

42

Computer Science 161

Trusted Computing Base

• Trusted computing base (TCB): The components of a system that security relies upon
• Properties of the TCB:
• Correctness
• Completeness (can’t be bypassed)
• Security (can’t be tampered with)
• Generally made to be as small as possible
• A smaller, simpler TCB is easier to write and audit.
• KISS principle: Keep It Simple, Stupid

43

Computer Science 161

Sending a message (Cryptography preview)

Create a system to transmit a secret message.

• The defenders win if the receivers get the message without any attackers getting the message. The attackers win if they figure out the message, or if the defenders fail to recover the message.

Who are the attackers?

• Everyone in the room. (Massive processing advantage)
• Attackers may use computers for brute-forcing. Defenders cannot use computers. (Resource advantage)

44

Computer Science 161

What's the Lesson?

45

Computer Science 161

Accident on Motorway

46

Here’s the hidden computer inside the sign.

Here’s a highway sign.

Here’s the control panel. Most signs use the default password, DOTS.

Computer Science 161

Caution! Zombies Ahead!!!

Note: Do not ever do this.

47

Computer Science 161

Trapped in Sign Factory! Send Help!

Takeaway: Shannon’s maxim/Don’t rely on security through obscurity

48

Computer Science 161

Principle:�Don’t Rely on Security Through Obscurity

Textbook Chapter 1.9

49

Computer Science 161

Security Principle: Shannon’s Maxim

• Shannon’s maxim: “The enemy knows the system”
• You should never rely on obscurity as part of your security. Always assume that the attacker knows every detail about the system you are working with (algorithms, hardware, defenses, etc.).

50

Assume the attacker knows where the “secret” control panel is located, and has read the manual with instructions on resetting the password.

Computer Science 161

Sending a message (Cryptography preview)

Create a system to transmit a secret message.

• The defenders win if the receivers get the message without any attackers getting the message. The attackers win if they figure out the message, or if the defenders fail to recover the message.

Before starting, the defenders must tell the entire class how their system works. (You may not rely on security through obscurity).

The defenders are allowed one number or word to be shared secretly (a secret key) that the attackers don't know. You must decide on a key beforehand, and your system should be able to send arbitrary messages for any key.

51

Computer Science 161

Sending a message (Cryptography preview)

Create a system to transmit a secret message.

• After you make a system, we'll pick one group to be the senders and receivers (together defenders). Everyone else will be attackers.
• The sender explains their system to the class, but gets one secret key.
• I'll provide a message (composed of two English words) to the sender. The sender will use their system to type anything on screen for the entire class to see. Attackers may use computers/online tools, defenders may only use basic calculators.
• The defenders win if the receivers get the message without any attackers getting the message. The attackers win if they figure out the message, or if the defenders fail to recover the message.

52

Computer Science 161

Sending a message (Cryptography preview)

1. Take message
2. Convert to 8-bit to number [0-25] in binary, space to 26
3. Secret key is a finite length 32-bit bitstream, repeated over and over
4. XOR with bitstream, output bitstream
5. Receiver XORs with secret key

Ex. "cat" with Secret Key 0xDEADBEEF

cat -> 2 0 19

2 0 19 -> 00000010 00000000 00010011

XOR everybit with the secret key -> 0xdcadad

53

Computer Science 161

Break

54

Computer Science 161

What's the Lesson?

55

Computer Science 161

Warning Dialogs

56

When you send information to the Internet, it might be possible for others to see that information. Do you want to continue?

In the future, do not show this message.

Yes

No

Computer Science 161

Warning Dialogs

57

When you see a dialog box like this, click ‘Yes’ to make it go away. If available, click the checkbox first to avoid being bothered by it again.

Yes

No

In the future, do not show this message.

Computer Science 161

Warning Dialogs

58

Examine Certificate...

Accept this certificate permanently

Accept this certificate temporarily for this session

Do not accept this certificate and do not connect to this Web site

Website Certified by an Unknown Authority

Unable to verify the identity of svn.xiph.org as a trusted site.

​

Possible reasons for this error:

- Your browser does not recognise the Certificate Authority that issued the site’s certificate.

- The site’s certificate is incomplete due to a server misconfiguration.

- You are connected to a site pretending to be svn.xiph.org, possibly to obtain your confidential information.

​

Please notify the site’s webmaster about this problem.

​

Before accepting this certificate, you should examine this site’s certificate carefully. Are you willing to accept this certificate for the purpose of identifying the Web site svn.xiph.org?

OK

Cancel

Computer Science 161

Warning Dialogs

59

View Incomprehensible Information

The presence of warning dialogs often represent a failure: How is the user supposed to know what to do?�Takeaway: Consider human factors

Unable to verify the identity of svn.xiph.org as a trusted site.

​

Blah blah geekspeak geekspeak geekspeak.

​

Before accepting this certificate, your browser can display a second dialog full of incomprehensible information. Do you want to view this dialog?

Make this message go away permanently

Make this message go away temporarily for this session

Stop doing what you were trying to do

OK

Cancel

Computer Science 161

Principle: Consider Human Factors

Textbook Chapter 1.2

60

Computer Science 161

Security Principle: Consider Human Factors

• It all comes down to people: The users
• Users like convenience (ease of use)
• It doesn't matter how secure a system is, if it isn't used
• Users will disable security systems if it makes their lives easier
• Social engineering attacks exploit other people’s trust and access for personal gain
• It all comes down to people: The programmers
• Programmers make mistakes
• Programmers use tools that allow them to make mistakes (e.g., C and C++)
• Consider the tools presented to users, and make them fool-proof

61

Physical security keys use the fact that humans are trained to safeguard keys

Computer Science 161

What's the Lesson?

62

Computer Science 161

Physical Safes

Takeaway: Security is economics

• We want our safes to stop people from breaking in, so let’s measure them by how long it takes an expert to break into one:

63

Computer Science 161

Security is Economics

Textbook Chapter 1.3

64

Computer Science 161

Security Principle: Security is Economics

• Cost/benefit analyses often appear in security: The expected benefit to the attacker should ideally be smaller than the expected cost of attack
• More security (usually) costs more
• If the attack costs more than the reward, the attacker probably won’t do it
• Example: You don’t put a $10 lock on a $1 item…
• … unless a $1 item can be used to attack something even more valuable
• Example: You have a brand-new, undiscovered attack that will work on anybody’s computer. You wouldn’t expose it on a random civilian
• iPhone security exploits are sold for ~$1M on the market, so it’s probably safe to use an iPhone on a hostile network if you aren’t a $1M target

65

Computer Science 161

What's the Lesson?

66

Computer Science 161

Burglar Alarms

• Security companies are supposed to detect home break-ins
• Problem: Too many false alarms. Many alarms go unanswered
• Placing a sign helps deter burglars from entering at risk of being caught…
• … even if you don’t have an alarm installed!
• Takeway: Prevent attacks when you can, but detect them if you can’t

67

Computer Science 161

Principle: Detect If You Can’t Prevent

Textbook Chapter 1.4

68

Computer Science 161

Security Principle: Detect if You Can’t Prevent

• Deterrence: Stop the attack before it happens
• Prevention: Stop the attack as it happens
• Detection: Learn that there was an attack (after it happened)
• If you can’t stop the attack from happening, you should at least be able to know that the attack has happened.
• Response: Do something about the attack (after it happened)
• Once you know the attack happened, you can try to recover
• Detection without response is pointless!

69

Computer Science 161

Response: Mitigation and Recovery

• Assume that bad things will happen! You should plan security in way that lets you to get back to a working state.
• Example: Earthquakes
• Have resources for 1 week of staying put
• Have resources to travel 50 miles from my current location
• Example: Ransomware
• Keep offsite backups!
• If your computer and house catch on fire, it should be no big deal.

70

Computer Science 161

Detection but no Response

• Bitcoin transactions are irreversible. If you are hacked, you can never recover your Bitcoins.
• $68M stolen from NiceHash exchange in December 2017
• Four multi-million-dollar attacks on Ethereum in July 2018
• Coinbase: One detected theft per day
• Takeaway: Prevention is great, but you must not only depend on prevention; you must also respond

71

Computer Science 161

What's the Lesson?

72

Computer Science 161

The Theodosian Walls of Constantinople

• The ancient capital of the Byzantine empire had a wall…
• Well, they had a moat…
• then a wall…
• then a depression…
• … and then an even bigger wall
• It also had towers to rain fire and arrows upon the enemy…
• Takeaway: Defense in depth

73

Computer Science 161

Principle: Defense in Depth

Textbook Chapter 1.5

74

Computer Science 161

Security Principle: Defense in Depth

• Multiple types of defenses should be layered together
• An attacker should have to breach all defenses to successfully attack a system
• However, consider security is economics
• Defenses are not free. Don't increase the cost of defense beyond its benefit.

75

Computer Science 161

What's the Lesson?

76

Computer Science 161

Welcome to a Nuclear Bunker

77

Computer Science 161

Principle: Separation of Responsibility

Textbook Chapter 1.7

78

Computer Science 161

Security Principle: Separation of Responsibility

• If you need to have a privilege, consider requiring multiple parties to work together (collude) to exercise it
• It’s much more likely for a single party to be malicious than for all multiple parties to be malicious and collude with one another

79

Computer Science 161

What's the Lesson?

80

Computer Science 161

Spot the Issue

81

Computer Science 161

Principle: Ensure Complete Mediation

Textbook Chapter 1.8 & 1.13

82

Computer Science 161

Security Principle: Ensure Complete Mediation

• Ensure that every access point is monitored and protected
• Reference monitor: Single point through which all access must occur
• Example: A network firewall, airport security, the doors to the dorms
• Desired properties of reference monitors:
• Correctness
• Completeness (can’t be bypassed)
• Security (can’t be tampered with)
• Should be part of the TCB

83

The cars drove around the barrier

Computer Science 161

Time-of-Check to Time-of-Use

• Complete mediation can be challenging due to race conditions
• Consider the following code:

84

procedure withdrawal(w)

// contact central server to get balance

1. let b := balance

​

2. if b < w, abort

​

// contact server to set balance

3. set balance := b - w

​

4. give w dollars to user

Suppose you have $5 in your account. How can you trick this system into giving you more than $5?

Computer Science 161

Time-of-Check to Time-of-Use

85

withdrawal(w=5)�1. let b := balance�2. if b < w, abort

withdrawal(w=5)�1. let b := balance�2. if b < w, abort�

// contact server to set balance�3. set balance := b - w��4. give w dollars to user

// contact server to set balance�3. set balance := b - w��4. give w dollars to user

Time

Computer Science 161

What's the Lesson?

86

Computer Science 161

Soda Hall

• Rooms in Soda Hall are locked, with electronic card keys for access
• What do you do if the power goes out?
• Fail closed: No one can get in if the power is out
• Fail open: Anyone can get in if the power goes out
• What’s the best option to choose for closets with expensive equipment? What about emergency exit doors?
• Takeaway: What's the lesson?

87

Computer Science 161

Principle: Use Fail-Safe Defaults

Textbook Chapter 1.10

88

Computer Science 161

Security Principle: Use Fail-Safe Defaults

• Choose default settings that “fail safe,” balancing security with usability when a system goes down
• This can be hard to determine

89

Computer Science 161

What's the Lesson?

90

Computer Science 161

uTorrent

91

Computer Science 161

uTorrent

92

Computer Science 161

uTorrent

93

Computer Science 161

uTorrent

94

Computer Science 161

uTorrent

• What was this program able to do?
• Leak your files
• Delete your files
• Send spam
• Run another malicious program

• What does this program need to be able to do?

• Display a window on the screen
• Manage some files (but not all files)
• Make Internet connections

• Takeaway: What's the lesson?

95

Computer Science 161

Principle: Least Privilege

Textbook Chapter 1.6

96

Computer Science 161

Security Principle: Least Privilege

• Consider what permissions an entity or program needs to be able to do its job correctly
• If you grant unnecessary permissions, a malicious or hacked program could use those permissions against you

97

Computer Science 161

Principle: Design in Security from the Start

Textbook Chapter 1.11

98

Computer Science 161

Security Principle: Design in Security from the Start

• When building a new system, include security as part of the design considerations rather than patching it after the fact
• A lot of systems today were not designed with security from the start, resulting in patches that don’t fully fix the problem!
• Keep these security principles in mind whenever you write code!

99

Computer Science 161

Security Principles: Summary

• Know your threat model: Understand your attacker and their resources and motivation
• Consider human factors: If your system is unusable, it will be unused
• Security is economics: Balance the expected cost of security with the expected benefit
• Detect if you can’t prevent: Security requires not just preventing attacks but detecting and responding to them
• Defense in depth: Layer multiple types of defenses
• Least privilege: Only grant privileges that are needed for correct functioning, and no more
• Separation of responsibility: Consider requiring multiple parties to work together to exercise a privilege
• Ensure complete mediation: All access must be monitored and protected, unbypassable
• Shannon’s maxim: The enemy knows the system
• Use fail-safe defaults: Construct systems that fail in a safe state, balancing security and usability.
• Design in security from the start: Consider all of these security principles when designing a new system, rather than patching it afterwards

100

Computer Science 161