watching software run

32
Watching Software Run Brian Chess Nov 18, 2009

Upload: krysta

Post on 26-Feb-2016

16 views

Category:

Documents


0 download

DESCRIPTION

Watching Software Run. Brian Chess Nov 18, 2009. Success is foreseeing failure. – Henry Petroski. Static Analysis. Misconceptions Prevail. High priority int main(int argc , char** argv ) { char buffer[10]; strcpy(buffer , argv[1]); } Low priority - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: Watching Software Run

Watching Software Run

Brian Chess Nov 18, 2009

Page 2: Watching Software Run

Success is foreseeing failure. – Henry Petroski

Page 3: Watching Software Run

Static Analysis

Page 4: Watching Software Run

Misconceptions PrevailHigh priorityint main(int argc, char** argv) { char buffer[10]; strcpy(buffer, argv[1]);}

Low priorityint main(int argc, char** argv) { char buffer[10]; strcpy(buffer, “test”);}

Page 5: Watching Software Run

Trace potentially tainted data through the programReport locations where an attacker could take advantage of a vulnerable function or construct

Many other approaches, no one right answer

Taint propagation

= getInputFroNetwork();

copyBuffer( , );

exec( );

buff

buffnewBuff

newBuff (command injection)

Page 6: Watching Software Run

A never-ending battle against bad code

• Format String attacks: known for 10+ yearsprintf(input);

• SQL Injection attacks: known for ? yearsstatement.execute(input);

Page 7: Watching Software Run

The Stereotypes

• Static analysis– Good: thorough– Bad: too many results

• Testing– Good: concrete results – Bad: misses too many things

Page 8: Watching Software Run

Security in the Development Lifecycle

Page 9: Watching Software Run

A Lesson from Cryptography

Security is hard to measure– Enemy has unknown capabilities– Small mistakes can have big consequences

So how many of those static analysis results do we have to fix?

9

Page 10: Watching Software Run

Risk Management vs. Compliance

Risk Management• Probabilistic framework for

allocating resources

Compliance• Fulfill somebody else's

requirements

10

Page 11: Watching Software Run

Compliance wins

Why isn't everyone a risk manager? • Risks not widely understood• People manage their own risk, not risk to the public

Page 12: Watching Software Run

Compliance wins

What to comply with?

Page 13: Watching Software Run

• Building Security In Maturity Model

• Real data from real initiatives

• McGraw, Chess, & Migues

• http://bsi-mm.com

Breaking new ground

Page 14: Watching Software Run

The nine

Two more unnamed financial services firms

Page 15: Watching Software Run

• Four domains• Twelve practices• An “archeology grid”

A Software Security Framework

Page 16: Watching Software Run

Ten things everybody does• Activities that ALL do

– evangelist role– policy– awareness training– history in training– security features– SSG does ARA– code review tools– black box tools– external pen testing– good network security

SMCP

T

AM

SFD

SRAA

CR

ST

PT

SE

CMVM

0

2

4

Average maturity over the nine

Average maturity over the nine

Page 17: Watching Software Run

Terminator

Page 18: Watching Software Run

Success is foreseeing failure. – Henry Petroski

Page 19: Watching Software Run

Reactive Revisited

• A good idea: build security in• Problem: software will still be vulnerable• Solution: must compensate at runtime

Page 20: Watching Software Run

20

Risk in a new endeavor

Time

Risk

Market Risk

Security Risk

Page 21: Watching Software Run

Reactive Technology Today

• Protecting hosts and networks– Firewalls– Anti-virus– Intrusion detection

• Protecting software– Patching– Web Application Firewall– Language Level: Java Security Model

Page 22: Watching Software Run

Patching

• Reaction time matters• DON’T BREAK STUFF• Microsoft has patched on Patch Tuesday for 30

months straight• Patch flood means no one is ever fully patched

Page 23: Watching Software Run

Web Application Firewalls (WAF)

• Sits on network, watches web requests• Context problem– What will the program do with this input?

• Good for collecting attacks• Scaling problem– Does go easily into the cloud

Page 24: Watching Software Run

Java Security Model

• General access control mechanism– Domains / domain change– Privileges / privilege enforcement

• Built to– Protect good Java from bad Java– Protect a good computer from bad Java

• Nobody uses it

Page 25: Watching Software Run

Return of the Reference Monitor

• Inline reference monitors (IRM)• Aspect-oriented programming• Watch interfaces between major components– Report important events– Enforce policy

Page 26: Watching Software Run

Interface monitor architecture<Rule>

Monitor

Event

Event Handlers

Action

ProgramPoint

Target Program

VM

<EventHandler>

SyslogLog

VM sees extensions as aprofiler or a debugger

Page 27: Watching Software Run

Federation

Fortify 360 Server

VM

Controller

VM VM

Page 28: Watching Software Run

Static Analysis vs. Interface Monitors

Static Analysis• Part of construction• Must anticipate all

problems• Locality important• Performance not

important

Interface Monitors• Part of deployment• Must anticipate all

symptoms• Locality not important• Performance critically

important

Page 29: Watching Software Run

DEMO

Page 30: Watching Software Run

Better protection: SQL Injection

Target Program

Source of mal input

Database

WAF protectshere

We'll protecthere

Page 31: Watching Software Run

Patching a privilege escalation vulnerability

Target Program

Source of mal input

Unauthorizedrequest

User Role

We'll make the connection

Page 32: Watching Software Run

Watching Software Run

Brian Chess Nov 18, 2009