Successful implementation of secure systems depends on defining security
requirements early. All ITSEC disciplines (COMPUSEC, COMSEC, EMSEC,
physical, and personnel) must be considered in the requirements definition
process to arrive at a complete set of requirements. This permits the
program manager, the user representative, and the DAA to evaluate cost
versus risk tradeoffs successfully and assign security requirement implementation
to hardware or software components, or procedures.
E7.3.2. While all systems
share a common set of minimum security requirements, some systems will
inherit additional requirements based on their mission and function.
Additionally, some systems, based on mission and function, may need a higher
level of assurance that security requirements have been implemented
successfully. That is a basic distinction among the classes.
E7.3.3. When a system is
identified with a class of similar systems, the class repository may be
accessed for a common set of ITSEC requirements. This eliminates the need
for the program manager of each system to develop the security requirements
independently from myriad
security instructions and directives and forward them to the DAA for
approval. The question then remains, how will these requirement sets be
E7.3.4. The approach is twofold.
E184.108.40.206. Existing systems will be analyzed to
determine their classes. Those systems that have been accredited may be
used as "models" for others of the class. Their ITSEC requirements,
high-level architectures and approved solutions may be documented in a
common repository. When a new system is required in that class, or a
legacy system needs to be upgraded, the class repository will provide
E220.127.116.11. An independent requirements definition
process needs to collect all ITSEC requirements into a common database.
Then the requirements need to be reviewed to remove conflicts and
duplications to produce a clean, and complete set of requirements. Those
requirements may be allocated to each security class. The result will be
an agreed on consistent set of security requirements for each class.
Again, users of that class will have the economy of a readily obtainable