Transcript Secure Design Principles

Writing Secure Code
The Proactive secure
Development Process
by
Michael Howard
and
David LeBlanc
Version 02U-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 02U-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 02U-1
Computer Security: Art and Science
3
Process Improvements
Figure 2-1 Incremental security improvements to the
development process.
Version 02U-1
Computer Security: Art and Science
4
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.
Version 02U-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 02U-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 02U-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 02U-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 02U-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 02U-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 02U-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 02U-1
Computer Security: Art and Science
12
Personas
Version 02U-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 (DoS)
vulnerability
Version 02U-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 02U-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 02U-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
1Sep-30-2003
Beta 2 Release
Oct-30-2003
Ship product!
Version 02U-1
SecurityActivities
Security-Focused Day
Security Review II with Secure
Windows Initiative Team
Priority 1 and 2 Security
Bugs
Security-Focused Day
M3 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 02U-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 02U-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 02U-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 02U-1
Computer Security: Art and Science
21
Security Team Review
Have knowledgeable people who
specialize in security outside your
team review your plans.
Version 02U-1
Computer Security: Art and Science
22
Development Phase
Involves writing and debugging code
Important to produce best-quality
code possible
Version 02U-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 02U-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 02U-1
Computer Security: Art and Science
25
Review Old Defects
“Learn from past mistakes”
Version 02U-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 02U-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 02U-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 02U-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 02U-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 the threats
Version 02U-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 02U-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 02U-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 02U-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 02U-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 02U-1
Computer Security: Art and Science
36