Evaluating Existing Systems Standards approaches arent always - - PowerPoint PPT Presentation

evaluating existing systems
SMART_READER_LITE
LIVE PREVIEW

Evaluating Existing Systems Standards approaches arent always - - PowerPoint PPT Presentation

Evaluating Existing Systems Standards approaches arent always suitable Not helpful for evaluating the security of running systems Not great for custom systems What do you do for those problems? Lecture 15 Page 1 CS 236 Online


slide-1
SLIDE 1

Lecture 15 Page 1 CS 236 Online

Evaluating Existing Systems

  • Standards approaches aren’t always

suitable

  • Not helpful for evaluating the security
  • f running systems
  • Not great for custom systems
  • What do you do for those problems?
slide-2
SLIDE 2

Lecture 15 Page 2 CS 236 Online

Two Different Kinds of Problems

  • 1. I need to evaluate the design and

implementation of the system

  • 2. I need to evaluate what’s going on in

the system as it runs

slide-3
SLIDE 3

Lecture 15 Page 3 CS 236 Online

Evaluating System Design Security

  • Sometimes standards aren’t the right choice
  • What if you’re building your own custom

system?

  • Or being paid to evaluate someone else’s?

– That’s some companies’ business

  • This kind of review is about design and

architecture – Evaluating running systems comes later

slide-4
SLIDE 4

Lecture 15 Page 4 CS 236 Online

How Do You Evaluate a System’s Security?

  • Assuming you have high degree of

access to a system – Because you built it or are working with those who did

  • How and where do you start?
  • Much of this material is from “The Art of

Software Security Assessment,” Dowd, McDonald, and Schuh

slide-5
SLIDE 5

Lecture 15 Page 5 CS 236 Online

Stages of Review

  • You can review a program’s security at

different stages in its life cycle – During design – Upon completion of the coding – When the program is in place and

  • perational
  • Different issues arise in each case
slide-6
SLIDE 6

Lecture 15 Page 6 CS 236 Online

Design Reviews

  • Done perhaps before there’s any code
  • Just a design
  • Clearly won’t discover coding bugs
  • Clearly could discover fundamental

flaws

  • Also useful for prioritizing attention

during later code review

slide-7
SLIDE 7

Lecture 15 Page 7 CS 236 Online

Purpose of Design Review

  • To identify security weaknesses in a

planned software system

  • Essentially, identifying threats to the

system

  • Performed by a process called threat

modeling

  • Usually (but not always) performed

before system is built

slide-8
SLIDE 8

Lecture 15 Page 8 CS 236 Online

Attack Surfaces

  • Attackers have to get into your software somehow
  • The more ways they can interact with the

software, the more things you must protect

  • Some entry points are more dangerous than others

– E.g., those that lead to escalated privilege

  • A combination of these factors defines a system’s

attack surface

  • The smaller the attack surface, the better

– But attack surface doesn’t indicate actual flaws, just places where they could occur

slide-9
SLIDE 9

Lecture 15 Page 9 CS 236 Online

Threat Modeling

  • Done in various ways
  • One way uses a five step process:

1. Information collection 2. Application architecture modeling 3. Threat identification 4. Documentation of findings 5. Prioritizing the subsequent implementation review

slide-10
SLIDE 10

Lecture 15 Page 10 CS 236 Online

  • 1. Information Collection
  • Collect all available information on design
  • Try to identify:

– Assets – Entry points – External entities – External trust levels – Major components – Use scenarios

slide-11
SLIDE 11

Lecture 15 Page 11 CS 236 Online

One Approach1

  • Draw an end-to-end deployment

scenario

  • Identify roles of those involved
  • Identify key usage scenario
  • Identify technologies to be used
  • Identify application security

mechanisms

1From http://msdn.microsoft.com/en-us/library/ms978527.aspx

slide-12
SLIDE 12

Lecture 15 Page 12 CS 236 Online

