SSD951: Secure Software Development Secure Development Lifecycle (SDL)

1. SSD951: Secure Software DevelopmentSecure Development Lifecycle (SDL) Dr. Shahriar Bijani Shahed University Fall 2016

2. Slides’ References • David Wheeler, Secure Software Design & Programming, SWE 681/ISA 681, George Mason University, Jan 2015. • SE 331- Engineering Secure Software, Rochester Institute of Technology, May 2014. • DimitryAverin, Security Engineering for Software , CS996 – Information Security Management, NYU Polytechnic School of Engineering, 2005. • Pascal Meunier, Secure Software Engineering, Purdue University • Security Development Lifecycle, Microsoft.

3. Software Security • Software security as part of the larger problem of developing robust, reliable code • Describe the relationship between software security and: • Corporate information security policies • Corporate risk strategies

4. Why is most software insecure? • Many developers don’t know how to develop secure software • Most universities don’t have it in their syllabi • Or it’s optional graduate level, not required in undergrad • Programming books/courses don’t teach it • Some common operations intrinsically dangerous (esp. C) • Most developers don’t think like an attacker • “How could this be attacked?” • Developers don’t learn from others’ security mistakes • Most vulnerabilities caused by same mistakes over 40+ years • Customers can’t easily evaluate software security • Managers don’t always resource/trainadequately • …

5. What is “Software Security”? • NOT just a set of features • Secure software > Security software • Although tools and experts are helpful, • You can’t just deploy a magical tool and expect all vulnerabilities to disappear • You can’t outsource all of your security knowledge • Even if you are using a security library, know how to use it properly

6. What is “Software Security”? • NOT just a set of features • NOT a problem for just mathematicians • NOT just using Cryptography • Cryptography • Is important and needed • Cannot solve all of your security problems • Proofs, access control rules, and verification are helpful, but inherently incomplete

7. What is “Software Security”? • NOT a problem for just networking and operating systems • Software had security problems long before we had the internet • If you left a window open in your house, would you try to fix the roads?

8. What is “Software Security”? • A reality that everyone must face • Not just developers, all stakeholders • A learnable mindset for software engineers • The ability to prevent unintended functionality • At all layers of the stack • In all parts of your system

9. Myths • Security is only required in the OS • 15% are OS vulns • I only need a good patch strategy • Mean time to attack: 330 days -> 2 weeks • I have a firewall, AntiVirusand IDS • 92% of vulns are software, not network • Functional testing finds security defects • Good practices from design to deploy are required • I use tested components in Java (or .NET) • Only helps with some classes of problem • I use cryptography • Helps with some threats, but just one tool in the toolbox

10. Which Approach? • Defense in depth: Having multiple defense mechanisms (“layers”) in place, so that an attacker has to defeat multiple mechanisms to perform a successful attack • Defense in breadth: Applying approaches to develop secure software throughout the lifecycle • Developing secure software requires actions throughout lifecycle • “Defense-in-breadth”

11. Traditional Software Engineering Requirements Design Implementation Verification Deployment Maintenance • Many years of software development experience created a well defined application software development lifecycle • There are many software development methodologies (ex. XP, waterfall, etc) they all have these basic steps • Capability Maturity Model for Software (SW-CMM), is used to measure quality of methodologies employed

12. Results from Current Software Engineering Methods • >1000 new vulnerabilities reported every year • About 50% of vulnerabilities are commonly repeated mistakes • About 25% could be avoided by considering secure design principles • Need new methods • “We can't solve problems by using the same kind of thinking we used when we created them.” (Albert Einstein)

13. Assurance • Axiom: It is impossible to demonstrate with absolute certainty that a moderately complex application doesn't have any vulnerabilities. • Second Best: We can provide assurance that an application was designed, implemented, tested in rigorous ways (and by skilled people) that decrease the chances of having vulnerabilities and defects. • e.g., training in secure programming provides assurance • software engineering processes designed for assurance

