Arguments against Building Secure Systems

1. Writing Secure CodeThe Proactive secure Development ProcessbyMichael Howard and David LeBlanc Computer Security: Art and Science

2. Arguments against Building Secure Systems • Security is boring • Security is often seen as a functionality disabler, as something that gets in the way • Security is difficult to measure • Security is usually not the primary skill or interest of the designers and developers creating the product • Security means not doing something exciting and new. Computer Security: Art and Science

3. Process Improvements • Security questions during interviews • Threat Modeling • Set the bug bar and end-of-life plans • External review • Security push • Response process Computer Security: Art and Science

4. Process Improvements Computer Security: Art and Science

5. Role of Education • Education is the key and the first and most important step of the process. • Many software developers understand how security features work but do not understand how to build secure systems. So education through extensive training is pivotal to building secure systems. Computer Security: Art and Science

6. Role of Education • Ongoing Training • Monthly training • Have guest speakers discuss security issues and lessons learned in their area of security and offer product expertise. Computer Security: Art and Science

7. Role of Education Computer Security: Art and Science

8. Role of Education • The More Eyes Fallacy • More eyes = More flaws = wrong • Understanding security issues and having experience building secure systems are momentous to doing a truly appropriate review. • Thinking like an attacker holds the key and education is important to get to that level. Computer Security: Art and Science

9. Design Phase • Important to get security goals and designs right as early as possible • Security Questions During Interviews • Ask security related questions during interview • Example: A buffer overrun • Hire people who can think with a security/hacking mindset. • Hire people with a mechanic mindset Computer Security: Art and Science

10. Define the Product Security Goals • Know your clients and their requirements. • Don’t include features that the target audience do not want. • Create a document that answers the following questions: • Who is the application’s audience? • What does security mean to the audience? Does it differ for the different members of the audience ? Are the security requirements different for different customers? Computer Security: Art and Science

11. Define the Product Security Goals • Where will the application run? On the internet? Behind a firewall? On a cell phone? • What are you attempting to protect? • What are the implications to the users if the objects you are trying to protect are compromised? • Who will manage the application? The user or a corporate IT administrator? • What are the communication needs of the product? Is the product internal to the organization or external, or both? Computer Security: Art and Science

12. Define the Product Security Goals • What security infrastructure services do the operating system and the environment already provide that you can leverage? • How does the user need to be protected from his own actions? Computer Security: Art and Science

13. Personas Computer Security: Art and Science

14. Security Is a Product Feature • Design Security into every aspect of your application. • The Microsoft Clip Art Gallery buffer overrun that led to arbitrary code execution • A flaw in the Solaris file restore application, ufsrestore, could allow an unprivileged local user to gain root access • The sort command in many UNIX-based operating systems, including Apple’s OS X, could create a denial of service (DoS) vulnerability Computer Security: Art and Science

15. Security Is a Product Feature • Milestone 0: Designs complete • Milestone 1: Add core features • Milestone 2: Add more features • Milestone 3: Add security • Milestone 4: Fix bugs • Milestone 5: Ship product Computer Security: Art and Science

16. Implications and Consequences • Adding security later is wrapping security around existing features, rather than designing features with security in mind.  • Adding any feature, including security, as an afterthought is expensive. • Adding security might change the way you’ve implemented features. This too can be expensive. • Adding security might change the application interface, which might break the code that has come to rely on the current interface. Computer Security: Art and Science

17. Product Schedule: A Good Example Date Product Milestone Security Activities Feb-02-2003   Security-Focused Day Feb-24-2003   Security Review II with Secure Windows Initiative Team Feb-28-2003 Beta 1 Zero Priority 1 and 2 Security Bugs Mar-07-2003 Beta 1 Release Apr-03-2003   Security-Focused Day May-25-2003 M3 Code Complete Jun-01-2003   Start 4-week-long security push Jul-01-2003   Security Review (including push results) III Aug-14-2003 Beta 2 Release Aug-30-2003   Security-Focused Day Sep-21-2003 Release Candidate 1Sep-30-2003   Final Security Overview IV with Secure Windows Initiative Team Oct-30-2003 Ship product!  Computer Security: Art and Science

