Baseline Operating Systems Security™
Working Group

MINUTES

April 7, 2004
University of North Carolina at Charlotte

 

 

Presiding, Author of Minutes: Jack Cole

Meeting was called to order at 9:30 am ET . Participants introduced themselves, and attendance taken.

ATTENDANCE (7)
Jack Cole - ARL
Stuart Katzke - NIST
Leslee LaFountain - DoD
Craig Noah – Northrop Grumman
Gary Stoneburner - NIST
Stephen Wolthusen - Fraunhofer
Yuliang Zheng - UNCC

The agenda was accepted as proposed, and the IEEE Patent Policy was reviewed using the authorized slide set.

Operating procedures were discussed. ACTION: Jack still has not written these, but will circulate proposed procedures to the group before June meeting.

MAIN BUSINESS

This was the first meeting of the BOSS WG, and many ideas were explored.

Two main decisions were made:

  1. That BOSS will use the Common Criteria (CC) framework, and
  2. To harmonize BOSS with the medium robustness protection profile (PP) at IATF.NET

In addition, two strong needs were cited:

  1. To make design goals explicit (e.g., cost effective, current best practice, etc)
  2. To include more networking aspects in PP

Ongoing concerns expressed by the group include:

  1. Scope of BOSS: Currently limited to commercial-off-the-shelf (COTS), general-purpose (GP) operating systems, but how and should BOSS encompass the needs of  embedded/real-time systems? In multiple standards under an umbrella standard?

  2. Outside of the scope of BOSS there exists a need for metrics of the benefit of using evaluated products. Else why will people use standards such as this (these)? Nevertheless, the benefits of CC should be communicated to the critical infrastructure protection community.

DISCUSSION

Discussions centered on a few areas of interest, but not all discussions came to a conclusion or were decisive.
  1. The need to harmonize this effort with existing efforts, especially the medium robustness operating system PP at IATF.NET. It was suggested that these two PPs are not far apart, and that this harmonization is achievable.

  2. Whether and how to use CC.

    For example, EAL2+ seemed justified to one attendee, but expense of evaluation to EAL4,5 deemed too great. Another cited the need for cost effectiveness, as FISMA requires, and the NIST strategy of standardizing on current best practices.

    FISMA - Federal Information Security Management Act of 2002

  3. What is the threat space addressed.

    The question was raised about how will standard conformance work versus security targets, and how will there be a fit with a wide range of missions.

  4. How to evaluate conformance to the standard(s), and what the IEEE might do to protect the value of its mark. Testing and conformance were generally discussed.

    A valid CC PP based on intergovernmental agreements has to be evaluated, but who will pay for that, and how much will it cost? In the best case, the cost might be $10K, and funding might be sought from a U.S. Government agency. For EAL2, one evaluation might be sufficient for international purposes. Some "facts" were cited: Evaluations are very subjective processes; pre-evaluations avoid "gotchas"; the first use finds problems with security targets and vendor implementations; and therefore a reference implementation is not practical.

    The CC AMA was also discussed, and how this might mature to a capability of managing the situation of an approved OS that is patched or otherwise changed since evaluated.

  5. How to fit the CC framework into the format of an IEEE standard.

  6. How to get stakeholders (operating system (OS) vendors and others) involved in developing this standard. The desire to engage stakeholders is frustrated by the lack an identifiable operating system community. For example, there are no outstanding OS conferences.

  7. Being explicit about design goals; avoiding fuzzy requirements, things that do not have to be done; and making compliance easy were all discussed.

  8. That a guide or roadmap for vendors, stakeholders will be needed for progressive states of higher level requirements, explaining a layering structure and permitting custom development integration work.

  9. The need for internationalization of this standard.

 

SUMMARY OF ACTIONS REQUIRED

  1. Compare PPs (IATF/NIST) (Gary)
  2. Determine IEEE capability to protect its mark (Jack)
  3. Find out how well the NIST CSPP-OS maps to the format of an IEEE standard (Jack)
  4. Draft a set of policies and procedures for the group (Jack)
  5. Get stakeholders involved (All)

 

Next Meeting: May 6, 2004, Washington D.C. area
Meeting adjourned at 3:30pm ET


updated Wednesday, May 19, 2004
Contact Webmaster

This site and all contents (unless otherwise noted) are Copyright © 2004
Institute of Electrical and Electronics Engineers, Inc.
All rights reserved.