14. How do you measure assurance? • International Standard: Common Criteria • Defines Evaluation Assurance Levels (EALs) 1-7 • EALs 3-4 commonly requested by governments and security-demanding organizations • EAL 4 evaluation typically costs $1 million • High assurance (EALs 5-7) is out of the scope of this tutorial • This section provides an overview of selected topics related to assurance

15. Secure Software Engineering • Goal: minimize the number of security vulnerabilities in design, implementation and deployment • Identify and remove vulnerabilities in the development lifecycle as early as possible. Three essential components • Repeatable process • Engineer Education • Metrics and Accountability • SDL – Secure Development Lifecycle • Used along with traditional/current software development techniques in order to introduce security at every stage of software development

16. SDL – Requirements Phase Requirements Design Implementation Verification Deployment Maintenance • Development of requirements • Gather information about application [costumer/experience/survey] • Analysis of requirements • Are all the security issues addressed • CIA (Confidentiality, Integrity, Availability) • Verification of requirements • Are there are any inconsistencies / system interface / correctness • Documentation • Feasibility of requirements • [repeat] • The bottom line: Planning at this stage offers the best opportunity to build secure software in the most efficient manner [cost, time, etc]

17. SDL – Requirements Phase Requirements Design Implementation Verification Deployment Maintenance • Develop Security Requirements • Security Requirements of a system/application must be developed along with any other requirements (e.g. functional, legal, user, etc) • Risk analysis • Identify all the assets at risk • Identify all the threats • Develop security policies • Used as guidelines for requirements • Develop security metrics

18. SDL – Design Phase Requirements Design Implementation Verification Deployment Maintenance • At this stage all design decisions are made, about • Software Architecture • Software components • Programming languages • Interfaces • … • Develop documentation • Confirm that all requirements are followed and met

19. SDL – Design Phase Requirements Design Implementation Verification Deployment Maintenance • To Do: • Threat Models • Input Data Types • Security Use Cases • Security Architecture • How to Secure? • Secure Design Principles should be applied • We may use SecureDesign Patterns • Tools • E.g. SecureUML– Secure Unified Modeling Language

20. Security Design Principles • Despite years of research, it is still difficult to design systems that comprehensively prevent security flaws • But good practices for good design have been documented (= software engineering)

21. Security Design Principles • Principle of Least Privilege • Principle of defense in depth (Layering) • Fail Safe Defaults • Economy of Mechanism • Complete Mediation • Open Design (Avoid security by obscurity) • Separation of Privilege • Least Common Mechanism • Psychological Acceptability • Isolation • Encapsulation • Modularity • Least Astonishment • Attack Surface Reduction • Keep security simple

22. Least Privilege • "A subject should only be given those privileges it needs in order to complete its task." • Access control problem: how closely can (role-based, etc...) access control or capabilities match the needed privileges? At what cost? • Weakness of some Microsoft Applications: IIS 5 runs under the Local System account, equivalent to root privileges. Apache may run as “nobody” under UNIX; under Windows the equivalent procedure is possible but convoluted (and rarely done).

23. defense in depth (layering) • use of multiple, overlapping protection approaches • suggests that where one control would be reasonable, more controls that approach risks in different fashions are better. • Controls, when used in depth, can make severe vulnerabilities extraordinarily difficult to exploit and thus unlikely to occur. • secure coding: tier-based validation, centralized auditing controls, and requiring users to be logged on all pages.

24. Partitioning (Compartmentalization) • Technique to separate the code in different parts, so that each part runs with least privilege. • if a part is compromised, others are still OK • Example: Separating a user interface from the program running with special privileges (e.g., root) • Good implementation examples in Linux • Bad idea: Windows task bar tray icons running with Local System privileges • Secunia advisory SA10949, Dell TrueMobile WLAN card utility • tray icon launches help with SYSTEM privileges • can be exploited to execute arbitrary code with SYSTEM privileges

