version 02u-1 computer security: art and science1 writing secure code the proactive secure...

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

Writing Secure Code

The Proactive secure Development Process

byMichael Howard

and David LeBlanc


Arguments against Building Secure Systems

Security is boringSecurity is often seen as a functionality disabler, as something that gets in the waySecurity is difficult to measureSecurity is usually not the primary skill or interest of the designers and developers creating the product Security means not doing something exciting and new.


Process Improvements

Security questions during interviews

Threat Modeling

Set the bug bar and end-of-life plans

External review

Security push

Response process


Process Improvements

Figure 2-1 Incremental security improvements to the development process.


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.


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.


Role of Education

Figure 2-2 The mind-set change that occurs when you teach security

skills to formerly nonsecurity people.


Role of Education

The More Eyes FallacyMore 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.


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


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?



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?



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?


Personas


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


Security Is a Product Feature

Milestone 0: Designs completeMilestone 1: Add core featuresMilestone 2: Add more featuresMilestone 3: Add securityMilestone 4: Fix bugsMilestone 5: Ship product


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.


Product Schedule: A Good Example

Date Product Milestone SecurityActivitiesFeb-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!


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


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


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.


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


Security Team Review

Have knowledgeable people who specialize in security outside your team review your plans.


Development Phase

Involves writing and debugging code

Important to produce best-quality code possible


Practices to Achieve Quality Code

Be hardcore about who can check in code

Security Peer Review of New CodeWrite 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.


Define Secure Coding Guidelines

Inform the team ofHow the buffers should be handled

How untrusted data should be treated

How data should be encrypted


Review Old Defects

“Learn from past mistakes”


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


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.


Practices to Performing a Security Push

Perform threat modeling firstKeep the information flowingSet 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


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


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


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.


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.


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


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.


Summary

Education and training are very important to building secure systemsSecurity Features != Secure FeaturesDo not add security as an afterthoughtDo not ship with known exploitable vulnerabilitiesEvaluate 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 02u-1 computer security: art and science1 writing secure code the proactive secure...

Documents

security features

area of security

security mean

security skills

product security goalswhere

product security goalsknow

security related questions

product internal