Face Off: Secure Code, Myth or Reality? Gary McGraw, Ph.D., Cigital Fred Cohen, Ph.D., Burton Group Andrew Briney, Moderator

Face Off: Secure Code, Myth or Reality?

Gary McGraw, Ph.D., Cigital

Fred Cohen, Ph.D., Burton Group

Andrew Briney, Moderator

Resolved: “Writing “secure” software is a practical, achievable goal in an enterprise setting. Introductory Remarks (15 minutes)

• McGraw: YES

• Cohen: NO

Moderator Question to McGraw• McGraw answer (3 minutes)

• Cohen rebuttal and question (1 minute)

• McGraw answer (1 minute)

Moderator Question to Cohen• Cohen answer (3 minutes)

• McGraw rebuttal and question (1 minute)

• Cohen response (1 minute)

Software Security is a Good Idea

Gary McGraw, Ph.D.CTO, Cigitalhttp://www.cigital.com

We have a security problem

Reactive solutions are failing

Bad software is the root cause

Windows Complexity

05

1015202530354045

Win3.1

(1990)

WinNT

(1995)

Win 95(1997)

NT 4.0(1998)

Win 98(1999)

NT 5.0(2000)

Win2K

(2001)

XP(2002)

Mil

lio

ns

of

Lin

es

There is a solution

Awareness (among developers)• Books, training, clue

Resources for builders• Frameworks, languages, patterns

Touchpoints in the SDLC• Tools, processes, knowledge

Software security = good

Software is the target of attack

We must build better software to make

progress in computer security

We must involve BUILDERS

Toward More Secure Enterprise Applications – Software, Systems and Surety Processes

Fred Cohen, Principal Analyst, Burton Group

[email protected]

mailto:[email protected]

http://www.burtongroup.com/

Building more secure enterprise applications

Thesis

• Software quality has become a critical issue

• Tools, techniques, processes, metrics and training exist

But are not widely enough used

• Vendors can do much better

But they won’t until you insist

• But in the end, software can go only so far

Systems surety approaches are the long-term issue

• Standards approaches exist and should be leveraged


Agenda

• The state of software quality vs. the risks we face

• How do we improve the quality of systems we

build/buy

• How do we deal with low surety systems being used

for medium risk applications

• Standards

• Recommendations


Agenda

• The state of software quality vs. the risks we face


build/buy



• Standards

• Recommendations

Threat

ConsequenceHighLow

High

Manage continuously

Easy to accept risk

Avoid this risk

Reassess threatupward

Accept or avoid the riskManage tightly

Continuous reassessment processScenario analysis and practiceTop level managementTighter controlsMore expensive

Looser controlsSimple approaches

Mid-level managementLimited review process

Low cost solutions sought

Manage attentively

Manage carefully

Oversee PeriodicallyProbabilistic Risk Analysis

Expert Facilitated Analysis

Due Diligence

Scenario-based analysisGame theoretic

Covering Approaches

Systems analysis

Protection Posture Assessments

Vulnerability Testing

Low risk

Medium risk

High risk

The state of software quality

The state of software quality Poor at best

• Lots of well known vulnerability types persist

• We have long known ways to eliminate them

Input overruns – curable with compilers and runtime checks

Input syntax not checked – curable with standard input tools

Race conditions – curable with existing system lock

mechanisms

Unchecked returns – curable by language selection or libraries

Trusting outside sources – curable by programmer awareness

• All of these and more are commercially detectable

Cost is less than $1 per line of code

Cigital, Fortify, OunceLabs, Reasoning, Secure Software,

@Stake, …

Also free open source tools for all of these areas

• Is it negligence or gross negligence to not check?

The state of software quality (2)

Vendors can do much better

• Demand more to get more

Quality testing/certification by independent laboratories

(not vendor paid)?

Certification against Common Criteria (for what properties?)

Contractual mandates and acceptance testing?

Patching like recalls: paid for by the vendor, liability for consequences?

• Should enterprises sue vendors?

Merchantability and suitability for purpose are not waiveable

