Appendix A. Knowledge Base Integrity

This appendix provides a detailed description of underlying data structures, as well as other information needed for maintaining the knowledge base.  It is important that the meaning of the knowledge base is maintained and that inconsistencies not be introduced between one part and another.

The data elements of each table have specific meaning, however the true meaning of this knowledge base comes in the relationships and mappings between the tables.  One example is the relationship between the threat category table and the general threat table:  knowing which general threats belong to a given threat category is an important part of the semantics of that category.  Another example is the relationship between the general threat table and the detailed attack table:  detailed attacks play a key role in understanding how a given general threat may be carried out and thus how it may be countered.  Therefore, this section explains how the knowledge base addresses semantic integrity (maintaining the meaning portrayed in the relationships).

Appendix A.1 explains how, for the majority of the knowledge base, the integrity of the relationships is maintained via Access methodology.  However, there are some relationships that require special treatment and needed to be handled differently.  These differences are explained in Appendices A.2, A.3, and A.4, and present additional integrity checks required for maintaining knowledge base consistency.  Finally, Appendix A.5 provides additional software documentation not directly involved in maintaining semantic integrity. 

A.1 Enforcing Referential Integrity via Access

Integrity of the relationships among tables is handled primarily by the Relationships mechanism found on the Access Tools menu.  (For example, see Figure A-1 below.)  In the case of simple tables and mapping tables, we have the following.  In this diagram the meaning of the infinity symbol () on a link is that there can be zero or more (a maximum of ) many mapping records that reference one (1) table key field via the given link. This is a "one to many" relationship.  For example there is a "one to many" relationship from the General Threat table to the Threat/Attack Mapping table.  There is a similar relationship with the Detailed Attacks table to the Threat/Attack Mapping table.  These two relationships to the mapping table essentially create a "many to many" relationship between the Threat Category and General Threat tables. 

Figure A-1:  Relationship Example

The referential integrity, as well as maintaining updates across the tables, is enforced with the Access mechanism shown in Figure A-2 below.  Whenever an identifier in a simple table changes or is deleted, the change automatically propagates to the corresponding mapping table — with a few exceptions.  The exceptions happen when a link may point to any one of several different tables. 

Figure A-2:  Referential Integrity

A.2 Propagating References That May Point to Several Different Tables

Some references cannot be checked in Access.  The range of the Threat Category/G-Threat Mapping table is given by the Threats and Categories query.  The range of the Objective/Component Mapping table is given by the All Components query.  Access will not automatically check referential integrity in these cases.  To compensate for this, the corresponding simple-table forms contain private procedure, named Form_BeforeUpdate, that check to see if the identifier has changed, and in that case, propagate the change to all affected tables.

Propagation of the changes is accomplished with the help of the following procedures from the FormHandler module:

PropagateUpdate(TableName$, FieldName$, OldValue$, NewValue$)
PropagateUpdateInPrompts(OldEffectID$, NewEffectID$)

There are no routines to automatically propagate deletions, and you can certainly edit the tables directly bypassing the above integrity procedures.  In any case, the following table lists key-field name changes that are propagated in the above fashion:

Table A-1:  Propagating Key Field Name Changes

Notice that although the DKORs table references key fields from other tables, there is currently no method for propagating changes into the DKORs.  Furthermore, any DKOR that recommends changing an identifier name should reference both the old and the new values — otherwise it will be unreadable after the name change.

Currently, there is no automated effort to update general text fields when identifiers change.  A nice addition to the knowledge base would be to have the BeforeUpdate procedures maintain a log of name changes.

A.3 Integrity Checks for Mapping Tables

The Threat Categories/GThreatMapping form contains an integrity-check button that calls the procedure

IntegrityChecks.DomainAndRange "Threat Categories," "General Threats", _
    "Threat Category/G-Threat Mapping"

This performs the following checks:

