Discussion Paper (Defense in Depth)

ISOL536 Security Architecture and Design

Week 4 “Defensive Tactics and Technologies”

Agenda

• Foreach STRIDE Threat:

– Defensive tactics and technologies

– Operations and development

• Reading: Chapter 8

STRIDE (Review) Threat Property

Violated Definition Example

Spoofing Authentication Impersonating something or someone

else.

Pretending to be any of Bill Gates, Paypal.com or

ntdll.dll

Tampering Integrity Modifying data or code Modifying a DLL on disk or DVD, or a packet as it traverses the network

Repudiation Non-repudiation Claiming to have not performed an action.

“I didn’t send that email,” “I didn’t modify that

file,” “I certainly didn’t visit that web site, dear!”

Information Disclosure

Confidentiality Exposing information

to someone not

authorized to see it

Allowing someone to read the Windows source

code; publishing a list of customers to a web

site.

Denial of Service Availability Deny or degrade service to users

Crashing Windows or a web site, sending a

packet and absorbing seconds of CPU time, or

routing packets into a black hole.

Elevation of Privilege Authorization Gain capabilities without proper

authorization

Allowing a remote Internet user to run

commands is the classic example, but going

from a limited user to admin is also EoP.

AUTHENTICATION: ADDRESSING SPOOFING

Understanding Authentication

• To prove or show (something, esp. a claim or an artistic work) to be true or genuine

• Applies to all sorts of things

– Programs or libraries on disk

– Remote machines

– People (a complex subject, covered later in the course)

Tactics for Authentication

• Local – Leverage the OS/program (database, web server, etc)

– Defaults are not always secure

• Remote machines – Cryptographic methods (more reliable)

– Consistency checking DNS, IP, route (less reliable)

• Cryptographic key exchange – DNSSec, PKI, etc: All involve trust delegation

– Manual: expensive, sometimes worthwhile for existing business relationships

Developer Ways to Address Spoofing

• Leverage the OS

– Use full pathnames (what does open(“foo.txt”) find?)

– Make pathnames canonical

• Resolving links including ../ or symlinks

• Remove %20 or other encoding

– Check permissions

– Shared directories are usually troublesome

• Cryptographic identifiers & validation

Operational Ways to Address Spoofing

• Difficult to improve local (on-system) name resolution when the code is done

• Possible to use SSH or IPSec or other crypto tunneling to reduce spoofing issues over the network

Technologies for Addressing Spoofing

• Authenticating computers

– IPSec, DNSSec, SSH Host keys

– Kerberos

– Windows Domain authentication

– PKI with SSL/TLS

• Authenticating bits (files, messages, etc)

– Digital signatures

– Hashes (appropriately managed)

Technologies for Addressing Spoofing (2)

1. Something you know, like a password 2. Something you have, like an access card 3. Something you are (or are measured to be)

– “Biometrics” – Fingerprints, vein patterns, photographs

4. Someone you know who can authenticate you • The first three are traditional, #4 is new • “Multi-factor authentication” usually means more than

one from the list – Some people call channels a factor – Many of them should threat model better

Understanding Integrity

• To interfere with (something) in order to cause damage or make unauthorized alterations

• Can apply to data wherever it is, including:

– Disk

– Network

– Memory

Tactics for Integrity

• System defenses

– Permissions (operating system/program)

• Cryptographic defenses

– Digital signatures

– Hashes/MACs

• Logging and audit

– These do not prevent, but may deter

– Generally used as a fallback or defense in depth

Developer Ways to Address Integrity

• Use permissions as provided

• Cryptography is required over a network

• Implementing a permission system is hard

– Lots of mistakes have been made & documented

Operational Ways to Address Integrity

• Add additional protections – Tripwire-like systems on local machine

– Tunneling over network

• Tripwire: acting on alerts is key! – Don’t be these folks ->

• Good alert design is a pre-requisite – Too many alerts, people will be overwhelmed

– Too few, they’ll miss stuff

Technologies for Addressing Integrity

• Protect files with – Digital signatures – ACLs/permissions – Hashes – Windows Mandatory Integrity Control features – Unix immutability

• Protect network traffic with – SSL – SSH – IPSec – Digital signatures

Understanding Non-Repudiation

• Repudiation: To refuse to accept or be associated with; deny the truth or validity of some statement

• Non-repudiation are the tools & technologies to establish what happened — ideally to the satisfaction of everyone involved or impacted

• Bridges business & technical levels

• Repudiation can be a feature – “Off The Record”

Tactics for Non-Repudiation

