Application Security and Threat Modeling Ben Hickman VP Engineering email@example.com
Agenda Why Worry? Creating a Security Process Threat Models The Threat Modeling Process Secure Programming Principles Security Testing Questions?
Why Worry?Attacks are increasingAttack complexity is increasing stack overruns, heap overruns, format strings, integer overflow, …?Time from vulnerability discovery to exploit is decreasingSecurity is a CERT Incidentsrequirement or (http://www.cert.org/stats/cert_stats.html)a competitive 140000advantage 120000 100000 80000 60000 40000 20000 0 88 89 90 91 92 93 94 95 96 97 98 99 00 01 02 03 19 19 19 19 19 19 19 19 19 19 19 19 20 20 20 20
Creating a Security Process •Train and keep current in application security. •Architects, developers, testers People •Stay disciplined about security. •Stay current with the state of the art. •Make security a critical part of design, development, testing, and deployment. Process •Security threat analysis part of every design •Design and code reviews •External audits. •Build tools, automate as much as possible.Technology •Select technology a security focus.
A Security Framework: SD3 •Engineer training Secure •Secure architecture •Security code reviews By Design •Threat modeling •Reduce vulnerabilities in code Secure •Reduce attack surface area •Unused features off by default By Default •Run with least privilege Secure •Protect, detect, defend, recover, manage •Process: how to’s, architecture guidesIn Deployment •Proper training
Threat Models You cannot build secure applications unless you understand your threats “We use SSL!” “We have a firewall!” Create a security analysis of your application Find different bugs than code review and testing Find layered security bugs Quantify your attack surface Starting point for testing
The Sample Application Administrative Application Administrator Authentication Admin Bill Payment Data interface logic Data User InterfaceUser Bill payment business logic Web server Web service clientUser Upload interface Developer
The Threat Modeling Process1. Decompose the application2. Determine the threats3. Rank the threats by decreasing risk4. Choose how to respond to the threats5. Choose mitigation techniques
1. Decompose The Application Diagram the flow of data and/or control Data flow diagrams UML activity diagrams Recursively decompose the application into systems First determine trust boundaries Define subsystems
1. Decompose The Application continued Go n levels deep 2, 3, 4, … Until you understand the processes in the application Consider: Define the scope, not every inner working Identify data sources and processes Identify request target and response recipients Flow of data/control across trust boundaries
Context Data Flow Diagram Data center Internet Admin Admin task request Admin task response Bill payment request Bill Payment application User Bill payment response Update files Developer
Level 1 Data Flow Diagram (partial) Data center Machine boundary Internet Authentication Bill payment Data data Cred- entials Auth Bill payment status data request Bill payment Bill payment Bill payment request data request request Service Enforce bill payment Access User client policy data request Bill payment Bill payment Bill payment response response data Request Requested page code Web Web service Pages code
2. Determine The Threats Use STRIDE to categorize the threats Spoofing identity Tampering with data Repudiation Information disclosure Denial of service Elevation of privilege
Spoofing Identity An attacker poses as another user or a machine poses as a valid/trusted machine Examples Basic HTTP authentication sends credentials in the clear Credentials or tokens stored in HTTP cookies Authentication tokens in the clear on the wire Intercepting DNS requests – DNS spoofing
Tampering With Data Attacker modifies data Examples SQL injection to modify database data Modifying data on the wire, in transit Unsecured access to pages and components HTTP Cookies
Repudiation No way to know what an attacker or user did Examples User performs an illegal operation and there is no trace of what happened Attacker gets a product ordered without paying and there is no audit trail
Information Disclosure Exposure of information to a user who is not supposed to see it Examples Reading on the wire Unsecured pages and components Error messages that reveal implementation details
Denial Of Service Attacker denies service to valid users Examples DDoS attacks Poorly behaved components that can be exploited Disabling a credential store
Elevation Of Privilege Unprivileged user gains privileged access Examples Install an .exe and wait for an admin logon Unsecured components that communicate to other services with admin rights Impersonation
Document The Threats Threat Trees Threat Outlines Threat Details
Threat Trees Describes the attacker’s process Threat #1 Gain user’s credentials I, S, E 1.1 1.3 1.4 1.2 Snoop Compromise Malicious software Guess valid authentication server credential reads local user’s credentials connection store password 1.4.1 1.4.2 User acquires Install malicious virus that reads code on computer password
Threat Outlines 1 Gain user’s credentials 1.1 Snoop authentication connection 1.2 Guess valid credentials 1.3 Compromise server credential store 1.4 Malicious software reads local user’s password • 1.4.1 User acquires virus that reads password • 1.4.2 Install malicious code on computer
Threat DetailsTitle Gain user’s credentialsThreat target Bill payment requestThreat types Information disclosure, Spoofing identity, Elevation of privilegeRisk …Mitigation techniques Use SSLBug number …
3. Rank The Threats Calculate using DREAD Damage potential Reproducibility Exploitability Affected users Discoverability Rank by decreasing risk Rank each from 1 – 10 Threat risk = average
3. Rank The Threats Calculate by following the path of least resistance 1 Gain user’s credentials Damage potential: 8 Reproducibility: 10 Exploitability: 7 Affected users: 10 Discoverability: 10 DREAD Risk: 7.5
4. Choose How To Respond Do nothing You’ll eventually pay for this choice Warn the user Will the user know what to do? Remove the problem Rather than ship a security bug Fix the problem Yes!
5. Choose Mitigation TechniquesSpoofing identity Appropriate authentication Don’t store secretsTampering with Data Appropriate authorization Hashes, digital signatures Tamper-resistant protocolsRepudiation Digital signatures Audit trailsInformation disclosure Authorization Encryption Don’t store secretsDenial of service Filtering, Throttling, QoS Appropriate AuthorizationElevation of Privilege Run with least privilege
5. Choose Mitigation Techniques continued Update your threat documentation to include mitigation Threat #1 Gain user’s credentials I, S, E 1.1 1.3 1.4 1.2 Snoop Compromise Malicious software Guess valid authentication server credential reads local user’s credentials connection store password 1.4.1 1.4.2 User acquires Install malicious Enforce strong virus that reads Using SSL code on computer passwords password Need physical Need physical access to access to server machine
Secure Programming Principles Don’t trust user input Run with least privilege Secure failure and defaults Defend with depth Don’t store secrets Assume external systems are insecure
Security Testing The QA process must include a security focus Think ‘evil’ Threat model drives testing Each threat gets tested STRIDE drives techniques DREAD drives priorities Mutate data for attacks Can you identify new threats?
Questions?Passionate about technology Strategy & Consulting Education & Mentoring Application Development Application Securityhttp://www.sftsrc.com