Presentation is loading. Please wait.

Presentation is loading. Please wait.

CSE350 Software Design and Engineering University of Pennsylvania Office: 254 Moore GRW, Phone: 8-9509 April 9 th, 2002.

Similar presentations

Presentation on theme: "CSE350 Software Design and Engineering University of Pennsylvania Office: 254 Moore GRW, Phone: 8-9509 April 9 th, 2002."— Presentation transcript:

1 CSE350 Software Design and Engineering University of Pennsylvania Office: 254 Moore GRW, Phone: 8-9509 April 9 th, 2002

2 Administrative: Lectures lToday: Engineering Trustworthy Software (the POSSE project) l4/16 (last class): Semester Summary

3 Outline of Talk lThe need for trustworthy software lThe classical software engineering approach lDistributed development with open source lA new DARPA initiative – CHATS lPortable Open Source Security Elements (POSSE) lQuestions

4 What’s the worry??? lIt’s not a world of spreadsheets anymore… lSoftware is used to control major portions of infrastructure such as rail, power and water lReliability and security are intimately related lThere have been huge efforts and corresponding monies spent on building highly reliable systems (NASA, telephone switching software) and highly secure systems (US and other militaries) lWhy aren’t COTS systems secure?

5 “Any and all security features implemented in application software, and any and all security application programs (including firewalls, intrusion detection systems, authentication program, etc.) can be rendered useless and of no protective effect by an attack which results in seizure of control of the computer’s operating system ” - Randall Sandone, Argus Systems Group, Inc. The need for trustworthy software (and why we should start with the O.S.) “Current security efforts suffer from the flawed assumption that adequate security can be provided in applications with the existing security mechanisms of mainstream operating systems. In reality, the need for secure operating systems is growing in today’s computing environment due to substantial increases in connectivity and data sharing. The threats posed by the modern computing environment cannot be addressed without secure operating systems. Any security effort which ignores this fact can only result in a ‘fortress built upon sand’.” - NSA Operating System Security Paper, NISSC, October 1998 “It doesn’t matter what else you do if it’s all built on untrusted operating systems” - Steve Kent, Defense Science Board, 5/2000

6 Features, Security and Engineering lSecurity is not about features lIt is about delivering features reliably lMeeting expectations with no unexpected (and exploitable) behavior(s) lWe have done a very poor job of delivering secure software because we are not willing to expend the “grunt work” (such as use of formal methods and audits) that delivering secure software requires lWhen traditional software development is used, the freeze for proof/audit causes TOAD (Technically Obsolete at Delivery :-) software

7 Trusted Computer System Evaluation Criteria: Summary

8 1960 123459876123459876123459876123459876 1970198019902000 Project MAC funded by DARPA MULTICS Starts DSB “Orange Book” Task Force Unix “Orange Book” DoD 5200.28 Provably Secure Operating Systems (PSOS) Start DoD Computer Security Initiative DoD Computer Security Center Provably Secure Operating Systems (PSOS) Ends SCOMP Rated A1 Approx. 100 MULTICS sites MULTICS Version 11.0 Rated B2 XENIX 3.0 Rated B2 Gemini Trusted Network Processor Rated A1 XTS-300 Rated B3 US DoD, the last 40 years: l1965-1975Experimentation w/MULTICS, PSOS, KSOS l1975-1985Specification and Evaluation Criteria Development (see TCSEC slide earlier) Techniques for assessing assurance levels - failed because of static models l1985-1992Compartmented Mode Workstation (CMW) Secure Solaris: SUN spent $34M over 5 years; commercial flop l1995-TodayOpen Source Development Model Last MULTICS site shutdown Anderson Report Ware Report

9 DARPA Composable High Assurance Trusted Systems (CHATS) program lConcept: Doug Maughan, lExperimental research into open source development methodology lSee whether it works (for a problem that really matters to US Defense…) lUtilize existing open source communities lGoal: GOTS (vs. COTS) systems with more trust and assurance

10 DOD Customer Experienced People Viable Marketplace Net Centric Fabric Security Interest OS Knowledge Base COMMUNITY Robust Open Source Process for CHATS Direction and Focus DARPA Security Architecture Assurance Knowledge Window of Opportunity Magnifying Glass Secure Systems Results

11 Why is DARPA doing this? lAny incremental improvement in Assurance is a gain for DoD Any incremental improvement will readily be shared across a wide OS development community Any codified incremental improvement available for contract and procurement requirements Non-proprietary worked examples available to the marketplace Existing individual OS developments can continue with specific specification activities The community will take over once DARPA provides the direction and focus lROI-orientation of marketplace inhibits commercial progress

