Getting past that problem why architecture is the key to software security
Download
1 / 26

Getting Past THAT PROBLEM Why Architecture is the Key to Software Security - PowerPoint PPT Presentation


  • 64 Views
  • Uploaded on

Getting Past <THAT PROBLEM> Why Architecture is the Key to Software Security. Gary McGraw, Ph.D. CTO, Cigital http://www.cigital.com. Defend the perimeter with a firewall To keep stuff out Over-rely on crypto “We use SSL” “Review” products when they’re done Why your code is bad

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Getting Past THAT PROBLEM Why Architecture is the Key to Software Security' - edna


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Getting past that problem why architecture is the key to software security l.jpg

Getting Past <THAT PROBLEM>Why Architecture is the Key to Software Security

Gary McGraw, Ph.D.

CTO, Cigital

http://www.cigital.com


Old school security is reactive l.jpg

Defend the perimeter with a firewall

To keep stuff out

Over-rely on crypto

“We use SSL”

“Review” products when they’re done

Why your code is bad

Promulgate “penetrate and patch”

Disallow advanced technologies

Extensible systems (Java and .NET) are dangerous

The “fat guy with keys” does not really understand software development.

Old school security is reactive


Modern security is about managing risks l.jpg

There is no such thing as 100% secure

Must make tradeoffs

Should be business decisions

Proactive security is about building things right

Design for security

Security analysis

Secure coding practice

Security testing

It’s all about the software

Most security problems are caused by software bugs and flaws

We must build secure software

Modern security is about managing risks

Software vulnerability

reports to CERT/CC



Technology choices are glossed l.jpg