Sources of Information

  • Documentation
  • Interviewing developers
  • Standards documentation
  • Source code profiling

– If source already exists

  • System profiling

– If a working version is available

slide-13
SLIDE 13

Lecture 15 Page 13 CS 236 Online

  • 2. Application Architecture

Modeling

  • Using information gathered, develop

understanding of the proposed architecture

  • To identify design concerns
  • And to prioritize later efforts
  • Useful to document findings using

some type of model

slide-14
SLIDE 14

Lecture 15 Page 14 CS 236 Online

Modeling Tools for Design Review

  • Markup languages (e.g., UML)

– Particularly diagramming features – Used to describe OO classes and their interactions – Also components and uses

  • Data flow diagrams

– Used to describe where data goes and what happens to it

slide-15
SLIDE 15

Lecture 15 Page 15 CS 236 Online

  • 3. Threat Identification
  • Based on models and other information

gathered

  • Identify major security threats to the

system’s assets

  • Sometimes done with attack trees
slide-16
SLIDE 16

Lecture 15 Page 16 CS 236 Online

Attack Trees

  • A way to codify and formalize possible

attacks on a system

  • Makes it easier to understand relative

levels of threats – In terms of possible harm – And probability of occurring

slide-17
SLIDE 17

Lecture 15 Page 17 CS 236 Online

A Sample Attack Tree

  • For a web application involving a database
  • Only one piece of the attack tree
  • 1. Attacker gains access to user’s

personal information

1.1 Gain direct access to database 1.2 Login as target user 1.3 Hijack user session 1.4 Intercept personal data 1.2.1 Brute force password attack 1.2.2 Steal user credentials 1.1.1 Exploit application hole 1.3.1 Steal user cookie 1.4.1 ID user connection 1.4.2 Sniff network

slide-18
SLIDE 18

Lecture 15 Page 18 CS 236 Online

The STRIDE Approach

  • Developed and used by Microsoft

– Part of their SDL threat modeling process1

  • Depends on having built a good system model

diagram – Showing components, data flows, interactions – Specifying where data and control cross trust boundaries

  • Then, for each element, consider the STRIDE

threats

1http://blogs.technet.com/b/security/archive/2012/08/23/microsoft-s-free-security-

tools-threat-modeling.aspx

slide-19
SLIDE 19

Lecture 15 Page 19 CS 236 Online

STRIDE Threats

  • Spoofing
  • Tampering
  • Repudiation
  • Information Disclosure
  • Denial of Service
  • Escalation of Privilege
slide-20
SLIDE 20

Lecture 15 Page 20 CS 236 Online

How To Apply STRIDE

  • For each element in diagram, consider

each possible STRIDE threat

  • Some types of threats not applicable to

some types of elements

  • Pay particular attention to things

happening across trust boundaries

slide-21
SLIDE 21

Lecture 15 Page 21 CS 236 Online

  • 4. Documentation of Findings
  • Summarize threats found

– Give recommendations on addressing each

  • Generally best to prioritize threats

– How do you determine priorities? – DREAD methodology is one way

slide-22
SLIDE 22

Lecture 15 Page 22 CS 236 Online

DREAD Risk Ratings

  • Assign number from 1-10 on these categories:
  • Damage potential
  • Reproducibility
  • Exploitability
  • Affected users
  • Discoverability
  • Then add the numbers up for an overall rating
  • Gives better picture of important issues for each

threat

slide-23
SLIDE 23

Lecture 15 Page 23 CS 236 Online

  • 5. Prioritizing Implementation

Review

  • Review of actual implementation once

it’s available

  • Requires a lot of resources
  • You probably can’t look very closely

at everything

  • Need to decide where to focus limited

amount of attention

slide-24
SLIDE 24

Lecture 15 Page 24 CS 236 Online

One Prioritization Approach

  • Make a list of the major components
  • Identify which component each risk

(identified earlier) belongs to

  • Total the risk scores for categories
  • Use the resulting numbers to prioritize