12 What is DARPA actually doing? lCHATS is ca. 12 projects, spread across OpenBSD, FreeBSD (TrustedBSD) and Linux lIndustrial participation – Microsoft has been invited to, and attended (Butler Lampson, Steve Lipner) CHATS workshops. SGI, IBM, Apple involved. Not uncritical, but… lCa. $10 million for 18 months, start Summer ’01 lAdditional increments of $20-40 million if evidence of success lFirst round therefore “low-hanging fruit” vs. really hard problems

13 Portable Open Source Security Elements (POSSE) Must keep security in the development mainstream Generate a community of open source security expertise, by demonstration and code sharing Accelerate the introduction of security technologies in both OpenBSD and across all open projects; collaborations with TrustedBSD, etc. Apply OpenBSD audit methodology to OpenSSL Document the audit process to disseminate techniques more widely

14 The Model Linux/ SE Linux FreeBSD (Trusted ) Portable Software Security Training/ Audit Training Security-Focused Community POSSE OpenBSD

15 OpenBSD as platform lBSD license – attractive to companies lOpen Source - 4.4 BSD based - split from NetBSD lCentral focus of project is security! Development characterized by continuous audit lWidely used in security products (e.g., IDS) and embedded systems See

16 POSSE project goals lAudit OpenSSL lHardware Crypto Support Both symmetric and asymmetric support Important for OpenSSL /dev/policy kernel interface for policy rules Prototype policy daemon/kernel done for D.F. Means of importing many SE Linux features lFile system attributes Persistent meta-data for objects (ACLs, labels, capabilities) Absorb from TrustedBSD work – R. Watson lSecure Bootstrap (SEBOS) – W. Arbaugh

17 Accomplishments so far lOpenBSD-influenced OpenSSL crypto framework lOpenSSL hardware crypto support now working on many varieties of hifn (7951/7811) card lPowerPC support New pf(4) packet filter lTCP ISN randomization lStack offset randomization (helps with buffer overflows) randomly sized gap is placed at the top of user stack lApache policy module (based on KeyNote) lEAFS in OpenBSD 3.1 release, Summer 2002 APIs lockstepped with Trusted BSD

18 Technology Transition / Commercial Uptake lOpenSSH Next release of Solaris ships with OpenSSH-derivative Apple’s new UNIX ships with OpenSSH IBM, HP and SGI all enqueued lDriver Support GTGI will use Hifn 7811 software in PowerCrypt XL GTGI crediting DARPA (i.e., POSSE) Avaya uses OpenBSD Hifn support in VSU-1000 VOIP appliance (400 Mbps) Many Network Security Appliance vendors…

19 Deliverables and Timeline - POSSE Start Year 1 Year 2 Audit OpenSSL HW crypt for SSL OpenBSD releases /dev/policy OpenSSH progress Continue and Document Audit Enhanced File Sys Absorb SE Linux OpenBSD releases SEBOS OpenBSD releases

20 Longer-term questions lResearch Issues Does “open source” review necessarily result in a “more assured” end product? What “processes” need to be established to ensure community-wide critical review? Current evaluation methodologies are based on “static” configurations. How must these change to deal with dynamic reconfigurability and be accomplished in very short timeframes? Spawn new research areas for compiler and programming languages which can enable trusted system development and assist auditors (such as recent work of Dawson Engler, Spiros Mancoridis, John Viega and David Wagner)

21 POSSE Personnel lPI, Jonathan Smith (Penn) lTheo de Raadt (OpenBSD project) lMichael Greenwald (Penn) lAngelos Keromytis (Columbia University) lBen Laurie (AL Group, Ltd.) lDale Rahn (Penn) lJason Wright (Penn) lTodd Miller (Penn) lStefan Miltchev (Penn) lSotiris Ioannidis (Penn)

22 Credits lSome slides from Doug Maughan of DARPA CHATS is his initiative lEffort sponsored by the Defense Advanced Research Projects Agency and Air Force Research Laboratory, Air Force Materiel Command, USAF, under agreement number F30602-01-2-0537 lMany, many contributors to software base… It will require a commitment …to release software…that prevents a hacker or an intruder from …executing or causing to be executed any malicious code on the target machine. - Kevin Mitnick, convicted felon

23 Independent Studies lAnyone who gets an “A” in CSE350 can do an independent study or Senior Project with me lPOSSE and similar projects are currently what I am interested in lOther ideas entertained…

Download ppt "CSE350 Software Design and Engineering University of Pennsylvania Office: 254 Moore GRW, Phone: 8-9509 April 9 th, 2002."

Similar presentations

Ads by Google