CSC 593: Secure Software Engineering Seminar

1. CSC 593: Secure Software Engineering Seminar James Walden and Charles Frank Secure Development Lifecycle CSC 593: Secure Software Engineering Seminar

2. Topics • Common Approaches. • Categories of Security Flaws. • Security first and last. • The Lifecycle. CSC 593: Secure Software Engineering Seminar

3. Common Approaches • Penetrate and Patch Let someone else find flaws, then we’ll fix it. • Penetration Testing We’ll test it until we find all the flaws. • Secure Coding Follow this checklist, and everything is fine. CSC 593: Secure Software Engineering Seminar

4. Penetrate and Patch Discover flaws after deployment. Often by attackers. Users may not deploy patches. Patches may have security flaws (15%?) Patches are map to vulnerabilities. Attackers reverse engineer to create attacks. CSC 593: Secure Software Engineering Seminar

5. Penetration Testing Allocate time at end of development to test. Often time-boxed: test for n days. Schedule slips often reduce testing time. Problem: fixing flaws is expensive late in lifecycle. Regular testing Demonstrate that features work as desired. Security testing Demonstrate that application has no extra capabilities. How can you prove a negative? CSC 593: Secure Software Engineering Seminar

6. Secure Coding Secure coding Coding methods training. Checklist-based approach. Problem: relies on flawless developers. Not all problems are implementation based. Requirements may be wrong. Design may not allow for security. CSC 593: Secure Software Engineering Seminar

7. Categories of Security Flaws • Architectural/design-level flaws: security issues that original design did not consider or solve correctly. • Implementation flaws: errors made in coding the design. • Operational flaws: problems arising from how software is installed or configured. CSC 593: Secure Software Engineering Seminar

8. Architecture/Design Flaws • Race Condition • Application checks access control, then accesses a file as two separate steps, permitting an attacker to race program and substitute the accessible file for one that’s not allowed. • Replay Attack • If an attacker can record a transaction between a client and server at one time, then replay part of the conversation without the application detecting it, a replay attack is possible. • Sniffing • Since only authorized users could directly access network in original Internet, protocols like telnet send passwords in the clear. CSC 593: Secure Software Engineering Seminar

9. Implementation Flaws • Buffer overflow • Application with fixed-size buffer accepts unlimited length input, writing data into memory beyond buffer in languages w/o bounds checking like C/C++. • Input validation • Application doesn’t check that input has valid format, such as not checking for “../” sequences in pathnames, allowing attackers to traverse up the directory tree to access any file. • Back door • Programmer writes special code to bypass access control system, often for debugging or maintenance purposes. CSC 593: Secure Software Engineering Seminar

10. Operational Flaws • Denial of service • System does not have enough resources or ability to monitor resources to sustain availability under large number of requests. • Default accounts • Default username/password pairs allow access to anyone who knows default configuration. • Password cracking • Poor passwords can be guessed by software using dictionaries and permutation algorithms. CSC 593: Secure Software Engineering Seminar

11. Why security first? • Adding security later is wrapping security around existing features, not designing features with security in mind. • Adding security later is expensive. • Adding security may change how you implement application features. • Adding security may change user interface. CSC 593: Secure Software Engineering Seminar

12. SDLC Artifacts CSC 593: Secure Software Engineering Seminar

13. Trustworthy Computing SDLC CSC 593: Secure Software Engineering Seminar

14. SD3+C Secure by Design protect application and its data. Secure by Default designers should assume that security flaws exist. principles: least privilege and fail-safe defaults Secure in Deployment documentation and tools for users and administrators. easy to install security updates. Communications communicate openly and responsibly with end users and/or administrators to help them take protective action. CSC 593: Secure Software Engineering Seminar

15. What is Threat Modeling? Assessing security risks of a software system from an adversary’s perspective. CSC 593: Secure Software Engineering Seminar

16. Requirements Management support Security advisor / officer Security Features Authentication, access control, cryptography. Misuse Cases How might application features be abused? Threat Modeling What assets are you protecting? What threats to those assets exist? CSC 593: Secure Software Engineering Seminar

