1. CSCD 303 Essential Computer Security Winter 2014 Lecture 16 Creating Secure Programs

2. Overview Developing Secure Programs – Traditional – Secure Code Model – Security Threats – What Microsoft Does

3. Secure Software What does it mean for software to be secure? Software security is an idea implemented to protect software against malicious attack and other hacker risks so that the software continues to function correctly under such potential risks

4. Build Security In Security First, Designing with Security, Build Security In All these names were used to address “new” concept to include security in with design of software Prior to this radical idea, security was and still is an afterthought to most popular software Here is a good summary of this concept by Gary McGraw http://searchsecurity.techtarget.com/opinion/Gary- McGraw-on-software-security-assurance-Build-it- in-build-it-right There are many reasons for Security First ….

5. Why Put Security First? 1. Adding security later is wrapping security around existing features, not designing features with security in mind. 2. Adding security later is expensive. 3. Adding security may change how you implement application features. 4. Adding security may change user interface.

6. How Software is Created Modern Software Systems Developed through software development process or model Many different development models Look at most classic and then see how secure development fits within this model

7. Waterfall Model Requirements – defines needed information, function, behavior, performance and interfaces. Design – data structures, software architecture, interface representations, algorithmic details. Implementation – source code, database, user documentation, testing Test – Test each component and integrated tests Installation – self explained Maintenance – Fix minor problems, bug fixes and updates

8. Waterfall Strengths Easy to understand, easy to use Provides structure to inexperienced staff Milestones are well understood Sets requirements stability Good for management control (plan, staff, track) Works well when quality is more important than cost or schedule

9. Waterfall Deficiencies 1. All requirements must be known up front 2. Deliverables created for each phase are considered frozen – inhibits flexibility 1. Can give a false impression of progress 2. Does not reflect problem-solving nature of software development – iterations of phases 1. Integration is one big bang at end 2. Little opportunity for customer to preview system (until it may be too late)

10. Using Waterfall Model Where could we inject security into the development process ? And, what could we do?

11. Security Development Lifecycle Product Inception Assign resource Security plan Design Design guidelines applied Security architecture Security design review Ship criteria agreed upon Guidelines&Best Practices Coding Standards Testing based on threat models Tool usage Security Push Security push training Review threat models Review code Attack testing Review against new threats Meet signoff criteria Final Security Review(FSR) Review threat models Penetration Testing Archiving of Compliance Info Security Response Feedback loop -Tools/ Processes -Postmortems -SRLs RTM& Deployment Signoff DesignResponse Threat Modeling Models created Mitigations in design and functional specs Security Docs& Tools Customer deliverables for secure deployment RequirementsImplementationVerificationRelease Model developed by Microsoft

12. Version 02U-112 Security Development Lifestyle Artifacts

13. Security in the Development Cycle Security Modeling in Development is a Risk Mitigation Strategy You will not find all bugs… You will not see all the vulnerabilities… Your design will have errors of omission and oversight – But, better than alternative which is do nothing

14. Security Modeling Another way to think of process of developing secure software Techniques to – Evaluate an application’s overall security or – Assess impact of specific threat Objectively identify vulnerabilities and address countermeasures Integrated steps to take in development process

15. Security Modeling – The Process Define threats Consider data stored in system, and how it can be misused Consider architecture of system, and opportunities it affords malicious users Specific threat identification processes can be used Assess the Impact You’ve found a vulnerability… what happens if someone actually finds it? How badly would you or your users be affected? Implement a Countermeasure Mitigate the risk to the best of your ability – code a preventative action, limit the exposure

16. Defining the Threats Decompose your application to ask questions about how each use case or application component could go awry Two Processes defined by Microsoft... STRIDE STRIDE is a classification scheme for characterizing known threats according to the kinds of exploit that are used (or motivation of the attacker). Spoofing Identity Tampering with Data Repudiation Information Disclosure Denial of Service Elevation of Privilege DREAD DREAD is a classification scheme for quantifying, comparing and prioritizing the risk presented by each evaluated threat.

