23.11.2014 Views

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

SHOW MORE
SHOW LESS

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

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!