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
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
Output must be marked with a plain language version <strong>of</strong> <strong>the</strong> object's<br />
sensitivity level (e.g., English language security classification banner at<br />
<strong>the</strong> <strong>to</strong>p and bot<strong>to</strong>m <strong>of</strong> each page).<br />
3.2.2.2.1.7 Manda<strong>to</strong>ry Access Control (Class B1 and above):<br />
From Manda<strong>to</strong>ry Access Control (MAC) rules, subjects (e.g., users, programs)<br />
are allowed access (e.g., read, write, change, delete) <strong>to</strong> objects (e.g.,<br />
data). A subject's clearance level must always be consistent with an<br />
object's sensitivity level. Thus, subjects may read from an area (e.g., main<br />
memory) with an equal or lesser sensitivity level, and may write <strong>to</strong> an area<br />
with an equal or greater sensitivity level.<br />
3.2.2.2.1.8 Subject Sensitivity Labels (Class B2 and above):<br />
During an interactive session, <strong>the</strong> TCB must keep <strong>the</strong> terminal user informed <strong>of</strong><br />
changes in <strong>the</strong> "current working security level." Terminal users may request<br />
a display <strong>of</strong> <strong>the</strong> complete sensitivity label for processes <strong>the</strong>y are using.<br />
3.2.2.2.1.9 Device Labels (Class B2 and above):<br />
The TCB must keep track <strong>of</strong> <strong>the</strong> minimum and maximum security level<br />
assignments <strong>of</strong> all physically attached devices (e.g,., terminals, printers).<br />
These assignments are <strong>of</strong>ten called "classmarks".<br />
3.2.2.2.2 ACCOUNTABILITY<br />
Accountability is <strong>the</strong> ability <strong>to</strong> trace actions affecting security <strong>to</strong> <strong>the</strong><br />
responsible party. This feature ensures <strong>the</strong> user's dialogue is with <strong>the</strong> TCB<br />
and not with a masquerading program (e.g., during log-in).<br />
3.2.2.2.2.1 Identification and Au<strong>the</strong>ntication (all classes):<br />
Users must identify <strong>the</strong>mselves (e.g., provide user-identifications) <strong>to</strong> <strong>the</strong><br />
system and <strong>the</strong> TCB must au<strong>the</strong>nticate <strong>the</strong> user's identity (e.g., passwords).<br />
3.2.2.2.2.2 Audit (Class C2 and above):<br />
The TCB must record all security- relevant events (e.g., changes <strong>to</strong> device<br />
classmarks) in a TCB-protected area called <strong>the</strong> "audit trail."<br />
3.2.2.2.2.3 <strong>Trusted</strong> Path (Class B2 and above):<br />
The TCB must provide a means <strong>to</strong> identify itself clearly <strong>to</strong> <strong>the</strong> user.<br />
3.2.2.2.3 ASSURANCE<br />
Assurance provides <strong>the</strong> steps necessary <strong>to</strong> demonstrate that <strong>the</strong> security policy<br />
has been correctly implemented.<br />
3.2.2.2.3.1 System Architecture (all classes):<br />
The system architecture must separate TCB processes (e.g., reference<br />
moni<strong>to</strong>r) from user processes (e.g., application programs). The system<br />
<strong>Page</strong> 38