Each Threat Category is a source link in the mapping table.
Each General Threat is a target link in the mapping table.
The source of each mapping link is a Threat Category.
The target of each link is either a Threat Category or General Threat, but not both.

Similar checks are made for Assumption Category Mappings and for Policy Category Mappings.

A.4 Integrity for Attributes, Prompts, and DKORs

A.4.1 Attributes

Attributes of environment statements have been constrained to a machine-processable taxonomy, with one exception, namely threat actions.  The taxonomy was designed for classifying threats, but has since been adapted to Policies (i.e., the threat that a policy may not be met) and Assumptions (which might be false).

For the most part, these constraints are accomplished by linking attribute fields to specially designed scalar tables.  In the knowledge base, these are the ones whose names begin with TXN_. 

Figure A-3:  Attribute Relationships

As can be seen from the above diagram, Record IDs are not automatically constrained by the Access referential integrity mechanism.  The record ID can be drawn from any of the five supported types of environment statements.  The types themselves are listed in the table TXN_Env_Aspects, and each Attributes record must specify one of these types. 

Once the environment type, or Aspect as its called in the CC, has been chosen, the Record ID must be drawn from the simple table of the named type.  This is enforced by routines associated with the form.  If the environment aspect is modified, the routine CtrlEnvAspect_AfterUpdate() calls the routine Form_Current and clears the Record_ID field. 

The private Form_Current routine is called whenever a new record is selected.  It does the following:

