1. CSCD 303 Essential Computer Security Spring 2013 Lecture 18 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 All these names were used to address the “new” concept to include security in with the design of the 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 is Software Created Modern software systems Developed through a software development process or model Many different development models Look at the 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 All requirements must be known up front Deliverables created for each phase are considered frozen – inhibits flexibility Can give a false impression of progress Does not reflect problem-solving nature of software development – iterations of phases Integration is one big bang at the end Little opportunity for customer to preview the 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 the bugs… You will not see all the vulnerabilities… Your design will have errors of omission and oversight – But, better than the alternative which is do nothing

14. Security Modeling Another way to label the process of developing secure software Techniques to evaluate an application’s overall security or assess the impact of a specific threat Objectively identify vulnerabilities and address countermeasures Integrated steps to take in the development process

15. Security Modeling – The Process Define threats Consider the data stored in the system, and how it can be misused Consider the architecture of the system, and the 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 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 amount of 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. Version 02U-119 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. Version 02U-122 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. Version 02U-123 Threat Modeling Process 1. Understand adversary’s view of system 2. Evaluate threats

24. Version 02U-124 Understanding the 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. Version 02U-125 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. Version 02U-126 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. Version 02U-127 Analyze Threats Decompose threats into individual, testable conditions using attack trees Attack Trees – Hierarchical decomposition of a threat – Root of tree is adversary’s goal in the attack – Each level below root decomposes the attack into finer approaches – Child nodes are ORed together by default – Special notes may indicate to AND them

28. Version 02U-128 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. Version 02U-129 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. Version 02U-131 Implementation Coding standards Acceptable libraries and functions. Checklists. Static analysis tools Identifies common errors. Code reviews More effective than testing in many reports.

32. Version 02U-132 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. Version 02U-133 Maintenance Prepare before release time. Receiving vulnerability reports. Releasing security advisories. Developing, testing, and distributing patches.

34. Microsoft Security Development

35. Version 02U-135 SDLC at Microsoft 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. 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

43. 43 Customer Process Improvement Build a more Simplified, Manageable Process Enhance and Improve Bulletin Content Expand Resources and Support Moved to monthly release of security bulletins: A predictable, manageable process Enable advance planning and preparations Software Update Validation Program to help ensure quality Advance notification three business days prior to release Publicly posted on Microsoft.com; Email alert available Revamped technical security bulletin format: Added a monthly summary bulletin that includes a summary table of affected software for each bulletin Added mitigations and workarounds per vulnerability Added more information and guidance on distribution and deployment Improved bulletin search tool on TechNet Security Security Advisories Technical webcast on Wednesday following the release RSS feed for security bulletins New notification services, including a comprehensive version and instant message alerts Malicious Software Removal Tool

44. 44 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

45. 45 Watch Observe environment to detect any potential issues Leverage existing relationships with: Partners Security researchers and finders Monitor customer requests and press inquiries Alert and Mobilize Convene and evaluate severity Mobilize security response teams and support groups into two main groups: Emergency Engineering Team Emergency Communications Team Start monitoring WW press interest and customer support lines for this issue AssessandStabilize Assess the situation and the technical information available Start working on solution Communicate initial guidance and workarounds to customers, partners and press Notify and inform Microsoft sales and support field Resolve Provide information and tools to restore normal operations Appropriate solution is provided to customers, such as a security update, tool or fix Conduct internal process reviews and gather lessons learned

46. 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

47. 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

48. 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/

49. End System Security Flaws ( …Its the people) Lab this week is on buffer overflow, do on your own