25. Fail-Safe Defaults • "Unless a subject is given explicit access to an object, it should be denied access to that object" • Apache access control through .htaccess:first (default) rule: deny from allallow from ... • Tied with the issue of failing “safe” vs failing “functional” • Switches that fail open as hubs under unusual circumstances • “Brittle” or catastrophic failures vs graceful

26. Economy of Mechanism • Keep Security Simple • Security mechanisms/measures should be as simple as possible • Simpler to implement and to verify • Fewer vulnerabilities • Complex mechanisms may not be correctly: • understood • modeled • configured • implemented • used • Complex mechanisms may engender partial implementations and compatibility

27. Economy of Mechanism: Failed Example • IPSEC (layer 3): Can do almost everything to secure TCP/IP but is monstrously complex • Sub-protocols with their own headers, which may be nested... • Every vendor’s implementation is slightly different and often incompatible with the others • Design by political committee tries to be everything to everyone! • People switch to SSL VPNs (layer 7) • Proven, robust • Much more simple • Compatible

28. Complete Mediation • Don’t trust services • All accesses to objects must be checked against an access control system to ensure that they are allowed • Performance vs security issue • Results of access check are often cached • What if permissions have changed since the last check? • Mechanisms to invalidate or flush caches after a change are often missing

29. Complete Mediation: Failure Example • Access is checked only when opening a file, which returns a file descriptor • UNIX: forked and exec’ed processes inherit file descriptors • Even if processes call setuid to relinquish access to a high privilege, there may remain open files that stay open even if the process should now not be able to access them. • Emacs used to have this problem

30. Open Design • Avoid security by obscurity • “The security of a mechanism should not depend on the secrecy of its design or implementation.” • the design should be open rather than secret (e.g., encryption algorithms)  security by obscurity • If the details of the mechanism leaks (through reverse engineering or social engineering), then it is a catastrophic failure for all the users at once. • If the secrets are abstracted from the mechanism, e.g., inside a key, then leakage of a key only affects one user. • This does not mean you should disclose source code!

31. Open Design: Failure Example • Electronic voting machines! Diebold voting machines source code analysis: • Passwords embedded in the source code. • Unauthorized privilege escalation and other vulnerabilities • Incorrect use of cryptography • Undetected, unlimited votes by voters • Insider threats - company workers or election officials can alter voters' ballot choices without their knowledge (source: Kohno, Stubblefield, Rubin and Wallach, 2003 Johns Hopkins University)

32. Notes on Open Design • Some hackers would rather have the binary than the source code when designing exploits • Obscurity is OK if the design is secure regardless • If details are leaked, the software is still secure

33. Separation of Privilege • “A system should not grant permission based on a single condition.” • Removes a single point of failure • Example: two-factor authentication • Requiring both biometric and token recognition systems reduces risks • Similar to the separation of duty: • By requiring multiple factors, collusion becomes necessary, and risks due to bribery (compromise of one factor) are reduced • Dual-signature checks

34. Separation of Privilege: Successful Example • UNIX: sudo allows the execution of commands with root privileges • Possible only if • user knows the appropriate password and • user is already member of an authorized group (e.g., wheel) This example is from Bishop M., "Computer Security: Art and Science")

35. Notes on the Separation of Privilege • Often confused with the principle of least privilege • e.g., OpenSSH has a "UsePrivilegeSeparation" option which really is an implementation of least privilege, in two parts of the code. • Compartmentalization is the technique used to separate code so that the principle of least privilege can be applied on these parts.

36. Least Common Mechanism • “Mechanisms used to access resources should not be shared” • Concept: You have two different services, of different priorities and value, provided to two different sets of users. The more they share resources, the more likely one can influence the other to: • Transmit forbidden data (covert channels issue) • Limit availability (denial of service)

