3. Knowledge Base Overview

This knowledge base overview discusses common features of the knowledge base forms, reports, and queries.  Detailed table descriptions are given in Section 4

3.1 Forms

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



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.
(See Section 4.4.)

Write a Domain Knowledge Observation Report on the current record.
(See Section 4.6.1, Appendix A.4.3.)

 Table 3-2:  Edit-Related Buttons




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.)

3.2 Reports

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 (on the MS Access Print Preview menu.

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



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.


Arranged by type of environment statement. The .html version includes the results of the "See Also" query described in Section 4.4.3.


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
DKORs by Date
DKORs by Table and Record ID

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.

3.3 Queries

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.