1. 1 Integrating Information Security Into the Procurement Process for Large Systems MITRE © 2003 The MITRE Corporation. All rights reserved.

2. 2 Agenda  Challenge: Improve IT Security in the context of large scale acquisitions  Proposed a Solution  Borrow concept from the Common Criteria for Information Technology Security Evaluation (CC)  Introduce the notions of:  A System Protection Profile (SPP)  A System Protection Profile Template (SPPT)

3. 3 © 2003 The MITRE Corporation. All rights reserved. Proposed Solution: Use Common Criteria to Express Needs Clearly  What the Common Criteria (CC) is  An internationally agreed framework for expressing information technology (IT) security  A means by which results of IT security evaluations can be recognized across boundaries  ISO Standard 15408  Dictionary or catalog of security requirements  What the CC is not  A security architecture  A process

4. 4 © 2003 The MITRE Corporation. All rights reserved. Proposed Solution: Include System Protection Profile as Part of Initial Solicitation  The System Protection Profile (SPP) is a statement of an organization’s security needs for a specific system  Description of security environment, policy, objectives  What the agency wants to accomplish, not how  Implementation-independent set of security requirements  Rationale of how requirements meet objectives Tailored to System Threats and Operational Environment Reflects Agency IT Architecture CapturesSecurityObjectives Included in Solicitation/ C&A Evidence System IT Security Requirements  The System Protection ProfileTemplate (SPPT) captures FAA security requirements for NAS systems  Using Common Criteria language and structure  Intended to be tailored for specific acquisitions  Contains required text  Contains instructions on how to produce the System Protection Profile (SPP)  Can cite relevant product Protection Profiles

5. 5 © 2003 The MITRE Corporation. All rights reserved. System Protection Profile Format  Environment  Threats  Policies  Security Objectives  Security functional specifications  Security assurance specifications (i.e., developer and IV&V Requirements)  Rationale

6. 6 © 2003 The MITRE Corporation. All rights reserved. Proposed Solution: Use SPP to Align Acquisition, Security Engineering, & C&A Processes SECURITY ACQUISITION Specifications Development Input to solicitation Contract Evaluation Testing Maintenance Vet SPPT SPP part of of Security Documents Security Documents May Be Revised Security Testing Periodic Review Time Mission Needs

7. 7 © 2003 The MITRE Corporation. All rights reserved. Security Throughout the Life Cycle  Maintain secure operational environment  Continually review security procedures and practices  Assess system changes for security impact  Conduct risk assessment  Update System Protection Profile(SPP)

8. 8 © 2003 The MITRE Corporation. All rights reserved. Systems Contracting Using The System PP Template (SPPT)  Large category of systems that are custom and unique (one of a kind)  May be built from scratch or by integrating COTS products  Most NAS systems fall into this category  Functional security specification statements reused in solicitation Functional Specification  Most assurance requirements belong in Statement Of Work (SOW)  Specifies way in which the developer performs: schedule, expected workmanship, and procedures associated with the system development  Deliverable specifications in Contract Data Requirements Lists (CDRLs) & Data Item Descriptions (DIDs)

9. 9 © 2003 The MITRE Corporation. All rights reserved. Using a SPP and the CC in System Evolution Life-Cycle  Many complex large systems evolve over multiple years  Complete requirements often cannot be adequately stated at start of system development  Requirements expected to change over system life  Need to maintain system security requirements over entire system life-cycle  Rationale may be used to support revisions to the requirements  Security should be involved in a project from the beginning — security engineering axiom  CC assumes maturity and completeness, ready for evaluation — maturity of NAS systems evolves over years  Coping Strategy: evolve security architecture as decisions are made 1997 INFOSEC Calendar

10. 10 © 2003 The MITRE Corporation. All rights reserved. Partitioning the SPP into Acquisition Documents

11. 11 © 2003 The MITRE Corporation. All rights reserved. FAA Experience  The FAA is currently applying the NAS PP Template in major acquisitions  En Route Automation Modernization (ERAM)  Controller to Pilot Data Link Communication (CPDLC)  Observations  System security requirements are understandable and comprehensive  Specifications developed quickly  Developers liked the functional specifications that resulted  Asssurance specs were an emense help in identifying the necessary CDRLs and DIDs  Excellent mechanism to capture refinements and the rationale for evolutionary changes in the system development  Clarifications in version 2

12. 12 © 2003 The MITRE Corporation. All rights reserved. References  National Information Assurance Partnership (NIAP)  http://www.niap.nist.gov/  International Common Criteria Organization  http://www.commoncriteria.org/  NAS System Protection Profile Template v.1  http://www.faa.gov/aio/common/documents.htm#ais-docs  Authors  Dr. Marshall Abrams, MITRE  abrams@mitre.org, (703) 883-6938  Kris Britton, NIAP  Kris@empire.eclipse.ncsc.mil, (410) 859-6457  Joe Veoni, MITRE  jveoni@mitre.org, (703) 883-7517