18. Making Time for Security • Adjust features, costs and schedule • Doing security design work early in the development cycle allows you to better predict the schedule impact Computer Security: Art and Science

19. Threat Modeling • Threat models help form the basis of design specifications. • Threat models require understanding of security threats. Secure systems simply cannot be built without threat models Computer Security: Art and Science

20. Build End-of-Life Plans for Insecure Features • Software never dies; it just becomes insecure. • Phase out an old feature and replace it with a more secure version currently available. Computer Security: Art and Science

21. Setting the Bug Bar • Fix bugs that make sense to fix • Set your tolerance for defects low • Reduce your attack surface by following certain best practices Computer Security: Art and Science

22. Security Team Review • Have knowledgeable people who specialize in security outside your team review your plans. Computer Security: Art and Science

23. Development Phase • Involves writing and debugging code • Important to produce best-quality code possible Computer Security: Art and Science

24. Practices to Achieve Quality Code • Be hardcore about who can check in code • Security Peer Review of New Code • Write a tool that uses your source control software to build an HTML or XML file of the source code changes made in the past 24 hours. Computer Security: Art and Science

25. Define Secure Coding Guidelines • Inform the team of • How the buffers should be handled • How untrusted data should be treated • How data should be encrypted Computer Security: Art and Science

26. Review Old Defects • “Learn from past mistakes” Computer Security: Art and Science

27. External Security Review • Have a security consulting company review your code and plans • Good because it will have an outside perspective • Have the company provide feedback to the team Computer Security: Art and Science

28. Security Push • Goals of security pushes initiated by Microsoft starting late in 2001 • Raise the security awareness of everyone on the team • Find and fix issues in the code, in some instances, the design of the product • Get rid of some bad habits • Build a critical mass of security people across the team. Computer Security: Art and Science

29. Practices to Performing a Security Push • Perform threat modeling first • Keep the information flowing • Set up a core security team that meets each day to go over bugs and issues and that looks for patterns of vulnerability • The same team should have a mailing list or some sort of electronic discussion mechanism to allow all team members to ask security questions • Present prizes for best bugs, most bugs found, and so on Computer Security: Art and Science

30. Be Mindful of Your Bug Counts • Allow a developer to have no more than five bugs at a time • Total number of bugs for the product should be no more than three times the number of developers in the group Computer Security: Art and Science

31. Keep Track of Bug Metrics • Log an entry in your bug-tracking database • Add an extra field to the database to determine what kind of security threat the bug poses • Can use the STRIDE threat model to categorize the threats Computer Security: Art and Science

32. Test Phase • Testers must learn the same security techniques as developers. • The idea here is to not “test in” security but rather to verify that the system design and code can withstand attack. Computer Security: Art and Science

33. Shipping and Maintenance Phases • How do you know when you are done? • Done when you have no known security vulnerabilities that compromise the security goals determined during the design phase. • May have to reset the schedule to accommodate a security issue when about to ship. • Consider adding a list of known security issues in a readme file. Computer Security: Art and Science

34. Response Process • Once a flaw is found, put it through a triage mechanism during which you determine what the flaw’s severity is, how best to fix the flaw, and how to ship the fix to customers. • If a vulnerability is found in a component, look for all the other related issues in the component Computer Security: Art and Science

35. Accountability • If a security flaw is found, the person that wrote the code should fix it. This prevents him/her from making the same mistake. Computer Security: Art and Science

36. Summary • Education and training are very important to building secure systems • Security Features != Secure Features • Do not add security as an afterthought • Do not ship with known exploitable vulnerabilities • Evaluate your process, determine what your company’s goals are, and then plan for the changes that address the security goals. • Change perceptions and attitudes in order to build secure software • Questions/Comments ??? Computer Security: Art and Science