Licenses on software favor vendors too heavily

Is it negligent not to spend $1/line to avoid global catastrophic failures?

• Should programmers/firms lose their licenses?

Too many software tickets and you can’t program any more?

Too many software failures and you won’t buy from them any more?


Trends and where they can get us

• The trends are not looking very good

$B+ in US patch costs alone in 2003

More and more faults despite more and more promises

Despite major efforts by major players software quality

remains poor

• Nobody can create high quality software at market pace

The market has to change its mind and demand quality over

pace

• Starting to happen – but major impacts on innovation

Major breakthroughs are needed in R&D (universities)

• Far unfunded today - $10M/year give or take

The problem will remain this bad? (unsustainable)

• In 10 years major software quality problems will remain

Risk

Surety

Time


Stupid software notions

• Testing will detect enough faults

No amount of testing will produce high quality code

• Defensive programming is bad

Defensive programming means checking things

carefully

• It’s approved by/good enough for [place name here]

References like this sound good but get full details and

check them

• It’s secure, it was programmed in/by [name]

Everyone makes mistakes – process is critical

• It’s certified at level C2 / EAL4 / whatever

Unless you understand these certifications and targets

in detail don’t assume these are good things

Threat

ConsequenceHighLow

High

Manage continuously

Easy to accept risk

Avoid this risk

Reassess threatupward

Accept or avoid the riskManage tightly

Continuous reassessment processScenario analysis and practiceTop level managementTighter controlsMore expensive

Looser controlsSimple approaches

Mid-level managementLimited review process

Low cost solutions sought

Manage attentively

Manage carefully

Oversee PeriodicallyProbabilistic Risk Analysis

Expert Facilitated Analysis

Due Diligence

Scenario-based analysisGame theoretic

Covering Approaches

Systems analysis

Protection Posture Assessments

Vulnerability Testing

Low risk

Medium risk

High risk●Software quality will only get you so far

The state of software quality


Agenda• The state of software quality vs. the risks we face


build/buy



• Standards

• Recommendations

How do we improve software quality?

Improve the education of our people• NSTSSI-certified programs for managers• Graduate degree in software engineering with security

specialization• Security-related education, training, experience• Funded University research programs

Things to look for in qualified people• CISSP*(ISC2*) and similar certifications for managers• Someone who has actually implemented a government

approved secure system for implementers• Someone who has led a government approved secure

implementation for project lead

*National Security Telecommunications System Security Initiative*Certified information system security professional (International Information Systems Security Certification Consortium)

How do we improve software quality? (2)

Apply systems engineering practices• A suitable design process is necessary

• Proper policies, procedures, and standards

• External review at all steps of the effort helps

• Extensive audit of the process

• Proper vetting of the people

• Protection testing, not just functional testing

• In-depth documentation

• Skilled people in the process

• Careful technology selection

OrganizationalPerspectives and

Business Processes

Management

Policy

Standards

Procedures

Documentation

Auditing

Testing

Technology

Personnel

Incidents

Legal

Physical

Knowledge

Organization

Awareness

How do we improve software quality? (3)

Capability maturity model for IT security• None – not done• Initial - few processes are defined, and success depends on

individual effort talent and heroic effort• Repeatable - the necessary process discipline is in place to

repeat earlier successes on projects with similar applications• Defined - the process for both management and engineering

activities is documented, standardized, and integrated into an organization-wide process and used by all projects

• Managed - both the process and end-products are quantitatively understood and controlled using detailed measures

• Optimizing - continuous process improvement is enabled by quantitative feedback from the process and from testing innovative ideas and technologies

Measured against process elements of risk management, engineering, assurance management, and coordination for specific process objectives

LifecyclesData People

Systems Business




build/buy



• Standards

• Recommendations

Dealing with low surety components

When should I move to medium surety systems

• Management has to define the risk thresholds

associated with surety levels

• Users need to know what risk level they are

operating at so they can use the right systems

• Business functions should not be supported on

systems with lower surety than the risk warrants

