security archetecture

Sairag
chapter9.pdf

ISOL 536 Security Architecture and Design

Threat Modeling Session 8a

“What are you going to do about it ?”

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

• Ultimately, a management decision

– 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