37. Least Common Mechanism: Failed Example • Microsoft NT architecture: FTP and Web services on the same computer share a common thread poolExhausting the FTP thread pool will cause failed connection requests for the Web service. • CVE-1999-1148IIS processes passive FTP connection requests by assigning a thread to each port waiting for a client to connect • What if they never connect?

38. Psychological Acceptability • Security mechanisms should not make the resource more difficult to access than if the security mechanism were not present. • Example: Commercial where users have lost (all?) other hair in order to comply with a biometric authentication mechanism requesting hair samples. • Problem: Users looks for ways to defeat the mechanisms and “prop the doors open” • In practice, difficulty proportionate to the value of the protected asset is accepted

39. Acceptability Example Example mechanisms ignored for convenience • Trusted hosts -- if you’re logged into host 'A', then you automatically have access to host 'B' • .rhosts mechanism bypasses password security check • .rhosts file in / directory allows remote root access without a password • Authentication is based on IP addresses, which can be mapped to a different host through ARP poisonning

40. Isolation • Public access should be isolated from critical resources (no connection between public and critical information) • Users files should be isolated from one another (except when desired) • Security mechanism should be isolated (i.e., preventing access to those mechanisms)

41. Other Security Design Principles Encapsulation: similar to object concepts (hide internal structures) Modularity: modular structure Least astonishment: a program or interface should always respond in a way that is least likely to surprise a user Attack Surface Reduction Reduce the amount of code executing by default Reduce the volume of code that is accessible to untrusted users by default Close doors (access points) that can be easily opened/exploited

42. SDL – Implementation Phase Requirements Design Implementation Verification Deployment Maintenance • This is the stage where coding is done. • To produce secure software • Coding Standards • Centralized Security Modules • Secure builds and configurations • Known security vulnerabilities - use good programming practices • CWE/SANS top 25… • OWASP Top 10 • Follow Design & Develop Documentation

43. SDL – Verification Phase Requirements Design Implementation Verification Deployment Maintenance • Testing of the code developed in the previous stage • Cleared security tests • Security vulnerability tracking • Code Reviews • Documentation

44. SDL – Release Phase Requirements Design Implementation Verification Deployment Maintenance • How To – Secure Deployment • Deployment Principles • Deployment Patterns

45. Deployment Principles • The importance of configuration • How physical deployment impacts security • How software design can make it easier to manage security and detect attacks post-deployment Requirements Design Implementation Verification Deployment Maintenance

46. Deployment Patterns • Understand the common application types: • Mobile Client • Rich Client • Rich Internet Application • Service Interfaces (SAAS) • Web Application • Understand the common deployment patterns: • Single server, non-distributed • Multiple server, distributed • Understand the impact: • Impersonation and delegation • Layer interfaces • Trust boundaries Requirements Design Implementation Verification Deployment Maintenance

47. SDL – Response Phase Requirements Design Implementation Verification Deployment Maintenance • Causes: • Costumer feedback • Security incident details and vulnerability reports • … • Types of maintenance • Need to introduce new functionality • Need to upgrade to keep up with technology • Discovered vulnerability

48. Facts: • Every security vulnerability / flaw ignored in an earlier phase will end-up at later phase[s] • Resulting into greater • Cost • Time of the software development and/or maintenance

49. $15,000 60 Requirements 50 $12,000 Design 40 $9,000 Coding Percentage of Defects 30 Cost Per Defect $6,000 Testing 20 Maintenance $3,000 10 0 0 Earlier, Better Defects at Each Stage of Software Development Cost of Fixing Defects at Each Stage of Software Development Source:TRW

50. Case Study: Microsoft SD3 + C • Secure by Design • Software designed and implemented to “protect” itself and its information • Secure by Default • To minimize the harm when vulnerabilities exploited, software’s default state should promote security (ex. least necessary privileges) • Secure in Deployment • Software accompanied by tools and guidance to assist secure use • Communications • Developers should be prepared for discovery of product vulnerabilities and should communicate openly and responsibly with end users. (e.g. patching, deploying workarounds)