• Associate the simple table indicated by the Env_Aspect with the Record_ID combo box on the form, ensuring that every selected Record_ID reference will be valid.
• Ensure that displayed agent attributes are relevant to the current agent type (so inanimate agents aren't credited with Sophistication, Attitude, or Motive).
• Display the Security Functions Attribute only if Security Protection is one of the possible Loss Types.
• Unlock the form, if you have just selected a new record.

Of course, these checks can be bypassed by editing the Attributes table directly.  To ensure that nothing has gone wrong, there is an integrity-check button on the Attributes form that checks validity of the following assertions:

• Every Record_ID field in the Attribute table is defined in the table indicated by the Env_Aspect field.
• Every General environment statement has an associated Attribute record.

In principle, it would be advantageous for every Attack and Detailed Policy Statement to also have an associated set of attributes, but the knowledge base has not evolved to this point, so the integrity-check button omits these checks.

Finally, the form suggests that the Security Functions attribute be drawn from the set of all CC classes — including CC-Extended classes.  This check is not enforced, and ideally, this field could be extended to accommodate any set of CC Classes.

A.4.2 Prompts

The Prompts table combines and augments the hierarchies apparent in the Mapping tables that associate categories of environment statements with environment statements of the same kind.  The hierarchical structure is captured explicitly by the ChildList field.  The intended semantics is that the child lists define a hierarchy (specifically, a directed acyclic graph).  This means that each prompt is a node in a graph with a well-defined rank, where rank is defined as the maximum number of parent-child links along any path from the RootPrompt to that prompt.  Thus, the RootPrompt has rank 0, the Goto Selected Child button on the Prompts form always leads to a prompt of higher rank, and the First Parent button always leads to a prompt of smaller rank.

The Prompts form contains five different integrity checks.  These, together with the integrity checks associated with the mapping forms, provide additional assurance, as will be explained below.

Prompt Hierarchy Check

The first integrity-check button on the Prompts form checks to see that the child lists do indeed lead to a well-defined rank function.  Specifically, it computes prompt ranks and checks the validity of the following assertions:

• Each child in each child list is a defined Prompt_ID in the Prompts table.
• Each child has a greater rank than its parent(s), so no prompt is its own ancestor.
• Each prompt with a nonempty child list has just one nontrivial Effect (except for the RootPrompt, which has no associated environment statement or category).

Has Parent Check

The second integrity-check button checks that RootPrompt is the only node in the hierarchy that doesn't have a parent.

Answers-Match-Effects Check

The third integrity-check button checks that each AnswerList has the same length as the corresponding EffectList.

Child-Link Definition Check

The fourth integrity-check button ensures consistency between the Prompts table and the Category mapping tables.  Specifically, for each prompt, it checks that if the ChildList is nonempty, then the prompt has just one nontrivial Effect — call this the Parent Effect.  Each child prompt also has one or more named effects (since it is not the RootPrompt).  Each such child effect must be defined in the appropriate environment table, and each parent-effect/child-effect pair must occur in the appropriate mapping table.

Child-Link Completeness Check

Finally, the fifth integrity-check button checks that each link in a Category/Env-Stmt mapping table is represented via a parent-child link in the Prompts table.  Specifically, it checks that the source category is the unique Effect associated with some prompt and that the target statement or category is an Effect associated with some prompt on its ChildList. 

Additional Integrity-Related Routines

The AnswerList, EffectList, and ChildList must, of course be lists.  To represent these as selectable lists on the Prompts form, the private Form_Current procedure uses these lists as the row source for associated list boxes.  If you have selected a new record, Form_Current also unlocks the form.  The unlocking routine replaces the list boxes with editable text boxes.

As with several other tables, there is a private Form_BeforeUpdate procedure that propagates changes to Record_IDs throughout the Prompt form's ChildLists.

Additional Properties that Follow from the Integrity Checks

Several interesting checks aren't implemented because they will hold, provided the knowledge base passes all of the above integrity checks.  A brief listing and verification of these properties follows.

Effect Definition.  Each nontrivial Prompt Effect is an environment statement or category (but not both). 

Proof.  RootPrompt has no effects (by assumption).  Each other Prompt is a child of another prompt (by the Has-Parent check).  Hence, this child is the target in a mapping link (by the Child-Link Definition check).  Hence, it is a category or environment statement (by the integrity checks for mapping tables). 

Statement Coverage:  Each environment statement and category is referenced as the effect of at least one prompt. 

Proof.  Each such statement or category is the source or target in a mapping table (by the integrity checks for mapping tables).  Each such link is represented in the Prompts table (by the Child-Link Completeness check).  Hence, that source or target occurs in the Prompts table.

Category Hierarchies:  Each of the Category mapping tables determines a well-defined hierarchy. 

Proof.  The graph formed by the links in each table is a sub-graph of the Prompts hierarchy (by Child-Link Completeness).  Hence, each such graph is itself a well-defined hierarchy (by the Prompt Hierarchy check). 

A.4.3 DKORs

Like the Attributes table, the Record_IDs in the DKORs form may come from more than one table, in fact, any table at all.  The Table field on the DKORs form uses the TableOfTables table to get its list of tables.  The Form_Current procedure then updates the Row Source for the Record_ID field, in the same fashion as the Attributes table.

If you have selected a new DKORs record (as when the DKORs form is opened via the DKOR button on another form), Form_Current unlocks the form and sets the Author field to the current default, which just happens to be stored in the AsteriskTable table.

If you change the DKOR author, the procedure AuthorBox_AfterUpdate automatically changes the default author, decreasing the chance of a DKOR being filled out with the wrong author. 

Initially, the default author in the AsteriskTable should be ???.  The Form_Open procedure for the DKORs form checks for this value and, if found requires the author to supply a better author name.  It is always possible to reset the default author to ???, either by editing the AsteriskTable or by changing the author on a new DKORs record to ???, hitting the Undo button and closing the form.

A.5 Software Support Modules

Supporting software modules for the knowledge base facilitate opening an arbitrary form to a specified record, making log tables, performing set operations, and building the property sheets needed to transport the knowledge base to the CC Toolbox.

A.5.1 Opening a Form at a Particular Record

The knowledge base uses three different methods for opening a form at a given record.  The more common method is accomplished via subroutine calls of the form
FormHandler.OpenAtRecord TableID$, RecordID$.  The OpenAtRecord routine performs the following activities:

• Look up TableID$ (which may be either a table or query) in the TableOfTables Table to find the name of the corresponding form and open the form
• Learns the name of the table's first key field using the FormHandler.GetKeyFields and then go to the record named by RecordID$, if that exists.

A minor variant of this method is to create a new record if the desired record isn't found.  This is done by the procedure FormHandler.FindOrAddRecord TableID$, RecordID$.  When using this method, it is important to save the current record first.  Otherwise, FindOrAddRecord will use the altered name to create a new record in the target table!

The third method, which is used for progressing down the hierarchy of CC-Extending forms, is to open the form with an applied filter that hides irrelevant records.  You can always access the entire table by releasing the filter button ().
 

A.5.2 Log Tables

The routines of the Logs module are used by the integrity checks and by the Property Sheet parser.  Table A-2 gives the format of each field of the Log table.

Table A-2:  Log Table

OpenLog(Log, LogName$, CallingID$) opens the named Log, creating the log table if necessary.  LogName$ is typically Integrity Check Log.  CallingId$ is normally the name of the Error-checking routine.  OpenLog clears all entries in the log associated with CallingId$, creates a new initial entry for CallingID$, and zeros the error count, which is stored in the AsteriskTable.

LogEntry(log, Env_Aspect$, RecordID$, AttributeID$, Message$, cmt) fills in an entry.  Env_Aspect$ is typically the table or sub-table being checked.  RecordID$ is the record where the problem is. AttributeID$ is normally the name of the error-checking routine.  Message$ and cmt are the logged error messages; typically cmt = 0.

CloseLog(Log As Recordset, CallingId$, Threshold As Integer) presents a summary message telling how many errors were found.  Log and CallingId$ are as for OpenLog.  Threshold is typically 0 (zero tolerance for errors).
 

 A.5.3 Set Manipulation

These manipulate ordered lists, which are represented as character strings.  The list separator is ", ", but there is limited recovery from the use of "," as the list separator.  The empty string implements the empty set. 

Add_Item(ItemList$, Item$) adds Item$ to the list, if the item isn't already in the list.  The Item$ must not be the empty string and must not contain ",".  Add_Item correctly handles the case where one item is a sub-string of another.

Remove_Item(ItemList$, Item$) removes Item$ from ItemList$, if the item is in the list.

Choose_First(ItemList$, Item$) finds the first item in the list and sets Item$ to that value.  If ItemList$ is empty, then Item$ is empty on exit.

A.5.4 Property Sheets

Appendix B.1 provides instructions on how to generate property sheets for the CC ToolBox and should be read first.  This subsection explains the underlying requirements for property sheets, documents the BuildPropertySheet module, and briefly talks about the reverse problem of recreating a knowledge base from property sheets.

Java-Defined Property Sheet Format

Property sheets, as defined in Java, provide a way to represent hash tables as text files.  Each key-value pair is represented as a text line of the form <key><separator><value>.  End of line characters may be embedded within the pair by preceding them with "\".  Leading spaces on each line are ignored.  The separator can be padded with blanks.  This knowledge base uses "=" as the separator.  The CC ToolBox assumes that key values are in HTML format, so ends of lines have to be marked with the <BR> HTML tag.  The BuildPropertySheet.PrintProperty routine formats key-value pairs into property-sheet format.

As explained below, the CC ToolBox property sheets contain nine types of key-value pairs. 

Work List Properties

Work list properties provide a summary of the overall contents of the property sheet.  The DumpAllTables routine produces these last.  There are six work lists, as described in the following table.  (In all cases, list elements are separated by commas.)  The last Extensions list is dumped only if the ShowCCExtensions flag is True.

Table A-3:  Work list Property Field Values

Category Prompt Properties

The Category Prompt properties hold the contents of the Prompts table, and indirectly, the contents of the Category mapping tables.  They have the following forms, where <PromptID> is the key field of any record in the Prompts table.

Table A-4:  Category Prompt Property Field Values

Category Data Properties

The definitions of Threat, Policy, and Assumption Categories are taken directly from the corresponding tables.  Each key, <CatID>, is the identifier of a Threat, Policy, or Assumption Category, prefixed with TC., PC., or AC., respectively.  The field designations in the following table are approximate, as corresponding fields for the three types of categories have slightly different names.

Table A-5:  Category Data Property Field Values

Policy, Threat, and Assumption Properties

These capture information from General Threats, Policies, and Assumptions tables.  Each key, <EnvStmtID>, is the identifier of a General Threat, Policy, or Assumption, prefixed with T., P., or A., respectively.  The field designations in the following table are approximate, as corresponding fields for the three types of environment statements have slightly different names.  Moreover, the last two entries require further explanation. 

The Examples list for a given general environment statement is the list of all Attacks or Detailed Policies that it is associated with in the mapping tables that take General Threats to Detailed Attacks and General Policy Statements to Detailed Policy Statements.

The Objectives list for a given general environment statement is the list of all objectives that may be associated with a given general environment statement through consideration of attacks or detailed policies and their associated objectives.  Thus, these lists are determined by the two queries, Threat/Objective Mapping Query and General Policy/Objective Mapping Query.

Table A-6:  Policy, Threat, and Assumption Property Field Values

Policy, Threat, and Assumption Attributes

The format for attribute properties is similar to the above, but with the attributes drawn from the Attributes table.  The content of individual attributes is taken directly from the corresponding field in the Attributes table, but there are some minimal requirements for content:

The Loss_Types and IT_Capabilities attributes are not dumped unless both are nontrivial.

The Forces attribute is not dumped if the threat agent is human.

The Authentication, Attitude, Motive, Sophistication, and Role attributes are not dumped unless the threat agent is human.

If after suppressing partial data in this fashion there are no nontrivial attribute values left to dump, then the only value dumped is the first HasAttributes property. 

Table A-7:  Policy, Threat, and Assumption Attribute Field Values

Attack and Detailed Policy Statement Properties

Attacks and Detailed Policy Statements are dumped from their representative tables.  Lists of countering/supporting Objectives are also dumped with the aid of mapping tables.  For each pair, <DetailID> consists of "DA." or "DP." appended with the key field.

Table A-8:  Attack and Detailed Policy Statement Property Field Values

Detail/Objective Mapping Properties

The mapping tables from Attacks and Detailed Policy Statements down to Security Objectives contain information on how to specialize the countering/supporting Objectives, and on why the results are good.  In the following, <DetailID>^<ObjID> consists of DA. or DP. Followed by an Attack or Detailed Security Policy identifier, a caret (^), and O. followed by an Objective identifier.

Table A-9:  Detail / Objective Mapping Property Field Values

Objective Properties

The definition of each objective is dumped, along with a list of its implementing components, where each <ObjID> consists of O. followed by an Objective identifier. 

Table A-10:  Objective Property Field Values

Objective/Component Mapping Properties

For each pair of keys, <ObjID> and <CmptID>, information on how to specialize the given Component to meet the given Objective, along with accompanying rationale is dumped from the Objective/Component Mapping table in the format given below.

Table A-11:  Objective/Component Mapping Property Field Values

Extension Properties

CC-Extending Classes, Families, Components, and Elements are all dumped in the same format.  In the following table, <Id> is the identifier of the extended topic, which must start with an F or an A.  The ppPrompt and Rationale fields are not present for CC-Extending elements.  These properties are dumped only if the ShowCCExtensions flag is True.

Table A-12:  Extension Property Field Values

Overview of the BuildPropertySheet Subroutines

The DumpAllTables procedure converts the main knowledge base tables to property lists via calls to subroutines, as shown below.  In a few cases, the routine depends on whether the ShowCCExtensions flag is True.

Table A-13:  Table Dumping Subroutines