17. STRIDE Threat Categorization Microsoft Developed This Spoofing ex: Replaying authentication transaction. Tampering ex: Modifying authentication files to add new user. Repudiation ex: Denying that you purchased items you actually did. Information disclosure ex: Obtaining a list of customer credit card numbers. Denial of service ex: Consuming CPU time via hash algorithm weakness. Elevation of privilege ex: Subverting a privileged program to run your cmds. Microsoft article on Stride with Example http://msdn.microsoft.com/en- us/magazine/cc163519.aspx

18. Stride in a Nutshell OWASP overview of Stride and other threat models https://www.owasp.org/index.php/Threat_Risk_Modeling

19. Evaluate Risk with DREAD Damage Potential Extent of damage if vulnerability exploited. Reproducibility How often attempt at exploitation works. Exploitability Amount of effort required to exploit vulnerability. Affected Users. Ration of installed instances of system that would be affected if exploit became widely available. Discoverability Likelihood that vulnerability will be discovered.

20. Assessing Vulnerabilities Impact DREAD aims to quantify a threat DREAD modeling influences the thinking behind setting the risk rating, and is also used directly to sort the risks. The DREAD algorithm, shown below, is used to compute a risk value, which is an average of all five categories. Assign a value between 1 and 10 and use the mean Risk_DREAD = (DAMAGE + REPRODUCIBILITY + EXPLOITABILITY + AFFECTED USERS + DISCOVERABILITY) / 5 Damage Potential 0 – no damage; 10 – complete system damage Reproducibility 0 – Almost impossible to reproduce; 10 – can reproduce at any time Exploitability 0 – Extremely sophisticated skills required; 10 – anybody with a browser Affected Users 0 – No users; 10 – All users (or beyond… think VA data leak) Discoverability 0 – Requires source code; 9 – details of exploit are in public domain; 10 – it’s in easily discoverable data in the application itself.

21. Threat Modeling in General

22. Goals of Threat Modeling 1. Understand threats to guard against during requirements analysis. 2. Provide basis for which security mechanisms to include during design. 3. Verify security of system design. 4. Provide basis for prescribing secure implementation practices. 5. Provide basis for testing system security after implementation.

23. Threat Modeling Process 1. Understand adversary’s view of system 2. Evaluate threats

24. Understanding Adversary’s View 1. Identify System Assets – System resources that an adversary might attempt to access, modify, or steal. – Ex: credit cards, network bandwidth, user access. 2. Identify Entry Points – Any location where data or control transfers between the system being modeled and another system. – Ex: network sockets, RPCs, web forms, files 3. Determine Trust Levels – Privileges external entities have to legitimately use system resources.

25. Evaluate Threats Identify Threats For each entry point, determine how an adversary may attempt to affect an asset. Based on asset, predict what adversary would try to do and what his goals would be. Analyze Threats Decompose threats into individual, testable conditions using techniques like attack trees Evaluate risk of threat with DREAD categories

26. Identify Threats Can an unauthorized network user view confidential information such as addresses or passwords? Can an unauthorized user modify data like payments or purchases in the database? Could someone deny authorized users access to the application? Could an authorized user exploit a feature to raise their privileges to administrator level?

27. Analyze Threats Decompose threats into individual, testable conditions using attack trees Attack Trees – Hierarchical decomposition of threat – Root of tree is adversary’s goal in attack – Each level below root decomposes attack into finer approaches – Child nodes are OR'd together by default – Special notes may indicate to AND them

28. Attack Trees—Graph Notation Goal: Read file from password-protected PC Read File Get PasswordNetwork AccessPhysical Access Search DeskSocial EngineerBoot with CDRemove hard disk

29. Attack Trees—Text Notation Goal: Read message sent from one PC to another 1. Convince sender to reveal message. 1.1 Blackmail. 1.2 Bribe. 2. Read message when entered on sender’s PC. 1.1 Visually monitor PC screen. 1.2 Monitor EM radiation from screen. 3. Read message when stored on receiver’s PC. 1.1 Get physical access to hard drive. 1.2 Infect user with spyware. 4. Read message in transit. 1.1 Sniff network. 1.2 Usurp control of mail server.

30. Other Stages Secure Development

31. Implementation Coding standards Acceptable libraries and functions Checklists. Static analysis tools Identifies common errors Code reviews More effective than testing in many reports

