security archetecture

ISOL 536 Security Architecture and Design

Threat Modeling Session 9a

“Check Your Work”

Agenda

• Testing software you make

• Testing software you acquire

• QA’ing your threat modeling work

• Reading: Chapter 10

Context

All testing

Security testing

Threat model- driven testing

Testing Software You Make

• All threats you find can be tested • In agile shops that rely on Test-Driven

Development (TDD), threat modeling is a great way to design tests – Two tests per threat

• One for no mitigation case • One that attempts to bypass mitigation

• Start with a test to execute the threat • Continue with tests that bypass mitigations (aka

2nd order attacks) • Automation vs manual

Penetration Testing

• Aka “ethical hacking,” “red teaming”

• Improve the security of your code by breaking it

• Differs from threat modeling

– Done late

– Hard to judge scope

– Sometimes “black box” where testers start without knowledge of system

Testing Software You Acquire

• Build a software model

– Use the documentation and actual software

– See if they include a threat model or security operations guide

• Look for threats

• Address the issues you find

Build a Software Model

• Components – Start with the binaries, databases, dependencies

– Some will likely merge into a single process for threat modeling purposes

• Trust boundaries – Account(s) used

– Sockets, RPC (data flow ends)

– Admin interfaces

• Look at platform changes on install

• Diagram as you find things

Look for Threats

• Use the model you’ve created

• This is similar to looking for threats in any other software

– You’re less familiar with it

– It may include relevant documentation

– (If not, what does that tell you?)

• Use STRIDE, CAPEC, attack trees, etc.

Address the Issues You Find

• Ask the creator to fix them – Be ready to discuss views of requirements, tradeoffs – Some backwards vendors will threaten you (this is a

red flag they don’t understand security) – Generally the least investment if the vendor will fix

them

• Look for an alternative – Easier if you TM early

• Mitigate yourself – Using operational security techniques from earlier

classes on “what to do about it”

QA’ing the Threat Modeling Process

• Another aspect of checking your work

• Check software model/reality conformance

• Check that each task and process is done

• Bug checking: Look at each TM bug

– Is it closed properly (fixed, not wontfix)?

– Is there a test case?

– Tags on bugs really helpful here

Recap

• Testing software you make

• Testing software you acquire

• Knowing when you’re done