Watching Software Run Brian ChessNov 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 int main(int argc, char** argv) { char buffer[10]; strcpy(buffer, “test”); }

Trace potentially tainted data through the program Report 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 newBuff (command injection)

A never-ending battle against bad code Format String attacks: known for 10+ years printf(input); SQL Injection attacks: known for ? years statement.execute(input);

The Stereotypes Static analysis – Good: thorough – Bad: too many results Testing – Good: concrete results – Bad: misses too many things

Security in the Development Lifecycle

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

Risk Management vs. Compliance Risk Management Probabilistic framework for allocating resources Compliance Fulfill somebody else's requirements 10

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

Compliance wins What to comply with?

Building Security In Maturity Model Real data from real initiatives McGraw, Chess, & Migues Breaking new ground

The nine Two more unnamed financial services firms

Four domains Twelve practices An “archeology grid” A Software Security Framework

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

Terminator

Success is foreseeing failure. – Henry Petroski

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

20 Risk in a new endeavor Time Risk Market Risk Security Risk

Reactive Technology Today Protecting hosts and networks – Firewalls – Anti-virus – Intrusion detection Protecting software – Patching – Web Application Firewall – Language Level: Java Security Model

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

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

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

Return of the Reference Monitor Inline reference monitors (IRM) Aspect-oriented programming Watch interfaces between major components – Report important events – Enforce policy

Interface monitor architecture Monitor Event Event Handlers Action Program Point Target Program VM SyslogLog VM sees extensions as a profiler or a debugger

Federation Fortify 360 Server VM Controller VM

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

DEMO

Better protection: SQL Injection Target Program Source of mal input Database WAF protects here We'll protect here

Patching a privilege escalation vulnerability Target Program Source of mal input Unauthorized request User Role We'll make the connection

Watching Software Run Brian ChessNov 18, 2009