NOT the Orange Book - Guide to the Definition, Specification, Tasking, and Documentation for the Development of Secure Computer Systems -- Including Condensations of the Members of the Rainbow Series and Related Documents".
c6dff998576d157864f2223dd477431e1e887552832d7e05c17ef30e82ff227c<HTML>
<HEAD>
<TITLE>NOT the Orange Book</TITLE>
</HEAD>
<BODY BGCOLOR="#ffffff" TEXT="#000000" LINK="#0000ff" VLINK="#551a8b">
<P>
1 November 1998<BR>
Source: Paul Merrill
<P>
This document available Zip-compressed:
<A HREF="http://jya.com/ntob.zip">http://jya.com/ntob.zip</A> (92K)
<P>
<HR>
<P>
<TABLE CELLPADDING="20" ALIGN="Center" BGCOLOR="black" width=100%>
<TR>
<TD><CENTER>
<TABLE CELLPADDING="20" ALIGN="Center" BGCOLOR="#ff8000" width=100%>
<TR>
<TD><H1 ALIGN=Center>
<FONT COLOR="White">NOT the Orange Book</FONT>
</H1>
<H3>
<P ALIGN=Center>
<B>By Paul H. Merrill</B>
</H3>
</TD>
</TR>
</TABLE>
</CENTER>
</TD>
</TR>
</TABLE>
<P>
<BR wp="br2">
<B>A Guide to the Definition, Specification, Tasking, and Documentation for
the Development of Secure Computer Systems -- Including Condensations of
the Members of the Rainbow Series and Related Documents,
<A HREF="mailto:PaulMerrill@ACM.Org">Paul H. Merrill</A>, Merlyn Press,
Wright-Patterson Air Force Base, 1992.</B>
<P>
<HR>
<P align="center">
<STRONG>Works by the Author from Merlyn Press</STRONG><BR wp="br2">
<P align="center">
<STRONG>Graphics User's Manual for the NCR Worksaver System</STRONG>
<P align="center">
<STRONG>Appendix I: TRIGS COMPUSEC Requirements</STRONG>
<P align="center">
<STRONG>TRIGS Computer Lifecycle Management Plan</STRONG>
<P align="center">
<STRONG>TRIGS Software Risk Management Plan</STRONG>
<P align="center">
<STRONG>Test Report: Sigma II Silver Harvester</STRONG>
<P align="center">
<STRONG>SoftWare Evaluation Team Report</STRONG>
<P align="center">
<STRONG>Software Quality Assurance</STRONG>
<P align="center">
<STRONG>PHIP Segment Specification</STRONG>
<P align="center">
<STRONG>Rainbow Readers' Digest</STRONG>
<P align="center">
<STRONG>NOT The Orange Book</STRONG> <BR wp="br1">
<BR wp="br2">
<HR>
<P ALIGN=center>
Copyright 1992 Paul H. Merrill
<P align="center">
All rights reserved with the exception of unrestricted use by the government.
<P ALIGN=center>
<HR>
<H2 align="center">
<STRONG>Dedication and Acknowledgement</STRONG>
</H2>
<P>
To Hugh Lynn, without whom this never would have gotten started. To Terry
Tucker, without whose inspiration this would not be what it is. To Larry
Miner, without whose indulgence this would never have been finished. To Jim
Plaisted, Laura Picon, Mel Hoeferlin, Dave Hensley, and Dan O'Connor, without
whose kind words this would not have been as well-aimed. To Larry Yelowitz
and DoctorDave Gobuty, without whose pressure the diamond might not be so
pure. To Steve Job, for making Apple what it was. And, of course, to Mom
and PoP.
<H2 align="center">
<STRONG>Foreword</STRONG>
</H2>
<P>
This book was started to serve as a text from which to teach an introductory
course in Computer Security. As the writing progressed, it became apparent
that more depth was needed than a simple introductory course would
entailÄandÄthat the work would need to serve those people not taking
the course. I sincerely hope that this helps you as much as it was intended
to.
<P>
<HR>
<H1 align="center">
<STRONG>Introduction</STRONG>
</H1>
<P>
This book was written to help reduce the onslaught of information available
in the field of operational computer security to manageable proportions and
to help make sense of the process needed to correctly determine the level
of computer security needed for a specific program. There are four major
groups of intended readers who can gain from the use of this text.
<P>
<B>Active COMPUSEC Professionals:</B> Those who regularly work with COMPUSEC
issues will find that this book works quite nicely to bring together, in
a manageable size, the gems from a shelf full of reference publications.
After all, who can remember it all, all of the time; paper was invented so
people could forget. Also, this book should help to locate that fine nuance
which is "in one of those books over there" but eludes capture on the tip
of the tongue at the moment.
<P>
<B>Novice COMPUSEC Professionals:</B> Those who have only recently begun
to work the COMPUSEC issues will find that this book helps to point out what
they don't know and then take a good stab at filling the void, to working
levels at least.
<P>
<B>COMPUSEC-Associated Professionals:</B> For the mass of people who work
in association with COMPUSEC professionals, especially on a program which
has COMPUSEC as a significant portion of the effort, this book serves to
enlighten without wasting an inordinate amount of time.
<P>
<B>COMPUSEC Unknowns:</B> For those who aren't sure whether their program
requires active computer security measures, this book serves to point out
what there is to be gained by COMPUSEC in an integrated security engineering
effort.
<P>
<EM><B>NOT The Orange Book</B></EM> is not intended to replace the Rainbow
Series or the associated publications produced by other governmental bodies.
Rather it seeks to point the way in a shorter and simpler format. But, just
as Cliff Notes are not the same as the classics covered by them, there is
still a need, at times, to read the full text of the standard documents.
Neither is this book intended to replace the engineering process (or the
thought process) in determining the computer security requirements. The use
of this book has been envisioned in the following ways. <BR wp="br1">
<BR wp="br2">
<B>Table of Contents:</B> The table of contents is written in the Old Style,
with major topics within the section included in the table itself. If a
particular topic is in question, between the titles and the topics, the
appropriate section should be able to be found with little difficulty. If
it is certain that the full text is going to be needed for close scrutiny,
the entry includes the title, number, and color (if a Rainbow Member) of
the unDigested document.
<P>
<B>Defining the System: </B>A guided tour of the thought processes and basic
algorithms involved seeks to help the Reader to determine the level of computer
security needed for the particular system and its environment. As a part
of this process the tradeoffs which need to be considered between computer
security and the other securities are discussed.
<P>
<B>Spare Parts Bin:</B> In the various portions of this section are the spare
parts needed to specify the requirements and task the work effort and
documentation for the various levels of computer security.
<P>
<B>Digests: </B>Each of the digests uses the information in the Table of
Contents, with amplification, as a header and follows with the highlights
from the particular book. If the digest leaves questions unanswered, going
to the full text is probably in order.
<P>
<B>Case Studies: </B>Through the use of several case studies (at high levels
of abstraction) the Reader may be able to focus the other information and
tools discussed and provided by this book.
<P>
<B>Glossary:</B> There are two "Glossaries" in this book. The first is the
digest of TG-004, the second is a glossary of the terms which need definition
in this book. While it would have been nice to have only one glossary, that
would have required deletion of TG-004 (not good for completeness) or the
inclusion of terms in the TG-004 digest which are not in TG-004 (not good
for purity.)
<P>
<HR>
<BR wp="br2">
<H1 align="center">
<STRONG>Table of Contents</STRONG>
</H1>
<P>
<STRONG>Dedication and Acknowledgement</STRONG>
<P>
<STRONG>Foreword </STRONG>
<P>
<STRONG>Introduction</STRONG>
<P>
<STRONG>Table of Contents</STRONG>
<H3>
<B><A HREF="#I">Section I: Building A Secure System</A></B>
</H3>
<BLOCKQUOTE>
<STRONG>System Security Engineering Management</STRONG>
<BLOCKQUOTE>
Systems Security Engineering as a Part of Systems Engineering<BR>
CompuSec Engineering as a Part of Systems Security Engineering<BR>
The "Securities"<BR>
System Accreditation<BR>
Security After Deployment<BR>
The Fundamental Laws of Computer Security
</BLOCKQUOTE>
<P>
<STRONG>Determining the System's Security Needs</STRONG>
<BLOCKQUOTE>
Threats and Vulnerabilities => Risks<BR>
Sharing the Security NeedsÄorÄ"CompuSec and the Securities"<BR>
Yellow Books (I & II)<BR>
Lowering the CompuSec Needs
</BLOCKQUOTE>
<P>
<STRONG>Statement of Work Issues </STRONG>18<STRONG> </STRONG>
<BLOCKQUOTE>
Format Considerations
<BLOCKQUOTE>
Separate WBS Item / Scattered Throughout
<BLOCKQUOTE>
Cost <BR>
Quality<BR>
Oversight<BR>
Perceived Importance
</BLOCKQUOTE>
</BLOCKQUOTE>
<P>
System Security Engineering Management Program
<BLOCKQUOTE>
The Securities<BR>
Oversight of Program<BR>
Industrial Security and the Rest
</BLOCKQUOTE>
<P>
Documentation
<BLOCKQUOTE>
For Itself<BR>
For Oversight Effort<BR>
Pertinent Documents
</BLOCKQUOTE>
</BLOCKQUOTE>
</BLOCKQUOTE>
<H3>
<B><A HREF="#II">Section II: Spare Parts</A></B>
</H3>
<BLOCKQUOTE>
<STRONG>C1 Class</STRONG>
<BLOCKQUOTE>
Discretionary Access Control (DAC)<BR>
Identification And Authentication<BR>
SOW Tasking
</BLOCKQUOTE>
<P>
<STRONG>C2 Class</STRONG>
<BLOCKQUOTE>
Discretionary Access Control (DAC)<BR>
Identification And Authentication<BR>
Audit<BR>
System Security Architecture<BR>
SOW Tasking
</BLOCKQUOTE>
<P>
<STRONG>B1 Class</STRONG>
<BLOCKQUOTE>
Discretionary Access Control (DAC)<BR>
Identification And Authentication<BR>
Audit<BR>
System Security Architecture<BR>
Labels<BR>
Mandatory Access Control (MAC)<BR>
SOW Tasking
</BLOCKQUOTE>
<P>
<STRONG>B2 Class</STRONG>
<BLOCKQUOTE>
Discretionary Access Control (DAC)<BR>
Identification And Authentication<BR>
Audit<BR>
System Security Architecture<BR>
Labels & Mandatory Access Control (MAC)<BR>
SOW Tasking
</BLOCKQUOTE>
<P>
<STRONG>B3 Class</STRONG>
<BLOCKQUOTE>
Discretionary Access Control (DAC)<BR>
Identification And Authentication<BR>
Audit<BR>
System Security Architecture<BR>
Labels & Mandatory Access Control (MAC)<BR>
SOW Tasking
</BLOCKQUOTE>
<P>
<STRONG>A1 Class</STRONG>
<BLOCKQUOTE>
Discretionary Access Control (DAC)<BR>
Identification And Authentication<BR>
Audit<BR>
System Security Architecture<BR>
Labels & Mandatory Access Control (MAC)<BR>
SOW Tasking
</BLOCKQUOTE>
<P>
<STRONG>CDRL Inputs</STRONG>
<P>
<STRONG>Data Item Descriptions (DIDs)</STRONG>
<BLOCKQUOTE>
Subsystem Design Analysis Report<BR>
System Security Management Plan<BR>
Security Vulnerability Analysis<BR>
System/Subsystem Specification Document for AISs<BR>
Adversary Mission Analysis<BR>
Logistical Support Analysis
</BLOCKQUOTE>
<P>
</BLOCKQUOTE>
<H3>
<B><A HREF="#III">Section III: Rainbow Readers' Digest</A></B>
</H3>
<BLOCKQUOTE>
<STRONG>DOD 5200.28-STD Orange </STRONG>(Formerly: CSC-STD-001-83) <BR>
<STRONG>DoD Trusted Computer System Evaluation Criteria</STRONG>
<BLOCKQUOTE>
Fundamental Computer Security Requirements<BR>
Divisions and Classes of Systems<BR>
Testing Guidelines<BR>
Commercial Product Evaluation<BR>
Requirements
</BLOCKQUOTE>
<P>
<STRONG>CSC-STD-002-85 Green <BR>
DoD Password Management Guideline</STRONG>
<BLOCKQUOTE>
Individual Password<BR>
Password Change<BR>
Password Protection<BR>
Password Length
</BLOCKQUOTE>
<P>
<STRONG>CSC-STD-003-85 Yellow I <BR>
Computer Security Requirements</STRONG>
<BLOCKQUOTE>
Minimum User Clearance (R<SUB>Min </SUB>)<BR>
Maximum Data Sensitivity (R<SUB>Max </SUB>)<BR>
Risk Index<BR>
Computer Security Requirements
</BLOCKQUOTE>
<P>
<STRONG>CSC-STD-004-85 Yellow II<BR>
Rationale Behind Computer Security Requirements</STRONG>
<BLOCKQUOTE>
Risk Index<BR>
Security Risk Index Matrix<BR>
Security Index Matrix For Open Security Environments<BR>
Security Index Matrix For Closed Security Environments
</BLOCKQUOTE>
<P>
<STRONG>CSC-STD-005-85 Dark Blue<BR>
DoD Magnetic Remanence Security Guideline</STRONG>
<BLOCKQUOTE>
Declassification and Clearing<BR>
Declassification Permission<BR>
Properly Functioning Media<BR>
Non-functional Media<BR>
Destruction
</BLOCKQUOTE>
<P>
<STRONG>NCSC-TG-001 Tan<BR>
A Guide to Understanding Audit</STRONG>
<BLOCKQUOTE>
Audit Requirements Overview<BR>
Audited Events<BR>
Selective Audit
</BLOCKQUOTE>
<P>
<STRONG>NCSC-TG-002 Blue<BR>
Trusted Product Evaluations A Guide for Vendors</STRONG>
<BLOCKQUOTE>
Phases of the Trusted Product Evaluation Program<BR>
Technical Description of the Product<BR>
Legal Agreement
</BLOCKQUOTE>
<P>
<STRONG>NCSC-TG-003 Tangerine I<BR>
A Guide to Understanding Discretionary Access Control</STRONG>
<BLOCKQUOTE>
Implementation Methodologies<BR>
Control Permission and Access Modes<BR>
Requirements
</BLOCKQUOTE>
<P>
<STRONG>NCSC-TG-004 Aqua <BR>
Glossary of Computer Security Terms</STRONG>
<P>
<STRONG>NCSC-TG-005 Red I<BR>
Trusted Network Interpretation</STRONG>
<BLOCKQUOTE>
Security Policy<BR>
New Evaluation Areas<BR>
Network Components<BR>
Cascading
</BLOCKQUOTE>
<P>
<STRONG>NCSC-TG-006 Tangerine II <BR>
A Guide to Understanding Configuration Management</STRONG>
<BLOCKQUOTE>
Configuration Management (CM) Use<BR>
CM Requirements<BR>
CM Tasks
</BLOCKQUOTE>
<P>
<STRONG>NCSC-TG-007 Burgandy<BR>
A Guide to Understanding Design Documentation</STRONG>
<BLOCKQUOTE>
C2 Design Documentation Requirements<BR>
B1 Design Documentation Requirements<BR>
B2 Design Documentation Requirements<BR>
B3 Design Documentation Requirements<BR>
A1 Design Documentation Requirements
</BLOCKQUOTE>
<P>
<STRONG>NCSC-TG-008 Lavender<BR>
A Guide to Understanding Trusted Distribution</STRONG>
<BLOCKQUOTE>
Trusted Distribution (TD) Assurances<BR>
Post-Production Protection<BR>
Transit Protection
</BLOCKQUOTE>
<P>
<STRONG>NCSC-TG-009 Venice Blue<BR>
Computer Security Subsystem Interpretation</STRONG>
<BLOCKQUOTE>
Required Features<BR>
Assurance Requirements<BR>
Documentation Requirements
</BLOCKQUOTE>
<P>
<STRONG>NCSC-TG-011 Red II<BR>
Trusted Network Interpretation Environments Guideline</STRONG>
<BLOCKQUOTE>
Network Security Architecture and Design<BR>
Risk Assessment<BR>
Network Security Services
</BLOCKQUOTE>
<P>
<STRONG>NCSC-TG-013 Hot Pink<BR>
Rating Maintenance Phase Program Document</STRONG>
<BLOCKQUOTE>
Preevaluation Phase<BR>
Vendor Assistance Phase/Design Analysis Phase<BR>
Evaluation Phase<BR>
Rating Maintenance Phase
</BLOCKQUOTE>
<P>
<STRONG>NCSC-TG-014 Purple<BR>
Guidelines for Formal Verification Systems</STRONG>
<BLOCKQUOTE>
Endorsement And ETL Listing<BR>
Technical factors<BR>
Features<BR>
Assurance<BR>
Required Documentation
</BLOCKQUOTE>
<P>
<STRONG>NCSC-TG-015 Brown<BR>
A Guide to Understanding Trusted Facility Management</STRONG>
<BLOCKQUOTE>
Security Administrator<BR>
Secure Operator<BR>
Account Administrator<BR>
Auditor
</BLOCKQUOTE>
<P>
<STRONG>NCSC-TG-017 Light Blue<BR>
Identification and Authentication</STRONG>
<BLOCKQUOTE>
Authentication by Knowledge<BR>
Authentication by Ownership<BR>
Authentication by Characteristic<BR>
Implementation<BR>
I&A Requirements by Class
</BLOCKQUOTE>
<P>
<STRONG>NCSC-TG-019 Blue<BR>
Trusted Product Evaluation Questionnaire</STRONG> <BR wp="br1">
<BR wp="br2">
<STRONG>NCSC-TG-020 Gray<BR>
Access Control List (ACL) Features for UNIX </STRONG>
<P>
<STRONG>NCSC-TG-021 Lilac<BR>
Trusted Database Management System Interpretation </STRONG>
<BLOCKQUOTE>
Conditions for Evaluating by Parts<BR>
Local/Global Requirements<BR>
Interpretation of the Orange Book Requirements
</BLOCKQUOTE>
<P>
<STRONG>NCSC-TG-025 Green<BR>
Data Remanence in Automated Information Systems</STRONG>
<BLOCKQUOTE>
Standard Clearing / Purging Methods<BR>
Considerations<BR>
Approved Procedures for Various Media
</BLOCKQUOTE>
<P>
<STRONG>NCSC-TG-026 Fluorescent Orange <BR>
Security Features User's Guide</STRONG>
<BLOCKQUOTE>
Audience<BR>
Format<BR>
Presentation<BR>
Example SFUGs
</BLOCKQUOTE>
<P>
<STRONG>C Technical Report 79-91 Yellow<BR>
Integrity in Automated Information Systems</STRONG>
<BLOCKQUOTE>
Integrity Goals<BR>
Integrity Principles<BR>
Integrity Policies and Mechanisms<BR>
Integrity Separation Policies<BR>
General Integrity Policies
</BLOCKQUOTE>
<P>
<STRONG>NTISSAM COMPUSEC/1-87<BR>
Advisory Memorandum on Office Automation Security </STRONG>
<BLOCKQUOTE>
User Responsibilities<BR>
Security Officer Responsibilities
</BLOCKQUOTE>
<P>
<STRONG>MIL-STD 1785<BR>
System Security Engineering Program Management Requirements</STRONG>
<BLOCKQUOTE>
Concept Exploration Phase<BR>
Demonstration and Validation Phase<BR>
Full-Scale Development Phase<BR>
Production and Deployment Phase
</BLOCKQUOTE>
<P>
<STRONG>DRS-2600-5502-86<BR>
Security Requirements for System High<BR>
and Compartmented Mode Workstations</STRONG>
<BLOCKQUOTE>
System High Requirements<BR>
Compartmented Mode Requirements
</BLOCKQUOTE>
</BLOCKQUOTE>
<H3>
<B><A HREF="#IV">Section IV: Case Studies</A></B>
</H3>
<BLOCKQUOTE>
<STRONG>NDG: New Development Gonculator</STRONG>
<BLOCKQUOTE>
Threats<BR>
Data / Classified material<BR>
Implementation
</BLOCKQUOTE>
<P>
<STRONG>UG: Upgrade Gonculator</STRONG>
<BLOCKQUOTE>
Threats<BR>
Data / Classified material<BR>
Implementation
</BLOCKQUOTE>
<P>
<STRONG>CGG: Communications Group Gonculator </STRONG>
<BLOCKQUOTE>
Threats<BR>
Data / Classified material<BR>
Implementation
</BLOCKQUOTE>
<P>
<STRONG>GIGS: Ground Intelligence Gonculator System </STRONG>
<BLOCKQUOTE>
Threats<BR>
Data / Classified material<BR>
Implementation
</BLOCKQUOTE>
<P>
<STRONG>Yellow Books</STRONG>
<BLOCKQUOTE>
NDG Assessment<BR>
UG Assessment<BR>
CGG Assessment<BR>
GIGS Assessment
</BLOCKQUOTE>
</BLOCKQUOTE>
<H3>
<B><A HREF="#V">Section V: Notes</A></B>
</H3>
<BLOCKQUOTE>
<STRONG>Abbreviations and Acronyms</STRONG>
<P>
<STRONG>Glossary</STRONG>
</BLOCKQUOTE>
<P>
<HR>
<P>
<H1 align="center">
<STRONG>Section <A NAME="I">I</A>:</STRONG>
</H1>
<H1 align="center">
<STRONG>Building A Secure System </STRONG>
</H1>
<H2 align="center">
<STRONG>I. Building a Secure Computer System</STRONG>
</H2>
<P>
As the Information Age progresses, the reliance on computers is increasing
at a steady pace. Along with this reliance comes an ever increasing need
to apply the standard management practices, which are a part of the rest
of our lives, to computers. Security has long been a standard management
practice which now needs to make its way into the management of computer
systems too. People who would never leave their office unlocked will leave
their computer modem activated without a second thought. People who would
never hand over their checkbook will leave their financial data on a diskette
unprotected. The same people who would never hand out the combination to
their safe will resist the use of password protection on a computer with
the same information stored. Security must be part and parcel of a computer
system, and it must be built into the system with minimum negative impact
and maximum return on the investment.
<H3>
System Security Engineering Management
</H3>
<P>
The security aspects of a program are maintained and nourished through Systems
Security Engineering Management as set forth in MIL-STD-1785. Systems Security
Engineering covers the entire spectrum of security activities with an integrated
approach that allows for methodical and comprehensive coverage of the security
effort.
<P>
<U><B>Systems Security Engineering as a Part of Systems Engineering</B></U>
<P>
Through the Systems Engineering discipline, Systems Security Engineering
in general, and Computer Security (CompuSec) in particular, can be accomplished
in an efficient and orderly manner. The iterative analytical techniques which
are so much a part of the Systems Engineering process are totally applicable
to the requirements definition for the Systems Security Engineering process
as well. Top level functions still decompose into lower level functionality.
The design tradeoffs and requirements analysis are still studied, interpreted,
and selected in the same manner. MIL-STD-1785 gives the tasks to be performed
and their sequencing; Systems Engineering gives the methodology to accomplish
the tasking.
<P>
<U><B>Computer Security Engineering as a Part of Systems Security
Engineering</B></U>
<P>
Though only lightly touched upon in MIL-STD-1785, computer security (CompuSec)
is an integral part of system security engineering for programs which incorporate
computers processing sensitive data. Due to the ever increasing storage capacity,
processing power, and transmission rates, damages and losses from computers
have become a very real concern across the whole of society. An entire
briefcaseful of classified data will fit on a single diskette. The average
computer heist is orders of magnitude greater than the average bank robbery.
Because computers operate so much faster than humans, the computer must handle
a significant portion of the security.
<P>
<U><B>The "Securities"</B></U>
<P>
Systems Security Engineering is concerned with a group of security disciplines
which are interrelated and have significant overlap in the protection given
against various vulnerabilities. Each must be considered, along with its
strengths and weaknesses during system requirements definition and development.
<BLOCKQUOTE>
<B>Information Security (INFOSEC):</B> Concerned with access to information
without regard to the form of the information. (Closely related to CompuSec
with a large area of overlap.)
<P>
<B>Physical Security:</B> Concerned with physical access to the protected
resources. (Locks, doors, fences, and guards.)
<P>
<B>Computer Security (CompuSec):</B> Concerned with regulating and recording
access to computer resources and the data residing in the computer.
<P>
<B>Personnel Security:</B> Concerned with the verified "Goodness" of the
personnel involved with a system (Clearances).
<P>
<B>Product Security:</B> Concerned with the security of the "product" during
the manufacturing process. (A CompuSec concern for Configuration Management
and Trusted Distribution)
<P>
<B>Industrial Security:</B> Concerned with the developing contractors' security
aspects and activities. (Higher Industrial Security is one way to lower CompuSec
requirements.)
<P>
<B>Operations Security (OPSEC):</B> Concerned with operational information
and the restricting of data to the appropriate personnel. (Loose Lips )
<P>
<B>Communications Security (COMSEC):</B> Concerned with the secure communications
and cryptographical aspects. (Often lumped with CompuSec and called INFOSEC.)
<P>
<B>Emanations Security (EMSEC, Tempest):</B> Concerned with stray electronic
impulses and the ability to use them to derive useful information.
<P>
<B>Administrative Security (Procedural Security):</B> Concerned with the
procedures used to provide for security. (Hand-written audit trails,
Administrative restriction to a given security level on a given machine,
Two-Man rule, etc.)
</BLOCKQUOTE>
<P>
<U><B>System Accreditation</B></U>
<P>
No matter what kind of computer system is being developed, there will be
someone (or some agency), responsible for allowing the system to operate
with the data needed. This someone, the accreditor {or Designated Approving
Authority (DAA), or any number of other names depending on the system} looks
at the entire system and all of the securities and evaluates the interactions
to determine the overall security suitability of the total system. Early
and active involvement of the DAA in the development of the requirements
and the system design is necessary to the development of a secure system
which will be allowed to operate, as planned, when finished.
<P>
<U><B>Security After Deployment</B></U>
<P>
Whatever security is designed and built into the system during development
must take into account the security measures which will be implemented after
system deployment. Computer security measures require action from a security
person at least on a part-time basis and, for larger systems, teams of security
personnel are needed full time. In addition, the various implementation levels
for physical security and personnel security can either raise or lower the
necessary security measures which need to be incorporated into the computer
system itself. (Obviously the security measures for an Automatic Teller Machine
(ATM) are radically different than the measures for the bank's mainframe
computer.) Security measures considered during design and development must,
therefore, take into account usability and personnel availability as well
as other security measures which may modify the security needs of the computer
system itself.
<P>
<B><U>The Fundamental Laws of Computer Security</U> </B><BR wp="br1">
<BR wp="br2">
The First Law of Computer Security
<BLOCKQUOTE>
P(Bany) = 1.0
<P>
The probability of a Bust on any secure system is 1.0<BR>
If someone really wants in.
</BLOCKQUOTE>
<P>
The Second Law of Computer Security
<BLOCKQUOTE>
The best security system ever built will not function<BR>
If not used.
</BLOCKQUOTE>
<P>
The Third Law of Computer Security
<BLOCKQUOTE>
To err is Human<BR>
To really screw things up, use a Computer.
</BLOCKQUOTE>
<P>
The Fourth Law of Computer Security
<BLOCKQUOTE>
The audit trail is there to tell you who to shoot.
</BLOCKQUOTE>
<P>
<HR>
<H3>
Determining the System's Security Needs
</H3>
<P>
In order to levy appropriate CompuSec requirements and task the developing
contractor properly, it is first necessary to determine the types of security
needed and the levels of security for each type needed. This book does not
seek to fully define the levels of security for all of the "Securities" -
just identify the tradeoffs which can be made between the "Securities" and
then fully define the level of CompuSec needed for a given set of assumptions
about the system, its environment, and its capabilities.
<P>
<U><B>Threats and Vulnerabilities => Risks</B></U>
<P>
The purpose of the CompuSec requirements and tasking levied on a system is
to lower the risks of the system. Risks occur when a threat finds a vulnerability
to attack. By reducing either the threat or the system's vulnerability to
the threat, the risk is reduced.
<P>
<B>Vulnerabilities:</B> Vulnerabilities can be grouped into two main categories
for CompuSec purposes; the system itself and the data which is stored, processed,
and/or transmitted by the system.
<P>
The computer portion of the system itself is relatively fragile by nature
and is susceptible to system shutdown or slowdown without very much effort
on the part of the threat. Even a relatively small degradation in performance
is sufficient to cause the system to become effectively worthless. In addition,
the typical non-embedded system is a high dollar value piece of equipment
which is always a favorite target.
<P>
The data used within the system is obviously a target for the threats to
the system. After all, the manipulation of the data is why the computer system
is being developed. Whether classified or not, the data is needed by the
user of the system or it should not be on the system. Any data that is needed
by the user is also needed by those Not So Friendly people in the world and/or
the Not So Friendlies would like to see the data not be available to the
user.
<P>
<B>Threats:</B> Threats to a system come in a wide variety of shapes and
sizes. An airborne system has the threat that it might fall to Earth. A ground
based system has the threat of power surges during a thunder storm. Either
of these threats can effectively deny the user the use of the system and
its data without any malicious intent on the threats part. In addition, there
are indeed Not So Friendly people out there who will want a system and its
data, either for their own or to deny the use of the system to the user.
Each threat must be considered for each system, though the nature of the
system will limit the viable threats somewhat. (Computer Centers rarely suffer
from bird strikes and crash from the sky.)
<P>
<B>Risks:</B> When the Vulnerable assets of a system are subject to targeting
by the Threats to the system, Risk of Bad Things happening is present. The
point behind the CompuSec engineering effort is to reduce the risks to an
acceptable level so that the Bad Things won't happen beyond the system's
level to cope with them. (Because the Bad Things for one system are different
than the Bad Things for another system, the Approach to determining the needs
for a system is the purpose of this section.)
<P>
<U><B>Sharing the Security Needs or"CompuSec and the Securities"</B></U>
<P>
Theoretically the computer system could be built which would allow anyone,
even Not So Friendly folk, to sit down at the terminal and have an acceptable
level of risk. In fact, this is essentially the case for the network of ATMs
raising its head all over the place. This is not, however, the optimum situation
for most systems. Through a well-reasoned engineering trade-off process,
a suitable mix of the securities can be found which will minimize performance
degradation and cost while remaining in the realm of well understood techniques
and well within the state-of-the-art (and probably within the
state-of-the-technology.)
<P>
<B>Performance Considerations:</B> Whatever security measures are levied
on the system will have some effect on the performance of the system. In
the case of the ATMs, ease of use is reduced by the need to have the Card
and the limited functionality of the available options. If human intervention
is required for each access to data, the queue will build to intolerable
levels for an active system. Requiring the system to maintain security labels
on each subject and object within the system will add unnecessary throughput
to a system which operates at a single security level. A facility entry system
which backs-up the personnel around the block at shift change is most probably
counter-productive. Some of the basic trade-offs between CompuSec and the
other Securities are:
<P>
<B><I>Layered Physical Security</I></B> will allow for more ready access
to the terminals for a limited set of users, provided that the Physical Security
measures are sized properly for the actual traffic flow. The Physical Security
tends to be manpower intensive and or to use emerging technology which will
add another set of CompuSec concerns regarding the computer that runs the
physical security. In most instances, some level of Physical Security will
be required.
<P>
When control over the users is possible, <B><I>Personnel Security</I></B>
can reduce the level of CompuSec required. Unfortunately, operational
considerations do not always allow for sufficient controls to be placed on
the personnel. The ultimate case in point is the ATM Network, but, in this
day and age of multinational cooperation, the limiting of personnel to US
nationals goes out the window when the system is sold through Foreign Military
Sales (FMS). The limiting of personnel to relatively high clearance levels
will add to the lifecyle cost of the system unless the users are, by the
nature of their duties, already cleared to the required level.
<P>
While labor-intensive, <B><I>Procedural Security</I></B> can solve many
"unsolvable" situations. The system operators must have the ability to circumvent
the normal operations of the system in order to perform some of their tasks
- Procedural Security is the answer. Overuse of this technique will limit
the ability of the "watchers" to watch effectively, and the higher the use
the higher the problem of watching the watchers grows.
<P>
Intelligent use of these securities will allow for a greater degree of trust
to be granted the system's software through development by cleared personnel
and configuration management throughout the life of the system, including
upgrades. All of those little devils like Trojan Horses, Viruses, Logic Bombs,
Worms, etc. will be greatly reduced, and possibly stopped, through careful
application of <B><I>Administrative, Product, and Industrial
Securities</I></B>.
<P>
<B>Costs:</B> Additional requirements, of any kind, add to the development
cost of a system. In some cases, though, the lifecycle cost will be lower
because of the increased requirements. The following are some of the aspects
of the cost of the requirements that need to be considered.
<P>
Because the majority of the CompuSec requirements are realized in software,
the development cost of CompuSec requirements are substantial. To some degree
these costs can be lowered through the purchase of COTS systems from the
National Computer Security Center's (NCSC) Evaluated Product List (EPL) for
the appropriate level of security. The other securities are typically realized
as hardware subsystems and as operational procedure manuals. Depending on
the level of security required, these can be COTS turnkey systems and procedures
which are simple and straight forward. In the extreme case, the requirements
can represent a major development effort in their own right.
<P>
The payoff for the expense in development is that if the computer performs
a function, a person does not need to. CompuSec requirements which are executed
properly reduce the manpower needed for the life of the system. The personnel
needs linked to Physical Security are high and the Administrative Security
methodologies also are labor intensive. Personnel Security can become
prohibitively expensive in more resources than mere money if the required
clearance levels grow too far beyond the minimum necessary in an effort to
simplify the security requirements in other security disciplines.
<P>
<B>Level of Understanding:</B> Of all of the security disciplines which are
managed by System Security Engineering Management, CompuSec is probably the
least well understood. While there is nothing especially difficult about
CompuSec, its relative newness leads to misunderstandings concerning its
requirements which would not happen in another discipline. Because of this
low misunderstanding threshold, any requirements which are leveled in the
CompuSec arena must be stated in the clearest form possible and monitored
closely to ensure proper execution.
<P>
<B>Do-Ability:</B> In conjunction with the generally low level of understanding
of the CompuSec discipline, the do-ability of CompuSec functionality bottoms
out in much shallower water than with functionality that is better understood.
The state-of-the-art for CompuSec is not on a par with the
state-of-the-technology for other aspects of systems development. Each time
a CompuSec requirement is levied it must be carefully examined to ensure
the do-ability.
<P>
<U><B>Yellow Books (I & II)</B></U>
<P>
The Yellow Books are members of the Rainbow Series put out by the NCSC. (Actually
they are CSC-STD-003-85 and CSC-STD-004-85. Digests of these two standards
can be found in Section III: Rainbow Readers' Digest.) The sole purpose of
these two documents is to give a standard method for determining the needed
Orange Book Class for a given system with its given set of circumstances.
The approach taken by the Yellow Books is conceptually simple: take the level
of data on the system and compare it to the clearances of the people with
access to the system. The greater the difference between the lowest cleared
person and the highest level of data, the higher the risk. The following
steps are taken to quantify this risk.
<P>
<B>Minimum User Clearance Rating (RMin):</B> Through the use of the table
in the Yellow Books, a numeric rating is given to the clearance of the lowest
cleared personnel who will have access to the system. This number will be
between 0 (Uncleared, without access to Sensitive Unclassified Information)
and 7 (TS/SBI with access to Multiple Categories of TS Data).
<P>
<B>Maximum Data Sensitivity Rating (RMax):</B> Through the use of the appropriate
table in the Yellow Books, a numeric rating is given to the sensitivity of
the most sensitive data operated on by the system. The number will be between
0 (Unclassified) and 7 (TS with two or more categories of Secret or TS data).
<P>
<B>Risk Index:</B> The Risk Index is computed by subtracting the RMin from
the RMax. When a non-positive (zero or negative) value is the result {all
users cleared to equal to or higher than all of the data}, the Risk Index
is 1 if there are any categories to which any user does not have access and
0 otherwise. When a positive value is the result, the Risk Index is that
result.
<BLOCKQUOTE>
(<STRONG>Risk Index = RMax - RMin</STRONG>)
</BLOCKQUOTE>
<P>
<B>Modes of Operation:</B> The CompuSec requirements for a system vary with
the mode of operation and the controls that are necessary to allow for operation
in that mode. There are four recognized modes of operation for secure computer
systems. Each of these modes has its own environment in which to operate
and conditions that indicate its use.
<P>
The <B><I>Dedicated Mode</I></B> of operation is indicated for a system when
each user has clearance for all of the data on the system, formal access
to all of the data, and a valid need-to-know for all of the data.
<P>
The system <B><I>high mode</I></B> of operation is indicated for a system
when each user has clearance for all of the data on the system and formal
access to all of the data on the system, but not all of the users have a
valid need-to-know for all of the data on the system.
<P>
The <B><I>compartmented mode</I></B> of operation is indicated for a system
when each user has clearance for all of the data on the system but not all
users have formal access or a valid need-to-know for all of the data on the
system.
<P>
The <B><I>multilevel mode</I></B> of operation is indicated for systems where
not every user has clearance for all of the data on the system, formal access
to all of the data on the system, or a valid need-to-know for all of the
data on the system.
<P>
<B>Development Environment:</B> Malicious logic planted by the developers
during development is almost impossible to find until it is too late. When
a system is developed by personnel who are verified to not be Not So Friendly
People the system can be trusted to act in the manner in which it was designed
(at least more so than a system which may have been developed by malicious
programmers.) Because of this, the Yellow Books allow for less stringent
CompuSec requirements when the system is developed in a closed environment
than if it is developed in an open environment.
<P>
There are two required conditions for a Closed Development Environment, both
of which must be met, to qualify a development environment as Closed.
<P>
<B>Developers:</B> The developers must have clearances and authorizations
equal to the data which will be processed by the system, or at least Secret
clearance for systems that will process data at or above Secret. (This is
to reduce the risk of malicious logic being inserted by the developers.)
<P>
<B>Configuration Control:</B> Configuration control must be sufficient to
ensure no malicious logic is inserted after development.
<P>
If either of the above conditions are not met, the development environment
is Open. It should be noted that most COTS systems are developed in an Open
Environment. (In fact, most commercial vendors fail both conditions).
<P>
<B>Orange Book Class:</B> Now that the Risk Index, Mode of Operation, and
Development Environment type have been selected/defined for the system, the
Orange Book Criteria Class needed for the system can be determined. The actual
CompuSec requirements and tasking are based upon the Orange Book Class indicated.
<BLOCKQUOTE>
<B>C1:</B> Provides for nominal Discretionary Access Control (DAC).
<P>
<B>C2:</B> Provides for more finely grained DAC, auditing, and accountability
through individual login procedures.
<P>
<B>B1:</B> Additionally provides for Mandatory Access control (MAC), an informal
policy model, and export labeling.
<P>
<B>B2:</B> Additionally provides for a formal model, covert channel analysis,
a structured Trusted Computing Base (TCB), and stringent Configuration
Management.
<P>
<B>B3:</B> Additionally provides for a small TCB which contains only security
policy enforcement functions, a separate security administrator function,
and all accesses to objects are to be mediated.
<P>
<B>A1:</B> Functional requirements are the same as B3. Additionally provides
for formal design specification and verification techniques and more stringent
documentation and Configuration Management requirements.
</BLOCKQUOTE>
<P>
<U><B>Lowering the CompuSec Needs</B></U>
<P>
Now that the various trade-off options have been discussed and an initial
Orange Book class has been identified with the Yellow Books, the iterative
process of tuning the system operational concept to lower the CompuSec needs
begins. The following areas are the primary areas where progress can be made
in this effort.
<P>
<B>Classified Needs:</B> The assumed classified needs of the system should
be reviewed to ensure the validity of each level of classified or sensitive
data. In some instances, the data requirements of the system could be satisfied
with a lower level of data which can materially lower the level of CompuSec
requirements. Nice-To-Haves aren't so nice when they get to be expensive.
<P>
<B>Operational Personnel:</B> If the system concept calls for most of the
operational personnel to be cleared to Level X and a few to be cleared only
to the lower Level Y, it should be investigated whether the few can be reasonably
cleared to Level X as well. If, on the other hand, only a few of the personnel
are cleared (conceptually) to Level X, it should be investigated whether
the Level X personnel (and the Level X data) could be segregated into a subsystem
of the total system which is not accessible to the Level Y personnel.
<P>
Environmental Considerations: The net effects of the other securities should
be reviewed to tune the trade-offs on iteration of the security requirements
definition. In some instances, slightly raising the other Securities'
requirements will greatly lower the CompuSec requirements. In other cases,
it may become clear that relieving the other Securities of some of their
requirements will have no negative impact on the system because CompuSec
is going to need to cover that aspect of security anyway.
<H3>
Statement of Work (SOW) Issues
</H3>
<P>
As the Class of requirements increases, the documentation requirements and
other tasks also increase. By the time that the jump from B3 to A1 comes
along, the only changes are to the tasking and documentation; the functional
requirements are identical. This part of the book will supply the Spare Parts
and "installation instructions" for the SOW.
<P>
There are some decisions to be made for the specific program in question;
these decisions will be discussed in the Format Considerations portion. The
impacts of the decisions are subtle, but, like much subtlety, the effects
can be truly insidious.
<P>
System Security Engineering Management (SSEM), as set forth in MIL-STD-1785,
covers a broad range of security disciplines which includes computer security.
The SSEM Program portion shows the paths which will help the program arrive
at the appropriate destination for the system. It is especially important
that the other securities neither wash out the computer security nor allow
the computer security to wash them out.
<P>
The Documentation portion gives a guided tour of the various documents which
are peculiar to, or measurably altered by, computer security.
<P>
The Tasks portion breaks the tasks into digestible chunks and presents them
by Orange Book Class. The final arrangement in the SOW will be based on the
decisions which need to be made with the help of the Format Considerations
portion presented earlier in the SOW part and as modified by the SSEM program
portion.
<H3>
Format Considerations
</H3>
<P>
The formatting of the tasking within the SOW can have impacts beyond the
surface impression. The continuity of the security effort and the cost of
that effort are both affected by the layout of the tasking as well as the
reporting of the effort and its costs. The decision must be made early in
order to have the security built into the program instead of a Johnny-Come-Lately
effort tacked on to the main effort after it is too late to achieve much
more than expensive Lip Service.
<P>
<U><B>Separate WBS Item / Scattered Throughout </B></U>
<P>
At the lower extreme, the C1 Class systems require very little in the way
of special requirements or extra documentation. For such systems there is
no need to have a special niche set in the Work Breakdown Structure (WBS)
for the CompuSec effort.
<P>
On the other hand, the A1 Class systems have such intensive requirement sets,
software proofs, and documentation that the set of activities represents
a significant portion of the overall effort for the system. For such systems
there is a definite need to elevate security in general, or CompuSec in
particular, a relatively high niche in the WBS for reporting purposes and
to give a unified front for the related, and interdependent, activities involved
in the design and development of an A1 Class system.
<P>
Now that the decisions for the extremes are taken care of, consideration
must be given to the middle ground. The relative scale and scope of the CompuSec
effort as a portion of the total effort will be the primary determining factor
for a given system. Secondary considerations are the relative awareness of
the CompuSec arena by the contractor personnel involved and the relative
newness of the techniques which are planned to be used. A relatively high
level WBS element dedicated to the CompuSec effort will generally lead to
a CompuSec "office" within the contractor with the charge of monitoring the
implementation of the requirements and handling the documentation requirements.
<P>
<U><B>Cost Quality Oversight Perceived Importance</B></U>
<P>
The higher the level of the WBS element for CompuSec is defined, the finer
the detail cost accounting for the CompuSec effort will be. This is, of course,
the way the WBS works. In conjunction with the finer detail of the cost
accounting, the actual cost will also tend to rise with the level of the
WBS. More management emphasis and a higher level manager to manage the effort
equate to more effort expended and more effort expended equates to higher
cost for the CompuSec effort.
<P>
With the higher level of management attention, the quality of the work performed
tends to improve somewhat. If the tasking is scattered about the system effort
the tendency exists for the CompuSec portion of the effort to get slighted
in favor of the "Real Effort". As the effort is drawn together, the "Real
Effort" becomes the CompuSec effort. This results in a more concerted effort
and trade-offs being made which favor the being viewpoint (at least part
of the time.)
<P>
Along with the cost visibility comes overall program oversight of the effort
both on the part of the contractor and the government. This improved oversight
of the effort can result in great savings because the CompuSec arena is not
well understood for the most part. As time marches on and more contractors
(and government personnel) become experienced with CompuSec the great need
for special oversight will wane, but, for now, the greater the oversight
the better. In addition to the direct government oversight, if the contractor
has a cadre of experienced personnel, the CompuSec "office" at the contractor
can serve as an Internal Independent Verification and Validation (IIV&V)
team. Of course, the usual problems related to IIV&V will still exist;
the reporting chain will not reach high enough, the IIV&V personnel will
be pulled to perform Software Engineering at the drop of a schedule, etc.
For a time, the visibility and oversight will be improved greatly.
<P>
The single greatest reason for elevating the level of the WBS element for
the CompuSec effort is the perceived importance of the effort by the contractor.
The contractor is resource limited. The areas which are perceived as being
important to the government will receive the higher priorities in the allocation
of resources. If the CompuSec effort is perceived as being of low importance,
the resources allocated will be low priority resources.
<H3>
System Security Engineering Management Program
</H3>
<P>
The System Security Engineering Management (SSEM) Program is called for by
MIL-STD-1785. While the CompuSec portion of the SSEM Program is the primary
emphasis of this book, the Program as a whole needs to be examined to determine
the appropriate way to task the portions.
<P>
<U><B>The Securities</B></U>
<P>
Each of the Securities mentioned earlier in this Section are covered by SSEM.
For any given program, some, all, or none of the securities will have minimal
impact or import. Each must be examined and the appropriate measures, studies,
etc. must be taken to counter the threats. For the most part, the measures
to be taken will take the form of support subsystems and/or procedural and
administrative measures. By the start of Engineering and Manufacturing
Development (EMD), and the writing of the EMD SOW, the appropriate tasking
should be clear for each of the securities. The SSEM Program should cover
the group as a whole with separate sections as needed for the actual design
and implementation.
<P>
<U><B>Oversight of Program</B></U>
<P>
In order to maintain an appropriate level of oversight by the government,
it is a good idea to levy the SSEM Program Management tasks as one of the
direct tasks under System Engineering. This allows the tasks to receive the
proper attention by the proper personnel. Within the SSEM PM section, the
various securities can be broken out as needed.<U></U>
<P>
<U><B>Industrial Security and the Rest</B></U>
<P>
One care that should be taken is to ensure that none of the securities ride
rough-shod over the others. (Yes, that includes CompuSec) Another security
which tends to grow a life of its own is Industrial Security. While definitely
needed, Industrial Security should be kept well separated from the rest of
the securities (except perhaps Product Security). A good model for a program
which includes a fairly stiff CompuSec effort would be; System Engineering
=> SSEM => Industrial Security, CompuSec, The Other Securities.<U></U>
<H3>
Documentation
</H3>
<P>
Along with the functional requirements for each of the Classes of secure
computer systems come documentation requirements. In some cases, the
documentation needs closely parallel the standard documentation (users guides,
etc.) and these needs can be filled by replacement or modifications to the
standard documents. In other cases, the CompuSec documents have no equivalent
document (<EM>Formal Top Level Specification</EM>, <EM>Computer Security
Policy Model</EM>, etc.).
<P>
<U><B>For Itself</B></U>
<P>
Some of the CompuSec documentation is needed because the document produced
is needed by the operators of the system. For instance, the user's manuals,
especially the <EM>Security Features Users Guide</EM>, are needed to allow
the full and efficient use of the secure system as designed and built. On
the other hand, the security test documentation and the covert channel analysis
are needed by the security personnel to help circumvent penetration attempts
during the operational phase of the system lifecycle. While these documents
are not part of the standard documentation package for most systems, they
are essential to the ultimate security of the system.
<P>
<U><B>For Oversight Effort</B></U>
<P>
Other documents in the package are for program oversight purposes. For instance,
the <EM>Computer Security Policy Model</EM> is used as an intermediate document
to ensure the correct interpretation and implementation of the <EM>Computer
Security Policy</EM>. While these documents serve no innate long term purpose,
the long term effects of not having the documents are massive. Because the
CompuSec arena is not well understood and the vocabulary is basically unstable,
there is an increased need for the contracting agency to maintain good oversight
of the contractor's effort (and for the contractor to do the same).
<P>
<U><B>Pertinent Documents</B></U>
<P>
Because the documents are not those typically used for most programs, here
is a list of the basic documents and their descriptions in order to help
familiarize the reader with the terrain when the SOW tasking, CDRL, and tailored
DIDs portions are reached.
<P>
<B>System Security Engineering Management Plan:</B> This is the cornerstone
document for the security engineering effort. In it the contractor lays out
the plan for managing the entire security engineering effort. Along with
the other securities comes CompuSec and the plans to interpret, allocate,
and implement CompuSec requirements and taskings. The document usually works
best when detailed plans are given for the next phase of the program and
broad plans are given for the remainder of the program. Updates at the beginning
of each phase will then allow for the each layer of detailed planning to
be based on a firm understanding of the approaches being taken. This is the
document which will allow the government to gain confidence in the contractor's
understanding of the tasking and requirements in a timely manner.
<P>
<B>Computer Security Management Plan:</B> This Plan is a CompuSec specific
offshoot of the SSEM Plan. Here the detailed plans for CompuSec are laid
out in excruciating detail. This allows the contractor and the government
to ensure the understanding of the effort by the team which will actually
be performing the tasking. On a large program with an intensive security
engineering effort both documents are needed to allow for the varying levels
of abstraction involved. On a smaller program, or a program with less intensive
security needs, one or the other of the documents should be sufficient by
itself.
<P>
<B>Security Vulnerability Analysis (SVA):</B> The SVA is generated during
Concept Exploration and updated during Dem Val. By the time that FSD rolls
around the SVA is complete and is used by the designers to determine the
appropriate implementations to counter the vulnerabilities.
<P>
<B>Computer Security Policy:</B> The Policy contains the stated rules and
assumptions under which the system will be built and function. Some of the
topics covered would be the assumed level of personnel that will operate
the system, the mode of operation for the system, whether Mandatory Access
Control will be used, and the assumed operational environment for the system.
The Policy really should be written by the government but typically it is
left to the contractor to determine the Policy for the system, which works
well if the government takes an active role in the approval process.
<P>
<B>Computer Security Policy Model:</B> This is the bridging document between
the <EM>Policy</EM> and the requirements. Depending on the Class of the system
the model is either a formal mathematical model or an informal English language
descriptive model. While the Model tends to be a good-sized document it should
be given close attention to ensure complete understanding of the
<EM>Policy</EM> by the contractor.
<P>
<B>Security Concept of Operations:</B> This is the "Artists Rendition" of
the CompuSec arena. This is where the conceptual implementation of the Policy
is laid out and the interplay of the various Securities is discussed. This
document should be written for the ease of understanding by the non-Security
professional. This is the probable source (along with the <EM>Policy</EM>)
for the inputs to the Yellow Books in the determination of the needed Class
of security requirements and tasking for the system.
<P>
<B>Security Architecture Study:</B> This study covers the finer details of
the security architecture after the initial determination of the needed Class
has been made. The results can result in changes in the needed Class through
reallocation to the Other Securities.
<BLOCKQUOTE>
NOTE: The <EM>Policy</EM>, <EM>SVA</EM>, <EM>Model</EM>, <EM>Security</EM>
<EM>Con</EM> <EM>Ops</EM>, and <EM>Security</EM> <EM>Architecture</EM>
<EM>Study</EM> are developed and finalized around the same time period and
are iteratively developed as the interdependencies and repercussions of the
decision process are felt.
</BLOCKQUOTE>
<P>
<B>Covert Channel Analysis Report:</B> This report is mandated for systems
at or above Class B2. The methods of passing data outside normal, controlled
channels are analyzed and any which are of sufficient bandwidth are studied
for elimination/minimization purposes.
<P>
<B>Computer Security Audit Analysis:</B> This analysis is performed on a
recurring basis to trace the implementation of the audit trail requirements.
Understanding of the contractor approach and realization of the requirements
can be gained as well as the impacts of the audit process in processor
throughput, network bandwidth availability, and storage space required. The
periodic release is needed because the actual system performance costs continue
to become more finely defined as the implementation approaches completion.
<P>
<B>Security Features Users Guide (SFUG):</B> This is the guide to understanding
the functionality of the security features, their interactions, and guidelines
for their use. For the lower Classes of systems, the SFUG can be a section
of the users' manual but as the classes grow, so does the SFUG. Whenever
possible, the SFUG should be a free-standing document for ease of use (and
finding it).
<P>
<B>Trusted Facility Manual:</B> This manual covers the duties and roles of
the security related positions on the system. The manual is sometimes realized
as Positional Handbooks for each of the positions with the pertinent details
needed for each position in its own Handbook. If realized as a single volume,
the details for each position related to the security implementation needs
to be present.
<P>
<B>Descriptive Top Level Specification (DTLS):</B> Starting at the B2 Class,
the DTLS describes the Trusted Computing Base (TCB) in intimate detail,
especially the TCB interface.
<P>
<B>Formal Top Level Specification (FTLS):</B> This is an A1 Class required
document that is the formal (mathematical) brother of the DTLS. The FTLS
must be produced with a endorsed formal specification system and must be
mapped to the code of the TCB.
<P>
<B>Security Test Documentation:</B> Security test documentation serves two
purposes: during development and test the documentation is used for the separate
testing of the security features to ensure the security of the system. The
documentation is then maintained to allow for retesting after modifications
and updates to the system and for the use of the security personnel in the
evaluation of the risks related to proposed changes to the systems and its
environment.
<P>
<B>Security Test Plan:</B> The test plan, like most test plans, covers the
Big Picture without going into great detail. It is the best view of the testing
effort, though, and can be quite useful for gaining insight into the security
implementation.
<P>
<B>Security Test Procedures:</B> The procedures, like most procedures, are
excruciatingly detailed directions for the test itself. Where these test
procedures differ is the pointing away from simple requirement satisfaction
and more toward security satisfaction.
<P>
<B>Security Test Report:</B> The test report is the results of the testing
and should be maintained through the life of the system to ensure continued
protection and to document flaws which may exist.
<P>
<HR>
<P>
<H1 align="center">
<STRONG>Section <A NAME="II">II</A>:</STRONG>
</H1>
<H1 align="center">
<STRONG>Spare Parts</STRONG>
</H1>
<H2 align="center">
<STRONG>II. Spare parts</STRONG>
</H2>
<P>
In <U><B>Section I: Building a Secure System</B></U> the determination of
the appropriate Class of secure system was made. In addition, the pros and
cons of SOW and WBS options were discussed and decisions were to be made
based on the particular system being developed. Also, a list of pertinent
documents were discussed for the CompuSec arena.
<P>
In <U><B>Section II: Spare Parts</B></U> the pieces are listed which can
be put together to form the CompuSec portions of the specification, SOW,
and CDRL for the system in question. The section is broken into parts based
on the Class of system determined in Section I. For each of the Classes from
C1 through A1, the requirements, SOW tasking, and CDRL inputs are listed.
<P>
<B>Requirements:</B> The requirements are laid out as a separate appendix
to the specification. While this is not intensely needed for the lower Classes,
by the time that the B-level Classes are reached, the requirements are involved
enough to necessitate the creation of a separate appendix.
<P>
<B>SOW Tasking:</B> The SOW portion is composed of paragraphs which will
need to be arranged in the SOW in accordance with the decisions, made in
Section I, concerning SOW formatting.
<P>
<B>CDRL Inputs:</B> The CDRL input section gives essentially all of the
document-specific except for the distribution section which will need to
be determined for each system individually.
<BLOCKQUOTE>
NOTE -- The Tasking and CDRL inputs are not separated by phase. If the program
has clear phases, some of the tasks and documentation will need to be tailored
accordingly.
</BLOCKQUOTE>
<P>
Following the portions concerned with the various Classes of systems, there
is a portion containing the major Data Item Descriptions (DID). In some cases
there will be a need to tailor the DIDs. Such tailoring should be performed
only with the greatest of care.
<P>
Two things to remember when using these Spare Parts are:
<P>
These are the basic minimums for a generic system. For your specific system
there may be portions which just do not apply and there may be portions which
need to be added.
<P>
Nothing replaces careful thought and consideration.
<P>
<HR>
<H3>
C1 Class
</H3>
<P>
The C1 class secure computer system is the lowest level of CompuSec<STRONG>
</STRONG>requirements defined by the Orange Book. C1 class systems are
appropriate for operation in the dedicated mode of operation only. The
protections are not sufficient to protect against an internal attack.
<P>
There are a limited number of high level subjects and objects which are protected
at all and the limits on the sharing of objects are not restrictive.
<P>
The users are required to login but the system does not need to be able to
identify individual users uniquely. This implies that group logins (or project
logins) are allowed.
<P>
The Trusted Computing Base (TCB) is required to protect itself (software)
for outside interference and tampering and to be able to validate the operations
of the TCB hardware and firmware.
<P>
<B>C1 Class Requirements</B>
<BLOCKQUOTE>
10.1 Discretionary Access Control (DAC)
<BLOCKQUOTE>
10.1.1 The TCB shall control access between named users and named objects.
<P>
10.1.2 The TCB shall allow users to specify and control sharing of objects
by named individuals or groups or both.
</BLOCKQUOTE>
<P>
10.2 Identification and Authentication
<BLOCKQUOTE>
10.2.1 The TCB shall require users to identify themselves before performing
any other actions on behalf of that user.
<P>
10.2.2 The TCB shall authenticate the user's identity before performing any
other actions on behalf of that user.
<P>
10.2.3 The TCB shall protect authentication data from unauthorized access.
</BLOCKQUOTE>
<P>
10.3 The TCB shall protect itself from external interference and tampering.
<P>
10.4 The TCB shall have the capability to validate the correct operations
of the TCB's hardware and firmware.
</BLOCKQUOTE>
<P>
<B>C1 Class SOW Tasking</B>
<P>
<B>A. Data Accession List.</B> The contractor shall maintain a complete list
of all data generated as a result of this contract. The contractor shall
list the data by title, date, and subject. The list shall include all memos,
letters, meeting minutes, phone logs, etc. All data not required by the CDRL
shall be considered contractor format. The document shall be titled
<EM>Gonculator Data Accession List.</EM> (DI-A-3027A/T)
<P>
<B>B. System Description.</B> The contractor shall prepare separately published
common appendices which describes the system for use with the system
documentation. These appendices shall be prepared in an Unclassified version,
if possible, and such classified versions that are required for a full
description of the Gonculator System. The contractor shall use the common
appendices in place of the system description within the bodies of the
documentation. The descriptions shall be titled <EM>Gonculator System Description
Appendix, </EM> (Appropriate Classification)<STRONG><EM>
</EM></STRONG>Version. (DI-GDRQ-80567/T)
<P>
<B>C. System Security Management Program.</B> The contractor shall conduct
a System Security Management Program in accordance with the approved System
Security Management Plan.
<P>
<B>D. System Security Management Plan.</B> The contractor shall develop a
system security management plan describing the contractor's security engineering
and management approach. The plan should include all aspects of system security,
including computer security. The document shall be titled <EM>Gonculator
System Security Management Plan.</EM> (DI-MISC-80839/T)
<P>
<B>E. Security Vulnerability Analysis.</B> The contractor shall conduct a
security vulnerability analysis and document the results. The study shall
include identification of logical security vulnerabilities of the system,
defining functional requirements which may secure the system from exploitation,
and choosing safeguards to reduce identified vulnerabilities. The document
shall be titled <EM>Gonculator Security Vulnerability Analysis.</EM>
(DI-MISC-80841/T)
<P>
<B>F. Computer Security Policy.</B> The contractor shall prepare a document
that defines the security policy enforced by the computer system. The document
shall be titled <EM>Gonculator Computer Security Policy.</EM> (DI-GDRQ-80567/T)
<P>
<B>G. Security Features Users Guide.</B> The contractor shall generate a
Users' Guide that documents the protection mechanisms provided by the system,
guidelines for their use, and how the protection mechanisms interact with
each other. The users guide may be published as either a common appendix
to the positional handbooks or a stand-alone document titled <EM>Gonculator
Security Features Users' Guide</EM>. (DI-MCCR-80019A/T)
<P>
<B>H. Trusted Facility Manual.</B> The contractor shall generate a manual
that documents cautions about functions and privileges that should be controlled
when running the secure facility in accordance with DOD-5200.28-STD. The
document shall be titled <EM>Gonculator Trusted Facility Manual.</EM>
(DI-MCCR-80019A/T)
<P>
<HR>
<H3>
C2 Class
</H3>
<P>
The C2 class secure computer system enforces a more finely grained DAC than
C1 class systems do. C2 class systems are appropriate for operation in the
dedicated or system high modes of operation only. The protections include
individual accountability.
<P>
There are a limited number of high level subjects and objects which are
protected. Propagation of access rights is controlled. Access is controlled
at the granularity of named individual and/or group of named individuals.
<P>
The users are required to login and the system needs to be able to identify
individual users uniquely. While individuals are individuals, group access
rights are still allowed.
<P>
Reuse of storage objects (memory, disk space, buffers, etc.) is only allowed
after the object is cleared to disallow any access to the old data.
<P>
Audit is required to make users responsible for their actions. Half of the
theory behind audits is to allow for the security personnel to find wrongful
acts and identify the perpetrator; the other half of the theory is that an
advertised audit process will keep Honest people Honest.
<P>
The Trusted Computing Base (TCB) is required to protect itself (software)
for outside interference and tampering and to be able to validate the operations
of the TCB hardware and firmware.
<P>
<B>C2 Class Requirements</B>
<BLOCKQUOTE>
10.1 Discretionary Access Control (DAC)
<BLOCKQUOTE>
10.1.1 The TCB shall control access between named users and named objects.
<P>
10.1.2 The TCB shall protect all named objects from unauthorized access.
<P>
10.1.3 The TCB shall allow for the inclusion or exclusion of access to named
objects at the level of the single user.
<P>
10.1.4 The TCB shall allow authorized users to specify and control sharing
of objects by named individuals or groups of individuals or both.
<P>
10.1.5 The TCB shall provide controls to limit propagation of access rights.
</BLOCKQUOTE>
<P>
10.2 The TCB shall clear all memory objects before reallocation.
<P>
10.3 Identification and Authentication
<BLOCKQUOTE>
10.3.1 The TCB shall require users to uniquely identify themselves before
performing any other actions on behalf of that user.
<P>
10.3.2 The TCB shall authenticate the user's unique identity before performing
any other actions on behalf of that user.
<P>
10.3.3 The TCB shall protect authentication data from unauthorized access.
<P>
10.3.4 The TCB shall associate the user's unique identity for all auditable
actions taken by the user.
</BLOCKQUOTE>
<P>
10.4 Audit
<BLOCKQUOTE>
10.4.1 The TCB shall be able to create an audit trail.
<P>
10.4.2 The TCB shall maintain the audit trail on-line for a minimum of thirty
days.
<P>
10.4.3 The TCB shall protect the audit trail from modification or unauthorized
access.
<P>
10.4.4 The TCB shall audit the following event types:
<BLOCKQUOTE>
a. Login.
<P>
b. Logout.
<P>
c. Access to objects.
<P>
d. Deletion of objects.
<P>
e. Actions taken by system operators, administrators, and security officers.
</BLOCKQUOTE>
<P>
10.4.5 The TCB shall include the following information in each audit trail
record:
<BLOCKQUOTE>
a. Date and time of event.
<P>
b. User identity.
<P>
c. Event type.
<P>
d. Success or failure of action.
<P>
e. Name of object, if any.
</BLOCKQUOTE>
<P>
10.4.6 The TCB shall selectively audit the actions of one or more users based
on individual identity.
</BLOCKQUOTE>
<P>
10.5 System Security Architecture
<BLOCKQUOTE>
10.5.1 The TCB shall protect itself from external interference and tampering.
<P>
10.5.2 The TCB shall isolate the resources to be protected by access controls
and auditing.
</BLOCKQUOTE>
<P>
10.6 The TCB shall have the capability to validate the correct operations
of the TCB's hardware and firmware.
</BLOCKQUOTE>
<P>
<B>C2 Class SOW Tasking</B>
<P>
<B>A. Data Accession List.</B> The contractor shall maintain a complete list
of all data generated as a result of this contract. The contractor shall
list the data by title, date, and subject. The list shall include all memos,
letters, meeting minutes, phone logs, etc. All data not required by the CDRL
shall be considered contractor format. The document shall be titled
<EM>Gonculator Data Accession List.</EM> (DI-A-3027A/T)
<P>
<B>B. System Description.</B> The contractor shall prepare separately published
common appendices which describes the system for use with the system
documentation. These appendices shall be prepared in an Unclassified version,
if possible, and such classified versions that are required for a full
description of the Gonculator System. The contractor shall use the common
appendices in place of the system description within the bodies of the
documentation. The descriptions shall be titled <EM>Gonculator System Description
Appendix, </EM> (Appropriate Classification)<STRONG><EM>
</EM></STRONG>Version. (DI-GDRQ-80567/T)
<P>
<B>C. System Security Management Program.</B> The contractor shall conduct
a System Security Management Program in accordance with the approved System
Security Management Plan.
<P>
<B>D. System Security Management Plan.</B> The contractor shall develop a
system security management plan describing the contractor's security engineering
and management approach. The plan should include all aspects of system security,
including computer security. The document shall be titled <EM>Gonculator
System Security Management Plan.</EM> (DI-MISC-80839/T)
<P>
<B>E. Security Vulnerability Analysis.</B> The contractor shall conduct a
security vulnerability analysis and document the results. The study shall
include identification of logical security vulnerabilities of the system,
defining functional requirements which may secure the system from exploitation,
and choosing safeguards to reduce identified vulnerabilities. The document
shall be titled <EM>Gonculator Security Vulnerability Analysis.</EM>
(DI-MISC-80841/T)
<P>
<B>F. Computer Security Policy.</B> The contractor shall prepare a document
that defines the security policy enforced by the computer system. The document
shall be titled <EM>Gonculator Computer Security Policy.</EM> (DI-GDRQ-80567/T)
<P>
<B>G. Computer Security Audit Analysis.</B> The contractor shall analyze
the audit schema for the system including events to be audited, audit record
structures, throughput requirements, storage needs, and archival storage
techniques. The document shall be titled <EM>Gonculator Computer Security
Audit Analysis.</EM> (DI-GDRQ-80567/T)
<P>
<B>H. Security Features Users Guide.</B> The contractor shall generate a
Users' Guide that documents the protection mechanisms provided by the system,
guidelines for their use, and how the protection mechanisms interact with
each other. The users guide may be published as either a common appendix
to the positional handbooks or a stand-alone document titled <EM>Gonculator
Security Features Users' Guide</EM>. (DI-MCCR-80019A/T)
<P>
<B>I. Trusted Facility Manual.</B> The contractor shall generate a manual
that documents cautions about functions and privileges that should be controlled
when running the secure facility in accordance with DOD-5200.28-STD. The
document shall be titled <EM>Gonculator Trusted Facility Manual.</EM>
(DI-MCCR-80019A/T)
<P>
<HR>
<H3>
B1 Class
</H3>
<P>
The B1 class secure computer system enforces a Mandatory Access Control (MAC)
policy and the associated labeling. B1 class systems are appropriate for
operation in the compartmented and multilevel modes of operation. Multilevel
mode operations should be carefully considered before use because there is
no protection from covert channel attacks.
<P>
There are a limited number of high level subjects and objects which are protected
by DAC. Propagation of access rights is controlled. Access is controlled
at the granularity of named individual and/or group of named individuals.
<P>
The users are required to login and the system needs to be able to identify
individual users uniquely. While individuals are individuals, group access
rights are still allowed.
<P>
Reuse of storage objects (memory, disk space, buffers, etc.) is only allowed
after the object is cleared to disallow any access to the old data.
<P>
Audit is required to make users responsible for their actions. Half of the
theory behind audits is to allow for the security personnel to find wrongful
acts and identify the perpetrator; the other half of the theory is that an
advertised audit process will keep Honest people Honest. With labeling and
MAC, the security level is also recorded for objects being audited.
<P>
Labels are required for all subjects and storage objects controlled by the
TCB. These labels are used for MAC decisions which are also mandated for
all subjects and storage objects under TCB control. The basic requirements
are a simple translation of the standard "Paper-style" requirements onto
the computer so the computer will mark and allow access properly.
<P>
The Trusted Computing Base (TCB) is required to protect itself (software)
for outside interference and tampering and to be able to validate the operations
of the TCB hardware and firmware.
<P>
<B>B1 Class Requirements</B>
<BLOCKQUOTE>
10.1 Discretionary Access Control (DAC)
<BLOCKQUOTE>
10.1.1 The TCB shall control access between named users and named objects.
<P>
10.1.2 The TCB shall protect all named objects from unauthorized access.
<P>
10.1.3 The TCB shall allow for the inclusion or exclusion of access to named
objects at the level of the single user.
<P>
10.1.4 The TCB shall allow authorized users to specify and control sharing
of objects by named individuals or groups of individuals or both.
<P>
10.1.5 The TCB shall provide controls to limit propagation of access rights.
</BLOCKQUOTE>
<P>
10.2 The TCB shall clear all memory objects before allocation to a new subject.
<P>
10.3 Identification and Authentication
<BLOCKQUOTE>
10.3.1 The TCB shall require users to uniquely identify themselves before
performing any other actions on behalf of that user.
<P>
10.3.2 The TCB shall authenticate the user's unique identity before performing
any other actions on behalf of that user.
<P>
10.3.3 The TCB shall ensure that the user's login security level and
authorizations are dominated by the user's clearance and authorizations.
<P>
10.3.4 The TCB shall ensure that the security level and authorizations of
subjects external to the TCB which are created on behalf of the user are
dominated by the user's clearance and authorizations.
<P>
10.3.5 The TCB shall protect authentication data from unauthorized access.
<P>
10.3.6 The TCB shall associate the user's unique identity for all auditable
actions taken by the user.
</BLOCKQUOTE>
<P>
10.4 Audit
<BLOCKQUOTE>
10.4.1 The TCB shall be able to create an audit trail.
<P>
10.4.2 The TCB shall maintain the audit trail on-line for a minimum of thirty
days.
<P>
10.4.3 The TCB shall protect the audit trail from modification or unauthorized
access.
<P>
10.4.4 The TCB shall audit the following event types:
<BLOCKQUOTE>
a. Login.
<P>
b. Logout.
<P>
c. Access to objects.
<P>
d. Deletion of objects.
<P>
e. Override of human-readable output markings.
<P>
f. Labeling of imported unlabeled data.
<P>
g. Any change in the designation of single level and multilevel devices.
<P>
h. Any change in security level or levels associated with a subject or object.
<P>
i. Actions taken by system operators, administrators, and security officers.
</BLOCKQUOTE>
<P>
10.4.5 The TCB shall include the following information in each audit trail
record:
<BLOCKQUOTE>
a. Date and time of event.
<P>
b. User identity.
<P>
c. Event type.
<P>
d. Success or failure of action.
<P>
e. Security level of object, if any.
<P>
f. Name of object, if any.
</BLOCKQUOTE>
<P>
10.4.6 The TCB shall selectively audit the actions of one or more users based
on individual identity and/or object security level.
</BLOCKQUOTE>
<P>
10.5 System Security Architecture
<BLOCKQUOTE>
10.5.1 The TCB shall protect itself from external interference and tampering.
<P>
10.5.2 The TCB shall isolate the resources to be protected by access controls
and auditing.
<P>
10.5.3 The TCB shall maintain distinct address spaces for process isolation.
</BLOCKQUOTE>
<P>
10.6 The TCB shall have the capability to validate the correct operations
of the TCB's hardware and firmware.
<P>
10.7 Labels
<BLOCKQUOTE>
10.7.1 The TCB shall maintain the sensitivity label associated with each
subject and object under TCB control.
<P>
10.7.2 The sensitivity label associated with a subject or an object shall
correctly represent the security level of the subject or object.
<P>
10.7.3 The TCB shall use the sensitivity labels as the basis for mandatory
access control decisions.
<P>
10.7.4 The TCB shall request a label from an authorized user before importing
unlabeled data.
<P>
10.7.5 The TCB shall associate an accurate and unambiguous sensitivity label
exported information.
<P>
10.7.6 The TCB shall designate each I/O device and communications channel
as a single level or multilevel device.
<P>
10.7.7 Any change in the designation of single level or multilevel shall
be performed manually.
<P>
10.7.8 The TCB shall associate with each object exported over a multilevel
device the sensitivity level in the same form as the data and physically
residing with the data.
<P>
10.7.9 The communications protocol used for each multilevel communications
port shall provide for the unambiguous pairing of the data and its associated
sensitivity label.
<P>
10.7.10 The TCB shall allow an authorized user to designate the single security
level of information imported or exported via a single level communications
port or I/O device.
<P>
10.7.11 The TCB shall allow the System Administrator to specify the printable
label names associated with exported sensitivity labels.
<P>
10.7.12 The TCB shall mark the top and bottom of all human readable output
with human readable sensitivity labels that properly represent the sensitivity
of the output.
</BLOCKQUOTE>
<P>
10.8 Mandatory Access Control (MAC)
<BLOCKQUOTE>
10.8.1 The TCB shall enforce mandatory access control for all subjects and
storage objects under its control.
<P>
10.8.2 A subject shall be allowed read access only if the hierarchical
classification in the subject's security level is greater than or equal to
the hierarchical classification in the object's security level and the
non-hierarchical categories in the subject's security level include all of
the non-hierarchical categories in the object's security level.
<P>
10.8.3 A subject shall be allowed write access only if the hierarchical
classification in the subject's security level is less than or equal to the
hierarchical classification in the object's security level and all of the
non-hierarchical categories in the subject's security level are included
in the non-hierarchical categories in the object's security level.
</BLOCKQUOTE>
</BLOCKQUOTE>
<P>
<B>B1 Class SOW Tasking</B>
<P>
<B>A. Gonculator Accreditation Working Group.</B> The contractor shall support
the Gonculator Accreditation Working Group (GAWG) through attendance at meetings
as needed, presenting current program data as requested, acting upon assigned
and accepted Action Items, and preparing minutes of the GAWG meetings. At
a minimum, the GAWG will meet twice a year. At a minimum, support at the
meetings shall include representatives from program management, configuration
management, system engineering, and security engineering. (DI-A-7089/T)
<P>
<B>B. Data Accession List.</B> The contractor shall maintain a complete list
of all data generated as a result of this contract. The contractor shall
list the data by title, date, and subject. The list shall include all memos,
letters, meeting minutes, phone logs, etc. All data not required by the CDRL
shall be considered contractor format. The document shall be titled
<EM>Gonculator Data Accession List.</EM> (DI-A-3027A/T)
<P>
<B>C. System Description.</B> The contractor shall prepare separately published
common appendices which describes the system for use with the system
documentation. These appendices shall be prepared in an Unclassified version,
if possible, and such classified versions that are required for a full
description of the Gonculator System. The contractor shall use the common
appendices in place of the system description within the bodies of the
documentation. The descriptions shall be titled <EM>Gonculator System Description
Appendix, </EM> (Appropriate Classification)<STRONG><EM>
</EM></STRONG>Version. (DI-GDRQ-80567/T)
<P>
<B>D. System Security Management Program.</B> The contractor shall conduct
a System Security Management Program in accordance with the approved System
Security Management Plan.
<P>
<B>E. System Security Management Plan.</B> The contractor shall develop a
system security management plan describing the contractor's security engineering
and management approach. The plan should include all aspects of system security,
including computer security. The document shall be titled <EM>Gonculator
System Security Management Plan.</EM> (DI-MISC-80839/T)
<P>
<B>F. Computer Security Management Program.</B> The contractor shall conduct
a Computer Security Management Program in accordance with the approved Computer
Security Management Plan.
<P>
<B>G. Computer Security Management Plan.</B> The contractor shall generate
a computer security management plan. The Plan shall include the methods used
to manage the computer security engineering program, program schedule, and
the steps to be taken to ensure the proper incorporation of the computer
security requirements into the system. The document shall be titled
<EM>Gonculator Computer Security Management Plan.</EM> (DI-MISC-80839/T)
<P>
<B>H. Security Vulnerability Analysis.</B> The contractor shall conduct a
security vulnerability analysis and document the results. The study shall
include identification of logical security vulnerabilities of the system,
defining functional requirements which may secure the system from exploitation,
and choosing safeguards to reduce identified vulnerabilities. The document
shall be titled <EM>Gonculator Security Vulnerability Analysis.</EM>
(DI-MISC-80841/T)
<P>
<B>I. Computer Security Policy.</B> The contractor shall prepare a document
that defines the security policy enforced by the computer system. The document
shall be titled <EM>Gonculator Computer Security Policy.</EM> (DI-GDRQ-80567/T)
<P>
<B>J. Computer Security Policy Model.</B> The contractor shall develop and
document a model of the security policy enforced by the system. The model
description shall include the specific protection mechanisms and an explanation
showing that they satisfy the model and will enforce the security policy.
The document shall be titled <EM>Gonculator Computer Security Policy Model.
</EM> (DI-GDRQ-80567/T)
<P>
<B>K. Security Architecture Study.</B> The contractor shall conduct a study
of the security architecture of the system and document the results of the
study. The study shall include partitioning of the system, cost/benefit analysis
for the architectural alternatives, and the required Class of system for
each alternative and for each partitioned subsystem. The report shall detail
the recommended architecture for the system. The document shall be titled
<EM>Gonculator Security Architecture Study.</EM> (DI-GDRQ-80567/T)
<P>
<B>L. System Security Concept of Operations.</B> The contractor shall generate
a system security concept of operations that documents the security concept
for the system including the incorporation of the protection philosophy into
the system. The document shall be titled <EM>Gonculator System Security Concept
Of Operations.</EM> (DI-MISC-80840/T)
<P>
<B>M. Computer Security Audit Analysis.</B> The contractor shall analyze
the audit schema for the system including events to be audited, audit record
structures, throughput requirements, storage needs, and archival storage
techniques. The document shall be titled <EM>Gonculator Computer Security
Audit Analysis.</EM> (DI-GDRQ-80567/T)
<P>
<B>N. Security Features Users Guide.</B> The contractor shall generate a
Users' Guide that documents the protection mechanisms provided by the system,
guidelines for their use, and how the protection mechanisms interact with
each other. The users guide may be published as either a common appendix
to the positional handbooks or a stand-alone document titled <EM>Gonculator
Security Features Users' Guide</EM>. (DI-MCCR-80019A/T)
<P>
<B>O. Trusted Facility Manual.</B> The contractor shall generate a manual
that documents cautions about functions and privileges that should be controlled
when running the secure facility in accordance with DOD-5200.28-STD. The
document shall be titled <EM>Gonculator Trusted Facility Manual.</EM>
(DI-MCCR-80019A/T)
<P>
<B>P. Security Test.</B> The contractor shall conduct a separate security
test in conjunction with the system acceptance test. The security test shall
show that all security mechanisms function as defined in the system documentation
and that the system is resistant to penetration. The security test shall
include an ad hoc, loosely structured test by the government test team. The
contractor shall train the government test team in the operation of the system
before the start of the test. The government test team will consist of six
people drawn from the developing, supporting, using, and accrediting communities.
<P>
<B>Q. Security Test Plan.</B> The contractor shall develop a test plan for
the security testing to be performed. The document shall be titled
<EM>Gonculator Security Test Plan. </EM> (DI-MCCR-80014A/T)
<P>
<B>R. Security Test Description.</B> The contractor shall develop test procedures
to implement the approved Gonculator<EM> </EM>Security Test Plan. The document
shall be titled <EM>Gonculator Security Test Description.</EM> (DI-MCCR-80015A/T)
<P>
<B>S. Security Test Report.</B> The contractor shall document the results
of the security test. The document shall be titled <EM>Gonculator Security
Test Report</EM>. (DI-MCCR-80017A/T)
<P>
<HR>
<H3>
B2 Class
</H3>
<P>
The B2 class secure computer system is based on clearly defined security
policy and model of the policy. B2 class systems are appropriate for operation
in the compartmented and multilevel modes of operation. Multilevel mode
operations should be carefully considered before use because there is limited
protection from covert channel attacks.
<P>
There are a limited number of high level subjects and objects which are protected
by DAC. Propagation of access rights is controlled. Access is controlled
at the granularity of named individual and/or group of named individuals.
<P>
The users are required to login and the system needs to be able to identify
individual users uniquely. While individuals are individuals, group access
rights are still allowed.
<P>
Reuse of storage objects (memory, disk space, buffers, etc.) is only allowed
after the object is cleared to disallow any access to the old data.
<P>
Audit is required to make users responsible for their actions. Half of the
theory behind audits is to allow for the security personnel to find wrongful
acts and identify the perpetrator; the other half of the theory is that an
advertised audit process will keep Honest people Honest. With labeling and
MAC, the security level is also recorded for objects being audited.
<P>
Labels are required for all system resources. These labels are used for MAC
decisions which are also mandated for all subjects and storage objects under
TCB control. The basic requirements are a simple translation of the standard
"Paper-style" requirements onto the computer so the computer will mark and
allow access properly.
<P>
The Trusted Computing Base (TCB) is required to protect itself (software)
from outside interference and tampering and to be able to validate the operations
of the TCB hardware and firmware.
<P>
<B>B2 Class Requirements</B>
<BLOCKQUOTE>
10.1 Discretionary Access Control (DAC)
<BLOCKQUOTE>
10.1.1 The TCB shall control access between named users and named objects.
<P>
10.1.2 The TCB shall protect all named objects from unauthorized access.
<P>
10.1.3 The TCB shall allow for the inclusion or exclusion of access to named
objects at the level of the single user.
<P>
10.1.4 The TCB shall allow authorized users to specify and control sharing
of objects by named individuals or groups of individuals or both.
<P>
10.1.5 The TCB shall provide controls to limit propagation of access rights.
</BLOCKQUOTE>
<P>
10.2 The TCB shall clear all memory objects before allocation to a new subject.
<P>
10.3 Identification and Authentication
<BLOCKQUOTE>
10.3.1 The TCB shall require users to uniquely identify themselves before
performing any other actions on behalf of that user.
<P>
10.3.2 The TCB shall authenticate the user's unique identity before performing
any other actions on behalf of that user.
<P>
10.3.3 The TCB shall ensure that the user's login security level and
authorizations are dominated by the user's clearance and authorizations.
<P>
10.3.4 The TCB shall ensure that the security level and authorizations of
subjects external to the TCB which are created on behalf of the user are
dominated by the user's clearance and authorizations.
<P>
10.3.5 The TCB shall protect authentication data from unauthorized access.
<P>
10.3.6 The TCB shall associate the user's unique identity for all auditable
actions taken by the user.
<P>
10.3.7 The TCB shall support a trusted communication path between the TCB
and a user, initiated exclusively by the user, for initial login and
authentication.
</BLOCKQUOTE>
<P>
10.4 Audit
<BLOCKQUOTE>
10.4.1 The TCB shall be able to create an audit trail.
<P>
10.4.2 The TCB shall maintain the audit trail on-line for a minimum of thirty
days.
<P>
10.4.3 The TCB shall protect the audit trail from modification or unauthorized
access.
<P>
10.4.4 The TCB shall audit the following event types:
<BLOCKQUOTE>
a. Login.
<P>
b. Logout.
<P>
c. Access to objects.
<P>
d. Deletion of objects.
<P>
e. Override of human-readable output markings.
<P>
f. Labeling of imported unlabeled data.
<P>
g. Any change in the designation of single level and multilevel devices.
<P>
h. Any change in security level or levels associated with a subject or object.
<P>
i. Identified covert storage channel exploitation events.
<P>
j. Actions taken by system operators, administrators, and security officers.
</BLOCKQUOTE>
<P>
10.4.5 The TCB shall include the following information in each audit trail
record:
<BLOCKQUOTE>
a. Date and time of event.
<P>
b. User identity.
<P>
c. Event type.
<P>
d. Success or failure of action.
<P>
e. Security level of object, if any.
<P>
f. Name of object, if any.
</BLOCKQUOTE>
<P>
10.4.6 The TCB shall selectively audit the actions of one or more users based
on individual identity and/or object security level.
</BLOCKQUOTE>
<P>
10.5 System Security Architecture
<BLOCKQUOTE>
10.5.1 The TCB shall maintain a domain of its own execution that protects
it from external interference and tampering.
<P>
10.5.2 The TCB shall isolate the resources to be protected by access controls
and auditing.
<P>
10.5.3 The TCB shall maintain distinct address spaces for process isolation.
<P>
10.5.4 The TCB shall be structured modularly.
<P>
10.5.5 The user interface to the TCB and all TCB elements shall be completely
defined.
</BLOCKQUOTE>
<P>
10.6 The TCB shall have the capability to validate the correct operations
of the TCB's hardware and firmware.
<P>
10.7 Labels
<BLOCKQUOTE>
10.7.1 The TCB shall maintain the sensitivity label associated with each
system resources accessible by subjects external to the TCB.
<P>
10.7.2 The sensitivity label associated with a subject or an object shall
correctly represent the security level of the subject or object.
<P>
10.7.3 The TCB shall notify a terminal user of each change in the user's
security level during a session.
<P>
10.7.4 The TCB shall support the assignment of minimum and maximum security
levels for all attached devices.
<P>
10.7.5 The TCB shall use the sensitivity labels as the basis for mandatory
access control decisions.
<P>
10.7.6 The TCB shall request a label from an authorized user before importing
unlabeled data.
<P>
10.7.7 The TCB shall associate an accurate and unambiguous sensitivity label
with all exported information.
<P>
10.7.8 The TCB shall designate each I/O device and communications channel
as a single level or multilevel device.
<P>
10.7.9 Any change in the designation of single level or multilevel shall
be performed manually.
<P>
10.7.10 The TCB shall associate with each object exported over a multilevel
device the sensitivity level in the same form as the data and physically
residing with the data.
<P>
10.7.11 The communications protocol used for each multilevel communications
port shall provide for the unambiguous pairing of the data and its associated
sensitivity label.
<P>
10.7.12 The TCB shall allow an authorized user to designate the single security
level of information imported or exported via a single level communications
port or I/O device.
<P>
10.7.13 The TCB shall allow the System Administrator to specify the printable
label names associated with exported sensitivity labels.
<P>
10.7.14 The TCB shall mark the top and bottom of all human readable output
with human readable sensitivity labels that properly represent the sensitivity
of the output.
</BLOCKQUOTE>
<P>
10.8 Mandatory Access Control (MAC)
<BLOCKQUOTE>
10.8.1 The TCB shall enforce mandatory access control over all subjects and
objects accessible to subjects external to the TCB.
<P>
10.8.2 A subject shall be allowed read access only if the hierarchical
classification in the subject's security level is greater than or equal to
the hierarchical classification in the object's security level and the
non-hierarchical categories in the subject's security level include all of
the non-hierarchical categories in the object's security level.
<P>
10.8.3 A subject shall be allowed write access only if the hierarchical
classification in the subject's security level is less than or equal to the
hierarchical classification in the object's security level and all of the
non-hierarchical categories in the subject's security level are included
in the non-hierarchical categories in the object's security level.
</BLOCKQUOTE>
</BLOCKQUOTE>
<P>
<B>B2 Class SOW Tasking</B>
<P>
<B>A. Gonculator Accreditation Working Group.</B> The contractor shall support
the Gonculator Accreditation Working Group (GAWG) through attendance at meetings
as needed, presenting current program data as requested, acting upon assigned
and accepted Action Items, and preparing minutes of the GAWG meetings. At
a minimum, the GAWG will meet twice a year. At a minimum, support at the
meetings shall include representatives from program management, configuration
management, system engineering, and security engineering. (DI-A-7089/T)
<P>
<B>B. Data Accession List.</B> The contractor shall maintain a complete list
of all data generated as a result of this contract. The contractor shall
list the data by title, date, and subject. The list shall include all memos,
letters, meeting minutes, phone logs, etc. All data not required by the CDRL
shall be considered contractor format. The document shall be titled
<EM>Gonculator Data Accession List.</EM> (DI-A-3027A/T)
<P>
<B>C. System Description.</B> The contractor shall prepare separately published
common appendices which describes the system for use with the system
documentation. These appendices shall be prepared in an Unclassified version,
if possible, and such classified versions that are required for a full
description of the Gonculator System. The contractor shall use the common
appendices in place of the system description within the bodies of the
documentation. The descriptions shall be titled <EM>Gonculator System Description
Appendix, </EM> (Appropriate Classification)<STRONG><EM>
</EM></STRONG>Version. (DI-GDRQ-80567/T)
<P>
<B>D. System Security Management Program.</B> The contractor shall conduct
a System Security Management Program in accordance with the approved System
Security Management Plan.
<P>
<B>E. System Security Management Plan.</B> The contractor shall develop a
system security management plan describing the contractor's security engineering
and management approach. The plan should include all aspects of system security,
including computer security. The document shall be titled <EM>Gonculator
System Security Management Plan.</EM> (DI-MISC-80839/T)
<P>
<B>F. Computer Security Management Program.</B> The contractor shall conduct
a Computer Security Management Program in accordance with the approved Computer
Security Management Plan.
<P>
<B>G. Computer Security Management Plan.</B> The contractor shall generate
a computer security management plan. The Plan shall include the methods used
to manage the computer security engineering program, program schedule, and
the steps to be taken to ensure the proper incorporation of the computer
security requirements into the system. The document shall be titled
<EM>Gonculator Computer Security Management Plan.</EM> (DI-MISC-80839/T)
<P>
<B>H. Security Vulnerability Analysis.</B> The contractor shall conduct a
security vulnerability analysis and document the results. The study shall
include identification of logical security vulnerabilities of the system,
defining functional requirements which may secure the system from exploitation,
and choosing safeguards to reduce identified vulnerabilities. The document
shall be titled <EM>Gonculator Security Vulnerability Analysis.</EM>
(DI-MISC-80841/T)
<P>
<B>I. Security Architecture Study.</B> The contractor shall conduct a study
of the security architecture of the system and document the results of the
study. The study shall include partitioning of the system, cost/benefit analysis
for the architectural alternatives, and the required Class of system for
each alternative and for each partitioned subsystem. The report shall detail
the recommended architecture for the system. The document shall be titled
<EM>Gonculator Security Architecture Study.</EM> (DI-GDRQ-80567/T)
<P>
<B>J. System Security Concept of Operations.</B> The contractor shall generate
a system security concept of operations that documents the security concept
for the system including the incorporation of the protection philosophy into
the system. The document shall be titled <EM>Gonculator System Security Concept
Of Operations.</EM> (DI-MISC-80840/T)
<P>
<B>K. Computer Security Policy.</B> The contractor shall prepare a document
that defines the security policy enforced by the computer system. The document
shall be titled <EM>Gonculator Computer Security Policy.</EM> (DI-GDRQ-80567/T)
<P>
<B>L. Computer Security Policy Model.</B> The contractor shall develop and
document a formal model of the security policy enforced by the system. The
model description shall include the specific protection mechanisms and an
explanation showing that they satisfy the model and will enforce the security
policy. The document shall be titled <EM>Gonculator Computer Security Policy
Model. </EM> (DI-GDRQ-80567/T)
<P>
<B>M. Computer Security Audit Analysis.</B> The contractor shall analyze
the audit schema for the system including events to be audited, audit record
structures, throughput requirements, storage needs, and archival storage
techniques. The document shall be titled <EM>Gonculator Computer Security
Audit Analysis.</EM> (DI-GDRQ-80567/T)
<P>
<B>N. Covert Channel Analysis.</B> The contractor shall conduct a thorough
search for covert storage channels and make a determination of the maximum
bandwidth of each identified channel. The contractor shall generate a covert
channel analysis report that documents the results of the covert channel
analysis. The document shall be titled <EM>Gonculator Covert Storage Channel
Analysis Report. </EM> (DI-GDRQ-80567/T)
<P>
<B>O. Descriptive Top Level Specification.</B> The contractor shall generate
a descriptive top level specification that completely and accurately describes
the TCB in terms of exceptions, error messages, effects, and interfaces.
The document shall be titled <EM>Gonculator Trusted Computing Base Descriptive
Top Level Specification.</EM> (DI-GDRQ-80567/T)
<P>
<B>P. Security Features Users Guide.</B> The contractor shall generate a
Users' Guide that documents the protection mechanisms provided by the system,
guidelines for their use, and how the protection mechanisms interact with
each other. The users guide may be published as either a common appendix
to the positional handbooks or a stand-alone document titled <EM>Gonculator
Security Features Users' Guide</EM>. (DI-MCCR-80019A/T)
<P>
<B>Q. Trusted Facility Manual.</B> The contractor shall generate a manual
that documents cautions about functions and privileges that should be controlled
when running the secure facility in accordance with DOD-5200.28-STD. The
document shall be titled <EM>Gonculator Trusted Facility Manual.</EM>
(DI-MCCR-80019A/T)
<P>
<B>R. Security Test.</B> The contractor shall conduct a separate security
test in conjunction with the system acceptance test. The security test shall
show that all security mechanisms function as defined in the system documentation
and that the system is resistant to penetration. The security test shall
include an ad hoc, loosely structured test by the government test team. The
contractor shall train the government test team in the operation of the system
before the start of the test. The government test team will consist of six
people drawn from the developing, supporting, using, and accrediting communities.
<P>
<B>S. Security Test Plan.</B> The contractor shall develop a test plan for
the security testing to be performed. The document shall be titled
<EM>Gonculator Security Test Plan. </EM> (DI-MCCR-80014A/T)
<P>
<B>T. Security TEST DESCRIPTION.</B> The contractor shall develop test procedures
to implement the approved Gonculator<EM> </EM>Security Test Plan. The document
shall be titled <EM>Gonculator Security Test Description.</EM> (DI-MCCR-80015A/T)
<P>
<B>U. Security Test Report.</B> The contractor shall document the results
of the security test. The document shall be titled <EM>Gonculator Security
Test Report</EM>. (DI-MCCR-80017A/T)
<P>
<HR>
<H3>
B3 Class
</H3>
<P>
The B3 class secure computer system is based on clearly defined security
policy and model of the policy. B3 class systems are appropriate for operation
in the compartmented and multilevel modes of operation.
<P>
Subjects and objects which are protected by DAC. Propagation of access rights
is controlled. Access is controlled at the granularity of named individual
and/or group of named individuals. The TCB is able to list the groups and
individuals with access to given objects including modes of access allowed
and those individuals and groups with no access allowed to an object. (This
implies, but does not explicitly require, Access Control Lists (ACL).)
<P>
The users are required to login and the system needs to be able to identify
individual users uniquely. While individuals are individuals, group access
rights are still allowed.
<P>
Reuse of storage objects (memory, disk space, buffers, etc.) is only allowed
after the object is cleared to disallow any access to the old data.
<P>
Audit is required to make users responsible for their actions. Half of the
theory behind audits is to allow for the security personnel to find wrongful
acts and identify the perpetrator; the other half of the theory is that an
advertised audit process will keep Honest people Honest. With labeling and
MAC, the security level is also recorded for objects being audited.
<P>
Labels are required for all system resources. These labels are used for MAC
decisions which are also mandated for all subjects and storage objects under
TCB control. The basic requirements are a simple translation of the standard
"Paper-style" requirements onto the computer so the computer will mark and
allow access properly.
<P>
The Trusted Computing Base (TCB) is required to protect itself (software)
for outside interference and tampering and to be able to validate the operations
of the TCB hardware and firmware. In addition, the TCB monitors the audit
events to determine if the activity indicates imminent security violations
and alerts the security officer upon occurrence.
<P>
<B>B3 Class Requirements</B>
<BLOCKQUOTE>
10.1 Discretionary Access Control (DAC)
<BLOCKQUOTE>
10.1.1 The TCB shall control access between named users and named objects.
<P>
10.1.2 The TCB shall protect all named objects from unauthorized access.
<P>
10.1.3 The TCB shall allow for the inclusion or exclusion of access to named
objects at the level of the single user.
<P>
10.1.4 The TCB shall allow authorized users to specify and control sharing
of objects by named individuals or groups of individuals or both.
<P>
10.1.5 The TCB shall provide controls to limit propagation of access rights.
<P>
10.1.6 The TCB shall shall be capable of specifying a list of individuals
and groups with access to the object including allowed access modes.
</BLOCKQUOTE>
<P>
10.2 The TCB shall clear all memory objects before allocation to a new subject.
<P>
10.3 Identification and Authentication
<BLOCKQUOTE>
10.3.1 The TCB shall require users to uniquely identify themselves before
performing any other actions on behalf of that user.
<P>
10.3.2 The TCB shall authenticate the user's unique identity before performing
any other actions on behalf of that user.
<P>
10.3.3 The TCB shall ensure that the user's login security level and
authorizations are dominated by the user's clearance and authorizations.
<P>
10.3.4 The TCB shall ensure that the security level and authorizations of
subjects external to the TCB which are created on behalf of the user are
dominated by the user's clearance and authorizations.
<P>
10.3.5 The TCB shall protect authentication data from unauthorized access.
<P>
10.3.6 The TCB shall associate the user's unique identity for all auditable
actions taken by the user.
<P>
10.3.7 The TCB shall support a trusted communication path between the TCB
and a user, initiated exclusively by the user or the TCB, for use when positive
TCB-to-user connection is needed.
</BLOCKQUOTE>
<P>
10.4 Audit
<BLOCKQUOTE>
10.4.1 The TCB shall be able to create an audit trail.
<P>
10.4.2 The TCB shall maintain the audit trail on-line for a minimum of thirty
days.
<P>
10.4.3 The TCB shall protect the audit trail from modification or unauthorized
access.
<P>
10.4.4 The TCB shall audit the following event types:
<BLOCKQUOTE>
a. Login.
<P>
b. Logout.
<P>
c. Access to objects.
<P>
d. Deletion of objects.
<P>
e. Override of human-readable output markings.
<P>
f. Labeling of imported unlabeled data.
<P>
g. Any change in the designation of single level and multilevel devices.
<P>
h. Any change in security level or levels associated with a subject or object.
<P>
i. Identified covert channel exploitation events.
<P>
j. Actions taken by system operators, administrators, and security officers.
</BLOCKQUOTE>
<P>
10.4.5 The TCB shall include the following information in each audit trail
record:
<BLOCKQUOTE>
a. Date and time of event.
<P>
b. User identity.
<P>
c. Event type.
<P>
d. Success or failure of action.
<P>
e. Security level of object, if any.
<P>
f. Name of object, if any.
</BLOCKQUOTE>
<P>
10.4.6 The TCB shall selectively audit the actions of one or more users based
on individual identity and/or object security level.
<P>
10.4.7 The TCB shall monitor the occurrence and accumulation of security
audit events and identify imminent security violations.
<P>
10.4.8 The TCB shall alert the security officer of identified imminent security
violations and take action to terminate continuing violations.
</BLOCKQUOTE>
<P>
10.5 System Security Architecture
<BLOCKQUOTE>
10.5.1 The TCB shall maintain a domain of its own execution that protects
it from external interference and tampering.
<P>
10.5.2 The TCB shall isolate the resources to be protected by access controls
and auditing.
<P>
10.5.3 The TCB shall maintain distinct address spaces for process isolation.
<P>
10.5.4 The TCB shall be structured modularly.
<P>
10.5.5 The user interface to the TCB and all TCB elements shall be completely
defined.
</BLOCKQUOTE>
<P>
10.6 The TCB shall have the capability to validate the correct operations
of the TCB's hardware and firmware.
<P>
10.7 Labels
<BLOCKQUOTE>
10.7.1 The TCB shall maintain the sensitivity label associated with each
system resources accessible by subjects external to the TCB.
<P>
10.7.2 The sensitivity label associated with a subject or an object shall
correctly represent the security level of the subject or object.
<P>
10.7.3 The TCB shall notify a terminal user of each change in the user's
security level during a session.
<P>
10.7.4 The TCB shall support the assignment of minimum and maximum security
levels for all attached devices.
<P>
10.7.5 The TCB shall use the sensitivity labels as the basis for mandatory
access control decisions.
<P>
10.7.6 The TCB shall request a label from an authorized user before importing
unlabeled data.
<P>
10.7.7 The TCB shall associate an accurate and unambiguous sensitivity label
with all exported information.
<P>
10.7.8 The TCB shall designate each I/O device and communications channel
as a single level or multilevel device.
<P>
10.7.9 Any change in the designation of single level or multilevel shall
be performed manually.
<P>
10.7.10 The TCB shall associate with each object exported over a multilevel
device the sensitivity level in the same form as the data and physically
residing with the data.
<P>
10.7.11 The communications protocol used for each multilevel communications
port shall provide for the unambiguous pairing of the data and its associated
sensitivity label.
<P>
10.7.12 The TCB shall allow an authorized user to designate the single security
level of information imported or exported via a single level communications
port or I/O device.
<P>
10.7.13 The TCB shall allow the System Administrator to specify the printable
label names associated with exported sensitivity labels.
<P>
10.7.14 The TCB shall mark the top and bottom of all human readable output
with human readable sensitivity labels that properly represent the sensitivity
of the output.
</BLOCKQUOTE>
<P>
10.8 Mandatory Access Control (MAC)
<BLOCKQUOTE>
10.8.1 The TCB shall enforce mandatory access control over all subjects and
objects accessible to subjects external to the TCB.
<P>
10.8.2 A subject shall be allowed read access only if the hierarchical
classification in the subject's security level is greater than or equal to
the hierarchical classification in the object's security level and the
non-hierarchical categories in the subject's security level include all of
the non-hierarchical categories in the object's security level.
<P>
10.8.3 A subject shall be allowed write access only if the hierarchical
classification in the subject's security level is less than or equal to the
hierarchical classification in the object's security level and all of the
non-hierarchical categories in the subject's security level are included
in the non-hierarchical categories in the object's security level.
</BLOCKQUOTE>
</BLOCKQUOTE>
<P>
<B>B3 Class SOW Tasking</B>
<P>
<B>A. Gonculator Accreditation Working Group.</B> The contractor shall support
the Gonculator Accreditation Working Group (GAWG) through attendance at meetings
as needed, presenting current program data as requested, acting upon assigned
and accepted Action Items, and preparing minutes of the GAWG meetings. At
a minimum, the GAWG will meet twice a year. At a minimum, support at the
meetings shall include representatives from program management, configuration
management, system engineering, and security engineering. (DI-A-7089/T)
<P>
<B>B. Data Accession List.</B> The contractor shall maintain a complete list
of all data generated as a result of this contract. The contractor shall
list the data by title, date, and subject. The list shall include all memos,
letters, meeting minutes, phone logs, etc. All data not required by the CDRL
shall be considered contractor format. The document shall be titled
<EM>Gonculator Data Accession List.</EM> (DI-A-3027A/T)
<P>
<B>C. System Description.</B> The contractor shall prepare separately published
common appendices which describes the system for use with the system
documentation. These appendices shall be prepared in an Unclassified version,
if possible, and such classified versions that are required for a full
description of the Gonculator System. The contractor shall use the common
appendices in place of the system description within the bodies of the
documentation. The descriptions shall be titled <EM>Gonculator System Description
Appendix, </EM> (Appropriate Classification)<STRONG><EM>
</EM></STRONG>Version. (DI-GDRQ-80567/T)
<P>
<B>D. System Security Management Program.</B> The contractor shall conduct
a System Security Management Program in accordance with the approved System
Security Management Plan.
<P>
<B>E. System Security Management Plan.</B> The contractor shall develop a
system security management plan describing the contractor's security engineering
and management approach. The plan should include all aspects of system security,
including computer security. The document shall be titled <EM>Gonculator
System Security Management Plan.</EM> (DI-MISC-80839/T)
<P>
<B>F. Computer Security Management Program.</B> The contractor shall conduct
a Computer Security Management Program in accordance with the approved Computer
Security Management Plan.
<P>
<B>G. Computer Security Management Plan.</B> The contractor shall generate
a computer security management plan. The Plan shall include the methods used
to manage the computer security engineering program, program schedule, and
the steps to be taken to ensure the proper incorporation of the computer
security requirements into the system. The document shall be titled
<EM>Gonculator Computer Security Management Plan.</EM> (DI-MISC-80839/T)
<P>
<B>H. Security Vulnerability Analysis.</B> The contractor shall conduct a
security vulnerability analysis and document the results. The study shall
include identification of logical security vulnerabilities of the system,
defining functional requirements which may secure the system from exploitation,
and choosing safeguards to reduce identified vulnerabilities. The document
shall be titled <EM>Gonculator Security Vulnerability Analysis.</EM>
(DI-MISC-80841/T)
<P>
<B>I. Security Architecture Study.</B> The contractor shall conduct a study
of the security architecture of the system and document the results of the
study. The study shall include partitioning of the system, cost/benefit analysis
for the architectural alternatives, and the required Class of system for
each alternative and for each partitioned subsystem. The report shall detail
the recommended architecture for the system. The document shall be titled
<EM>Gonculator Security Architecture Study.</EM> (DI-GDRQ-80567/T)
<P>
<B>J. System Security Concept of Operations.</B> The contractor shall generate
a system security concept of operations that documents the security concept
for the system including the incorporation of the protection philosophy into
the system. The document shall be titled <EM>Gonculator System Security Concept
Of Operations.</EM> (DI-MISC-80840/T)
<P>
<B>K. Computer Security Policy.</B> The contractor shall prepare a document
that defines the security policy enforced by the computer system. The document
shall be titled <EM>Gonculator Computer Security Policy.</EM> (DI-GDRQ-80567/T)
<P>
<B>L. Computer Security Policy Model.</B> The contractor shall develop and
document a formal model of the security policy enforced by the system. The
model description shall include the specific protection mechanisms and an
explanation showing that they satisfy the model and will enforce the security
policy. The document shall be titled <EM>Gonculator Computer Security Policy
Model. </EM> (DI-GDRQ-80567/T)
<P>
<B>M. Computer Security Audit Analysis.</B> The contractor shall analyze
the audit schema for the system including events to be audited, audit record
structures, throughput requirements, storage needs, and archival storage
techniques. The document shall be titled <EM>Gonculator Computer Security
Audit Analysis.</EM> (DI-GDRQ-80567/T)
<P>
<B>N. Covert Channel Analysis.</B> The contractor shall conduct a thorough
search for covert channels and make a determination of the maximum bandwidth
of each identified channel. The contractor shall generate a covert channel
analysis report that documents the results of the covert channel analysis.
The document shall be titled <EM>Gonculator Covert Storage Channel Analysis
Report. </EM> (DI-GDRQ-80567/T)
<P>
<B>O. Descriptive Top Level Specification.</B> The contractor shall generate
a descriptive top level specification that completely and accurately describes
the TCB in terms of exceptions, error messages, effects, and interfaces.
The document shall be titled <EM>Gonculator Trusted Computing Base Descriptive
Top Level Specification.</EM> (DI-GDRQ-80567/T)
<P>
<B>P. Security Features Users Guide.</B> The contractor shall generate a
Users' Guide that documents the protection mechanisms provided by the system,
guidelines for their use, and how the protection mechanisms interact with
each other. The users guide may be published as either a common appendix
to the positional handbooks or a stand-alone document titled <EM>Gonculator
Security Features Users' Guide</EM>. (DI-MCCR-80019A/T)
<P>
<B>Q. Trusted Facility Manual.</B> The contractor shall generate a manual
that documents cautions about functions and privileges that should be controlled
when running the secure facility in accordance with DOD-5200.28-STD. The
document shall be titled <EM>Gonculator Trusted Facility Manual.</EM>
(DI-MCCR-80019A/T)
<P>
<B>R. Security Test.</B> The contractor shall conduct a separate security
test in conjunction with the system acceptance test. The security test shall
show that all security mechanisms function as defined in the system documentation
and that the system is resistant to penetration. The security test shall
include an ad hoc, loosely structured test by the government test team. The
contractor shall train the government test team in the operation of the system
before the start of the test. The government test team will consist of six
people drawn from the developing, supporting, using, and accrediting communities.
<P>
<B>S. Security Test Plan.</B> The contractor shall develop a test plan for
the security testing to be performed. The document shall be titled
<EM>Gonculator Security Test Plan. </EM> (DI-MCCR-80014A/T)
<P>
<B>T. Security TEST DESCRIPTION.</B> The contractor shall develop test procedures
to implement the approved Gonculator<EM> </EM>Security Test Plan. The document
shall be titled <EM>Gonculator Security Test Description.</EM> (DI-MCCR-80015A/T)
<P>
<B>U. Security Test Report.</B> The contractor shall document the results
of the security test. The document shall be titled <EM>Gonculator Security
Test Report</EM>. (DI-MCCR-80017A/T)
<P>
<HR>
<H3>
A1 Class
</H3>
<P>
The A1 class secure computer system is based on clearly defined security
policy and model of the policy. A1 class systems are appropriate for operation
in the multilevel mode of operation. The functional requirements for A1 are
identical to the requirements for the B3 class system. The increased protection
offered by A1 systems is through increased assurance measures.
<P>
Subjects and objects which are protected by DAC. Propagation of access rights
is controlled. Access is controlled at the granularity of named individual
and/or group of named individuals. The TCB is able to list the groups and
individuals with access to given objects including modes of access allowed
and those individuals and groups with no access allowed to an object. (This
implies, but does not explicitly require, Access Control Lists (ACL).)
<P>
The users are required to login and the system needs to be able to identify
individual users uniquely. While individuals are individuals, group access
rights are still allowed.
<P>
Reuse of storage objects (memory, disk space, buffers, etc.) is only allowed
after the object is cleared to disallow any access to the old data.
<P>
Audit is required to make users responsible for their actions. Half of the
theory behind audits is to allow for the security personnel to find wrongful
acts and identify the perpetrator; the other half of the theory is that an
advertised audit process will keep Honest people Honest. With labeling and
MAC, the security level is also recorded for objects being audited.
<P>
Labels are required for all system resources. These labels are used for MAC
decisions which are also mandated for all subjects and storage objects under
TCB control. The basic requirements are a simple translation of the standard
"Paper-style" requirements onto the computer so the computer will mark and
allow access properly.
<P>
The Trusted Computing Base (TCB) is required to protect itself (software)
for outside interference and tampering and to be able to validate the operations
of the TCB hardware and firmware. In addition, the TCB monitors the audit
events to determine if the activity indicates imminent security violations
and alerts the security officer upon occurrence.
<P>
<B>A1 Class Requirements</B>
<BLOCKQUOTE>
10.1 Discretionary Access Control (DAC)
<BLOCKQUOTE>
10.1.1 The TCB shall control access between named users and named objects.
<P>
10.1.2 The TCB shall protect all named objects from unauthorized access.
<P>
10.1.3 The TCB shall allow for the inclusion or exclusion of access to named
objects at the level of the single user.
<P>
10.1.4 The TCB shall allow authorized users to specify and control sharing
of objects by named individuals or groups of individuals or both.
<P>
10.1.5 The TCB shall provide controls to limit propagation of access rights.
<P>
10.1.6 The TCB shall shall be capable of specifying a list of individuals
and groups with access to the object including allowed access modes.
</BLOCKQUOTE>
<P>
10.2 The TCB shall clear all memory objects before allocation to a new subject.
<P>
10.3 Identification and Authentication
<BLOCKQUOTE>
10.3.1 The TCB shall require users to uniquely identify themselves before
performing any other actions on behalf of that user.
<P>
10.3.2 The TCB shall authenticate the user's unique identity before performing
any other actions on behalf of that user.
<P>
10.3.3 The TCB shall ensure that the user's login security level and
authorizations are dominated by the user's clearance and authorizations.
<P>
10.3.4 The TCB shall ensure that the security level and authorizations of
subjects external to the TCB which are created on behalf of the user are
dominated by the user's clearance and authorizations.
<P>
10.3.5 The TCB shall protect authentication data from unauthorized access.
<P>
10.3.6 The TCB shall associate the user's unique identity for all auditable
actions taken by the user.
<P>
10.3.7 The TCB shall support a trusted communication path between the TCB
and a user, initiated exclusively by the user or the TCB, for use when positive
TCB-to-user connection is needed.
</BLOCKQUOTE>
<P>
10.4 Audit
<BLOCKQUOTE>
10.4.1 The TCB shall be able to create an audit trail.
<P>
10.4.2 The TCB shall maintain the audit trail on-line for a minimum of thirty
days.
<P>
10.4.3 The TCB shall protect the audit trail from modification or unauthorized
access.
<P>
10.4.4 The TCB shall audit the following event types:
<BLOCKQUOTE>
a. Login.
<P>
b. Logout.
<P>
c. Access to objects.
<P>
d. Deletion of objects.
<P>
e. Override of human-readable output markings.
<P>
f. Labeling of imported unlabeled data.
<P>
g. Any change in the designation of single level and multilevel devices.
<P>
h. Any change in security level or levels associated with a subject or object.
<P>
i. Identified covert channel exploitation events.
<P>
j. Actions taken by system operators, administrators, and security officers.
</BLOCKQUOTE>
<P>
10.4.5 The TCB shall include the following information in each audit trail
record:
<BLOCKQUOTE>
a. Date and time of event.
<P>
b. User identity.
<P>
c. Event type.
<P>
d. Success or failure of action.
<P>
e. Security level of object, if any.
<P>
f. Name of object, if any.
</BLOCKQUOTE>
<P>
10.4.6 The TCB shall selectively audit the actions of one or more users based
on individual identity and/or object security level.
<P>
10.4.7 The TCB shall monitor the occurrence and accumulation of security
audit events and identify imminent security violations.
<P>
10.4.8 The TCB shall alert the security officer of identified imminent security
violations and take action to terminate continuing violations.
</BLOCKQUOTE>
<P>
10.5 System Security Architecture
<BLOCKQUOTE>
10.5.1 The TCB shall maintain a domain of its own execution that protects
it from external interference and tampering.
<P>
10.5.2 The TCB shall isolate the resources to be protected by access controls
and auditing.
<P>
10.5.3 The TCB shall maintain distinct address spaces for process isolation.
<P>
10.5.4 The TCB shall be structured modularly.
<P>
10.5.5 The user interface to the TCB and all TCB elements shall be completely
defined.
</BLOCKQUOTE>
<P>
10.6 The TCB shall have the capability to validate the correct operations
of the TCB's hardware and firmware.
<P>
10.7 Labels
<BLOCKQUOTE>
10.7.1 The TCB shall maintain the sensitivity label associated with each
system resources accessible by subjects external to the TCB.
<P>
10.7.2 The sensitivity label associated with a subject or an object shall
correctly represent the security level of the subject or object.
<P>
10.7.3 The TCB shall notify a terminal user of each change in the user's
security level during a session.
<P>
10.7.4 The TCB shall support the assignment of minimum and maximum security
levels for all attached devices.
<P>
10.7.5 The TCB shall use the sensitivity labels as the basis for mandatory
access control decisions.
<P>
10.7.6 The TCB shall request a label from an authorized user before importing
unlabeled data.
<P>
10.7.7 The TCB shall associate an accurate and unambiguous sensitivity label
with all exported information.
<P>
10.7.8 The TCB shall designate each I/O device and communications channel
as a single level or multilevel device.
<P>
10.7.9 Any change in the designation of single level or multilevel shall
be performed manually.
<P>
10.7.10 The TCB shall associate with each object exported over a multilevel
device the sensitivity level in the same form as the data and physically
residing with the data.
<P>
10.7.11 The communications protocol used for each multilevel communications
port shall provide for the unambiguous pairing of the data and its associated
sensitivity label.
<P>
10.7.12 The TCB shall allow an authorized user to designate the single security
level of information imported or exported via a single level communications
port or I/O device.
<P>
10.7.13 The TCB shall allow the System Administrator to specify the printable
label names associated with exported sensitivity labels.
<P>
10.7.14 The TCB shall mark the top and bottom of all human readable output
with human readable sensitivity labels that properly represent the sensitivity
of the output.
</BLOCKQUOTE>
<P>
10.8 Mandatory Access Control (MAC)
<BLOCKQUOTE>
10.8.1 The TCB shall enforce mandatory access control over all subjects and
objects accessible to subjects external to the TCB.
<P>
10.8.2 A subject shall be allowed read access only if the hierarchical
classification in the subject's security level is greater than or equal to
the hierarchical classification in the object's security level and the
non-hierarchical categories in the subject's security level include all of
the non-hierarchical categories in the object's security level.
<P>
10.8.3 A subject shall be allowed write access only if the hierarchical
classification in the subject's security level is less than or equal to the
hierarchical classification in the object's security level and all of the
non-hierarchical categories in the subject's security level are included
in the non-hierarchical categories in the object's security level.
</BLOCKQUOTE>
</BLOCKQUOTE>
<P>
<B>A1 Class SOW Tasking</B>
<P>
<B>A. Gonculator Accreditation Working Group.</B> The contractor shall support
the Gonculator Accreditation Working Group (GAWG) through attendance at meetings
as needed, presenting current program data as requested, acting upon assigned
and accepted Action Items, and preparing minutes of the GAWG meetings. At
a minimum, the GAWG will meet twice a year. At a minimum, support at the
meetings shall include representatives from program management, configuration
management, system engineering, and security engineering. (DI-A-7089/T)
<P>
<B>B. Data Accession List.</B> The contractor shall maintain a complete list
of all data generated as a result of this contract. The contractor shall
list the data by title, date, and subject. The list shall include all memos,
letters, meeting minutes, phone logs, etc. All data not required by the CDRL
shall be considered contractor format. The document shall be titled
<EM>Gonculator Data Accession List.</EM> (DI-A-3027A/T)
<P>
<B>C. System Description.</B> The contractor shall prepare separately published
common appendices which describes the system for use with the system
documentation. These appendices shall be prepared in an Unclassified version,
if possible, and such classified versions that are required for a full
description of the Gonculator System. The contractor shall use the common
appendices in place of the system description within the bodies of the
documentation. The descriptions shall be titled <EM>Gonculator System Description
Appendix, </EM> (Appropriate Classification)<STRONG><EM>
</EM></STRONG>Version. (DI-GDRQ-80567/T)
<P>
<B>D. System Security Management Program.</B> The contractor shall conduct
a System Security Management Program in accordance with the approved System
Security Management Plan.
<P>
<B>E. System Security Management Plan.</B> The contractor shall develop a
system security management plan describing the contractor's security engineering
and management approach. The plan should include all aspects of system security,
including computer security. The document shall be titled <EM>Gonculator
System Security Management Plan.</EM> (DI-MISC-80839/T)
<P>
<B>F. Computer Security Management Program.</B> The contractor shall conduct
a Computer Security Management Program in accordance with the approved Computer
Security Management Plan.
<P>
<B>G. Computer Security Management Plan.</B> The contractor shall generate
a computer security management plan. The Plan shall include the methods used
to manage the computer security engineering program, program schedule, and
the steps to be taken to ensure the proper incorporation of the computer
security requirements into the system. The document shall be titled
<EM>Gonculator Computer Security Management Plan.</EM> (DI-MISC-80839/T)
<P>
<B>H. Security Vulnerability Analysis.</B> The contractor shall conduct a
security vulnerability analysis and document the results. The study shall
include identification of logical security vulnerabilities of the system,
defining functional requirements which may secure the system from exploitation,
and choosing safeguards to reduce identified vulnerabilities. The document
shall be titled <EM>Gonculator Security Vulnerability Analysis.</EM>
(DI-MISC-80841/T)
<P>
<B>I. Security Architecture Study.</B> The contractor shall conduct a study
of the security architecture of the system and document the results of the
study. The study shall include partitioning of the system, cost/benefit analysis
for the architectural alternatives, and the required Class of system for
each alternative and for each partitioned subsystem. The report shall detail
the recommended architecture for the system. The document shall be titled
<EM>Gonculator Security Architecture Study.</EM> (DI-GDRQ-80567/T)
<P>
<B>J. System Security Concept of Operations.</B> The contractor shall generate
a system security concept of operations that documents the security concept
for the system including the incorporation of the protection philosophy into
the system. The document shall be titled <EM>Gonculator System Security Concept
Of Operations.</EM> (DI-MISC-80840/T)
<P>
<B>K. Computer Security Policy.</B> The contractor shall prepare a document
that defines the security policy enforced by the computer system. The document
shall be titled <EM>Gonculator Computer Security Policy.</EM> (DI-GDRQ-80567/T)
<P>
<B>L. Computer Security Policy Model.</B> The contractor shall develop and
document a formal model of the security policy enforced by the system. The
model description shall include the specific protection mechanisms and an
explanation showing that they satisfy the model and will enforce the security
policy. The document shall be titled <EM>Gonculator Computer Security Policy
Model. </EM> (DI-GDRQ-80567/T)
<P>
<B>M. Computer Security Audit Analysis.</B> The contractor shall analyze
the audit schema for the system including events to be audited, audit record
structures, throughput requirements, storage needs, and archival storage
techniques. The document shall be titled <EM>Gonculator Computer Security
Audit Analysis.</EM> (DI-GDRQ-80567/T)
<P>
<B>N. Covert Channel Analysis.</B> The contractor shall use formal methods
to conduct a thorough search for covert channels and make a determination
of the maximum bandwidth of each identified channel. The contractor shall
generate a covert channel analysis report that documents the results of the
covert channel analysis. The document shall be titled <EM>Gonculator Covert
Storage Channel Analysis Report. </EM> (DI-GDRQ-80567/T)
<P>
<B>O. Descriptive Top Level Specification.</B> The contractor shall generate
a descriptive top level specification that completely and accurately describes
the TCB in terms of exceptions, error messages, effects, and interfaces.
The document shall be titled <EM>Gonculator Trusted Computing Base Descriptive
Top Level Specification.</EM> (DI-GDRQ-80567/T)
<P>
<B>P. Formal Top Level Specification.</B> The contractor shall develop a
Formal Top Level Specification that accurately describes the TCB in terms
of exceptions, error messages, and effects. The FTLS shall be developed with
the use of an NCSC-endosed formal specification and verification system.
The document shall be titled <EM>Gonculator Trusted Computing Base Formal
Top Level Specification.</EM> (DI-GDRQ-80567/T)
<P>
<B>Q. Security Features Users Guide.</B> The contractor shall generate a
Users' Guide that documents the protection mechanisms provided by the system,
guidelines for their use, and how the protection mechanisms interact with
each other. The users guide may be published as either a common appendix
to the positional handbooks or a stand-alone document titled <EM>Gonculator
Security Features Users' Guide</EM>. (DI-MCCR-80019A/T)
<P>
<B>R. Trusted Facility Manual.</B> The contractor shall generate a manual
that documents cautions about functions and privileges that should be controlled
when running the secure facility in accordance with DOD-5200.28-STD. The
document shall be titled <EM>Gonculator Trusted Facility Manual.</EM>
(DI-MCCR-80019A/T)
<P>
<B>S. Security Test.</B> The contractor shall conduct a separate security
test in conjunction with the system acceptance test. The security test shall
show that all security mechanisms function as defined in the system documentation
and that the system is resistant to penetration. The security test shall
include an ad hoc, loosely structured test by the government test team. The
contractor shall train the government test team in the operation of the system
before the start of the test. The government test team will consist of six
people drawn from the developing, supporting, using, and accrediting communities.
<P>
<B>T. Security Test Plan.</B> The contractor shall develop a test plan for
the security testing to be performed. The document shall be titled
<EM>Gonculator Security Test Plan. </EM> (DI-MCCR-80014A/T)
<P>
<B>U. Security TEST DESCRIPTION.</B> The contractor shall develop test procedures
to implement the approved Gonculator<EM> </EM>Security Test Plan. The document
shall be titled <EM>Gonculator Security Test Description.</EM> (DI-MCCR-80015A/T)
<P>
<B>V. Security Test Report.</B> The contractor shall document the results
of the security test. The document shall be titled <EM>Gonculator Security
Test Report</EM>. (DI-MCCR-80017A/T)
<P>
<HR>
<H3>
Contract Data Requirements List Inputs
</H3>
<P>
1. Gonculator Accreditation Working Group Meeting Minutes
<BLOCKQUOTE>
DI-A-7089 Meeting Minutes.
<P>
Due 5 Days after each GAWG Meeting.
<P>
Distribution to all GAWG Members and Attenders.
<P>
Justification: Data is needed to document the results of the GAWG.
<P>
Contractor format acceptable.
</BLOCKQUOTE>
<P>
2. Data Accession List
<BLOCKQUOTE>
DI-A-3027A Data Accession List
<P>
Due monthly.
<P>
Justification: Data is needed to monitor contractor work in progress.
<P>
Contractor format acceptable.
<P>
NOTE: This is a DID on contract for most programs. The reason it it included
in this list is the generally insufficient level of detail found on a DAL.
Since the DAL is based almost entirely on the tasking, there is a SOW paragraph
calling for the proper level of detail included in the SOW Tasking for each
Class.
</BLOCKQUOTE>
<P>
3. System Description Appendix
<BLOCKQUOTE>
DI-GDRQ-80567 Subsystem Design Analysis Report
<P>
Due 90DAC with Updates as the design of the system develops sufficiently
to invalidate the
<P>
previous version, but not later than each major review.
<P>
Direct distribution is limited to the Program Office, Program Engineering,
and Configuration
<P>
Management. The document will also be distributed as an appendix to all other
documents which need a system description.
<P>
Justification: This data is needed to form a unified view of the system as
it progresses.
<P>
Contractor format acceptable.
</BLOCKQUOTE>
<P>
4. System Security Management Plan
<BLOCKQUOTE>
DI-MISC-80839 System Security Management Plan
<P>
Due 90DAC with revisions for each new major phase of the program.
<P>
Distribution to the Program Office, Program Engineering, and Accreditor.
<P>
Justification: This data is needed to establish a viable System Security
Management
<P>
Program (SSMP). The approved plan is the direction to the contractor for
the implementation of the SSMP.
<P>
Contractor format acceptable. Delete 10.6.2 through 10.6.7
</BLOCKQUOTE>
<P>
5. Computer Security Management Plan
<BLOCKQUOTE>
DI-MISC-80839 System Security Management Plan
<P>
Due 90DAC with revisions for each new major phase of the program.
<P>
Distribution to the Program Office, Program Engineering, and Accreditor.
<P>
Justification: This data is needed to establish a viable Computer Security
Management
<P>
Program (CSMP). The approved plan is the direction to the contractor for
the implementation of the CSMP.
<P>
Contractor format acceptable. Delete 10.6.2 through 10.6.7
</BLOCKQUOTE>
<P>
6. Security Vulnerability Analysis
<BLOCKQUOTE>
DI-MISC-80841 Security Vulnerability Analysis
<P>
Preliminary version due 30DAC. Final due SRR-30 (or 90DAC if no SRR).
<P>
Distribution to the Program Office, Program Engineering, and Accreditor.
<P>
Justification: This data is needed to validate the sufficiency of the security
requirements levied on the system to avoid designed-in security breaches.
<P>
Contractor format acceptable.
</BLOCKQUOTE>
<P>
7. Security Architecture Study
<BLOCKQUOTE>
DI-GDRQ-80567 Subsystem Design Analysis Report
<P>
Preliminary version due 90DAC. Final due SDR-30.
<P>
Distribution to the Program Office, Program Engineering, and Accreditor.
<P>
Justification: This data is needed to validate the sufficiency of the security
requirements levied on the system to avoid designed-in security breaches.
<P>
Contractor format acceptable.
</BLOCKQUOTE>
<P>
8. System Security Concept of Operations
<BLOCKQUOTE>
DI-MISC-80840 Preliminary System Security Concept
<P>
Preliminary version due 90DAC. Final due SDR-30.
<P>
Distribution to the Program Office, Program Engineering, Users, and Accreditor.
<P>
Justification: This data is needed to validate the sufficiency of the security
requirements levied on the system to avoid designed-in security breaches
and to ensure the operational workability of the design concept.
<P>
Contractor format acceptable.
</BLOCKQUOTE>
<P>
9. Computer Security Policy
<BLOCKQUOTE>
DI-GDRQ-80567 Subsystem Design Analysis Report
<P>
Preliminary version due 30DAC. Final SRR-30. Revisions as needed by changes
to system security policy.
<P>
Distribution to the Program Office, Program Engineering, Users, and Accreditor.
<P>
Justification: This data is needed to establish the baseline for the security
policy to be enforced by the system.
<P>
Contractor format acceptable.
</BLOCKQUOTE>
<P>
10. Computer Security Policy Model
<BLOCKQUOTE>
DI-GDRQ-80567 Subsystem Design Analysis Report
<P>
Preliminary version due SDR-30. Final due PDR-30. Revisions as needed.
<P>
Distribution to the Program Office, Program Engineering, and Accreditor.
<P>
Justification: This data is needed to validate the model of the policy for
sufficiency and completeness.
<P>
Contractor format acceptable.
</BLOCKQUOTE>
<P>
11. Computer Security Audit Analysis
<BLOCKQUOTE>
DI-GDRQ-80567 Subsystem Design Analysis Report
<P>
Due SDR-30. Quarterly submittals after approval.
<P>
Distribution to the Program Office and Program Engineering.
<P>
Justification: This data is needed to evaluate the contractor design and
implementation of the audit requirements and related performance issues.
<P>
Contractor format acceptable.
</BLOCKQUOTE>
<P>
12. Covert Channel Analysis
<BLOCKQUOTE>
DI-GDRQ-80567 Subsystem Design Analysis Report
<P>
Preliminary version due SDR-30. Final due PDR-30. Revisions as needed.
<P>
Distribution to the Program Office, Program Engineering, and Accreditor.
<P>
Justification: This data is needed to evaluate the security of the contractor's
deign and implementation with regards to covert channels.
<P>
Contractor format acceptable.
</BLOCKQUOTE>
<P>
13. Descriptive Top Level Specification
<BLOCKQUOTE>
DI-GDRQ-80567 Subsystem Design Analysis Report
<P>
Preliminary version due SDR-30. Final due PDR-30. Revisions as needed.
<P>
Distribution to the Program Office, Program Engineering, and Accreditor.
<P>
Justification: This data is needed to validate the contractor's design for
the Trusted Computing Base (TCB).
<P>
Contractor format acceptable.
</BLOCKQUOTE>
<P>
14. Formal Top Level Specification
<BLOCKQUOTE>
DI-GDRQ-80567 Subsystem Design Analysis Report
<P>
Preliminary version due SDR-30. Final due PDR-30. Revisions as needed.
<P>
Distribution to the Program Office, Program Engineering, and Accreditor.
<P>
Justification: This data is needed to formally validate the contractor's
design for the Trusted Computing Base (TCB).
<P>
Contractor format acceptable.
</BLOCKQUOTE>
<P>
15. Security Features Users Guide
<BLOCKQUOTE>
DI-MCCR-80019A Software User's Manual
<P>
Preliminary due CDR-30. Final due 30 days before test.
<P>
Distribution to the Program Office, Program Engineering, Users, and Accreditor.
<P>
Justification: This data is needed to guide the users in the use of the security
features.
<P>
Contractor format acceptable.
</BLOCKQUOTE>
<P>
16. Trusted Facility Manual
<BLOCKQUOTE>
DI-MCCR-80019A Software User's Manual
<P>
Preliminary due CDR-30. Final due 30 days before test.
<P>
Distribution to the Program Office, Program Engineering, Users, and Accreditor.
<P>
Justification: This data is needed to guide the security personnel in the
use of the security safeguards.
<P>
Contractor format acceptable.
</BLOCKQUOTE>
<P>
17. Security Test Plan
<BLOCKQUOTE>
DI-MCCR-80014A Software Test Plan
<P>
Preliminary due CDR-30. Final due CDR+90.
<P>
Distribution to the Program Office, Program Engineering, Users, and Accreditor.
<P>
Justification: This data is needed to determine the sufficiency of the security
safeguards in the completed system.
<P>
Contractor format acceptable.
</BLOCKQUOTE>
<P>
18. Security Test Description
<BLOCKQUOTE>
DI-MCCR-80015A Software Test Description
<P>
Preliminary version due 90 days before test. Final due 30 days before test.
<P>
Distribution to the Program Office and Program Engineering.
<P>
Justification: This data is needed to establish the procedures to be used
during the system security test.
<P>
Contractor format acceptable.
</BLOCKQUOTE>
<P>
19. Security Test Report
<BLOCKQUOTE>
DI-MCCR-80017A Software Test Report
<P>
Due 30 days after security test completion.
<P>
Distribution to the Program Office, Program Engineering, Users, and Accreditor.
<P>
Justification: This data is needed to determine the sufficiency of the security
safeguards in the completed system.
<P>
Contractor format acceptable.
</BLOCKQUOTE>
<P>
<TABLE CELLPADDING="12">
<TR>
<TD>Gonculator Accreditation Working Group</TD>
<TD></TD>
<TD></TD>
<TD>B1</TD>
<TD>B2</TD>
<TD>B3</TD>
<TD>A1</TD>
</TR>
<TR>
<TD>Gonculator Accreditation Working Group </TD>
<TD></TD>
<TD></TD>
<TD>B1</TD>
<TD>B2</TD>
<TD>B3</TD>
<TD>A1</TD>
</TR>
<TR>
<TD>Data Accession List</TD>
<TD>C1</TD>
<TD>C2</TD>
<TD>B1</TD>
<TD>B2</TD>
<TD>B3</TD>
<TD>A1</TD>
</TR>
<TR>
<TD>System Description</TD>
<TD>C1</TD>
<TD>C2</TD>
<TD>B1</TD>
<TD>B2</TD>
<TD>B3</TD>
<TD>A1</TD>
</TR>
<TR>
<TD>System Security Management Program</TD>
<TD>C1</TD>
<TD>C2</TD>
<TD>B1</TD>
<TD>B2</TD>
<TD>B3</TD>
<TD>A1</TD>
</TR>
<TR>
<TD>System Security Management Plan</TD>
<TD>C1</TD>
<TD>C2</TD>
<TD>B1</TD>
<TD>B2</TD>
<TD>B3</TD>
<TD>A1</TD>
</TR>
<TR>
<TD>Computer Security Management Program</TD>
<TD></TD>
<TD></TD>
<TD>B1</TD>
<TD>B2</TD>
<TD>B3</TD>
<TD>A1</TD>
</TR>
<TR>
<TD>Computer Security Management Plan</TD>
<TD></TD>
<TD></TD>
<TD>B1</TD>
<TD>B2</TD>
<TD>B3</TD>
<TD>A1</TD>
</TR>
<TR>
<TD>Security Vulnerability Analysis</TD>
<TD>C1</TD>
<TD>C2</TD>
<TD>B1</TD>
<TD>B2</TD>
<TD>B3</TD>
<TD>A1</TD>
</TR>
<TR>
<TD>Security Architecture Study</TD>
<TD></TD>
<TD></TD>
<TD>B1</TD>
<TD>B2</TD>
<TD>B3</TD>
<TD>A1</TD>
</TR>
<TR>
<TD>System Security Concept of Operations</TD>
<TD></TD>
<TD></TD>
<TD>B1</TD>
<TD>B2</TD>
<TD>B3</TD>
<TD>A1</TD>
</TR>
<TR>
<TD>Computer Security Policy</TD>
<TD>C1</TD>
<TD>C2</TD>
<TD>B1</TD>
<TD>B2</TD>
<TD>B3</TD>
<TD>A1</TD>
</TR>
<TR>
<TD>Computer Security Policy Model</TD>
<TD></TD>
<TD></TD>
<TD>B1</TD>
<TD>B2</TD>
<TD>B3</TD>
<TD>A1</TD>
</TR>
<TR>
<TD>Computer Security Audit Analysis</TD>
<TD></TD>
<TD>C2</TD>
<TD>B1</TD>
<TD>B2</TD>
<TD>B3</TD>
<TD>A1</TD>
</TR>
<TR>
<TD>Covert Channel Analysis</TD>
<TD></TD>
<TD></TD>
<TD></TD>
<TD>B2</TD>
<TD>B3</TD>
<TD>A1</TD>
</TR>
<TR>
<TD>Descriptive Top Level Specification</TD>
<TD></TD>
<TD></TD>
<TD></TD>
<TD>B2</TD>
<TD>B3</TD>
<TD>A1</TD>
</TR>
<TR>
<TD>Formal Top Level Specification</TD>
<TD></TD>
<TD></TD>
<TD></TD>
<TD></TD>
<TD></TD>
<TD>A1</TD>
</TR>
<TR>
<TD>Security Features Users Guide</TD>
<TD>C1</TD>
<TD>C2</TD>
<TD>B1</TD>
<TD>B2</TD>
<TD>B3</TD>
<TD>A1</TD>
</TR>
<TR>
<TD>Trusted Facility Manual</TD>
<TD>C1</TD>
<TD>C2</TD>
<TD>B1</TD>
<TD>B2</TD>
<TD>B3</TD>
<TD>A1</TD>
</TR>
<TR>
<TD>Security Test</TD>
<TD></TD>
<TD></TD>
<TD>B1</TD>
<TD>B2</TD>
<TD>B3</TD>
<TD>A1</TD>
</TR>
<TR>
<TD>Security Test Plan</TD>
<TD></TD>
<TD></TD>
<TD>B1</TD>
<TD>B2</TD>
<TD>B3</TD>
<TD>A1</TD>
</TR>
<TR>
<TD>Security Test Description B1 B2 B3 A1</TD>
<TD></TD>
<TD></TD>
<TD>B1</TD>
<TD>B2</TD>
<TD>B3</TD>
<TD>A1</TD>
</TR>
<TR>
<TD>Security Test Report</TD>
<TD></TD>
<TD></TD>
<TD>B1</TD>
<TD>B2</TD>
<TD>B3</TD>
<TD>A1</TD>
</TR>
</TABLE>
<P>
<HR>
<H3>
Data Item Descriptions (DIDs)
</H3>
<P>
Because some of the DIDs mentioned in the SOW Tasking and CDRL Inputs portions
of this section may be unfamiliar to some, and difficult to find for all,
this portion of the section is dedicated to the DIDs themselves. Each of
the major DIDs is included in its entirety. The DIDs contained here are:
<BLOCKQUOTE>
DI-GDRQ-80567 Subsystem Design Analysis Report: This DID is a relatively
generic DID which is useful for the production of the out-of-the-norm documents.
In particular, the following documents use this DID:
<BLOCKQUOTE>
Covert Channel Analysis Report
<P>
Descriptive Top Level Specification
<P>
Formal Top Level Specification
<P>
Computer Security Audit Analysis
<P>
Computer Security Policy
<P>
Computer Security Policy Model
<P>
Security Architecture Study
<P>
System Description Appendix
</BLOCKQUOTE>
<P>
DI-MISC-80839 System Security Management Plan: This DID is useful for both
the System Security Management Plan and the Computer Security Management
Plan.
<P>
DI-MISC-80840 Preliminary System Security Concept: This DID is useful for
the System Security Concept of Operations.
<P>
DI-MISC-80841 Security Vulnerability Analysis: This DID is useful for the
Security Vulnerability Analysis. (Oddly enough.)
<P>
DI-IPSC-80690 System/Subsystem Specification (SS) Document for Automated
Information Systems (AIS): As the system's security functionality increases
as a proportion of the total system functionality this DID becomes increasingly
useful. In particular, if the system has security operations as its primary
function (as in a security add-on subsystem) this is the DID which should
be used.
<P>
DI-MISC-80842 Adversary Mission Analysis: This DID is a non-CompuSec portion
of the standard System Security Engineering Management Program.
<P>
DI-S-1817 Logistical Support Plan: This DID is a non-CompuSec portion of
the standard System Security Engineering Management Program.
</BLOCKQUOTE>
<P>
<HR>
<P>
<I>[Note: The following HTML versions of DIDs may be replaced with correctly
formatted DIDs 1817, 80016, 80017, 80567, 80690, 80839, 80840, 80841 and
80841 available in Word 7.0 files in a single Zip-compressed file:
<A HREF="http://jya.com/ntob-did.zip">http://jya.com/ntob-did.zip</A>
(51K) ]</I>
<P>
<HR>
<P>
<STRONG>Data Item Description </STRONG>
<P>
1. TITLE Subsystem Design Analysis Report
<P>
2. Identification Number DI-GDRQ-80567
<P>
3. Description/Purpose
<BLOCKQUOTE>
3.1 This report is used to evaluate the design approach for the configuration
item or subsystem and to provide visibility to the government. The data may
also be used to formulate additional technical direction to the design activity.
</BLOCKQUOTE>
<P>
4. Approval Date 880415
<P>
5. OPR F/AD/ALX
<P>
6a. DTIC Applicable X
<P>
6b. GDEP Applicable
<P>
7. Application/Interrelationship
<BLOCKQUOTE>
7.1 This data item description (DID) contains the format and content preparation
instructions for the data product generated by the specific and discrete
task requirements as delineated in the contract.
<P>
7.2 This report is normally prepared during the analysis effort for each
configuration item or subsystem during system acquisition. It may also be
applicable to other development efforts.
<P>
7.3 Specific requirements of MIL-STD-847 should be stated in the contract
data requirements list.
<P>
7.4 This report should be considered for submission to the Defense Technical
Information Center, Cameron Station, Alexandria VA under the provisions of
AFR 80-40.
<P>
7.5 This DID supersedes DI-S-3581.
</BLOCKQUOTE>
<P>
8. Approval Limitation
<P>
9a. Applicable Forms
<P>
9b. AMSC Number F4380
<P>
10. Preparation Instructions (Continued on Page 2)
<P>
11. Distribution Statement DISTRIBUTION STATEMENT A: Approved for public
release; distribution is unlimited.
<P>
Page <U>1 </U> of <U>2 </U> Pages
<P>
<HR>
<P>
Block 10. Preparation Instructions (Continued)
<BLOCKQUOTE>
10.1 <U>Reference Documents.</U> The applicable issue cited herein, including
their approval dates and dates of any applicable amendments, notices, and
revisions shall be specified in the contract.
<P>
10.2 <U>Format.</U> The report shall be structured to separately cover each
of the major subsections of the design analysis task. The analysis report
shall correlate the design requirements with the system requirement and any
specified requirement for the subsystem or configuration item. The report
shall include or reference all related data (sketches, preliminary drawings,
schematics, functional diagrams) necessary for portrayal of the analysis
or to aid in an understanding of the analysis.
<BLOCKQUOTE>
10.2.1 The report shall be generally written to MIL-STD-847 format. Specific
requirements of MIL-STD-847 will be stated in the contract.
</BLOCKQUOTE>
<P>
10.3 <U>Content.</U> The report shall include the following:
<P>
10.3.1 Objective of the analysis.
<P>
10.3.2 Description of the items involved, including adequate drawings,
schematics, and computer print-outs to support the analysis.
<P>
10.3.3 Specification of design constraints and assumptions imposed on the
analysis.
<P>
10.3.4 Discussion of the evaluation and analysis procedure, method, or technique
used, and its probable accuracy, explained by sample calculations.
<P>
10.3.5 Identification of source material used in the analysis.
<P>
10.3.6 Results of the analysis to include such aspects as:
<BLOCKQUOTE>
a. Predicted performance related to requirements.
<P>
b. Design impact and any constraints which influence other subsystems or
configuration items.
<P>
c. Producibility considerations.
<P>
d. Problems encountered or revealed and suggested solutions.
</BLOCKQUOTE>
<P>
10.3.7 Conclusions.
</BLOCKQUOTE>
<P>
Page <U>2 </U> of <U>2 </U> Pages
<P>
<HR>
<P>
<STRONG>Data Item Description </STRONG>
<P>
1. TITLE System Security Management plan
<P>
2. Identification Number DI-MISC-80839
<P>
3. Description/Purpose 3.1 Outlines and defines the contractor System Security
Management Program. The SSMP describes the methods used to (1) identify security
requirements, (2) synthesize and evaluate proposed solutions, and (3) provide
security inputs to the system acquisition process.
<P>
4. Approval Date 890605
<P>
5. OPR AF 10
<P>
6a. DTIC Applicable x
<P>
6b. GDEP Applicable
<P>
7. Application/Interrelationship 7.1 This Data Item Description contains
the format and content preparation instructions for data resulting from the
work task described by 5.3.1.1 of MIL-STD-1785. 7.2 Security Vulnerability
Analysis, DI-MISC-80841, is used with this Data Item Description when paragraphs
10.1.6.2 through 10.1.6.7 are cited. 7.3 This Data Item description supersedes
DI-R-3527/S-112-1. 7.4 Defense Technical Information Center, Cameron Station,
Alexandria VA 22314-6100.
<P>
8. Approval Limitation 9a. Applicable Forms 9b. AMSC Number F4730
<P>
10. Preparation Instructions (Continued on Page 2)
<P>
11. Distribution Statement DISTRIBUTION STATEMENT A: Approved for public
release; distribution is unlimited.
<P>
Page <U>1</U> of <U>3</U> Pages
<P>
<HR>
<P>
Block 10. Preparation Instructions (Continued)
<P>
10.1 The System Security Management Plan (SSMP) shall include the following:
<BLOCKQUOTE>
10.1.1 <U>Applicable Documents.</U> A list of documents which apply as directives
or guidance during the execution of the SSMP. The list shall include pertinent
legal, regulatory, and other published or draft contract requirements applicable
to the system under development. System security requirements and objectives
are drawn from these documents.
<P>
10.1.2 <U>Purpose.</U> State the approach to the System Security Engineering
Program (SSEP) and the principles which will be applied.
<P>
10.1.3 <U>Organization.</U> Describe the organizational placement and manning
of the contractor's security engineering management organization. Use charts
and diagrams to show organizational and functional relationships.
<P>
10.1.4 <U>System Security Engineering Management Program.</U> Describe the
activities planned to satisfy System Security engineering program objectives.
Use charts or diagrams to illustrate the program's functional interfaces,
engineering and design requirements, activity milestones, management process,
and levels of effort for each program phase.
<P>
10.1.5 <U>Program Data Flow.</U> Illustrate the manner in which basic program
data flows, indicating how the system security engineering organization will
monitor all program efforts and make inputs to decision processes.
<P>
10.1.6 <U>System Security Engineering Functions.</U> Describe the principal
functions and specific tasks to be performed as given in the Statement of
Work. Describe the assignment of these functions and tasks within the system
security engineering organization. Include the following:
<BLOCKQUOTE>
10.1.6.1 <U>Establishing the Security Requirements and Objectives Baseline.</U>
Describe how the SSMP will address the following security concerns: Personnel,
industrial, operations, product, communications, and physical security;
survivability, antiterrorism and counterintelligence aspects. Describe how
the security regulations and other program guidance will be identified and
synthesized into a set of security requirements and objectives. Illustrate
how these requirements and objectives will be used to measure the effectiveness
of security system arrangements and how required policy revisions to government
security programs will be processed.
<P>
10.1.6.2 <U>Threat Analysis.</U> Describe how the threat analysis will be
evaluated and integrated along with adversary mission objectives.
<P>
10.1.6.3 <U>Conducting the Adversary Mission Analysis and Constructing the
Preliminary Threat Logic Tree.</U> Describe the technical and analytical
methods used to identify criteria for success in adversary mission objectives
and to synthesize threat models. Delineate the system security technology
research tasks and explain how this research will be documented.
<P>
10.1.6.4 <U>Applying Threat Rejection Logic and Documenting the Results.</U>
Describe how qualitative and quantitative values will be established for
threats and countermeasures and the method to document threat rejection logic.
</BLOCKQUOTE>
</BLOCKQUOTE>
<P>
(Continued on Page 3)
<P>
Page <U>2 </U> of <U>3 </U> Pages
<P>
<HR>
<P>
Block 10. Preparation Instructions (Continued)
<BLOCKQUOTE>
<BLOCKQUOTE>
10.1.6.5 <U>Synthesizing Countermeasures.</U> Describe the process by which
countermeasures will be synthesized. Explain how this activity and the security
system synthesis and evaluation tasks will be coordinated.
<P>
10.1.6.6 <U>Adversary Vulnerability Measurement.</U> Describe fully the method
used to identify and conduct quantitative and qualitative analysis for risks
associated with each adversary mission objective. Include the application
of candidate countermeasures and the manner in which preferred countermeasures
will be selected and documented.
<P>
10.1.6.7 <U>Computing and Constructing a Summary Threat Matrix.</U> Describe
how the completed Threat logic Tree will be analyzed and system security
effectiveness will be computed. Include the method used to document the results.
<P>
10.1.6.8 <U>Integrating Security Functions with the System Engineering
Process.</U> Describe the process by which security inputs will be applied
to system functional design, requirements allocation, trade-off study, and
communications, electronic, and interface (CEI) design specification processes.
<P>
10.1.6.9 <U>Security System Synthesis and Evaluation.</U> Describe the method
by which security system hardware, facilities, procedures, and personnel
subsystems will be synthesized and evaluated. Specify the scope and type
of research to be conducted of existing material. Include techniques to evaluate
their applicability to security requirements.
<P>
10.1.6.10 <U>Test and Evaluation.</U> Describe the process use to identify
security test requirements and proposed test methods.
<P>
10.1.6.11 <U>Configuration Control.</U> Describe the manner in which system
security engineering efforts will be integrated with system configuration
control activities. Explain how the proposed changes to the system will affect
security efforts.
<P>
10.1.6.12 <U>Relationships with Other Contractors.</U> Outline the methods
by which system security engineering efforts of associate system contractors,
subcontractors, and vendors will be integrated within the System Security
Engineering Program.
<P>
10.1.6.13 <U>System Installation and Checkout.</U> Describe how the System
Security Engineering and Industrial and Product Security efforts will be
coordinated to ensure no security vulnerability is created during system
installation and checkout.
<P>
10.1.6.14 <U>Product Security.</U> Describe how the major system
components/products will be secured at the contractor's assembly plants.
Explain the security manpower, facilities, equipment, and procedures to be
used. Include the security interface with associate contractors, subcontractors,
and vendors.
</BLOCKQUOTE>
</BLOCKQUOTE>
<P>
Page <U>3</U> of <U>3</U> Pages
<P>
<HR>
<P>
<STRONG>Data Item Description </STRONG>
<P>
1. TITLE Preliminary System Security Concept
<P>
2. Identification Number DI-MISC-80840
<P>
3. Description/Purpose
<BLOCKQUOTE>
3.1 This Data Item Description outlines the format and content of the PSSC.
The PSSC is a document which cites security concepts and requirements relative
to a particular system. It is prepared by the contractor to provide the
Government with preliminary description of security requirements and resources.
</BLOCKQUOTE>
<P>
4. Approval Date 890605
<P>
5. OPR AF 10
<P>
6a. DTIC Applicable x
<P>
6b. GDEP Applicable
<P>
7. Application/Interrelationship
<BLOCKQUOTE>
7.1 This Data Item Description contains the format and content preparation
instructions for data resulting from the work task described by 5.3.1.3 of
MIL-STD-1785.
<P>
7.2 Security Vulnerability Analysis, DID DI-MISC-80841, is used with this
Data Item Description when paragraphs 10.1.5.1 through 10.1.5.5 are cited.
<P>
7.3 Defense Technical Information Center (DTIC), Cameron Station, Alexandria
VA 22314-6100.
</BLOCKQUOTE>
<P>
8. Approval Limitation
<P>
9a. Applicable Forms
<P>
9b. AMSC Number F4371
<P>
10. Preparation Instructions (Continued on Page 2)
<P>
11. Distribution Statement DISTRIBUTION STATEMENT A: Approved for public
release; distribution is unlimited.
<P>
Page <U>1</U> of <U>5</U> Pages
<P>
<HR>
<P>
Block 10. Preparation Instructions (Continued)
<BLOCKQUOTE>
10.1 The Preliminary System Security Concept (PSSC) shall include the following:
<BLOCKQUOTE>
10.1.1 <U>Program Data.</U>
<BLOCKQUOTE>
10.1.1.1 <U>Title.</U> Include the complete PSSC title.
<P>
10.1.1.2 <U>Submitting Agency.</U> List the name and address of the contract
agency submitting the report and the name and telephone number of a project
officer or point of contact.
<P>
10.1.1.3 <U>Contract Citation.</U> Identify the contract number and date
as listed by the government.
<P>
10.1.1.4 <U>Security Tasks.</U> Briefly describe major security tasks cited
in the statement of work and related contract documents.
<P>
10.1.1.5 <U>Distribution.</U> List the names and addresses of Government
and contract agencies receiving copies of this concept. If necessary, list
them in an appendix and make reference to it here.
</BLOCKQUOTE>
<P>
10.1.2 <U>System Concept.</U>
<BLOCKQUOTE>
10.1.2.1 <U>Description.</U> Briefly describe the system and its major
components. Cite separate configurations for Initial Operational Capability
(IOC) and Full Operational Capability (FOC), if different.
<P>
10.1.2.2 <U>Performance requirements.</U> Cite the major performance and
deployment criteria in the applicable statements of work and other related
contract documents which affect security.
<P>
10.1.2.3 <U>Reliability and maintainability.</U> Identify security issues
affecting system reliability, logistics reliability, availability, and
maintainability.
<P>
10.1.2.4 <U>System Survivability.</U> Show self-protection capabilities or
subsystem designs which may enhance security. (examples include devices against
tampering and spoofing, chemical or biological radiation hardness, nuclear
hardness, nuclear or non-nuclear electromagnetic pulse hardness, and the
use of passive detection technology.)
<P>
10.1.2.5 <U>Preplanned Product Improvements (P</U>3<U>I).</U> Describe provisions
or security implications for subsystem growth or improvements such as
modifications and upgrades.
</BLOCKQUOTE>
<P>
10.1.3 <U>Security Subsystem Employment Data.</U>
<BLOCKQUOTE>
10.1.3.1 <U>General employment description.</U> Describe how, where, when,
and what security subsystems will be used and how they will be integrated
with the system(s) they support.
<P>
10.1.3.2 <U>Command and control structure.</U> Describe the command and control
data that must be exchanged. Explain how security subsystems will it integrated
into the command and control structure projected to exist when it is deployed.
</BLOCKQUOTE>
</BLOCKQUOTE>
</BLOCKQUOTE>
<P ALIGN=Left>
(Continued on Page 3)
<P>
Page <U>2 </U> of <U>5 </U> Pages
<P>
<HR>
<P>
Block 10. Preparation Instructions (Continued)
<BLOCKQUOTE>
<BLOCKQUOTE>
<BLOCKQUOTE>
10.1.3.3. <U>Information systems.</U> Identify the information that must
be exchanged between this subsystem other systems, subsystems, or components.
Cite the expected length of each communications link, anticipated flow rate
across each link, required availability of each link, etc.
<P>
10.1.3.4 <U>Security subsystem standardization, interoperability, and
commonalty.</U> Describe requirements for joint service interface, NATO
cross-servicing and interoperability with existing systems and subsystems.
Identify procedural and technical interface standards incorporated in subsystem
design.
<P>
10.1.3.5 <U>Operational environment.</U> Describe climatic and atmospheric
environmental effects and considerations. If applicable, define the chemical
and biological environment in which equipment must function.
</BLOCKQUOTE>
<P>
10.1.4 <U>Security Subsystem Support.</U>
<BLOCKQUOTE>
10.1.4.1 <U>Maintenance planning.</U> Outline the actions, support, and
documentation necessary to establish maintenance concepts and requirements.
Include maintenance tasks to be accomplished for on- and off-equipment
maintenance; interservice, organic, and contractor mix, workloads, and time
phasing for depot maintenance. Explain the management strategies for selecting
and integrating contractor and government furnished equipment.
<P>
10.1.4.2 <U>Manpower and personnel.</U> Outline the projected manpower
requirements envisioned to support this subsystem(s). Include type of specialty
codes and skill levels required, time phased reporting, etc.
<P>
10.1.4.3 <U>Supply Support.</U> Show the proposed approach for provisioning
initial support and acquiring, distributing, and replenishing inventory spares
and repair parts.
<P>
10.1.4.4 <U>Support equipment.</U> Identify equipment required to support
this subsystem(s). Include ground handling and maintenance equipment, tools,
metrology and calibration equipment, and related computer hardware and software.
© 2022 Packet Storm. All rights reserved.
%7Cutmcsr%3D(direct)%7Cutmcmd%3D(none)){kind=small}
Follow us on Twitter
Follow us on Facebook
Subscribe to an RSS Feed