• Policy should identify and management should

support the sanctions associated with misuse

Business risk managementConsequencesVulnerabilitiesThreats

Accept / Transfer / Mitigate / Avoid

Attack andDefense

Processes

DetectReactAdapt

DeterPrevent

Dealing with low surety components (2) If the SW won’t get us there, what do we use

instead/addition?• Use physical safeguards

Nuclear power plant control rods held out by electromagnets Physical separation of networks, digital diodes, etc.

• Use programmable logic controllers (PLCs*) Finite state machine designs (e.g., Johnson Controls, Harris,

etc.) Rate and level limiters (e.g., in SCADA* systems)

• Failsafes against important consequence Lockouts for high energy emitters Braking systems when space is entered

• Carefully designed redundancy is applied N-version programming (e.g., on the space shuttle) Timeouts and retries with redundant processors (e.g., space

systems)

*Programmable Logic Controllers*Supervisory Control And Data Acquisition Integrity Availability Confidentiality Use Control

Objectives

Dealing with low surety components (3)

How to build medium out of low?• Control the context

Identify all medium/high consequences Use medium/high surety mechanisms to failsafe them Use medium/high surety systems for all feasible controls Carefully limit the scope and effect of software systems Use redundancy and sanity checks on low surety outputs Control what goes into and out of low surety systems Have a backup plan for when the low surety stuff fails Eliminate low surety interdependencies Be very careful about change controls Keep the low surety isolated from the world

• Identity management in a medium surety system

Context

LocationTime

PurposeBehaviorIdentityMethod




build/buy



• Standards

• Recommendations

Standards Generally Accepted Information Security Principles

(GAISP) and International Standards Organization (ISO)

17799

• Control standard for management

Deal with organizational, contextual, lifecycle,

and objectives perspectives at a control level

GAISP identifies pervasive principles (PPs), broad

functional principles (BFPs), mapping between

PPs and BFPs, rationale, and examples

• At a management level only

• No technical details, just due diligence issues


Business Processes

Management

Policy

Standards

Procedures

Documentation

Auditing

Testing

Technology

Personnel

Incidents

Legal

Physical

Knowledge

Organization

AwarenessLifecyclesData People

Systems BusinessIntegrity Availability Confidentiality Use Control

Objectives

Context

LocationTime


Standards (2) Trusted Computer System Evaluation Criteria (TCSEC)• Based on measuring assurance levels and functions

associated with trusted computing bases• Defined a set of specific controls and requirements on

those controls for assuring data confidentiality• Levels implied surety and security functionality

D: Minimal Protection (if it doesn’t meet anything better - COTS*)

C: Discretionary Protection (some features - little assurance)

B: Mandatory Protection (many features - good assurance)

A: Verified Protection (same features as B - far better assurance)

• The gold standard for operating systems• Only really addresses confidentiality• Produces hard-to-use systems


Business Processes

Management

Policy

Standards

Procedures

Documentation

Auditing

Testing

Technology

Personnel

Incidents

Legal

Physical

Knowledge

Organization

Awareness LifecyclesData People

Systems Business*Commercial Off-the-shelf

Standards (3)

Common Criteria (ISO 15408)• Process for certifying

protection profiles (PP) of systems

• You define the security target (ST)

• Authorized independent testers validate your claims

• Ratings given on several dimensions

• Common Criteria Recognition Agreement allows globalization of evaluations according to specifications

Example:• ST is purely a secrecy target• Implement with physical

separation• Gain EAL7 for the ST• But it may not meet your

integrity needs!

Evaluation assurance level (EAL)• Measures how certain the

evaluators are that the product meets the ST

• EAL1: functionally tested• EAL2: structurally tested• EAL3: methodologically

tested and checked• EAL4: methodologically

designed, tested and reviewed

• EAL5: semiformally designed and tested

• EAL6: semiformally verified design and tested

• EAL7: formally verified design and tested

Standards (4)

National Security Telecommunications System Security Initiative (NSTSSI) 4011, 4012, 4013, 4014, 4015• Training standards for people responsible for

