Secure software chapman
description
Transcript of Secure software chapman
![Page 1: Secure software chapman](https://reader033.fdocuments.us/reader033/viewer/2022042601/547ea5fbb37959532b8b54f7/html5/thumbnails/1.jpg)
Rod Chapman
Directions in Secure Software Development
High Assurance Software Symposium
![Page 2: Secure software chapman](https://reader033.fdocuments.us/reader033/viewer/2022042601/547ea5fbb37959532b8b54f7/html5/thumbnails/2.jpg)
Contents • Some observations
• Experiences with secure systems…
• Trends and Concerns
• A future?
![Page 3: Secure software chapman](https://reader033.fdocuments.us/reader033/viewer/2022042601/547ea5fbb37959532b8b54f7/html5/thumbnails/3.jpg)
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…”
![Page 4: Secure software chapman](https://reader033.fdocuments.us/reader033/viewer/2022042601/547ea5fbb37959532b8b54f7/html5/thumbnails/4.jpg)
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?
![Page 5: Secure software chapman](https://reader033.fdocuments.us/reader033/viewer/2022042601/547ea5fbb37959532b8b54f7/html5/thumbnails/5.jpg)
What changed? • In “Software Security: Building Security In…”, Gary
McGraw cites three main areas of change…
![Page 6: Secure software chapman](https://reader033.fdocuments.us/reader033/viewer/2022042601/547ea5fbb37959532b8b54f7/html5/thumbnails/6.jpg)
What changed? • Connectivity
• “Let’s network everything!”
![Page 7: Secure software chapman](https://reader033.fdocuments.us/reader033/viewer/2022042601/547ea5fbb37959532b8b54f7/html5/thumbnails/7.jpg)
What changed? • Extensibility
• “Dynamically loadable everything!”
![Page 8: Secure software chapman](https://reader033.fdocuments.us/reader033/viewer/2022042601/547ea5fbb37959532b8b54f7/html5/thumbnails/8.jpg)
What changed? • Growth in complexity
• More code implies more bugs
![Page 9: Secure software chapman](https://reader033.fdocuments.us/reader033/viewer/2022042601/547ea5fbb37959532b8b54f7/html5/thumbnails/9.jpg)
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]
![Page 10: Secure software chapman](https://reader033.fdocuments.us/reader033/viewer/2022042601/547ea5fbb37959532b8b54f7/html5/thumbnails/10.jpg)
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.
![Page 11: Secure software chapman](https://reader033.fdocuments.us/reader033/viewer/2022042601/547ea5fbb37959532b8b54f7/html5/thumbnails/11.jpg)
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.
![Page 12: Secure software chapman](https://reader033.fdocuments.us/reader033/viewer/2022042601/547ea5fbb37959532b8b54f7/html5/thumbnails/12.jpg)
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…
![Page 13: Secure software chapman](https://reader033.fdocuments.us/reader033/viewer/2022042601/547ea5fbb37959532b8b54f7/html5/thumbnails/13.jpg)
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!
![Page 14: Secure software chapman](https://reader033.fdocuments.us/reader033/viewer/2022042601/547ea5fbb37959532b8b54f7/html5/thumbnails/14.jpg)
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”…
![Page 15: Secure software chapman](https://reader033.fdocuments.us/reader033/viewer/2022042601/547ea5fbb37959532b8b54f7/html5/thumbnails/15.jpg)
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?
![Page 16: Secure software chapman](https://reader033.fdocuments.us/reader033/viewer/2022042601/547ea5fbb37959532b8b54f7/html5/thumbnails/16.jpg)
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
Telephone
Facsimile
Website