Language (#1)

C/C++

Java, C#

Perl, python, PHP

Operating system

Windows 9X

Windows NT/XP

Unix flavors

The environment in which software operates is critical

“Container” systems

CORBA

EJB

DCOM

Authentication mechanism

Biometrics

Password systems

Tokens

Smart cards

PCI keys

Network

802.11b (wireless)

Technology choices are glossed


Sociology problems l.jpg

Most security organizations are made up of network security people

MIS, IT focus

CISSP

Network people do not often understand software development

Code reviews alone do not cut it!

Most development shops have good intentions, but little security knowledge

Want to “build stuff”

No good knowledge source

See security review as a waste of time and a big hassle

Software security is

currently nobody’s job.

Sociology problems


Security problems are complicated l.jpg

IMPLEMENTATION BUGS people

THAT PROBLEM

String format

One-stage attacks

Race conditions

TOCTOU (time of check to time of use)

Unsafe environment variables

Unsafe system calls

System()

Untrusted input problems

ARCHITECTURAL FLAWS

Misuse of cryptography

Privileged block protection failure

Catastrophic security failure (fragility)

Type safety confusion error

Insecure auditing

Broken or illogical access control

Security problems are complicated


Flaw architectural problems with java l.jpg

Java’s classloading architecture flawed people

Separate instantiate class from manage name spaces

Every release had problems

March 96: JDK 1.0

March 97: JDK 1.0.7

July 98: JDK 1.2

What is “Java” anyway? (and what is .NET?!)

JavaCard

MicroChai

J2EE

More resources

TINI

J2SE

J2ME

FLAW: Architectural problems with Java


Slide9 l.jpg

Principles and Guidelines for people

Better Design


Reaching for the brass ring l.jpg
Reaching for the brass ring people

  • Design for security is critical

  • Teaching people HOW to do this is very hard

    • Apprenticeship is the state of the art today

    • Guidelines can help (but tend to be unsatisfyingly high level)

  • Guidelines can help, but are no magic bullet


Ten guiding principles for secure design l.jpg

Secure the weakest link people

Practice defense in depth

Fail securely

Follow the principle of least privilege

Compartmentalize

Keep it simple

Promote privacy

Remember that hiding secrets is hard

Be reluctant to trust

Use your community resources

Ten guiding principles for secure design


Twelve guidelines for writing safer java l.jpg

don’t depend on initialization people

limit access to entities

make everything final

don’t depend on package scope

don’t use inner classes

avoid signing your code

put all signed code in one archive

make classes uncloneable

make classes unserializeable

make classes undeserializeable

don’t compare classes by name

don’t store secrets

Twelve guidelines for writing safer Java


Problem serialization l.jpg
Problem: Serialization people

  • While serialized, objects aren’t protected by access controls

    • An attacker can read or modify the object in its serialized form

    • An attacker can create a serialized representation from scratch to insert into the system with bad data

  • Serialized data can be modified in several ways

    • Extending objects and overriding read/writeObject()

    • Extending ObjectInputStream/ObjectOutputStream

    • Capturing the data through network monitoring


Fix serialization l.jpg
Fix: Serialization people

  • Declare sensitive fields as transient if possible

  • If class will be serialized

    • Implement final writeObject() and readObject() methods to prevent subclasses overriding

    • Make sure readObject() was called - “initialized” set

  • If class should not be serialized

    • Prevent subclasses from overriding methods

      private final void writeObject()(ObjectOutputStream out) throws java.io.IOException {

      throw new java.io.IOException(“Object can not be serialized”);

      }

      private final void readObject()(ObjectOutputStream out) throws java.io.IOException {

      throw new java.io.IOException(“Object can not be deserialized”);

      }


Fix serialization15 l.jpg
Fix: Serialization people

  • Disallow permissions that allow modification to IO streams

    • SerializablePermission(“enableSubclassImplementation”)

    • SerializablePermission(“enableSubstitution”)

  • Encrypt serialized streams

    • At application level (key management is hard)

    • Through network mechanisms (SSL, IPSEC)

  • Consider using externalization as an alternative

    • Less data is transferred

    • Less ability for attacker to inject new classes

      Guidelines: “Make your classes Unserializable,” “Make your classes Undeserializable”


Slide16 l.jpg

Why Design? people


On bricks and walls l.jpg
On Bricks and Walls people

  • Proper use of “dangerous” system calls is equivalent to using solid bricks

  • Without an architecture, using all the right system calls won’t help


On architectural analysis l.jpg
On architectural analysis people

  • Designers should not do this

  • Build a one page white board design model (like that )

  • Use hypothesis testing to categorize risks

    • Threat modeling/Attack patterns

  • Rank risks

  • Tie to business context

  • Suggest fixes

  • Repeat


Slide19 l.jpg

60 people

Requirements

50

Design

40

Coding

Percentage of Defects

30

Testing

20

Maintenance

10

0

Defects at Each Stage of Software Development

Source:TRW


Slide20 l.jpg

$15,000 people

$12,000

$9,000

Cost Per Defect

$6,000

$3,000

0

Cost of Fixing Defects at Each Stage of Software Development

Requirements

Design

Coding

Testing

Maintenance

Source: TRW


@stake security defects l.jpg
@stake: Security Defects people

Source: 2002 @stake - The Hoover Project (n=45)


@stake early is good l.jpg

Although benefits can be found throughout the lifecycle, earlier involvement is most beneficial

Vulnerabilities are harder to address post-design

System-wide changesmay be required atlater stages

Enablingimprovementscan be madeat design state

@stake: Early is Good

Source: 2002 @stake - The Hoover Project


Microsoft s software security process l.jpg

Security push/audit earlier involvement is most beneficial

= on-going

Microsoft’s software security process

Where we need new tools and techniques

Threatanalysis

Secure questionsduring interviews

Learn &

Refine

External

review

Concept

Designs

Complete

Test plansComplete

Code

Complete

Ship

Post

Ship

Team member

training

Review old defects

Check-ins checked

Secure coding guidelines

Use tools

Data mutation

& Least Priv

Tests

SecurityReview


Open questions l.jpg
Open Questions earlier involvement is most beneficial

  • How is security best integrated into a standard engineering-based approach?

  • Do all engineers need to understand security?

  • What kind of organization can build secure software?

  • Is expertise and experience necessary for good security analysis?

  • Where does it come from?

  • How does auditing designs differ from auditing source code?

  • What role should security testing play in analysis?


Suggested research agenda l.jpg
Suggested research agenda earlier involvement is most beneficial

  • Quantify, analyze, and explain bug/flaw categories

  • Do more cost/benefit analysis proving that early is good

  • Untangle security software from software security at the requirements stage

  • Explain why the software security problem is growing

  • Build tools for earlier in the lifecycle

  • Find out how to teach this stuff

  • Invent measures and metrics


Pointers l.jpg
Pointers earlier involvement is most beneficial

  • Cigital’s Software Security Group invents and practices Software Quality Management

  • Get Building Secure Software

  • Send e-mail:

    [email protected]

“So now, when we face a choice between adding features and resolving security issues, we need to choose security.”

-Bill Gates


ad