This knowledge base overview discusses common features of the knowledge base forms, reports, and queries. Detailed table descriptions are given in Section 4.
This subsection presents common features of the various forms, almost all of which are immediately available from the Main Menu. Features that are specific to individual forms tend to be associated with the semantics of their underlying tables and are thus deferred to Section 4.
The forms all have navigation buttons that help to move up or down in the hierarchy of requirement concepts. For example, the top of the Detailed Attacks form has the following buttons:
Figure 3-1. Title and Primary Navigation Buttons for a Sample Form
The two buttons in the upper right of the figure allow one to move up to General Threats or to Links showing how General Threats map to Detailed Attacks. Likewise, the two buttons on the lower right allow one to move down to attack-countering Objectives or to Links showing how the current Attack may be countered.
The overall linking structure of the forms suggests the semantics of the knowledge
base. Links involving forms related to environment statements are summarized
in Figures 3-2, 3-3, and 3-4. Some form names have been truncated for
the sake of readability. The Main Menu and DKORs forms are not shown,
as they link to almost everything. Some links, those with black solid-fill
arrowheads (
), not only open the appropriate
form but also go to the most relevant record.
Figure 3-2. Links Among Assumption-Related Forms
Figure
3-3. Links Among
Threat-Related Forms
Figure 3-4. Links Among Policy-Related Forms
Finally, links for forms relating to Security Objectives and CC Components are shown in Figure 3-5. As indicated in the figure, the Objective/Component Mapping links Security Objectives to both CC Components and user-defined CC-Extending Components. Both kinds of Components fit into a hierarchy of Classes, Families, Components, and Elements. However, the knowledge base contains only summary information on CC Components, as the best source of information for these is the CC itself.
Figure 3-5. Links Among Objective-Related Forms
Form buttons for viewing a given table are explained in Table
3-1. Buttons for editing a given record are explained in
Table 3-2.
Table 3-1: Navigation and Review within a Given Table
Button |
Purpose |
|
Go to first record (at bottom left of form). |
|
Go to previous record. |
|
Go to any given record by typing in the record number, e.g., # 314. |
|
Go to next record. |
|
Go to last record. |
|
Sort on the field that currently has the focus (i.e., has been highlighted by clicking with the mouse). |
|
Close the form, saving any changes that may have been made. |
|
Same as the Stop button |
|
Go to the Main Menu form. |
|
View taxonomic attributes of the current
environment statement. |
|
Write a Domain Knowledge Observation Report
on the current record. |
Table 3-2: Edit-Related Buttons
Button |
Purpose |
|
Add a new record to the form's underlying table. |
|
Delete the current record. Works whether or not the current record has been saved. |
|
Unlock the form for editing. Forms that contain selection lists are initially locked to prevent accidental modification. |
|
In some forms, if the underlying table changes, the new values may not show up until the form is manually refreshed. This button does the same thing as the Refresh command on the MS Access Records menu. |
|
Undo recent changes to the current record. That is, undo all changes to the current record since it was last saved. |
|
Save current record. Records are saved automatically whenever the current record changes or the form closes. However, if several forms are open at the same time, changes in one form do not propagate to others until they are saved. This button serves the same purpose as the Save Record command on the MS Access Records menu. |
|
Run form-specific integrity checks. Most integrity checks are performed automatically whenever data changes. Some, however, must be done manually after the fact. When the check is performed, a summary of the results is placed in the Integrity Check Log table. Each integrity-check button has a "screen tip" that tells more about that particular check. (To view the tip, position the mouse over the check button, and the tip will appear.) |
The Reports are available in both .html and .rtf formats. The .html format may be preferable for online users because of its many hyperlinks. You can click here to view the Index file for the HTML reports. (Alternatively, you can open your CC PKB folder and double click on the CC PKB Reports "shortcut" file.) If wish to print out the .html version of a report, we suggest using a recent Web browser, e.g., Version 4.72 or later of either Netscape Communicator or Internet Explorer.
To view the reports in a form that can be converted to .rtf format, select
the Reports tab on the main MS Access Database
menu. Clicking on any of the report names will generate the report from
its underlying table or query. Then, to save the report in .rtf format
and view it in MS Word, click the OfficeLinks button 
)
To generate and view HTML reports from the knowledge base, click on the HTML button on the main menu. To generate a new set of HTML reports, fill in a name for the Reports folder, and press the button named Create HTML Reports and Index. After the reports are created, the name of this button changes to Update HTML Reports, and a View HTML Reports button appears that will take you to the new reports folder.
There is a report for each major table in the knowledge base. The reports and some comments on their content are given in Table 3-3.
Table 3-3: Reports
|
Report Name |
Comments |
|
Prompts |
Presents the Prompts Table. The .html version enumerates the prompts hierarchy in depth-first order, starting with the Root Prompt. |
|
Threat Categories |
Includes mapping to General Threats. |
|
Policy Categories |
Includes mapping to General Policy Statements. |
|
Assumption Categories |
Includes mapping to General Assumptions. |
|
General Threats |
Includes mapping to Detailed Attacks. |
|
General Policies |
Includes mapping to Detailed Policy Statements. |
|
General Assumptions |
Presents the General Assumptions table. |
|
Detailed Attacks |
Includes mapping to attack-countering Objectives. |
|
Detailed Policy Statements |
Includes mapping to policy-supporting Objectives. |
|
Attributes |
Arranged by type of environment statement. The .html version includes the results of the "See Also" query described in Section 4.4.3. |
|
Objectives |
Includes mapping to implementing Components. |
|
CC-Extending Classes
|
Includes member CC-Extending
Families.
|
|
CC-Extending Families |
Includes member Components, link to containing Class. |
|
CC-Extending Components |
Includes Element Descriptions, link to containing Family. |
|
DKORs by Author |
Observation Reports (DKORs) arranged in various orders. |
Each of the above reports prints out all fields from the indicated table. If there is an associated mapping table, its contents are printed out as well. Taken together, these reports give a complete presentation of the knowledge base security information.
To view a query, select the Queries tab on the main MS Access Database menu and click on the query. To see the query itself, click Design, or to view the record set defined by the query, click Open.
Some queries in the knowledge base are used to combine similar tables. An example involves the All Components query, which is used to combine the CC Components and CC-Extending Components tables shown in Figure 3-5. This and similar queries are presented in Sections 4.5.9, 4.5.10, and 4.5.11.
Other queries are used to compose mapping tables in order to provide information for the CC Toolbox. These are described in Sections 4.2.10 and 4.2.11.
Still other queries have been formulated for use in enforcing knowledge base integrity. See Appendix A regarding their use.
Finally, two queries are not used directly by forms or reports, but may be of use in tracking knowledge base development. The All Identifiers and Lexicon queries list each knowledge base identifier, along with additional information to help with identification. We used these during database development to report identifier names, so that two or more developers wouldn't provide incompatible uses for the same identifier.
or 
or 
or 