Improving the Information Assurance of LINUX

1. Session id: 40278 Improving the Information Assurance of LINUX Mary Ann DavidsonChief Security Officer Oracle Corporation

2. Agenda • Information Assurance • Formal Security Evaluation Criteria • Common Criteria EAL2 EAL4 • Evaluation Challenges for Open Source • Practical steps to date • Future steps to achieve EAL4 • Making Linux Unbreakable

3. Information Assurance • What is Information Assurance? • The degree of confidence in the correctness of technical security mechanisms • Validation of security claims • Why Information Assurance? • How you build product is as important as what you build • “You can’t bolt on what is not built in” • How can Linux demonstrate Information Assurance? • Formal security evaluations

4. What is a Security Evaluation? • Independent (third party) verification of a product’s security claims against security evaluation criteria: • International Common Criteria (ISO 15408) - worldwide de facto evaluation standard • U.S. Federal Information Processing Standard (FIPS)-140 • Results in certificate issued by national evaluation authority: • NIAP (a NIST/NSA partnership) in U.S. • CESG in U.K. • Mutual recognition arrangement of the CC (CCRA): • Evaluation (up to EAL4) done in any member country is accepted by all other countries • Currently 15 countries

5. Who Needs Security Evaluations? • Required by government and defense markets: • U.S. NSTISSP #11 • Russia required for systems that detail “state secrets” • Legislation in Germany and Italy • China’s new CNITSEC • Considered by financial markets (BITS) • Considered by healthcare markets (HIPAA) • Considered by security-conscious customers …for systems as well as products

6. What is NSTISSP #11? • U.S. Federal policy directive - requires any national security system to have independent measure of assurance (security evaluation): • NIAP certificate • CCRA certificate • FIPS 140 certificate • “National security system” is broadly defined(e.g., the HR system for the Armed Forces) • May be extended to all Federal systems underU.S. National Strategy to Secure Cyberspace

7. What does this mean for Linux? • Government can only buy products from the Evaluated Products List (EPL), e.g.: • Windows NT, 2000 • Solaris 8 • Linux needs to be evaluated: • By every commercial distributor that wants to sell to government, or • By the open source community …but apart from Federal requirements, why else evaluate?

8. Security Evaluations: The Benefits to the Developer • Better product • Discovery and resolution of vulnerabilities prior to certification, enhances product, avoids further costs • Secure development process • Rigorous Development Environment Assessment (DEA) sign-off (covers product security design, development, test, delivery and physical security environment) • Culture of security • Creates, improves or reinforces a product developer’s commitment to security, though rigorous and time-consuming • Competitive advantage

9. Security Evaluations: The Benefits to the Consumer • Evaluations are independent measures of assurance: • Evaluation technical laboratories are independently accredited • Certificate issued by independent national authority performing technical oversight of laboratories • Developer demonstrates commitment to security-proven products • Consumer confidence, greater for higher EAL levels • Fulfils procurement requirements: • NSTISSP #11 • Other national legislation or policy

10. Security Evaluations: The Drawbacks • Costly • > $750,000 to evaluate an OS to EAL4 • Time consuming • 2-3 years first time through, for EAL4 • 9 months once proficient • Traditional security analysis, e.g.: • Benign network assumptions permitted • Hacker style penetration testing can be avoided • Unrealistic configurations permitted • Lots of ‘academic’ proof documents to produce

11. UK Germany France ITSEC CC ISO Orange Book Federal Criteria MSFR CTCPEC Evolution of Security Evaluation Criteria

12. Historic Goals of the Common Criteria • Mutual Recognition • Now resolved in CCRA • Harmonization of existing national criteria • U.S. TCSEC (“Orange Book”) • European ITSEC • Canadian CTCPEC …into an ISO standard (now approved as ISO 15408)

13. What the Common Criteria is • CC is a dictionary of technical requirements • Functional requirements • Desired or claimed security behaviour • Assurance requirements • Measures that must be or have been taken that give grounds for confidence that security functions are correctly and effectively implemented • E.g., developer’s product testing, source code control

14. What the Common Criteria isn’t • Out of scope: • Non-technical security requirements: • Physical, Personnel, Procedural • Cryptography • CCRA (international mutual recognition) • Administration of a national scheme to do CC evaluations • Not the CC evaluation process/methodology

15. Common Criteria Concepts - 1 • Protection Profile (PP) • Collection of desired CC functional and assurance requirements • Written by procurers to specify what they need • Security Target (ST) • Collection of CC functional and assurance requirements to which a developer claims a product conforms/will conform • Written by developers to specify what a product does or will provide • ST may claim product conforms to a PP (but doesn’t have to)

