Writing Secure Code The Proactive secure Development Process

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

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

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

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

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

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

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

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

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 Version 02 U-1 Hire people who can think with a security/hacking mindset. Hire people with a mechanic mindset Computer Security: Art and Science 9

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

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

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

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

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 (Do. S) vulnerability Version 02 U-1 Computer Security: Art and Science 14

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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