32. Verification Fuzz Testing Automatic testing with random data. Unit Tests Test security features. Penetration Testing Driven by application risks. Threat model identifies most important assets and entry points.

33. Maintenance Prepare before release time. Receiving vulnerability reports. Releasing security advisories. Developing, testing, and distributing patches.

34. Microsoft Security Development

35. SDLC at Microsoft Security Development Lifecycle Management support Bill Gates letter about 2002 security push http://www.wired.com/techbiz/media/news/2002/01/49 826 Mandatory education For managers and engineers. Annual updates. Metrics Education coverage. Vulnerabilities discovered. Central Security Team Ensures someone is responsible. Keeps process and education updated.

36. Engineering Excellence Raise the bar of software security Improved development process New tools designed to help developers Guidance and training focused on secure coding Advance the state of the art of secure software development

37. Quality & Engineering Excellence Improved Development Process Threat modeling Code inspection Penetration testing Unused features off by default Reduce attack surface area Least Privilege Prescriptive Guidance Security Tools Training and Education Community Engagement Transparency Clear policy

38. Critical or important vulnerabilities in the first… Bulletins since TwC release Shipped July 2002 Bulletins in prior period 7 Service Pack 3 1 …365 days …455 days TwC release? 1316 4255 Yes No Bulletins since TwC release Shipped Jan. 2003 3 Service Pack 3 Bulletins in prior period 14 Continued Progress

39. 39 Source: Microsoft Security Bulletin Search 65 35 Days 3090150210270330390450510570630690720

40. Quality & Engineering Excellence Helping Developers Write More Secure Code.NET Framework 1.1 Cryptographic APIs Integrated PKI Visual Studio.NET 2003 Security Tools Web Services Enhancements Microsoft Security Developer Center Writing Secure Code v2 Developer webcasts

41. 41 Education for the SDL

42. Outreach And Communications Pre Release Security Bulletin Advance Notification - three business days prior to release Second Tuesday Release Day Updates posted on Download Center, Windows Update and/or Office Update Bulletins posted RSS Feeds Customer email and instant message notifications Community outreach MS Field alerts and call downs Post Release Security Bulletins Webcast (Wednesday following release, 11AM PT) Supplementary Webcasts if needed Monitor bulletin uptake and customer issues through PSS and Windows Update Bulletin maintenance Microsoft introduced "Patch Tuesday" in October 2003

43. 43 SSIRP - Software Security Incident Response Plan Companywide process to deal with critical security threats Mobilize Microsoft resources worldwide Goals: Quickly gain a thorough understanding of the problem Provide customers with timely, relevant, consistent information Deliver tools, security updates and other assistance to restore normal operation

44. Guidance, Tools & Response Delivering Support and Creating Community Security tools Microsoft Baseline Security Analyzer Security Bulletin Search Tool Guidance and training Security Guidance Center E-Learning Clinics Community engagement Newsletters Webcasts and chats http://www.microsoft.com/security http://www.microsoft.com/security http://www.microsoft.com/protect http://www.microsoft.com/protect

45. Microsoft Resources General Generalhttp://www.microsoft.com/security XP SP2 Resources for the IT Professional XP SP2 Resources for the IT Professionalhttp://www.microsoft.com/technet/winxpsp2 Security Guidance Center Security Guidance Centerhttp://www.microsoft.com/security/guidance Tools Toolshttp://www.microsoft.com/technet/Security/tools How Microsoft IT Secures Microsoft How Microsoft IT Secures Microsofthttp://www.microsoft.com/technet/itsolutions/msit E-Learning Clinics E-Learning Clinicshttps://www.microsoftelearning.com/security Events and Webcasts Events and Webcastshttp://www.microsoft.com/seminar/events/security.mspx

46. Secure Software Resources Waterfall Model http://www.techrepublic.com/article/understanding-the-pros- and-cons-of-the-waterfall-model-of-software- development/6118423 David LeBlanc's Blog about Dread http://blogs.msdn.com/b/david_leblanc/archive/2007/08/13/dre adful.aspx Gary McGraw's site Secure Code stuff http://www.cigital.com/~gem/

47. End System Security Flaws ( …Its the people) Lab this week is on practice with XSS and CSRF You can do the lab on your own through the web