Secure software chapman

Rod Chapman

Directions in Secure Software Development

High Assurance Software Symposium

Contents • Some observations

• Experiences with secure systems…

• Trends and Concerns

• A future?

Some observations • The safety-critical industry has been building

remarkably reliable and high-quality systems for

years…

• Can we apply the same approach for secure

systems?

• At Altran Praxis, we first tested this hypothesis in

1999 with the MULTOS CA system.

• It seems the answer is “Yes…but with a few key

assumptions changed…”

Some observations • In the last ten years or so, we have seen a huge rise

in interest in “security vulnerabilities” in

• operating systems,

• embedded systems,

• SCADA systems etc.

• What changed?

What changed? • In “Software Security: Building Security In…”, Gary

McGraw cites three main areas of change…

What changed? • Connectivity

• “Let’s network everything!”

What changed? • Extensibility

• “Dynamically loadable everything!”

What changed? • Growth in complexity

• More code implies more bugs

Safety and security… the difference? • Possibly the most notable difference is in the

environment itself.

• Safety-related systems – mostly operate in a benign

environment that we can control to some extent.

• Security-critical systems operate in a openly malicious

environment where we might have no control over inputs,

access, and so on

• ..and…attackers are arbitrarily intelligent, well-funded and

motivated.

• “Programming Satan’s Computer” [Needham and Anderson]

Experiences with Security

• In the worst-case, we must assume systems will be

attacked in a way that we haven’t even thought of (let

alone tested)…

• Therefore any sole claim of “we’ve tested it lots”, or

“we’ve tested it more…” offer limited confidence for

security properties

• So – why not use formal methods and sound static

verification – i.e. Correctness-by-Construction?

• Examples: MULTOS CA, Tokeneer, SPARKSkein, and other

SPARK users.

Experiences with Security

• At a technical level, strong static verification offers

confidence in a number of basic areas:

• Absence of “dumb bugs”…

• Verification of specific program properties of

interest.

• But...no silver bullet. There is still a need for solid

requirements engineering, security engineering,

architecture and so on.

Trends and Concerns

• Trend: massive resurgence in interest in static

analysis in general. (How many companies selling

“security vulnerability finder” tools???)

• Good! Raises awareness and average maturity.

• Concern: Almost all effort aimed at “low hanging

fruit” of retrospective analysis of legacy code-

bases. Gives the impression that this is the only

thing you can do…

Trends and Concerns

• Trend: lots of effort in “enumeration” of defects,

vulnerabilities, etc.

• Examples: SANS “Top 25” list, CVE, CWE, ISO OWGV

effort etc.

• Good! Provides a starting point..

• Concern: Encourages “box ticking” mentality.

• Concern: Application-specific security requirements

(i.e. the interesting stuff) is an infinite set. Trying to

enumerate it is unlikely to terminate!

A Future?

• We have shown that the CbyC/SPARK approach can

yield strong results, particularly for the highest-grade

secure systems.

• But…many systems incorporate:

• Legacy code, COTS, “SOUP”, many languages,

developed by many teams…

• The boundary between “safety” and “security” is

becoming blurred – many systems exhibit “both”…

A Future?

• Can we use architecture to isolate (sub-)systems of

differing security requirements?

• Can we combine verification evidence from multiple

sources to gain confidence where it’s most needed?

• Formal methods for the most critical components?

• Test, isolate, and contain for the less critical?

• What can we do to contractualize and enforce the

boundary between such components?

Altran Praxis Limited

22 St. Lawrence Street, Southgate,

Bath BA1 1AN

United Kingdom

+44 (0) 1225 466991

+44 (0) 1225 469006

www.altran-praxis.com

[email protected]

Telephone

Facsimile

Website

Email