building and evaluating systems trusted for national security needs

• Define requirements for educational programs that are approvable under the U.S. Centers of Excellence Program As training standards, they are terrible –

unusable – and mandatory But they address a wide array of worthwhile

issues that are key to success at building medium and high assurance systems

They also characterize a process that works well for designing and implementing trustworthy systems

Standards (5)

Other standards to consider• ISO 9000 and similar quality standards• Trusted Computing Group (TCG) Trusted Computing

Platform (TCP) standard

Most security software is low surety• Only proper development and operation processes

allow medium and high surety levels to be reached• Most enterprises operate medium surety systems,

but most vendors do not• Most medium surety systems use standards to

create medium surety results using a mix of medium and low surety components




build/buy



• Standards

• Recommendations

Recommendations

Surety should be mapped against risks• Low risk -> low surety (in aggregation -> medium surety)• Medium risk -> medium surety, High risk -> High surety• Remember that risk and surety levels are continua, not

discrete• Most medium surety systems use low surety components

Code validation• Enterprises and others should require validation against

known classes of vulnerabilities as a condition for purchase in any Medium or high surety application Widely deployed software operating system, or

component (aggregated risk makes it medium risk)• How does the vendor prove it? – independent evaluations• Eliminate unfair liability terms in licenses / challenge in

court / require contract language

Recommendations (2)Auditing and testing approaches• Audit approaches should be matched to surety levels

according to standards of practice at each level• Black box testing will only get you so far

Wrapper-based approaches (and other containers)• Apply to all surety levels but in different ways• Low surety levels:

Very effective at reducing cost of protection Should be applied at network, platform,

application layers• Medium and high levels: More carefully considered

Trusted systems technologies• Low: TCG applies and should be looked into• Medium: TCG will soon become viable, TCSEC

available today• High: TCSEC applies and should be used where

feasible and appropriate

Recommendations (3)

Contractual and procurement approaches• All software procurement at medium and high should

require appropriate levels of assurance in contracts• Medium: Mandatory validation against known fault types• High: Specific regulations and requirements for systems,

proofs wherever possible

Standards approaches• Existing standards at medium and high levels should be

followed

Knowledge and awareness requirements• CMM approach is a good one to follow for the enterprise• Low surety: CSI, SANS, MISTI, other training useful• Medium surety: Masters level courses with NSTSSI

certified courses in the program• High surety: NSTSSI certified courses mandatory

Attack andDefense

Processes

DetectReactAdapt

DeterPrevent


Business Processes

Management

Policy

Standards

Procedures

Documentation

Auditing

Testing

Technology

Personnel

Incidents

Legal

Physical

Knowledge

Organization

Awareness Integrity Availability Confidentiality Use Control

Objectives

Business risk management

ConsequencesVulnerabilitiesThreats

Accept / Transfer / Mitigate / Avoid

Context

LocationTime


LifecyclesData People

Systems Business

Protective Measures

C

VT

C

C

V

V

V

VV

V

V

T

T

Recommendations (4)A comprehensive approach and process


Conclusions

• Enterprises should insist on software quality

Widely known and readily curable fault types must be

sought and eliminated as a matter of due diligence by

vendors

Enterprises should insist with their pocketbooks and

through legal means

• Software quality will only get you so far

Proper internal systems implementation processes

are necessary for medium and high surety systems

Failsafes and wrapper methods are used to integrate

low surety components

• Standards exist and should be followed for medium and

high surety systems


References• Burton Group’s Directory and Security Strategies

Risk Management: Concepts and Frameworks

Enterprise Patch Management: Strategies, Tools,

and Limitations

Windows Server 2003 Security: Making Progress,

But Serious Concerns Remain

• Burton Group’s Application Platform Strategies

Application Security Frameworks: Protecting

Applications Consistently

Documents

Face Off: Secure Code, Myth or Reality? Gary McGraw, Ph.D., Cigital Fred Cohen, Ph.D., Burton Group Andrew Briney, Moderator