Improving the Information Assurance of LINUX

1
Improving the Information Assurance of LINUX
Session id 40278

• 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 cant 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
  products 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
• Chinas 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
  developers 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
• gt 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
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., developers product testing, source code
  control

14
What the Common Criteria isnt

• 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
  doesnt 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
Required at EAL4?
Required at EAL2?
Family
Class
Yes, level 1
No
ACM_AUT
Configuration Management
Yes, level 4
Yes, level 2
ACM_CAP
Yes, level 2
No
ACM_SCP
Yes, level 2
Yes, level 1
ADO_DEL
Delivery Operation
Yes, level 1
Yes, level 1
ADO_IGS
Yes, level 2
Yes, level 1
ADV_FSP
Development
Yes, level 2
Yes, level 1
ADV_HLD
Yes, level 1
No
ADV_IMP
Yes, level 1
No
ADV_LLD
Yes, level 1
Yes, level 1
ADV_RCR
Yes, level 1
No
ADV_SPM
20
EAL2 and EAL4 Requirements
Class Family Required at EAL2? Required at EAL4?
Guidance Documents AGD_AUT Yes, level 1 Yes, level 1
Guidance Documents AGD_CAP Yes, level 1 Yes, level 1
Life Cycle Support ALC_DVS No Yes, level 1
Life Cycle Support ALC_LCD No Yes, level 1
Life Cycle Support ALC_TAT No Yes, level 1
Tests ATE_COV Yes, level 1 Yes, level 2
Tests ATE_DPT No Yes, level 1
Tests ATE_FUN Yes, level 2 Yes, level 1
Tests ATE_IND No Yes, level 2
Vulnerability Assessment AVA_MSU No Yes, level 2
Vulnerability Assessment AVA_SOF Yes, level 1 Yes, level 1
Vulnerability Assessment AVA_VLA Yes, level 1 Yes, level 2
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 developers 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 (gt 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 Linuxs 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
  dont 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
• NSTISSP11 http//www.nstissc.gov/Assets/pdf/nst
  issp_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
A
39
(No Transcript)