16. Common Criteria Concepts - 2 • Target of Evaluation (TOE) • A product or system to be/being evaluated against an ST • Evaluation Assurance Level (EAL) • EAL1 (lowest) through EAL7 (highest) • EAL4 is highest level generally achievable by commercial products • i.e., EAL5 and above are usually for very low sale volume, special security products, normally for government use only, requires semi-formal (EALs 5, 6) and formal (EAL7) mathematical proof of correct design and implementation • EAL7 example: very simple function smart card

17. Demonstrating Assurance • Biggest difficulty in product evaluation is not in showing the product has claimed security functions, but in proving the claimed assurance is valid • Proprietary products are at a huge advantage: • Development is under the control of a single entity • Development processes, testing and controls, even if rudimentary, are simple to demonstrate • Open source concepts and practices make demonstrating assurance in an open source product much harder • First open source product just evaluated (August 2003) • As Evaluation Assurance Level (EAL) rises, more assurance demonstration is required

18. Which EAL should Linux obtain? • EAL2 for Linux is achievable • but some assurance requirements will still be tricky to demonstrate compliance with • EAL4 is regularly achieved by proprietary products (Windows, Solaris) with effort • EAL4 for Linux may be unachievable without compromising some open source concepts • Only attempting evaluation of Linux will prove whether it is possible: • Start with EAL2 of a commercial distribution to establish proof of concept, then • Aim for EAL4, accepting constraints on some open source ideals, if required?

19. Assurance Requirements at EAL2 and EAL4 Class Family Required at EAL2? Required at EAL4? Configuration Management ACM_AUT No Yes, level 1 ACM_CAP Yes, level 2 Yes, level 4 ACM_SCP No Yes, level 2 Delivery & Operation ADO_DEL Yes, level 1 Yes, level 2 ADO_IGS Yes, level 1 Yes, level 1 Development ADV_FSP Yes, level 1 Yes, level 2 ADV_HLD Yes, level 1 Yes, level 2 ADV_IMP No Yes, level 1 ADV_LLD No Yes, level 1 ADV_RCR Yes, level 1 Yes, level 1 ADV_SPM No Yes, level 1

20. EAL2 and EAL4 Requirements

21. What Assurance Deliverables Must the Developer Provide? • High and Low level design documents, e.g., architecture, functional, design and test specifications • Source code • (Secure) configuration advice • Test suites, scripts, program, harness, plus all expected results and evidence that the tests completed successfully for the TOE version • Product development lifecycle including: • Source code configuration control system • Documented secure bug fix procedure

22. Assurance Challenges for Linux - 1 • Much easier for commercial distributor than for the open source community • Configuration Management • Who ‘owns’ the open source code and specifies which configuration controlled code comprises the TOE? • The definitive source code must be held in a single source code control system. Who administers and documents its operation and authorises each developer’s permitted access to it? • What personnel security checks are performed before a developer is ‘hired’? What physical security exists to protect the source code? • Automated tools for source code access control and audit, to provide developer non-repudiation

23. Assurance Challenges for Linux - 2 • Delivery and Operation • Where can a customer go to obtain the open source Linux product that is the TOE, not just the source code? • Must have a mechanism to ensure a customer can check received product is exact TOE version, e.g. checksum • Delivery must be tamper-proof, e.g. shrink wrapped CDs • Development • Who or what is the single responsible entity that fills the CC role of developer for Linux? Can that entity demonstrate exclusive control and authority over the TOE? • All tools (e.g. compilers, debuggers) used by developers and for code integration must be documented and shown to be trustworthy

24. Assurance Challenges for Linux - 3 • Guidance documentation • Installation, configuration and secure use manuals are required. Who will write these for the open source TOE? • Life Cycle Support • How are new features authorised and how are they guaranteed to not interfere with or bypass existing security features? • The bug fix lifecycle must be fully documented and the same process always followed by every developer • What is the expedited security bug fixing process? Who has authority to ensure security bugs are fixed quickly? • When a bug fix also requires design document change, who ensures that happens?

25. Assurance Challenges for Linux - 4 • Tests • How is the integrated TOE tested and by whom? • Where are the expected and actual results kept, and who or what validates their success or failure? • Vulnerability Analysis • Done by the evaluators!

