Page 1 A Guide to the Procurement of Trusted Systems: An ... - csirt
Page 1 A Guide to the Procurement of Trusted Systems: An ... - csirt
Page 1 A Guide to the Procurement of Trusted Systems: An ... - csirt
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
<strong>the</strong> source language, although <strong>the</strong> function performed will be correctly done.<br />
Linkers (sometimes called "Linkage Edi<strong>to</strong>rs") can also be a security concern,<br />
since access <strong>to</strong> unintended data areas can Occur through "external reference"<br />
directives. Finally, some languages incorporate what is known as "run-time<br />
packages," chiefly <strong>to</strong> perform input-output operations. Run-time packages<br />
must be included within <strong>the</strong> security-relevant boundary, especially at <strong>the</strong><br />
higher TCB divisions/classes.<br />
3.3.2 THE PROCESS<br />
Figure 3-2 illustrates <strong>the</strong> s<strong>of</strong>tware development process in terms <strong>of</strong><br />
documentation required. Different terms are used for some <strong>of</strong> <strong>the</strong> design<br />
documents, but <strong>the</strong> document requirements are similar, if not identical. For<br />
example, <strong>the</strong> terms Functional Description, "A" Specification, and System<br />
Specification, are usually used interchangeably. Note that <strong>the</strong> process is<br />
iterative, and flows from very general <strong>to</strong>p-level policy and capabilities<br />
requirements statements, down <strong>to</strong> very precise implementation details.<br />
Security Policy<br />
*<br />
Security Policy Model<br />
*<br />
Functional Description<br />
("A" Specifications<br />
Descriptive Top Level Specification (DTLS)<br />
Formal Top Level Specification (FTLS, A1 only))<br />
*<br />
System/Subsystem Specifications<br />
("B" Specification)<br />
*<br />
Unit Specifications<br />
("C" Specification)<br />
Figure 3-2 Security Protection in <strong>the</strong> S<strong>of</strong>tware Development Process<br />
3.3.3 MANAGING SOFTWARE DEVELOPMENT<br />
As noted above, <strong>the</strong> key <strong>to</strong> success with s<strong>of</strong>tware is structure and<br />
discipline. Some <strong>of</strong> <strong>the</strong> specific success fac<strong>to</strong>rs follow:<br />
3.3.3.1 DESIGN DOCUMENTATION<br />
Documentation must start from <strong>the</strong> initial statement <strong>of</strong> requirements and<br />
continue through <strong>to</strong> <strong>the</strong> details <strong>of</strong> implementing, operating, and maintaining<br />
<strong>the</strong> system. The root is in <strong>the</strong> initial statement <strong>of</strong> requirements.<br />
3.3.3.1.1 SECURITY POLICY<br />
<strong>An</strong> explicit statement <strong>of</strong> <strong>the</strong> security policy should be enforced by <strong>the</strong> AS. The<br />
policy should be documented in <strong>the</strong> specification (requirements) section <strong>of</strong> <strong>the</strong><br />
RFP, and should clearly state <strong>the</strong> security enforcement rules by which <strong>the</strong><br />
system will operate.<br />
3.3.3.1.2 MODEL<br />
<strong>Page</strong> 42