• Fraud prevention

– Internal fraud such as embezzlement

– “Customer” fraud prevention

• Logs

– As much as you can, keep for as long as you can

• Cryptography

“Customer” Fraud Prevention

• Alice’s account is taken over & abused (or)

• Bob creates an account for fraud

• Must manage both

• Stable customers are good, predictable

• Technologies/services – Validation services

– Customer history sharing

– Multi-merchant data

– Purchase device tracking

Developer Ways to Address

• Log business logic

– Eg “For this transaction, we saw that geolocate(ip) was ‘Seattle,’ which is typical for this account.”

• Cryptographic digital signatures

– Most useful today between business partners, not consumer-usable

Operational Ways to Address

• Operations get stuck investigating

– Table-top exercises may expose issues that the logs don’t exist

• Scaling

– Logs may end up in diverse places

– Dedicated people

– Specialized tooling

Technologies for Addressing Repudiation

• Logs

– Logging

– Log analysis tools

– Secured log storage

• Digital signatures

• Secure time stamps

• Trusted third parties

Understanding Confidentiality

• To ensure that information is only disclosed to authorized parties

• Secrets in data – Yours: financial results, new product plans

– Entrusted to you: private data

– Complex rules: Who can see that Facebook post?

• Secrets also exist in metadata – “Layoff letter for Alice.docx”, “Janlayoff/alice.docx”

– Calls to an STD clinic (repeatedly?!)

Tactics for Confidentiality

• On a system

– ACLs/permissions

– Cryptography

• Between systems

– Cryptography

• To hide the existence of information

– Steganography

Developer Ways to Address

• Permissions/ACLs

• Cryptography

– Data (file on disk, email message)

– Container (volume encryption, email connections)

– Requires proper key management

– Remember: Encryption doesn’t provide authentication or integrity

Operational Ways to Address

• Add permissions/ACLs

• Volume encryption

– Protects if the machine is stolen and powered down

– Doesn’t protect against an attacker who breaks in

• Network encryption (SSH, SSL, IPSec)

Technologies for Confidentiality

• Protecting files – ACLs/Permissions – Encryption – Appropriate key management

• Protecting network data – Encryption – Appropriate key management

• Communication headers/act of communication – Mix networks – Onion routing – Steganography

Understanding Availability

• Being able to meet a defined or implied SLA

• Attacks can absorb any resource

– Disk, network, CPU

• Attacks can be transient or require intervention

– Network flooding stops when attacker does

– Fork bomb (eg: while(1) {fork();}) might need reboot

– Full disk might require human intervention

Tactics for Availability

• Have enough resources to serve requests

• Proof of work

– … “Proves Not to Work”

– Bitcoin uses high cost proofs

• Proof of communication

Developer Ways to Address

• Avoid fixed-size buffers

– For example, 5 half-open TCP connections

• Consider

– Resources you consume per request

– How many requests you’ll serve

– Clever attacks that balloon resource use

– Recovery

Operational Ways to Address

• Quotas

• Elastic cloud systems to add more resources

Technologies for Addressing DoS

• ACLs

• Filters

• Quotas (rate limits, thresholding, throttling)

• High availability design

• Extra bandwidth

• Cloud services

Understanding Authorization

• Elevation of Privilege is one class of authorization bypass

– The only one covered here

– Authorization systems are their own sub-field

Tactics for Authorization

• Limit the attack surface

– For example, small number of setuid programs

– Use sandboxes for network-exposed code

– Don’t run as root/admin

– Be aware that there’s often elevation paths for semi-privileged accounts

• Comprehensible, manageable permissions systems

Developer Ways to Address

• Limit the attack surface

• Carefully define purpose & validation rules for inbound data

• Define what you’ll accept, not what you reject

• Reject bad input, don’t try to sanitize

• Looped canonicalization routines

• Transform from one form to another (e.g., markdown to html)

Operational Ways to Address

• Defense in depth

• Run each target as its own unique limited user

– Unix “nobody” account ended up quite privileged

• Sandboxes

Technologies for Addressing

• ACLs

• Groups or role membership

• Role based access controls

• Windows privileges (runas)/Unix sudo

• Chroot, apparmor, other unix sandboxes

• MOICE Windows sandbox

• Input validation for defined purposes

Recap

• STRIDE

– The threat

– Tactics for managing it

– Developer tactics

– Operational tactics

– Technologies for addressing

• Phew! That’s a lot to know!

– It will be on the exam.

Threat Modeling Session 7

“What are you going to do about it ?” (3 of 3)

Instructor Materials

