1. Version 02U-1 Computer Security: Art and Science1 Writing Secure Code The Proactive secure Development Process by Michael Howard and David LeBlanc

2. Version 02U-1 Computer Security: Art and Science2 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.

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

4. Version 02U-1 Computer Security: Art and Science4 Process Improvements Figure 2-1 Incremental security improvements to the development process.

5. Version 02U-1 Computer Security: Art and Science5 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.

6. Version 02U-1 Computer Security: Art and Science6 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.

7. Version 02U-1 Computer Security: Art and Science7 Role of Education Figure 2-2 The mind-set change that occurs when you teach security skills to formerly nonsecurity people.

8. Version 02U-1 Computer Security: Art and Science8 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.

9. Version 02U-1 Computer Security: Art and Science9 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

10. Version 02U-1 Computer Security: Art and Science10 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?

11. Version 02U-1 Computer Security: Art and Science11 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?

12. Version 02U-1 Computer Security: Art and Science12 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?

13. Version 02U-1 Computer Security: Art and Science13 Personas

14. Version 02U-1 Computer Security: Art and Science14 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

15. Version 02U-1 Computer Security: Art and Science15 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

16. Version 02U-1 Computer Security: Art and Science16 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.

17. Version 02U-1 Computer Security: Art and Science17 Product Schedule: A Good Example Date Product Milestone SecurityActivities 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!

18. Version 02U-1 Computer Security: Art and Science18 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

19. Version 02U-1 Computer Security: Art and Science19 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

20. Version 02U-1 Computer Security: Art and Science20 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.

21. Version 02U-1 Computer Security: Art and Science21 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

22. Version 02U-1 Computer Security: Art and Science22 Security Team Review Have knowledgeable people who specialize in security outside your team review your plans.

23. Version 02U-1 Computer Security: Art and Science23 Development Phase Involves writing and debugging code Important to produce best-quality code possible

24. Version 02U-1 Computer Security: Art and Science24 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.

25. Version 02U-1 Computer Security: Art and Science25 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

26. Version 02U-1 Computer Security: Art and Science26 Review Old Defects “Learn from past mistakes”

27. Version 02U-1 Computer Security: Art and Science27 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

28. Version 02U-1 Computer Security: Art and Science28 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.

29. Version 02U-1 Computer Security: Art and Science29 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

30. Version 02U-1 Computer Security: Art and Science30 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

31. Version 02U-1 Computer Security: Art and Science31 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

32. Version 02U-1 Computer Security: Art and Science32 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.

33. Version 02U-1 Computer Security: Art and Science33 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.

34. Version 02U-1 Computer Security: Art and Science34 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

35. Version 02U-1 Computer Security: Art and Science35 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.

36. Version 02U-1 Computer Security: Art and Science36 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 ???