17. Design Design Principles Least Privilege Compartmentalize Design Patterns Threat Modeling Identify assets. Identify entry points. Design security mechanisms. CSC 593: Secure Software Engineering Seminar

18. Goals of Threat Modeling • Understand threats to guard against during requirements analysis. • Provide basis for which security mechanisms to include during design. • Verify security of system design. • Provide basis for prescribing secure implementation practices. • Provide basis for testing system security after implementation. CSC 593: Secure Software Engineering Seminar

19. Threat Modeling Process • Understand adversary’s view of system. • Characterize security of system. • Evaluate threats. CSC 593: Secure Software Engineering Seminar

20. Understanding the Adversary’s View • Identify System Assets. • System resources that an adversary might attempt to access, modify, or steal. • Ex: credit cards, network bandwidth, user access. • 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 • Determine Trust Levels. • Privileges external entities have to legitimately use system resources. CSC 593: Secure Software Engineering Seminar

21. Entry Points • Any method for system to accept input • Example: http://at204m02/ctrl.psp?pg=login • Web server: at204m02 • All network protocols that can access host • Web server specific attacks • ctrl.psp • Your controller application • pg=login • The login subsystem invoked by controller CSC 593: Secure Software Engineering Seminar

22. Client 1. System Database Report System Data Flow Diagrams Visual model of how system processes data. Hierarchical Level 0: Models whole system. Level 1: Models subsystems, … CSC 593: Secure Software Engineering Seminar

23. 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. CSC 593: Secure Software Engineering Seminar

24. 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? CSC 593: Secure Software Engineering Seminar

25. STRIDE Threat Categorization 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. CSC 593: Secure Software Engineering Seminar

26. 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. CSC 593: Secure Software Engineering Seminar

27. Goal: Read file from password-protected PC. Attack Trees—Graph Notation CSC 593: Secure Software Engineering Seminar

28. 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. CSC 593: Secure Software Engineering Seminar

29. 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. CSC 593: Secure Software Engineering Seminar

30. Quantifying Threats Calculate risk value for nodes in attack tree • Start at bottom of tree. • Assign a number 1-10 to each DREAD item. • Assign average of numbers to node. • Propagate risk values to parent nodes. • Sum risk values if child nodes are ANDed together. • Use highest risk value of all children if nodes are ORed together. Alternate technique: monetary evaluation • Estimate monetary value to carry out attacks. • Propagate values to parent nodes as above. • Note: smaller values are higher risks in this method. CSC 593: Secure Software Engineering Seminar

31. Implementation Coding standards Acceptable libraries and functions. Checklists. Static analysis tools Identifies common errors. Code reviews More effective than testing in many reports. CSC 593: Secure Software Engineering Seminar

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. CSC 593: Secure Software Engineering Seminar

33. Maintenance Prepare before release time. Receiving vulnerability reports. Releasing security advisories. Developing, testing, and distributing patches. CSC 593: Secure Software Engineering Seminar

34. SDLC at Microsoft Management support Bill Gates letter about 2002 security push. 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. CSC 593: Secure Software Engineering Seminar

35. SDLC Results CSC 593: Secure Software Engineering Seminar

36. References • Brad Arkin, “Software Penetration Testing,” IEEE Security & Privacy, 3(1):84-87, 2005. • Matt Bishop, Introduction to Computer Security, Addison-Wesley, 2005. • Graff, Mark and van Wyk, Kenneth, Secure Coding: Principles & Practices, O’Reilly, 2003. • Greg Hoglund and Gary McGraw, Exploiting Software: How to Break Code, Addison-Wesley, 2004. • Howard, Michael and LeBlanc, David, Writing Secure Code, 2nd edition, Micorosft Press, 2003. • Steve Lipner and Michael Howard, “The Trustworthy Computing Secure Development Lifecycle,” http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsecure/html/sdl.asp, 2005. • Frank Swiderski and Window Snyder, Threat Modeling, Microsoft Press, 2004. • John Viega and Gary McGraw, Building Secure Software, Addison-Wesley, 2002. CSC 593: Secure Software Engineering Seminar