See README.docx

for licensing & notes

Agenda

• Different ways to address threats

• Common mistakes

• Prioritization

• Reading: Chapter 9

How to Threat Model (Summary)

• What are you building?

• What can go wrong?

• What are you going to do about it?

• Check your work on 1-3

What Are You Going to Do About It?

• For each threat: – Fix it (avoid the problem)

– Mitigate with standard or custom approaches

– Standard approaches were the previous session

– Accept it

– Transfer the risk

• For each assumption: – Check it

– Wrong assumptions lead to reconsider what goes wrong

Fix It!

• The best way to fix a security bug is to remove the functionality – For example, if SSL doesn’t have a “heartbeat”

message, the “heartbleed bug” couldn’t exist

– You can only take this so far

– Oftentimes end up making risk tradeoffs

• If you don’t remove it, you can only mitigate, not fix

• Mitigate the risk in various ways (next slide)

Mitigate Threat

• Add/use technology to prevent attacks • As covered in previous session in depth

– You learned those first because they’re “go-to” – Only try other approaches when they’re not effective/feasible

• For example, prevent tampering: – Network: Digital signatures, cryptographic integrity tools, crypto

tunnels such as SSH or IPsec

• Developers, sysadmins have different toolkits for mitigating problems

• Standard approaches available which have been tested & worked through

• Sometimes you need a custom approach

Some Technical Mitigations

Threat Mitigation Technology Developer Example Sysadmin Example

Spoofing Authentication Digital signatures, Active directory, LDAP

Passwords, crypto tunnels

Tampering Integrity, permissions Digital signatures ACLs/permissions, crypto tunnels

Repudiation Fraud prevention, logging, signatures

Customer history risk management

Logging

Information disclosure

Permissions, encryption

Permissions (local), PGP, SSL

Crypto tunnels

Denial of service Availability Elastic cloud design Load balancers, more capacity

Elevation of privilege

Authorization, isolation Roles, privileges, input validation for purpose, (fuzzing*)

Sandboxes, firewalls

* Fuzzing/fault injection is not a mitigation, but a great testing technique See chapter 8, Threat Modeling for more

Custom Mitigations

• Sometimes the standard technologies don’t work for your situation

• Requires custom mitigations (or risk acceptance)

• Easy to get a custom mitigation wrong

• Hard and expensive to test (page 176)

Accepting Risk/Threats

• Works best when it’s your risk

– Your organization can accept risk

– Be careful about “accepting” risk for your customers.

• Customer risk acceptance

– Via user interface

– Sometimes the customer has details you can’t have (is this network your work or a coffee shop?)

Transferring Risk/Threats

• Via license agreements, terms of service, etc

• Silently

• Both can lead to unhappy customers

– Threat that no one reads ToS

– Surprise!

– Media blowups

Common Mistakes

• Custom mitigations because they’re fun

• Fuzzing as a mitigation

• Not covering all threats

Issue Prioritization Strategies

• Wait and see

• Easy fixes first

• Threat ranking with a bug bar

• Cost/damage estimation approaches

• DREAD

– Abandoned by its creators for being too subjective

– Loss of an awesome acronym

Wait and See

• Can be risky

– The “cheeseburger approach”

• Requires some way of seeing

– Change detection

– Signature-based detection

– Anomaly-based detection

– Impact detection

Easy Fixes First

• May be helpful when getting started

• Benefit: demonstrate value

• Risk: fixing the wrong things

Bug Bars

• Concrete impact levels drive severity (sev.)

• All anonymous, remote EoP are sev 1

• Information disclosure to authenticated users

– Normally sev 2

– Severity 1 if security info (passwords, crypto secrets) or violates explicit permissions

– Severity 3 if random information only

• Microsoft offers usable sample bars

Cost/Damage Estimation

• Probability/Impact – Hard to do well

– Predicting odds and difficulty is challenging (visa holograms beaten by tin-foil, gummy bear fingerprints)

– People living on a dollar a day

• FAIR (Factor analysis of information risk) – Useful

– Can be more time consuming than a bug bar

Arms Races

• Avoid when you can

• Economic game

– Maximize your profit

– Drive cost to the competition

• Tools

– Bag of tricks

– Last mover advantage

Recap

• For each threat:

– Fix/Standard mitigate/custom approaches

• Prioritization

– Wait & see/Easy fixes/bug bar

– Probability/Impact

• Arms races

What’s Next?

• Mid-Term Exam this week

• 30% of final grade

• 60 multiple choice questions

• 120 minutes to complete

• 1 attempt