26. Practical Steps Taken to Date • Need to provide Federal government with wider choice of OS products on the EPL • Oracle: • Extensive CC and other evaluation experience • 17 completed evaluations, 6 CC evaluations • Commitment to open standards and open source • Oracle desire to see Linux evaluated: • New platform for Oracle database to be evaluated on • Will not evaluate on Windows any more (no demand) • Two approaches: • EAL2 CC evaluation of commercial Linux distribution • CCeLinux Consortium

27. Red Hat Enterprise AS 2.1CC EAL2 Evaluation • Oracle in Sponsor role, Red Hat in Developer role • Evaluation being done in the UK (huge cost saving) at Syntegra (IT consultancy arm of BT) • CCRA ensures official recognition by U.S. and 14 others • Expected 9-10 month duration • Certificate expected December 2003 • Red Hat proprietary material provided to evaluators to remain proprietary • Newly generated input material and all results/output material will be made available to CCeLinux Consortium

28. CCeLinux Consortium • Non-profit organisation: • Formed by Cyber Security Policy & Research Institute, George Washington University (Tony Stanco) • Sole objective to have open source Linux CC evaluated • Intentions: • Open source CC EAL2 evaluation riding on the back of Red Hat CC EAL2 evaluation • Ultimately to get open source Linux CC EAL4 evaluated • Expected 18-36 month duration

29. Other Evaluation Efforts • IBM/SuSE just completed an EAL2 LINUX evaluation (August 2003) • Evaluation materials are available to others • EAL3 is their next target • Security targets for SuSE and RedHat are different, though assurance the same • SuSE – 19 functional claims • RedHat – 32 functional claims • General issue of evaluations – apples to apples comparison is not always easy • Important first step in establishing evaluatability of LINUX

30. Easing Future Security Evaluations of Linux • Integrate security into development process • Secure engineering and coding practice, e.g.: • Writing architecture, design, functional and test specifications with security strongly in mind • Check for classic security coding errors (e.g., buffer overflows, format string errors) • Write security regression test suites for all product components and inter-dependencies • Security awareness among developers, e.g. • Understanding basic hacker security exploits • Are mechanisms well-formed to address threats? • Security specific documentation • Build culture of security

31. Security Evaluations Are Not Enough • Methodology • Immature for newer (e.g. web-facing) products • Evaluators are not hackers • Focus more on secure design than penetration testing • Time-to-market • 12 month average cycle may trump security • Expense • High cost (> $750,000) per major product version

32. Why Linux Has To Get Security Evaluated - 1 • Mandated in order to sell to: • U.S. ‘national security systems’ (NSTISSP #11) • International markets requiring evaluated products • U.S. National Strategy to Secure Cyberspace may extend mandate to all Federal systems • Important purchasing factor for finance, healthcare, etc. • Consumer confidence of independent validation

33. Why Linux Has To Get Security Evaluated - 2 • Security evaluations are very expensive • No one commercial distributor could justify cost • Open source community consortium required to front the costs • Costs recovered through extra charge for commercial distributors’ sales to customers that specifically require evaluated version • Why EAL4? • To compete with commercial OS products • To prove Linux’s security credentials • To raise the bar

34. Making Linux Unbreakable • How to become Unbreakable • Formal security evaluations and informal ethical hacking • Build security into product from inception – don’t bolt it on • Create culture of security • How to stay Unbreakable • Extend culture of security • Changing culture is difficult - process, plans, policies, people cannot protect against indifference or ignorance • Repeat security evaluations aiming for higher assurance • Anticipate, research, stay one ahead of the hackers • Security is never finished

35. Next Steps…. • Relevant web sites to visit for more information • NSTISSP#11: http://www.nstissc.gov/Assets/pdf/nstissp_11.pdf • Common Criteria homepage: http://www.commoncriteria.org

36. Visit Our Security Partners • Join leading security providers and experts at the Oracle Security Command Center - Booth 1736 to learn first hand about new technologies to secure the enterprise and the homeland. Stop by for a chance to win a Dell Axim X5 handheld device. • Security Command Center Exhibitors: A4vison, Accela, Acsys Biometrics, Alert Technologies, Ascendent Telecommunicatons, BIO-Key International, Compressus, Dell Environmax, Deloitte Consulting, eSpatial, Netegrity, PCI Geomatics, PlanGraphics, 3Ship Analytics, Targusinfo, Thor Technologies, Vigilos, Waveset, Xybernaut. • Also visit Applications Security (Booth #841) and Vormetric (Booth #2243)

37. Reminder – please complete the OracleWorld online session surveyThank you.

38. Q & Q U E S T I O N S A N S W E R S A