# Assumption Categories

Description:
This category of assumptions covers the motives, attitude, competence, and operations of System Administrator personnel.

Assumption Editorial:
Category includes considerations of whether the administrator is hostile or nice, local or remote.


Description:
This category of assumptions covers the attitudes of System Administrators.


Description:
This category of assumptions covers the motives of System Administrators.


Description:
This category of assumptions covers communications to and from the TOE.

Assumption Editorial:
May be used to include or exclude threats by remote threat agents.


Description:
This category of assumptions covers the protection of security-relevant data.


Description:
This category of assumptions covers the physical protection of the facility and the TOE.

Assumption Editorial:
Helps identify threat agents, helps determine which threats are countered by the environment.


Description:
This category of assumptions covers procedures to ensure the proper administration of the TOE.


Description:
Various Assumptions about the operating environment.

Assumption Editorial:
This assumption contains all assumption categories explicitly and thus implicitly all assumptions.  In the corresponding links table, Root is not explicitly linked to individual assumptions.


Description:
This category of assumptions covers the motives, attitude, and access of users.

Assumption Editorial:
This category helps determine what kinds of users are there.


Description:
This category of assumptions covers the motives of users.


# AsteriskTable

HTMLStyleSheet:
BODY {  /* Set page margins, background */
	margin-top: 1em;
	margin-left: 2em;
	margin-right: 2em;
	font-size: 10pt;
	font-family: times new roman, serif;
	line-height: 1.2em;
	background: white;
	color: black;
}

h2 {    /* Main Page title */
	margin-bottom: 1em;
	text-align: center;
	font-size: 30pt;
	font-weight: bold;
	line-height: 1.2em;
	color: #660000;
	font-family: times new roman, serif;

}

h3 {    /* Environment Aspect titles */
	margin-bottom: .9em;
	text-align: left;
	font-size: 20pt;
	font-weight: bold;
	line-height: 1.8em;
	color: #660000;
	font-family: times new roman, serif;
}

p.h4 {    /* Attribute record titles */
	margin-bottom: 0;
	text-align: left;
	font-size: 14pt;
	font-weight: bold;
	/* line-height: 1.3em; */
	color: #000000;
	font-family: times new roman, serif;
}

em {	/* Field names */
	font-size: 9pt;
	font-weight: bold;
	font-style: normal;
	color: #660000;
	font-family: arial, verdana, sans-serif;
}

em.id { /* style for Identifier title */
/*	text-decoration: underline; */
	font-size: 9pt;
	font-weight: bold;
	color: #660000;
	font-family: arial, verdana, sans-serif;

}

em.gold { /* Editorial title */
	font-size: 9pt;
	font-weight: bold;
	color: #808080;
	font-family: arial, verdana, sans-serif;
}

em.AttType { /* Attribute Types (agent, method, result) */
	font-family: Times New Roman, Times, serif;
	color: #660000;
	font-size: 12pt; 
	font-weight: bold;
}
em.AttName { /* Attribute Types (agent, method, result) */
	font-family: arial narrow, arial, sans-serif;
	color: #660000;
	font-size: 10pt; 
	font-weight: normal;
}

em.AttVal { /* Attribute Types (agent, method, result) */
	font-family: arial narrow, arial, sans-serif;
	color: #000000;
	font-size: 10pt; 
	font-weight: normal;
}
var {	/* Subordinate Field names */
	font-size: 10.5pt; 
	font-weight: normal;
	font-style: normal;
	color: #660000;
	font-family: arial narrow, arial, sans-serif;
}

var.gold { /* for displaying Prompt ranks */
	color: #808080;
}

var.err { /* used for reporting bad links */
	color: #FF0000;
}

p {	/* style for body of subordinate links */
	text-align: left;
	text-indent: -24pt;
	margin-left: 24pt;
	margin-bottom: 0.9em;
	line-height: 1.2em;

}

td {	/* style for table data */
	font-size: 10pt;
}

b {	/* redundant? */
	font-weight: bold;

}

HTMLHeaderText:
$ReportName

HTMLEnvAspectsTable:
<table border="4" cellpadding="3" width="80%"
     bordercolor="#8B7DA2" bordercolordark="#21005A"
     bordercolorlight="#D7D1DE" cellspacing="1">
General Threats
General Policy Statements
General Assumptions
Detailed Attacks
Detailed Policy Statements

HTMLIndexFile:
CC PKB Reports
 
         $DBTitle
<table border="4" cellpadding="3" width="80%" bgcolor="#FFFFFF"
     bordercolor="#8B7DA2" bordercolordark="#21005A"
     bordercolorlight="#D7D1DE" cellspacing="1">
          Prompts                                  Attributes      

          Threat Categories

          Policy Categories

          Assumption Categories

          General Threats

          General Policy Statements

          General Assumptions

          Detailed Attacks

          Detailed Policy Statements

          S e c u r i t 
            y  O b j e c t i v e s

          Common Criteria Components

CC Extensions
          <table
            border="1" cellspacing="1" width="95%" bgcolor="#FFFFFF">
                Classes

                Families

                Components

          User Guide
Observation Reports
          
           Based on the CC Profiling Knowledge Base 
           TM 
           Schema 




# Attack/Objective Mapping

Objective Application:
Limit cryptographic management to specially authorized administrators.


Objective Application Rationale:
Deter modification or destruction of audit data through the creation of an audit-administration role.

This objective attempts to prevent misuse of audit data by limiting access to it.

Purpose: Prevent modification or destruction of audit data by limiting possible threat sources.

Only the audit administrator can control the audit trail per FMT_SMR.2 and FMT_MTD.1.  

Environmental support for this objective application could include the creation of procedures for the duties of the Audit Administration role.


Objective Application:
Select either variant to prevent this attack. The Availability is more effective because a maximum number of audit records lost can be specified and because it potentially addresses other failure scenarios for the audit mechanism.

Attack/Objective Editorial:
Potential rationale:
Necessary audit data to implicate attacks by other administrators is delivered per FAU_STG.2.


Attack/Objective Editorial:
The objective O.I&A_User is a dependancy for the objective O.Audit_Admin_Role.


Objective Application:
Consider preventing administrators from modifying user-defined access control attributes.

Objective Application Rationale:
This objective is a preventive measure that - with some exceptions - allows the TOE to prevent unauthorized administrative access to user objects.

Attack/Objective Editorial:
Design administrative functions in such a way that administrators do not automatically have access to user objects, except for necessary exceptions. For an accounts administrator, the necessary exceptions include allocation and de-allocation of storage.  For an audit administrator, the necessary exceptions include observation of audited actions. In general, the exceptions tend to be role specific.


X-Ray:
FAU_GEN.1:
Auditable actions: modification of access-control attributes by administrators. 
Auditable objects: all objects.

Objective Application Rationale:
Auditing administrators serves as an identification measure that can help prevent future similar attacks.  It also serves as a deterrent, reducing threat-agent motivation.


Objective Application Rationale:
The O.Audit_Loss_Respond objective helps counter the case where administrators take actions that result in the loss of incriminating audit records.


Objective Application:
Consider preventing administrators who control object attributes from modifying audit data.

Objective Application Rationale:
The O.Audit_Protect objective deters the administrator from modifying the audit data storage.


Objective Application:
Consider preventing privileged access to user data, except as necessary.

Objective Application Rationale:
The O.AC_Admin_Limit objective has been imposed to stop the administrator from having access to the user's data.


Objective Application Rationale:
The O.Audit_Admin_Role objective should be considered when the administrator would cover his tracks when accessing a user's data to make the unauthorized modifications.


Objective Application Rationale:
The objective O.Trusted_Int_Path should be selected when an administrator might attempt to gain user imposed data access information or user authentication data within the TSC.


Objective Application Rationale:
O.Audit_Admin_Role should be considered as a potential deterant to an administrator who may attempt any malicious modification of the information flow control policy.


Objective Application:
Access is limited to those authorized for the Audit Administrator role, per Objective O.Audit_Admin_Role.

Objective Application Rationale:
O.Audit_Protect should be provided in a manner to stop an administrator from destroying the audit data collected on this attack.


X-Ray:
FDP_IFC.1: This component should be implemented to provide a policy that would eliminate an administrator from redirecting traffic to an unauthorized location.

FDP_IFF.1: This component should implement the information flow to authorized location only.


X-Ray:
Administrator guidance shall address administrator errors that change the access control or information flow policy enforced by the system or application in such a way that it no longer serves its intended purpose.


Objective Application:
Disallow access control or information flow policies that are unsafe in any environment.


Objective Application:
Security management functions shall provide a well-defined correspondence between available parameter settings and potentially desired access control or information flow policies.


Objective Application:
Provide an administrative role specifically for managing access control or information flow policy.

X-Ray:
FMT_SMR.1, FMT_SMR.2:
The authorised identified role: identified audit role.


X-Ray:
Administrator guidance shall address errors that change the audit policy enforced by the TSF.


Objective Application:
Provide an administrative role specifically for managing the audit mechanism.


X-Ray:
AGD_ADM.1:
Administrator guidance shall address errors that change the authentication policy enforced by the TSF.


X-Ray:
AGD_ADM.1:
Administrator guidance shall address errors that interfere with availability of user information.


Objective Application:
Restrict activities that could have a general impact on availability of information to an administrative role.

X-Ray:
FMT_SMR.1, FMR_SMR.2:
The authorised identified role: identified audit role.


X-Ray:
AGD_ADM.1:
Administrator guidance shall address errors that interfere with availability of computing resources.


X-Ray:
AGD_ADM.1:
Administrator guidance shall address errors that lead to inappropriate system-entry policies.


Objective Application:
The authorized users are the administrator roles that you wish to constrain.

X-Ray:
FPR_UNO.4:
List the administrator roles that you wish to constrain.


Objective Application:
Include administrators in the list of users who are unable to link multiple uses of a service or resource by a user.

Objective Application Rationale:
This objective constrains the administrative roles identified in the attack as the threat agent.


Objective Application:
Choose the [Distribution] variant of this objective for higher effectiveness in countering this attack. Limit administrators' ability to observe operations to those which are necessary to perform their duties.

X-Ray:
FPR_UNO.1, FPR_UNO.2: 
Include administrators as appropriate to their duties in the list of users who are unable to observe operations. Tailor the lists of operations, objects, and protected users associated with each administrator role as required by your goals for privacy within the specific TOE environment.

Objective Application Rationale:
The [Distribution] variant of this objective makes it more difficult for administrators to gather privacy information. Administrators typically have greater access than users. Distributing privacy information is additional step to make collect the data more difficult.

This objective is more effective if all administrators are constrained under this objective.


Objective Application Rationale:
This objective helps prevent the attack by prohibiting the system from collecting privacy-related information in the first place. Administrators are thereby prevented from ever seeing the privacy-related information because it never exists on the system.


Objective Application:
Select the [Basic] variant unless there is a need for accountability.

X-Ray:
FPR_PSE.1, FPR_PSE.2, FPR_PSE.3:
Include administrators in the list of users who are unable to determine the real user identity associated with protected subjects.

Objective Application Rationale:
Any variant of the objective prevents the attacker from associating privacy-related information with a user.


Objective Application:
Choose the [Enhanced] variant of this objective for higher effectiveness in countering this attack

X-Ray:
FPR_ANO.1, FPR_ANO.2:
Include administrators in the list of users who are unable to determine the real user identity associated with protected subjects.

Objective Application Rationale:
The [Enhanced] variant of this objective helps prevent the attack by prohibiting the system from collecting privacy-related information in the first place. Administrators are thereby prevented from ever seeing the privacy-related information because it never exists on the system.


Objective Application:
Audit all external communication, especially that not explicitly associated with legitimate user activity.

Objective Application Rationale:
[Detection of trapdoors after installation.]
Objectives:  O.Audit_Account - in using this objective you would be concerned with the audit trail being accountable so if the developer got in you could discover the entry. This objective provides low effectiveness against this attack.


Objective Application Rationale:
[Detection of trapdoors after installation.]  O.Audit_Admin_Role - this objective would be needed if the developer could get in as an administrator. This objective provides low effectiveness against this attack.


Objective Application Rationale:
[Deterrence from writing trapdoors.] Objectives:  O.Code_Signing - this objective would potentially deter the developer as potential legal action could possibly hinge on verification of code from alteration after leaving developer site. (See the T.Repudiate_Send threat.)


Objective Application:
Require a search of the source code for evidence of trap-door functionality.

Objective Application Rationale:
[Detection of trapdoors before installation.] Objectives:  O.Source_Code_Exam - this objective would capture the source code assurance examination to prove no trapdoor exists from vendor.


Objective Application:
This objective is not directly implemented and is best dealt with by applying relevant TOE crypto objectives to the environment.


Objective Application:
Apply Fault_Tolerance to faults that sever communication between security-critical components of the distributed system.

X-Ray:
Specify security-critical functions that are to prevail, specify severed communicaitons among security-critical components as failures that are to be tolerated.


X-Ray:
FAU_GEN.1:
Record actions likely to be result in overload of communication resources.

Objective Application Rationale:
Audit data should be generated when a threat agent uses services in manner that causes multiple attempts to exceed resource quotas.

Attack/Objective Editorial:
For O.Audit_Generation objective, the auditable events would include for example, unauthorized information flows.


Objective Application:
For example, provide export of user data from the TOE with security attributes that limit the number of locations and specify which locations that the data can be sent to.

Objective Application Rationale:
Allowing data to or from locations not specified by the organization's policy could put excessive strain on bandwidth of communication lines and cause legitimate data flows to be delayed or denied.


Objective Application Rationale:
O.Hack_Traffic_Control can be used to prevent communications overload by discarding the hacker traffic when a hacker causes overload on communication channels.


Objective Application:
Heuristically give priority to those users that are least likely to cause a communications overload.


Objective Application Rationale:
The effectiveness of this objective when applied to the communications lines will vary greatly as a function of both the sophistication of the attack as well as the capability to detect those attacks (which depends on the physical properties of the communications lines).

Complete, physical protection of external communications lines will be almost impossible to provide when the communications destination is a remote site. Some additional protection of this nature might be provided by a second party (e.g., the owners of the communications lines).


Attack/Objective Editorial:
"(e.g. limit physical exposure of communication cables)"


Objective Application Rationale:
O.Encryption_Access makes cryptoanalysis more difficult.


Objective Application Rationale:
O.Encryption_Prohibit prevents this specific attack.


Objective Application Rationale:
O.Robust_Encryption makes cryptoanalysis more difficult.


Objective Application Rationale:
O.Encryption_Access prevents this specific attack.


Objective Application Rationale:
O.Audit_Gen_User, User identity association is clearly necessary for user accountablility and is equally clearly violated by a successful session capture attack.


Objective Application Rationale:
O.Trusted_Path: masquerade threats are threats against the trusted path objective whose purpose is to ensure that I&A is done in a reliable way.


X-Ray:
AGD_USR.1:
Provide user guidance in order to reduce the risk of an active workstation being left unattended and to provide instructions for use of screen locking mechanisms.


Objective Application:
Specialize this objective so that a user must use several mechanisms together to gain access to critical resources.


Objective Application:
It may be appropriate to zeroize cryptographic registers and partially encrypted data, in order to prevent adverse consequences of the attack.


Objective Application:
Apply O.Audit_Generation to the collection of audit records that are likely to be associated with task overloading.

X-Ray:
FAU_GEN.1:
Audit data should be generated when a threat agent uses services in manner that causes multiple attempts to exceed resource quotas.


Objective Application:
Heuristically give priority to those users that are least likely to cause task overloading.


Objective Application:
Specialize O.React_Discovered_Atk to the reporting of task overload.


X-Ray:
ADG_ADM.1:
Address social engineering attacks.


X-Ray:
ADG_USR.1:
Address social engineering attacks.


Objective Application:
Require that any clear-text headers be duplicated inside the encryption "envelope".


Objective Application:
Specialize O.Audit_Generation to the collection of audit records that are likely to be associated with storage overloading.


Objective Application:
This objective prevents the loss of security protection by preserving the TOE's secure state in the presence of specific hardware failures.

X-Ray:
FPT_FLS.1:
List the types of hardware failures for which the TOE guarantees it will "fail safe" (i.e., protect its secure state). The definition of secure state should capture critical aspects of the security design that could be violated as a result of the identified hardware failures.

Objective Application Rationale:
The definition of a secure state may regard missing functionality or TOE inoperability as "secure," unless availability is a concern.


Objective Application:
Both variants are capable of protecting security-relevant functionality and may address availability in the general sense.  The [Resistant] variant provides more comprehensive protection. 

Some hardware components are intrinsic to TSF enforcement, while others may affect TOE functional capabilities.  Both examples should be considered when specializing the objective.

X-Ray:
FRU_FLT.1: 
Specify the relevant hardware components and list the associated failures to which each must be tolerant.

FRU_FLT.2: 
List the associated failures to which all TOE hardware capabilities must be resistant.

Objective Application Rationale:
Explain the identified hardware components and the failures to which they are tolerant and/or resistant, with regard to the nature of protection being provided. If the [Basic] variant is used, protection is provided by avoiding the consequences of the attack.  If the [Resistant] variant is used, the attack is prevented for the specified cases.


Objective Application:
Specify inspection for absence of malicious code.


X-Ray:
FDP_ACF.1:
Rules governing access: Limit ability to modify trusted objects to a trusted role


Objective Application Rationale:
These controls offer the user protection against maliciously executed code: (a) by constraining those individuals that can execute code, and/or (b) by constraining what damage maliciously executed code may do to protected data.


Attack/Objective Editorial:
The objective O.Trusted_Path is a dependancy for the objective O.I&A_User_Action.

When the threat agent is not local then the objective O.I&A_User_Action would be dependent on the objective O.Trusted_Path&Channel.


X-Ray:
FPT_RCV.4: 
Specify the applicable security functions for which the PP will provide protection, and specify failures resulting from disruption of the power supply.

Objective Application Rationale:
If a power disruption or unintential system reset were to occur without the protection provided here, the contents of security attributes or other TSF-critical data could be corrupted.

This objective addresses environmental power disruptions and unintentional system resets by providing automatic recovery from those failures. This also prevents the loss of security protection by avoiding insecure states that could result from partially completed, security-critical operations.


Objective Application:
Any variant of this objective is applicable to this attack.  Each variant addresses system recovery to a secure state and may prevent security violations that would result from operating the system in an insecure state.

X-Ray:
FPT_RCV.1: 
No operations.

FPT_RCV.2: 
Specify failures that correspond to unexpected power disruption.

FPT_RCV.3: 
Specify failures that correspond to unexpected power disruption.

Objective Application Rationale:
The degree of functionality chosen should justify the claim that the effects of power disruptions to the TOE have been adequately addressed.


Objective Application:
This objective is allocated to the environment and addresses the case where those who handle nonrepudiation evidence are not associated with the TOE (e.g., the remote sender or a remote third party).  In the statement of the objective, these people are referred to as "remote".


Objective Application:
This objective is allocated to the TOE, since the receiving user is local.  When applying this objective, the term "receiving user" is interpreted to be the local user of the TOE that is repudiating receipt of the message.


Objective Application:
This objective is allocated to the TOE and addresses the case where those who handle nonrepudiation evidence are associated with the TOE (e.g., the local sender or a local third party).  In the statement of the objective, however, these people are referred to as "remote".


Objective Application:
This objective is allocated to the environment, since the receiving user is remote.  When applying this objective, the term "receiving user" is interpreted to be the user of a remote trusted system who is repudiating receipt of the message.


Objective Application:
This objective is allocated to the environment and addresses the case where those who handle nonrepudiation evidence are not associated with the TOE (e.g., the remote recipient or a remote third party).  In the statement of the objective, these people are referred to as "remote".


Objective Application:
This objective is allocated to the TOE, since the sending user is local.  When applying this objective, the term "sending user" is interpreted to be a local user of the TOE that is repudiating sending of the message.


Objective Application:
This objective is allocated to the TOE and addresses the case where those who handle nonrepudiation evidence are associated with the TOE (e.g., the remote recipient or a remote third party).  In the statement of the objective, these people are referred to as "remote" despite being "local" in the context of this attack.


Objective Application:
This objective is allocated to the environment, since the sending user is remote.  When applying this objective, the term "sending user" is interpreted to be a remote user in the TOE environment that is repudiating sending of the message.


Objective Application:
This objective is allocated to the environment and addresses the likely case where those who handle nonrepudiation evidence are associated with the remote system/application defining the transaction.  In this case, the sending "user" is the system or application that defines the transaction.


Objective Application:
This objective is allocated to the environment and addresses the likely case where those who handle nonrepudiation evidence are not associated with the TOE (e.g., the remote recipient or a remote third party). The remote recipient, in this case, is the remote system/application defining the transaction.


Objective Application:
This objective is allocated to the TOE, since the receiving user is local.  In this case, the sending "user" is the system or application that defines the transaction.


Objective Application:
This objective is allocated to the TOE, since the sending user is local.  In this case, the recipient is the system/application that defines the transaction.


Objective Application:
This objective is allocated to the TOE and addresses the likely case where those who handle nonrepudiation evidence are associated with the TOE (e.g., the local sender or a local third party).


Objective Application:
This objective is allocated to the TOE and addresses the case where those who handle nonrepudiation evidence are associated with the TOE (e.g., the remote recipient or a remote third party).


Objective Application:
This objective is allocated to the environment, since the receiving user is remote.


Objective Application:
This objective is allocated to the environment, since the sending user is remote.


Objective Application:
Specialize this objective to prevent the loss of security protection by preserving the TOE's secure state in the presence of specific software failures.

X-Ray:
FPT_FLS.1:
List the types of software failures for which the TOE guarantees it will "fail safe" (i.e., protect its secure state). The definition of secure state should capture critical aspects of the security design that could be violated as a result of the identified software failures.


Objective Application:
Both variants are capable of protecting security-relevant functionality and may address availability in the general sense.  The [Resistant] variant provides more comprehensive protection. 

Some software components are intrinsic to TSF enforcement, while others may affect TOE functional capabilities.  Both examples should be considered when specializing the objective.

X-Ray:
FRU_FLT.1: 
Specify the relevant software components and list the associated failures to which each must be tolerant.

FRU_FLT.2: 
List the associated failures to which all TOE software capabilities must be resistant.

Objective Application Rationale:
Explain the identified software components and the failures to which they are tolerant and/or resistant, with regard to the nature of protection being provided. If the [Basic] variant is used, protection is provided by avoiding the consequences of the attack.  If the [Resistant] variant is used, the attack is prevented for the specified cases.


Objective Application:
Preserve secure state in case of cryptographic failure.  To do this, it may be necessary to zeroize all cryptographic registers that contain red keys or partially encrypted data.


Objective Application:
Define secure state so as to facilitate detection of:

   a) Any failure that may allow the TOE to output unencrypted cryptographic keys, 
       plaintext sensitive data, or other secret cryptographic security parameters;

   b) Failure of a cryptographic function;

   c) TOE physical tampering (including environmental failure).

To maintain a secure state, it may be necessary to halt cryptographic operations and related I/O activity.  It may also require the zeroizing of critical registers and keys.


X-Ray:
AGD_ADM.1:
Provide the administrator with the guidacne need to restrict access to removable media devices.


X-Ray:
FAU_GEN.1:
Include in the list of auditable events writing to removable media.


Objective Application:
Choose the [Unmarked] variant of this objective.

X-Ray:
FDP_ETC.1:
Include rules in the information flow control policy that exclude writing sensitive or proprietary information to removable media.


Attack/Objective Editorial:
The objective O.Admin_Code_Val has a dependancy for the objectives O.Admin_Code_Val_Steg and O.Standard_Output_Pres.


Attack/Objective Editorial:
Link added due to no attack being linked to O.Standard_Output_Pres and this attack should have been linked to the objective.
This objective is dependent on the O.Admin_Code_Val objective.


X-Ray:
FAU_GEN.1:
Specify the generation of audit records that record user data-collection activities.


X-Ray:
FAU_GEN.1:
Record actions likely to result in overload of communication resources.


Objective Application:
A user could send and/or receive unauthorized information. Therefore limits should be placed on the types of acceptable information flows and the limits on information flows.  This would reduce bandwidth utilization and enforce organizational policy.


X-Ray:
FDP_ACC.1: Choose SFPs dealing with information quality


Objective Application:
Specify an access control or information flow policy in which data is labeled according to its confidentiality or secrecy.

Objective Application Rationale:
Effectiveness depends on accuracy of stored security attributes, on user compliance with procedural constraints on the use of output devices, and on correct functioning of TSF access control mechanisms.


Objective Application:
Specify role-related user attributes to assist in controlling user access to cryptographic assets.


Objective Application Rationale:
This is essentially just Bell-LaPadula star and simple security, no bells or whistles.


X-Ray:
AGD_USR.1:
User documentation shall address user errors that lead to loss of data.


X-Ray:
AGD_USR.1:
User documentation shall address user errors that lead to inaccessibility of user data.


X-Ray:
FAU_GEN.1:
Specify auditing of changes to authentication data.


Objective Application:
Choose the [Basic] variant of this objective.

X-Ray:
FMT_MTD.1:
Ensure that authentication data is included in the list of TSF data and is protected from unauthorized modification.


X-Ray:
FAU_GEN.1:
Specify auditing of modifications to user data.


X-Ray:
FAU_GEN.1:
Those events that are likely to be associated with task overloading.


X-Ray:
FAU_GEN.1:
Specify auditing of exported data.


Objective Application:
Specify labels that reflect data confidentiality or secrecy.


Objective Application:
Specify labels that reflect integrity of data or information content.


X-Ray:
FAU_GEN.1:
Those events that are likely to be associated with storage overloading.


Objective Application:
Heuristically give priority to those users that are least likely to cause a storage overload.


# CC Classes

Descriptive Name:
Protection of the TOE Security Functions


# CC Components

Descriptive Name:
Generation support and acceptance procedures


Descriptive Name:
Installation, generation, and start-up procedures


Descriptive Name:
Compliance with implementation standards - all parts


Descriptive Name:
Protection Profile, TOE description, Evaluation requirements


Descriptive Name:
Protection Profile, Security environment, Evaluation requirements


Descriptive Name:
Protection Profile, PP introduction, Evaluation requirements


Descriptive Name:
Protection Profile, Security objectives, Evaluation requirements


Descriptive Name:
Protection Profile, IT security requirements, Evaluation requirements


Descriptive Name:
Protection Profile, Explicitly stated IT security requirements, Evaluation requirements


Descriptive Name:
Security Target, TOE description, Evaluation requirements


Descriptive Name:
Security Target, Security environment, Evaluation requirements


Descriptive Name:
Security Target, ST introduction, Evaluation requirements


Descriptive Name:
Security Target, Security objectives, Evaluation requirements


Descriptive Name:
Security Target, PP claims, Evaluation requirements


Descriptive Name:
Security Target, IT security requirements, Evaluation requirements


Descriptive Name:
Security Target, Explicitly stated IT security requirements, Evaluation requiremennts


Descriptive Name:
Security Target, TOE summary specification, Evaluation requirements


Descriptive Name:
Analysis and testing for insecure states


Descriptive Name:
Strength of TOE security function evaluation


Descriptive Name:
Action in case of possible audit data loss


Descriptive Name:
Data authentication with identity of guarantor


Descriptive Name:
Export of user data without security attributes


Descriptive Name:
Export of user data with security attributes


Descriptive Name:
Partial elimination of illicit information flows


Descriptive Name:
Import of user data without security attributes


Descriptive Name:
Import of user data with security attributes


Descriptive Name:
Stored data integrity monitoring and action


Descriptive Name:
Management of security functions behaviour


Descriptive Name:
Allocation of information impacting unobservability


Descriptive Name:
Failure with preservation of secure state


Descriptive Name:
Inter-TSF availability within a defined availability metric


Descriptive Name:
Inter-TSF detection and correction of modification


Descriptive Name:
Basic internal TSF data transfer protection


Descriptive Name:
Limitation on scope of selectable attributes


Descriptive Name:
Basic limitation on multiple concurrent sessions


Descriptive Name:
Per user attribute limitation on multiple concurrent sessions


# CC Families

Descriptive Name:
Explicitly stated IT security requirements


Descriptive Name:
Inter-TSF user data confidentiality transfer protection


Descriptive Name:
Inter-TSF user data integrity transfer protection


Descriptive Name:
Internal TOE TSF data replication consistency


Descriptive Name:
Limitation on scope of selectable attributes


Descriptive Name:
Limitation on multiple concurrent sessions


# CC-Extending Classes

Class Overview:
Constraints on the environment include emanations security (to protect confidentiality measure) as well as protection from physical damage (to protect integrity and availability).

Rationale:
Justification of explicit statement: Constraints on the physical environment differ from ordinary user constraints and from IT constraints.

Prompt for PP Report:
Is there a need to provide security protection in the system's physical environment?

Prompt for ST Report:
Is there a need to provide security protection in the system's physical environment?


# CC-Extending Components

Component Overview:
The physical TOE environment shall provide an effective container that prevents the escape of intelligible electromagnetic and sound vibrations generated by the TOE.

Related Components:
Hierarchical To:
Management Dependencies:
Audit Dependencies: [for basic, minimal, detailed audit]
Other Dependent Components:

Rationale:
Justification of explicit statement.  This is explicitly an environmental requirement, in contrast to existing Part 2 CC components.
Applicability of Assurance Requirements.  Special skills may well be needed to evaluate satisfaction of this requirement.  However, there are commercial and government testing laboratories that could be consulted.

Prompt for PP Report:
Is there a need for the environment to contain emanations?

Prompt for ST Report:
Is there a need for the environment to contain emanations?

Component Editorial:
Used in connection with IT devices whose emanations contain intelligible secrets.


Component Overview:
TSF data initialization ensures that the default values of TSF security attributes are appropriate.

Rationale:
Justification of explicit statement.  Protection of TSF data by FMT_MTD.1.1 is analogous to the protection of user data attributes by FMT_MSA.3.2.  FMT_MTD-X.1 is needed to provide a corresponding analogue of FMT_MSA.3.1, so that default values for TSF data will be reasonable.

Prompt for PP Report:
Is there a need to ensure reasonable default values for TSF data?

Prompt for ST Report:
Does the system ensure reasonable default values for TSF data?


Component Overview:
IT equipment that processes sensitive user data may need to avoid the unintended transmission of information-bearing sounds or electromagnetic signals.

Rationale:
Justification of explicit statement.  FDP_UCT.1.1 is similar, but is clearly aimed at deliberate communications, appearing not to cover unintended emanations.  FPT_PHP claims generally to deal with physical protection, but the individual components all address physical modification rather than eavesdropping.
Applicability of Assurance Requirements.  Special skills may well be needed to evaluate satisfaction of this requirement.  However, there are commercial and government testing laboratories that could be consulted.

Prompt for PP Report:
Is there a need to control the system's emission of electromagnetic or other signals?

Prompt for ST Report:
Does the system actively limit it's emission of electromagnetic or other signals?

Component Editorial:
Specific commercial, military, and civilian government standards exist.  Many of these are publicly available.  These may be used to tailor this component appropriately.  Note that two different approaches to EMSEC are now in common use — suppression of emanations and the addition of noise.


# CC-Extending Elements

Element Description:
The physical TOE environment shall not permit the escape of [assignment: type of TOE emissions] in excess of [assignment: specified limit].

Prompt for ST Report:
Does the TOE limit specific types of emissions?


Element Description:
The TOE shall not emit [assignment: types of emissions] in excess of [assignment: specified limits].


Element Description:
The TOE connecting cables (power supply, communications lines) shall not emit [assignment: types of emissions] in excess of [assignment: specified limits].

Prompt for ST Report:
Do cables connected to the system limit specific types of emissions?


Element Description:
The TSF shall provide [selection: restrictive, permissive, other property] default values for [assignment: list of TSF data].

Prompt for ST Report:
Does the system provide appropriate default values for TSF data?


# CC-Extending Families

Family Overview:
Components in this family describe physical protection measures to protect confidentiality of information.

Rationale:
Justification of explicit statement:  Rather than force fit emanations security into an existing family (e.g., FPT_PHP), we chose to provide a new family.  See the component, F_PhysEnv_Cnf.1, for more details on newness.

Prompt for PP Report:
Is there a need to protect the confidentiality of information via environmental measures?

Prompt for ST Report:
Is there a need to protect the confidentiality of information via environmental measures?


# Detailed Attacks

Descriptive Name:
Accidental mismanagement of cryptographic functions

Attack Description:
An administrator misconfigures cryptographic functions or stores plaintext keys in insecure areas.


Descriptive Name:
Destruction or modification of audit data

Attack Description:
An administrator seeks to cover up misbehavior by destroying and/or falsifying audit data.

Attack-Selection Guidance:
This attack is relevant to multi-user systems with an auditing mechanism where some administrators may not be fully trustworthy.

Countermeasure Application:
Choose O.Audit_Protect, O.Security_Roles, and O.Audit_Admin_Role to prevent this attack.

Environmental support may include operational requirements for security roles and proper handling of audit data.

The protection provided is dependent upon specializing the objectives as provided guidance indicates.

Attack Editorial:
Access is limited to those authorized for the Audit Administrator role, per Objective O.Audit_Admin_Role.


Descriptive Name:
Administrator maliciously modifies or deletes data access control attributes

Attack Description:
An administrator maliciously modifies access control attributes, allowing the administrator or other perpetrator to gain access and manipulative capability to organizational assets, contrary to organizational policy.

Attack-Selection Guidance:
This attack is relevant to multi-user systems with individualized access controls where some administrators may be untrustworthy. This attack is also relevant when single user systems have a centralized administrative policy which precludes users from administrative authority.


Descriptive Name:
Administrator modifies or destroys user data or applications

Attack Description:
The administrator abuses IT or user trust, as being the administrator and without changing the user imposed data security attributes, by destroying data or applications for malicious reasons or to cover up misappropriate behavior.

Attack-Selection Guidance:
This attack is relevant when an administrator might attempt to circumvent user imposed data access controls.


Descriptive Name:
The administrator maliciously modifies information flow control.

Attack Description:
The administrator maliciously alters information flow control policy to allow information to flow to inappropriate locations for unauthorized users access or modification.

Attack-Selection Guidance:
This attack would most likely be relevant to a network administrator that would not necessarily be trustworthy. An example of this attack is the changing of routing tables or access control lists on a router.


Descriptive Name:
Administrator maliciously modifies system entry parameters

Attack Description:
An administrator or user masquerading as an administrator maliciously modifies system entry parameters which would allow unauthorized access to an organization's protected assets.

Attack-Selection Guidance:
This attack is most likely to be prevalent where outsiders wanting unauthorized access can sway an administrator. An example of this attack is the modification of the system's defined limit for unsuccessful logins, allowing unlimited password guessing. Unlimited password guessing would be very likely to eventually succeed in gaining unauthorized system (TOE) access.


Descriptive Name:
Administrator maliciously modifies security-critical code

Attack Description:
The administrator modifies the security-critical (TSF) code to weaken the security effectiveness of the TSF or introduce a new security breech.

Attack-Selection Guidance:
An example of this attack is when an administrator modifies the login implementation to capture user names and passwords.


Descriptive Name:
Administrator maliciously modifies user/subject bindings

Attack Description:
The administrator modifies a user/subject binding which would allow a user to act on an object without creating an audit trail.


Descriptive Name:
Administrator maliciously modifies user attributes and/or roles

Attack Description:
The administrator modifies or mishandles the users attributes or roles which allows users, unauthorized or authorized, to have the ability to perform inappropriate actions or could prevent a user from performing an authorized action.

Attack-Selection Guidance:
An example of this attack is when an administrator inappropriately gives a user "super user" status. The user can then change security attributes and gain unauthorized access to the organization assets.


Descriptive Name:
User privileges and/or authorizations are not updated upon reassignment

Attack Description:
A change in the status of users duties do not get reflected in administratively controlled privileges and/or authorizations.


Descriptive Name:
Administrator error modifies access control or information flow policy

Attack Description:
An administrator's error in data entry changes the access control or information flow policy enforced by the system in such a way that it no longer serves its intended purpose.


Descriptive Name:
Administrator error changes audit behavior

Attack Description:
An administrator's error in data entry changes the audit behavior of the system in such a way that auditing no longer serves its intended purpose.

Attack-Selection Guidance:
For example, an administrator's error modifies or deletes audit data.

Another example is when an administrator's error sets audit attributes in such a way as to allow inadmissible activities to go unaudited.


Descriptive Name:
Administrator error modifies authentication enforcement

Attack Description:
An administrator's error in data entry changes the authentication-enforcement mechanism of the system in such a way that it no longer serves its intended purpose.


Descriptive Name:
Administrator error makes information unavailable

Attack Description:
An administrator's error in data entry makes system or application information unavailable.

Attack-Selection Guidance:
For example, an administrator erroneously sets an object's security attributes, which prevents legitimate access to the object.

Another example is when an administrator erroneously sets performance-related parameters, which makes information unavailable.


Attack Description:
An administrator inadvertently leaves a back door port open after routine maintenance, allowing continuing unauthorized access by the service organization.

Attack-Selection Guidance:
Many vendors and service organizations provide update and maintenance services to customers by installing code in the systems to be serviced.  In general, this code is enabled and disabled by the administrator as service is required.  If an administrator inadvertently leaves the port open, the service organization may continue to use this open port for unauthorized entry to the system.


Descriptive Name:
Administrator error makes resource unavailable

Attack Description:
An administrator's error in data entry makes system or application resources unavailable.

Attack-Selection Guidance:
For example, an administrator erroneously modifies security attributes of non-user resources (e.g., communications channels, TOE data files, etc.), which makes the resources unavailable.


Descriptive Name:
Administrator error modifies entry policy

Attack Description:
An administrator's error in data entry changes the intended entry policy of the system or application.

Attack-Selection Guidance:
For example, an administrator's error modifies entry parameters, which permits access to the system or application in violation of entry policy.


Descriptive Name:
Administrator fails to update security configuration

Attack Description:
The organizational security policies changes but these changes are not reflected in all system configurations, resulting in circumvention and/or incorrect application of security policies.


Descriptive Name:
Administrator error modifies user security attributes

Attack Description:
An administrator's error in data entry modifies a user's security attributes, which makes the attributes inappropriate under the security policy of the system or application.

Attack-Selection Guidance:
For example, an administrator's error modifies a user's security attributes, which prevents the user from carrying out the user's responsibilities.

Another example is when an administrator's error modifies a user's security attributes, which gives the user authorization greater than the authorization dictated by the security policy of the system or application.


Attack Description:
An administrator aggregates information that indirectly reveals the identity (or other privacy related information) of user(s) in violation of user privacy policy.

Attack-Selection Guidance:
An example of this attack is when a telephone smart card is issued with a unique number, a telephone company system administrator can determine the behavior of the user of this telephone card. When a telephone profile of the user is known, the card can be linked to a specific user.

Countermeasure Application:
Choose the O.Prevent_Observe, O.Limit_ObserveRoles, and O.Prevent_Link objectives to prevent this attack. 

The protection provided is dependent upon specializing the objective as provided guidance indicates.
---
Because this is an administrator attack, it is difficult to prevent the attack with high effectiveness. The O.Prevent_Observe objective limits who can observe service usage. However, it is expected that some administrative roles would still be able to observe some service usage in order to perform their duties. O.Limit_ObserveRoles provides a limit on which roles are able to observe service usage, thereby minimizing the opportunity for the attack.  O.Prevent_Link limits administrators' ability to profile service usage.


Descriptive Name:
Administrator reads collected user privacy information

Attack Description:
An administrator reads information collected by the IT system or product that reveals the identity (or other privacy related information) of user(s) in violation of user privacy policy.

Attack-Selection Guidance:
For example, an online registration form for a software application collects the home telephone number of the application's buyer and subsequently an administrator reads the buyer's home telephone number.

Countermeasure Application:
Choose the O.Prevent_AskPrivInfo objective to prevent this attack.


Descriptive Name:
Administrator reads system generated privacy information

Attack Description:
An administrator reads information generated by the IT system or product that directly reveals the identity (or other privacy related information) of user(s) in violation of user privacy policy.

Attack-Selection Guidance:
For example, a system administrator reads a process table to learn the identity of the user associated with a particular process.

Countermeasure Application:
Choose the O.Permit_Aliases or O.Permit_Anonymity objectives prevent this attack, but not both. If user accountability is a concern, O.Permit_Aliases may be preferable. 

The protection provided is dependent upon specializing the objective as provided guidance indicates.
---
Either objective prevents the attack by obscuring the identity of the user. (Note that by definition privacy-related information is associated with user identity.)


Descriptive Name:
Inconsistent interpretation of audit data attributes

Attack Description:
The security-critical (TSF) components inconsistently interpret audit data attributes exchanged with another trusted IT product.


Attack Description:
The system leaves user information in a system buffer for view by another unauthorized user.


Attack Description:
A security-critical (TSF) component incorrectly modifies control data regarding a user process.


Attack Description:
The system incorrectly exchanges system data with another trusted system.


Attack Description:
A system failure may alter the behavior of the system's security functions in such a way that, upon recovery, it no longer properly enforces its security policy (TSP).


Attack Description:
The system does not accurately replicate system data to different parts of the system where replication is required.


Descriptive Name:
System modification by unauthorized source

Attack Description:
Software developer or hacker modifies system security functions resulting in a loss of security protection.


Descriptive Name:
Malicious developer creates secret trapdoor in system

Attack Description:
The system developer creates a secret back door in the system (TOE) that allows covert access by the developer.  This allows the developer to collect information, monitor user actions, modify the operation of the TOE, or just make unauthorized use of the TOE.

Attack-Selection Guidance:
This attack is relevant when a developer might be suspected of placing a trapdoor in the code.  In this context, the terms trapdoor and back door are very similar.  Trap doors have the connotation of being created inadvertantly by a software design flaw or secretly by an intruder.  Back doors are vendor-created but do not necessarily reflect malicious intent.

Countermeasure Application:
Select O.Code_Signing to deter the attack with moderate effectiveness.
Select O.Audit_Account to provide detection after the attack with low effectiveness (since the back door might bypass the audit mechanism).
Supplement O.Audit_Account with O.Audit_Admin_Role to counter the case where the developer uses the back door to obtain administrative privilege. 
Supplement O.Audit_Admin_Role with O.I&A_User to prevent unauthorized use of the audit-administration role.
---
Note that the included safeguards address the primary threat of placing the back door but do not counter the exploitation attacks that the back door would allow.


Descriptive Name:
Failure of external crypto support functions

Attack Description:
The TOE fails to provide adequate key management or operation due to failure of external cryptographic support

Countermeasure Application:
This problem is best dealt with by applying relevant TOE crypto objectives to the environment.


Attack Description:
Failure of a communications function severs communications between security-critical (TSF) components.

Countermeasure Application:
Apply O.Fault_Tolerance and O.Integrity_Data_Rep to prevent the attack.  Apply O.Integrity_Data_Rep and O.Trusted_DS_Recov to recover from the attack (and to prevent further damage after the initial attack).
---
Fault tolerance is much more difficult to achieve for a distributed system and requires other objectives to supplement the protection it provides.  O.Fault_Tolerance has to be applied with the idea that transient component failures will occur during normal system operations.


Descriptive Name:
Hacker gains access through a vulnerability in code

Attack Description:
The hacker can use vulnerabilities found in system or application code to break into a system undetected.


Descriptive Name:
Weak system access control mechanism or system access control implementation

Attack Description:
The system access control mechanism(s) or user attributes are weak and can be broken or the implementation methods of the system access control causes the weakness.


Descriptive Name:
Hacker causes overload of communication resources

Attack Description:
The unauthorized use of communication resources by a hacker causes a denial or delay in service to legitimate operations within the TOE scope of control.  This would include the excess bandwidth utilization, leading to the TOE's inability to perform it's security functions.

Countermeasure Application:
Apply O.Audit_Generation to detect the attack.
Apply O.Data_Imp_Exp_Control and/or O.Hack_Traffic_Control to detect attempts and prevent success.  This approach is useful when there is a specific policy against various classes of communication.
Apply O.Hack_Limit_Sessions, O.Priority_Of_Service, and/or O.Resource_Quotas to limit the extent of an attack without necessarily detecting specific occurrences.


Descriptive Name:
The communication mechanism emanates data

Attack Description:
An outsider uses special equipment to capture emanations off the communications line.

Attack-Selection Guidance:
The relevance of this attack is directly proportional to the degree of emanation by the communication medium.  This attack is inherent to broadcast communication techniques, where the emanations are intentional.
An example of this attack is when an outsider intercepts microwave transmissions or broadcast wireless transmissions using specialized devices.


Attack Description:
An outsider who is not an intended recipient intercepts user data communications.

Attack-Selection Guidance:
For example, an outsider may install a sniffer device at a remote system. The outsider may need to be privileged with respect to the remote system in order to carry out this attack. However, lax controls at the remote system may allow circumvention of this constraint.


Attack Description:
An outsider uses a device to physically tap the communications line.

Attack-Selection Guidance:
The relevance of this attack is directly related to the exposure of communications lines to unconstrained threat sources. The outsider must be relatively sophisticated and possess substantial resources to carry out this attack. Some communications line (e.g., fiber optics) may be relatively immune to this attack.

When applied to communications lines, the effectiveness of these objectives will vary greatly as a function of both the sophistication of the attack and the capability to detect or resist those attacks, which depends on the physical properties of the communications lines. Complete, physical protection of external communications lines will be almost impossible to provide when the communications destination is a remote site. Some additional protection might be provided by a second party (e.g., the owners of the communications lines).
An example of this attack is when an outsider taps into either unprotected communications lines within the system enclave or into wide area communications lines that cannot be protected.

Countermeasure Application:
Choose O.Tamper_ID to detect the attack.
Choose O.Tamper_Resistance to prevent the attack.


Attack Description:
The attacker discovers an unknown encryption key.

Attack-Selection Guidance:
In this attack, the attacker knows the encryption algorithm and has ciphertext of his own choosing, together with its decrypted plaintext.


Attack Description:
An attacker discovers an unknown encryption key by choosing a set of plaintexts and causing the corresponding set of ciphertexts to be generated.

Attack-Selection Guidance:
In this attack, the hacker knows the encryption algorithm.


Attack Description:
An attacker discovers an encryption key by choosing samples of both plaintext and ciphertext, and causing them to be encrypted and decrypted, respectively, using a known algorithm and the unknown key.

Attack-Selection Guidance:
This attack is a combination of the chosen plaintext and chosen ciphertext attacks.


Attack Description:
An attacker discovers the plaintext that corresponds to the given ciphertext, knowing only the encryption algorithm being used. The attacker has no plain-text examples to work from, nor does he/she know the encryption key that was used.

Attack-Selection Guidance:
The objective of the attack is normally to discover the plaintext that corresponds to the given ciphertext. However, the attacker would be glad to discover the key that was used. The Brute-Force Attack, in which all possible keys are tried, is an example of this attack.

Countermeasure Application:
If the cryptography is sufficiently strong, O.Robust_Encryption suffices.  Otherwise, supplement O.Robust_Encryption suffices with O.Encryption_Access for additional protection.


Attack Description:
An attacker discovers an encryption key by comparing corresponding plaintext and ciphertext samples.

Attack-Selection Guidance:
The attacker knows the encryption algorithm. In a variation of this attack, the attacker knows or guesses standardized parts of the plaintext that are in fixed locations. Another variation attempts to exploit probable words that are likely to be contained in the plaintext.


Descriptive Name:
Accidental or deliberate mishandling of cryptographic assets external to the TOE

Attack Description:
Cryptographic assets are mishandled after the leave the TOE, either in transit or while residing on stored media.


Descriptive Name:
A hacker assumes the identity of an authorized user

Attack Description:
A hacker captures the interactive session of an authorized user.  The hacker now appears as a legitimate user and can perform any action allowed to that user, including reading or modifying sensitive data.

Attack-Selection Guidance:
This attack is relevant to multi-user systems with remote users who access the system (TOE) via network connections.

Countermeasure Application:
Choose O.Audit_Gen_User to detect the attack after the fact.
Choose O.Trusted_Path to prevent the attack.


Descriptive Name:
A user assumes the identity of an authorized user

Attack Description:
An individual takes advantage of an unattended but active workstation to perform operations in the name of the logged-in user.  Such operations may include some operations that the attacker is not normally allowed to perform.

Attack-Selection Guidance:
This attack is relevant to multi-user systems with individualized access controls where some users may be untrustworthy and others careless.

Countermeasure Application:
Choose O.Screen_Lock to prevent the attack by allowing users or the TOE to lock unattended workstations. Choose O.Session_Termination to provide additional capability to prevent the attack. Choose O.User_Guidance to support these mechanisms.


Attack Description:
Services are provided to a user application without adequate authentication of the client requesting the service.  This would permit someone to receive services for which they are not authorized. However, the server would see them as a legitimate user, which is why this is classified as a masquerade attack.

Countermeasure Application:
Choose O.User_Auth_Multiple or O.User_Auth_Enhanced to strengthen authentication, preventing the attack. Choose O.Audit_Generation to detect the attack after the fact.


Descriptive Name:
Modification of security-critical data in transit from a remote trusted site

Attack Description:
Security-critical (TSF) data is modified in transit from a remote trusted site, either accidentally by the communications infrastructure or deliberately by a hostile outsider.

Attack-Selection Guidance:
Several kinds of modification are possible in this attack: modification of a single message, deletion or reordering of selected messages, insertion of bogus messages, replay of previous messages, and modification of accompanying message security attributes.

This could be accomplished as a man-in-the-middle attack.


Descriptive Name:
Modification of user data in transit from a remote site

Attack Description:
A hostile outsider modifies message data in route to the system.  Alternatively, errors in the communications infrastructure modify the message.

Countermeasure Application:
Choose O.Rcv_MsgMod_ID to detect the attack.
Choose O.Rcv_MsgMod_Rcvr to detect, recover from, and minimize adverse consequences of the attack.


Descriptive Name:
Modification of security-critical data in transit to a remote site

Attack Description:
Security-critical (TSF) data is modified in transit to a remote site, either accidentally by the communications infrastructure or deliberately by a hostile outsider.


Descriptive Name:
Modification of user data in transit to a remote site

Attack Description:
A hostile outsider modifies message data in route to a remote site.  Alternatively, errors in the communications infrastructure modify the message.

Countermeasure Application:
Choose O.Snt_MsgMod_ID to support detection of the attack.
Choose O.Snt_MsgMod_Rcvr to support detection of, and recovery from the attack.


Attack Description:
System emissions, typically electromagnetic radiation, disrupt electronic circuits in nearby equipment, causing them to fail or behave erratically.

Attack-Selection Guidance:
This attack is relevant if sensitive devices must operate in the vicinity of the TOE.

Countermeasure Application:
Choose O.InterferEman_Control to prevent the attack.


Descriptive Name:
Hacker collects information via emanations analysis

Attack Description:
An attacker collects unintended system emanations, interprets them, and thus retrieves information that is being processed by the system.

Attack-Selection Guidance:
Unintended system emanations include electromagnetic signals (including radio transmissions, heat, light) as well as sound emanations.  In one variant of this attack, collected information is used to assist in cryptoanalysis.

Countermeasure Application:
Choose O.IntelEman_Control to prevent the attack via TOE requirements.
Choose O.IntelEman_Contain to prevent the attack via environmental requirements.
Choose O.EMSEC_Design as an alternative to O.IntelEman_Control.

Specialize these objectives in such a way that any intelligible emanations escaping from the TOE are sufficiently weak that they do not get past barriers in the environment, at least not with sufficient strength to be detected and interpreted.


Attack Description:
Physical attack causes damage to cryptographic functions and/or release of cryptographic assets

Attack-Selection Guidance:
Choose O.Tamper_Resistance to prevent the attack.
Choose O.Tamper_ID to detect the attack.


Attack Description:
Hacker physically attacks the system, causing physical damage and loss of security protection.

Attack-Selection Guidance:
This attack is particularly relevant in environments where non-users have physical access to the system.


Descriptive Name:
Hacker causes system task overload resulting in denial of service

Attack Description:
Hacker causes system task overload resulting in denial of service. The system (TOE) has been over-tasked and can not complete the assigned tasking at all or in an expected amount of time. The hacker invokes processing functions in association with unauthorized activity that leads to overburdening processing resources on the TOE.

Attack-Selection Guidance:
This attack is relevant when processing resources may not be adequate to handle all potential authorized and hacker initiated processes. Therefore if processing capability will never be overburdened or limited hacker activity is authorized do not include this attack. Hacker activity may be authorized in limited amounts to analyze the hacker's present activity and to predict the hacker's potential future attack methods.

Countermeasure Application:
Choose O.Hack_Traffic_Control to prevent processor overload by discarding the hacker traffic when hacker traffic puts undue strain on the processor.


Attack Description:
A hacker persuades a user or administrator to reveal his password, giving the hacker access to the person's account privileges.


Descriptive Name:
Hacker uses social engineering to learn system information

Attack Description:
A hacker persuades a user or administrator to reveal information about system operational procedures, auditing and known flaws.

Countermeasure Application:
PP authors should also consider writing non-IT objectives to address social engineering attacks.


Descriptive Name:
Login program replicated to capture authentication data

Attack Description:
An attacker simulates the system's login program and runs it at an open terminal or workstation in order to capture a legitimate user's authentication data.


Attack Description:
An attacker may modify protocol headers such that a user believes the communication is coming from a source that is different from where it was actually sent.

Attack-Selection Guidance:
Examples include TCP/IP headers that are modified at a remote (e.g., hacker-controlled) site, as well as false information placed in e-mail header fields.

Countermeasure Application:
Not all objectives are relevant in all environments: 
   O.Comm_Trusted_Channel assumes the remote system is trusted.
   O.Repudiate_Send_Local assumes the remote system is trusted.
   O.Security_Data_Ext assumes the remote system is trusted.


Descriptive Name:
Hacker activities cause storage overload

Attack Description:
A hacker initiates processes that tax the amount of storage available in the system (TOE). Such would be the case when a hacker floods the TOE with e-mails.

Attack-Selection Guidance:
This attack is applicable if the hacker dumps unwanted data into TOE storage.

Countermeasure Application:
Choose O.Hack_Traffic_Control to prevent storage overload by discarding or rerouting the hacker traffic when a hacker causes overload on storage resources.


Descriptive Name:
System hardware fails during system operation

Attack Description:
System use uncovers a hardware flaw in a critical system component.

Attack-Selection Guidance:
The flaw may be a result of design or implementation errors. In some cases the provision of security protection depends upon specific functionality being present, as in the case of audit record storage.

Countermeasure Application:
Choose O.Fail_Secure to prevent the loss of security protection. Choose both O.Fail_Secure and O.Fault_Tolerance to prevent the loss of security protection and to provide availability. Objectives that counter this attack should be supplemented with assurance requirements commensurate with the desired degree of protection.


Attack Description:
A perpetrator disseminates malicious code via push or pull mechanism.

Attack-Selection Guidance:
The human can effect the dissemination of the code by using push or pull technologies (email, ftp, http gets, Java applets, etc.).  The human can be a person who is destructive in nature and has malicious intent. This may include the programmer of the code or someone who has knowledge of the code's existence.  Therefore this malicious human is deliberate in their actions and in this case is called a perpetrator.

Countermeasure Application:
Choose O.Obj_Protection and/or O.Remote_Execution to limit opportunities.
Choose O.Code_Signing to deter the attack and facilitate detection.
Choose O.Input_Inspection to detect and prevent the attack before it can succeed.
Choose O.General_Integ_Checks to detect the attack after it has occurred.
Choose O.Clean_Obj_Recovery to recover from the attack after it has occurred.


Attack Description:
A perpetrator executes malicious code either remotely or locally.

Attack-Selection Guidance:
If the human is the threat agent and is the perpetrator, the likelihood of attack being accidental is low. This attack execution can be at the time of the download or later after the code has been downloaded.  The perpetrator would have to have to gain access to the system to execute the code if it is at a later time then the original download.

Countermeasure Application:
Choose O.Admin_Code_Val and/or O.Remote_Execution to prevent execution of potentially malicious code; choose O.I&A_User_Action, and perhaps O.Trusted_Path or O.Trusted_Path&Channel to support O.Admin_Code_Val.
Choose O.Code_Signing and O.General_Integ_Checks to detect the attack.
Choose O.Isolate_Executables to limit results of the attack.
Choose O.Clean_Obj_Recovery to recover from the attack after it has occurred.


Attack Description:
An IT device accidentally transfers or downloads malicious code to itself or other device that it can influence.

Attack-Selection Guidance:
The dissemination of the malicious code can be done by an IT device automatically (email server, router, etc.).  Also, an IT device can either push or pull the malicious code using processes that are designed to perform such actions.  To determine the attitude of the IT device one would have to look at the intent of the OS and application software programmers, the system administrators and operators.  But by normal design these devices are not maliciously derived. Therefore, an IT device is normally disseminating malicious code in a neglectful or unintentional manner.  The devices do not normally include functionality to detect malicious code.

Countermeasure Application:
Choose O.Code_Signing and O.General_Integ_Checks to detect the attack.
Choose O.Input_Inspection and O.Obj_Protection to detect the attack before it can lead to harm.
Choose O.Clean_Obj_Recovery to recover from the attack after it has occurred.


Attack Description:
An IT device under normal operations enters a state required to execute the malicious code.

Attack-Selection Guidance:
The execution of malicious code is done through a triggering event.  If the triggering event were automatically triggered through some state of the infected system, the potential threat agent would be the system itself.

Countermeasure Application:
Choose O.Admin_Code_Val to prevent execution of potentially malicious code; choose O.I&A_User_Action to support O.Admin_Code_Val.
Choose O.Code_Signing and O.General_Integ_Checks to detect the attack.
Choose O.Isolate_Executables to limit results of the attack.
Choose O.Clean_Obj_Recovery to recover from the attack after it has occurred.


Attack Description:
An authorized user accidentally downloads malicious code.

Attack-Selection Guidance:
For example, the user can effect the dissemination of the code by using push or pull technologies (email, ftp, http gets, Java applets, etc.).  The nature of the user that disseminates the code can be a person who is performing normal day-to-day functions and accidentally disseminates the code.

Countermeasure Application:
Choose O.Obj_Protection to limit opportunities.
Choose O.Code_Signing to limit opportunities for the attack.
Choose O.Input_Inspection to detect and prevent the attack before it lead to damage.


Attack Description:
An authorized user executes malicious code accidentally.

Attack-Selection Guidance:
For example, an authorized user may complete an action that triggers the execution of malicious code.  This triggering event could be either by starting an executable piece of code, causing the IT system to get to a state upon which the execution takes place, or where an object that has been modified is accessed.


Attack Description:
A system allocates so many resources that not enough are left for a critical component to function correctly.

Attack-Selection Guidance:
For example, a user starts so many processes that the process table fills and a critical system process cannot start, or claims so much disk space that not enough is left for audit storage.


Attack Description:
An unintentional, malicious, or environmentally caused power reset occurs, resulting in the loss of critical information or the system to enter a non-secure state.

Attack-Selection Guidance:
For example, a system administrator may accidentally hit the system "reset" button while operating on a TSF database, and have its contents corrupted with insecure values.

Countermeasure Application:
Choose either O.Trusted_Recovery or O.Atomic_Functions, or both. 
---
For both alternatives, O.Trusted_Recovery provides the capability to recover from power failures and O.Atomic_Functions automatically recovers and prevents the loss of security protection.


Descriptive Name:
Denial of having received data from another local user

Attack Description:
A local, authorized user receives a message from another local user via the system, and then denies having received it.  This typically affects the sender of the message who is counting on responsibilities associated with receipt of the message.

Attack-Selection Guidance:
Typically, the denial is made in order to evade responsibilities incurred as a result of receiving the message (e.g., payment for information received).

Countermeasure Application:
O.NonRepud_Locals_Rcvd not only detects repudiation but prevents avoidance of accountability.  The preventive effect may be more effective if it is advertised in user documentation.


Descriptive Name:
Denial of having received information from a remote user

Attack Description:
A local, authorized user receives a message from another user at a remote trusted product, and then denies having received it.

Countermeasure Application:
Choose O.NonRepud_Gen_Recd and allocate this objective to the TOE.  This objective not only detects repudiation but prevents avoidance of accountability.  The preventive effect may be more effective if it is advertised in user documentation. 

In the event that the nonrepudiation evidence is generated for a remote user or administrator, also choose objective O.NonRepud_Assess_Recd, allocating this objective to the environment.


Descriptive Name:
Denial of having received information by a remote user

Attack Description:
A local, authorized user sends a message to another user at a remote trusted product who then denies having received it.

Countermeasure Application:
Choose O.NonRepud_Gen_Recd and allocate this objective to the IT environment.  This objective not only detects repudiation but prevents avoidance of accountability.  The preventive effect may be more effective if it is advertised in remote user documentation. 

In the event that the nonrepudiation evidence is generated for a local user or administrator, also choose objective O.NonRepud_Assess_Recd, allocating this objective to the TOE.


Descriptive Name:
Denial of having sent information to another local user

Attack Description:
A local, authorized user sends a message to another local user via the system, and then denies having done it.  This affects the recipient of the message as well as any resources allocated or modified by the recipient in response to the message.

Attack-Selection Guidance:
Typically, the denial is made in order to evade responsibilities incurred as a result of sending the message (e.g., retaliation for sending false or confidential information).

Countermeasure Application:
O.NonRepud_Locals_Sent not only detects repudiation but prevents avoidance of accountability.  The preventive effect may be more effective if it is advertised in user documentation.


Descriptive Name:
Denial of having sent information to a remote user

Attack Description:
A local, authorized user sends a message to another user at a remote trusted product, and then denies having done it.  This affects the recipient of the message as well as any resources allocated or modified by the recipient in response to the message.

Countermeasure Application:
Choose O.NonRepud_Gen_Sent and allocate this objective to the TOE.  This objective not only detects repudiation but prevents avoidance of accountability.  The preventive effect may be more effective if it is advertised in user documentation. 

In the event that the nonrepudiation evidence is generated for a remote user or administrator, also choose objective O.NonRepud_Assess_Sent, allocating this objective to the environment.


Descriptive Name:
Denial of having sent data by a remote user

Attack Description:
A local, authorized user receives a message from another user at a remote trusted product who then denies having sent it. This affects the recipient of the message as well as any resources allocated or modified by the recipient in response to the message.

Countermeasure Application:
Choose O.NonRepud_Gen_Sent and allocate this objective to the IT Environment.  This objective not only detects repudiation but prevents avoidance of accountability.  The preventive effect may be more effective if it is advertised in user documentation for the remote user.

In the event that the nonrepudiation evidence is generated for the recipient or a local administrator, also choose objective O.NonRepud_Assess_Sent, allocating this objective to the TOE.


Descriptive Name:
Circumvent non-repudiation in a transaction involving a user and a local system

Attack Description:
An authorized user participates in a transaction by responding to system/application prompts and then denies that the dialogue took place.  The user and system/application are collocated.

Attack-Selection Guidance:
An example of such a transaction is a user that updates a local database.

Countermeasure Application:
Choose O.NonRepud_Locals_Rcvd, O.NonRepud_Locals_Sent, and O.I&A_Transaction.  Be careful to use consistent component applications (e.g., so that the same administrator is cognizant of all nonrepudiation evidence for events in a given transaction).


Descriptive Name:
Circumvent non-repudiation in a transaction involving a local user and a remote system

Attack Description:
An authorized user participates in a transaction by responding to remote system/application prompts and then denies that the dialogue took place.

Attack-Selection Guidance:
This attack is seen from the perspective of the potential threat agent, who may require credibility in order to perform the transaction.  An example of such a transaction is a user that performs a purchase over the Internet and the seller requires protection from repudiation by the buyer who doesn't want to pay.

Countermeasure Application:
Choose O.I&A_Transaction. Choose the following objectives allocated to TOE or environment as indicated:
   O.NonRepud_Gen_Recd allocated to the TOE
   O.NonRepud_Gen_Sent allocated to the TOE
   O.NonRepud_Assess_Recd allocated to the environment
   O.NonRepud_Assess_Sent allocated to the environment.

Be careful to use consistent component applications (e.g., so that the same user or administrator is cognizant of all nonrepudiation evidence for events in a given transaction).


Descriptive Name:
Circumvent non-repudiation in a transaction involving a remote user and a local system

Attack Description:
An authorized remote user participates in a transaction by responding to local system/application prompts and then denies that the dialogue took place.

Attack-Selection Guidance:
An example of such a transaction is a remote user who performs a purchase over the Internet, and the local seller requires protection from repudiation by the buyer who doesn't want to pay.

Countermeasure Application:
Choose O.I&A_Transaction. Choose the following objectives allocated to TOE or environment as indicated:
   O.NonRepud_Gen_Recd allocated to the environment
   O.NonRepud_Gen_Sent allocated to the environment
   O.NonRepud_Assess_Recd allocated to the TOE
   O.NonRepud_Assess_Sent allocated to the TOE

Be careful to use consistent component applications (e.g., so that the same user or administrator is cognizant of all nonrepudiation evidence for events in a given transaction).


Descriptive Name:
System use uncovers an intrinsic software flaw in a critical system component

Attack Description:
An authorized user performs an operation or set of operations, exercising a software flaw in a security-critical component.

Attack-Selection Guidance:
The flaw may be a result of design or implementation errors. An example of this attack is when a hostile user performs stress testing that causes an operating system to enter an unsecure state.


Descriptive Name:
Accidental release of cryptographic assets due to TSF flaw or malfunction

Attack Description:
The TSF accidentally releases sensitive plaintext data, red keys, or other cryptographic assets to an inappropriate audience.


Descriptive Name:
User smuggles data using removable media

Attack Description:
A user collects sensitive or proprietary information and improperly removes it from the system by putting it on removable media.

Countermeasure Application:
Choose O.Audit_Account objective to provide user accountability.

Choose O.User_Defined_AC and/or O.Info_Flow_Control to prevent the gathering of arbitrary user data.

Choose O.Data_Imp_Exp_Control to prevent the attack by restricting what can be written to removable media.  Choose O.Admin_Guidance to support O.Data_Imp_Exp_Control.


Attack Description:
An authorized user hides sensitive information in an innocuous-appearing file, for the purpose of covertly passing it to an unauthorized party.  The hidden data is undetectable to anyone using the file for its intended purpose, but can be recovered using special techniques.

Attack-Selection Guidance:
This attack is relevant to systems that contain data of varying sensitivities and provide greater opportunity for disseminating less sensitive information. 
In a typical attack, the user embeds sensitive information in a digitally encoded picture or audio file, where the added bits do not significantly modify the perceived image or sound track.
Another example is to embed information in unused or under-populated fields in a message header.
Document processors provide still more examples by providing hidden fields that give information about the document processor's software license number, the document's author, or the identity of the computer being used.  In particular, word processors are providing an increasing array of information-hiding techniques for their users to employ, including hidden comment tags, hidden text, autotext, conditional text, document variables, hidden macros, previous-version data, uncollected "garbage," and more.

This attack is traditionally considered to be deliberate, as good steganographic techniques are unlikely to be accidental.  However, word processors are increasingly making accidental steganography easy, if not unavoidable.

Steganographic smuggling can be difficult to detect on the basis of direct evidence.  Without knowing the decryption technique, it is usually not feasible to tell steganographicly encrypted data from unencrypted data. However, there are some defenses against it.

Countermeasure Application:
Choose O.Admin_Code_Val_Sten to avoid the use of programs that might be capable of performing steganographic hiding. Choose O.Data_Export_Control to sanitize outputs to make steganography more difficult.  Choose O.Standard_Output_Pres to require the use of highly structured objects in which all data is both visible and needed, leaving no place for steganographic data to hide.


Attack Description:
An authorized user abuses granted authorizations by browsing files in order to collect data.

Countermeasure Application:
To detect this attack, choose the O.Audit_Generation objective.
To prevent this attack, choose the O.User_Defined_AC and O.Info_Flow_Control objectives.


Descriptive Name:
User collects authentication data by deception

Attack Description:
An authorized user steals authentication data by emulating a login procedure on an active terminal.

Attack-Selection Guidance:
For example, a user programs a terminal or workstation to simulate an inactive status, allowing that user to intercept authentication data or other confidential data that other users exchange with the terminal when they attempt to log in.

Countermeasure Application:
To detect this attack, choose the O.Access_History objective.
To prevent this attack, choose the O.Trusted_Path objective.


Attack Description:
An authorized user abuses granted authorizations by repeatedly accessing aggregate data in order to deduce specific, sensitive data.

Attack-Selection Guidance:
For example, a user with access to aggregated data, employing carefully planned queries, can compute or otherwise deduce the value of specific data elements to which he is not authorized. The user may ask for the average cost of a certain collection of nine projects and then for the average cost of those nine plus a tenth project. Each response gives no specific information about any of the projects and a user with a minimal right to know may be allowed this information. However, it is a simple task for him to use the two responses to compute the exact cost of the tenth project, information he may not be authorized to obtain.


Attack Description:
An authorized user abuses granted authorizations by eavesdropping on communication lines in order to collect data.

Attack-Selection Guidance:
For example, a user configures network software to collect network packets not addressed to the user's workstation.

Countermeasure Application:
To prevent this attack, choose O.Data_Exchange_Conf, O.Security_Roles, and O.Integ_User_Data_Int objectives.


Attack Description:
An authorized user collects residual data from public objects after prior usage.

Countermeasure Application:
To prevent this attack, choose O.No_Residual_Info.


Descriptive Name:
User's unauthorized use causes overload of communication resources

Attack Description:
An authorized user exceeds the authorized use of communication resources during the system (TOE) operation.  This causes a denial or delay in service to legitimate operations within the TOE scope of control.

Attack-Selection Guidance:
This attack covers the case where excess use interferes with the TOE's ability to perform its security functions.  Such would be the case if multiple user-generated concurrent communications sessions cause bandwidth overload.

See also attack DA.Hack_Comm_Overload

Attack Editorial:
1. When a user has the ability to give out information that could cause an outsider to send data that is not deemed acceptable by the organization's policy or from a location unacceptable by the organization's policy this objective should be considered (e.g. adult only web sites). 

2. When a user has the ability to send data to inappropriate locations or to more locations than the organization's policy allows this objective should be considered.

3. When a hacker can flood the system (TOE) with illicit data, import control should be enforced.


Descriptive Name:
Falsification of information quality in data export

Attack Description:
An authorized user presents incorrect information, indicating to the recipient that it is correct, thereby encouraging the recipient to make unwarranted use of the information.

Attack-Selection Guidance:
For example, user may misrepresent the authorship of the data or misrepresent the extent of review and approval behind it. This is an error of commission.


Descriptive Name:
Under-classification of data sensitivity on export

Attack Description:
An authorized user presents confidential or classified information to a recipient, indicating that it is less sensitive than it really is, thereby encouraging the recipient to pass it along to other potentially inappropriate recipients.

Attack-Selection Guidance:
For example, the user may misrepresent a copyright statement, military security classification, or public-release status. This may be an error of commission or omission depending on whether the information is properly labeled to begin with.


Descriptive Name:
Accidental release of cryptographic assets due to user error

Attack Description:
User error causes release of cryptographic assets to unauthorized recipients.


Descriptive Name:
Confidentiality violation of export control policy

Attack Description:
An authorized user exposes or exports data in violation of export control policy. The data may be private or classified, the recipient is not authorized to receive it.

Attack-Selection Guidance:
Depending on the degree of automated support for confidentiality, this attack may well be accidental.


Descriptive Name:
User accidentally releases incorrect information

Attack Description:
An authorized user presents incorrect information to a recipient who is expecting correct information.

Attack Editorial:
Several objectives need to be written.  Maintaining internal integrity labels, importing data with appropriate labels, restrictions on exporting unlabeled data (e.g., requiring a "DRAFT" label on exported low-integrity data), accepting corrective feedback on incorrect exported data, tracing the causes of such errors, etc.


Attack Description:
An authorized user accidentally deletes user data.

Attack-Selection Guidance:
Examples include the following:
User accidentally deletes data by striking the wrong key on the keyboard or by striking the enter key as an automatic response.
User does not understand the implications of the prompt at hand and inadvertently gives a response that deletes user data.
User misunderstands a system command and issues a command that unintentionally deletes user data.


Descriptive Name:
User error modifying attributes availability

Attack Description:
An authorized user erroneously modifies the initial security attributes of user data, which makes the data inaccessible.

Attack-Selection Guidance:
Examples include the following:
User accidentally modifies data attributes incorrectly by striking the wrong key on the keyboard or by striking the enter key as an automatic response and thus makes the data inaccessible.

User does not understand the implications of the prompt at hand and inadvertently gives a response that modifies data attributes incorrectly. The resulting attributes make the data inaccessible.

User misunderstands a system command and issues a command that unintentionally modifies data attributes incorrectly. The resulting attributes make the data inaccessible.


Descriptive Name:
Failure to provide object security attributes in data export

Attack Description:
An authorized user deliberately or accidentally exports data so that the data is not accompanied by required handling information.

Attack-Selection Guidance:
Examples of required handling information include copyright statement, military security classification, authorship, and review status.
This attack may also cause integrity and confidentiality breaches:
The user may present incorrect information without warning the recipient that it may be incorrect, thereby causing the recipient to make unwarranted use of the information. 
The user may present confidential or classified information without mentioning its sensitivity, thereby causing the authorized recipient to pass the information along to unauthorized recipients.


Attack Description:
An authorized user sets an object's security attributes inappropriately, misdirecting its use.  The misdirection may allow unauthorized reading or modification, or it may prohibit authorized reading or modification.

Attack-Selection Guidance:
The error may occur either through ignorance or accidentally as a side-effect of other actions.


Descriptive Name:
User error setting attributes availability

Attack Description:
An authorized user erroneously sets the initial security attributes of user data, which makes the data inaccessible.

Attack-Selection Guidance:
Examples include the following: 
User accidentally sets initial data attributes incorrectly by striking the wrong key on the keyboard or by striking the enter key as an automatic response and thus makes the data inaccessible.

User does not understand the implications of the prompt at hand and inadvertently gives a response that sets initial data attributes incorrectly. The resulting attributes make the data inaccessible.

User misunderstands a system command and issues a command that unintentionally sets initial data attributes incorrectly. The resulting attributes make the data inaccessible.


Descriptive Name:
Denial of service due to exhausted audit storage

Attack Description:
An authorized user's actions generate so many audit records that audit storage space is exhausted and the system subsequently denies further service until audit storage becomes available.

Attack-Selection Guidance:
The relevancy in this attack is a product of a user using resources, storage area (memory or disk space) to an extent that the area designated for use by audit data is no longer available.  This would happen when the OS does dynamic allocation of storage area for multiple needs.


Attack Description:
An authorized user modifies audit data or audit attributes to avoid accountability.

Attack-Selection Guidance:
Examples include the following:
A user frames another user by modifying audit data in such a way that it seems to prove misconduct on the part of the user being framed.
User sets audit attributes in such a way as to allow inadmissible activities to go unaudited.

Countermeasure Application:
To detect this attack, consider O.Audit_Generation and O.Audit_Gen_User.
To prevent this attack, consider O.Audit_Protect and O.Security_Roles.


Descriptive Name:
User improperly modifies authentication data

Attack Description:
An authorized user changes the authentication data of another user without first masquerading as that user, in a manner that is not consistent with organizational security policy.

Countermeasure Application:
To detect this attack, consider the O.Audit_Account objective.
To prevent this attack, consider O.Security_Data_Mgt objective applied to authentication data.


Attack Description:
An authorized user modifies or deletes user data in violation of organizational policy.

Attack-Selection Guidance:
For example, a user erroneously or deliberately overwrites data so that erroneous data is now marked as correct.

Countermeasure Application:
To detect this attack, consider the O.Audit_Generation.
To prevent this attack, consider the O.User_Defined_AC or O.Info_Flow_Control.


Attack Description:
User modifies or deletes TSF data undermining security protection.

Attack-Selection Guidance:
For example, a user gains access to the TSF and modifies TSF data.

Countermeasure Application:
Choose O.General_Integ_Checks and O.Audit_Generation to detect this attack.

Choose O.User_Defined_AC or O.Info_Flow_Control, together with O.Maintain_Sec_Domain and O.Reference_Monitor to prevent this attack.

Choose O.Config_Management, O.Integ_Sys_Data_Int, and O.Integrity_Practice to recover from this attack.


Descriptive Name:
User obstructs legitimate use of resources.

Attack Description:
An authorized user obstructs the use resources by unauthorized modification of data file, communication channel, or object security attributes.

Attack-Selection Guidance:
This attack is relevant when a user has the ability to modify a data file, communication channel, or object security attributes that could deny the affected resource to a legitimate user.

Countermeasure Application:
Choose O.Tamper_Resistance or O.Tamper_ID if the resource is subject to physical attack. 
Choose O.Manage_Res_Sec_Attr if incorrect or missing security attributes can result in loss of object availability.
Choose O.Priority_of_Service if potential threat agents include legitimate users.


Descriptive Name:
User's unauthorized actions over-task the system causing processor overload

Attack Description:
The system (TOE) has been over-tasked and can not complete the assigned tasking at all or in an expected amount of time. The user invokes processing functions in association with unauthorized activity that leads to overburdening processing resources on the TOE.

Attack-Selection Guidance:
This attack is only relevant when processing resources may not be adequate to handle all potential processes.  Therefore if processing capability will never be overburdened do not include this attack.

Countermeasure Application:
Choose O.Limit_Comm_Sessions if the user can cause processor overload by use of multiple sessions.
Choose O.Priority_Of_Service if non-priority services can use processor resources that critical services need.
Choose O.Resource_Quotas if particular services or applications the user starts should be given resource quotas to allow them to run as expected.
Choose O.Audit_Generation to detect the attack.


Descriptive Name:
User sends data violating confidentiality

Attack Description:
An authorized user abuses granted authorizations and violates export control policy by sending data to a recipient who is not authorized to receive the data.

Countermeasure Application:
Choose O.Audit_Generation to detect this attack.
Choose O.Integ_Data_Mark_Exp to prevent this attack.


Attack Description:
An authorized user deliberately exports data inappropriately, with the result that there is a lack of required quality control on the exported data.


Descriptive Name:
User's unauthorized actions cause storage overload

Attack Description:
An authorized user's unauthorized use of data storage causes a shortage of disk space for other users.

Attack-Selection Guidance:
For example, a user continues to store unauthorized objects and data until storage limits are exceeded and the system can no longer operate correctly. This attack is not applicable if the user will never exceed the storage limits available for all possible operations during the system's lifetime.


# Detailed Policy Statement/Objective Mapping

X-Ray:
Administrators must be kept informed of relevant threats and vulnerabilities and how to securely operate the TOE in the presence of identified and emerging threats and vulnerabilities.


X-Ray:
Users must be kept informed of relevant threats and vulnerabilities, how to report new threats and vulnerabilities, and how to apply relevant security mechanisms.


Objective Application:
Choose either variant of this objective (i.e., Subset or Complete). The Complete variant is recommended for a stronger
implementation of the need-to-know principle.

X-Ray:
FDP_ACC.1, FDP_ACC.2:
SFP: Need-to-Know.
Objects: those requiring need-to-know protection.
Subjects: those that may access the protected objects.
Operations: that that may extract information from the protected objects.

FDP_ACF.1:
SFP: Need-to-Know.
Attributes: 
     Object ownership: individuals or groups with designated need to know, optionally, operations that may be used to observe object content. 
     Rules governing access: state that (1) only those with designated need to know may observe, (2) only owners may alter attributes (possibly with suitable administrative override), and (3) only designated users (e.g., owners) may control object content.

Objective Rationale:
The SFP gives object owners the ability to restrict direct access to those with a designated need to know.  However, those with a need-to-know (and processes acting on their behalf) must be trusted to themselves enforce need-to-know constraints.


Policy/Objective Editorial:
<JMB> Old data from original O.Tamper_ID_Respond objective.

ID. O.Tamper_ID_Respond

Descriptive Name. Protect users from adverse consequences of physical damage to the system

Description. Provide system features that indicate when the system (TOE) has been tampered with, and use those features to limit security breaches resulting from physical damage.

Editorial. If the TSF protects the availability of user data, then the TSF must be able to detect loss of user data as a result of physical damage. However, the invoked CC components only address the TSF and not the entire TOE, and so refinement is needed.


# Detailed Policy Statements

Descriptive Name:
Changes to security data by authorized personnel

Detailed policy Description:
Provide mechanisms to assure that changes to security related data are executed only by authorized personnel.


Detailed policy Description:
The system shall provide individual accountability for auditable actions.


Detailed policy Description:
The system shall provide the capability to ensure that all audit records include enough information to determine the date and time of action, the system locale of the action, the system entity that initiated or completed the action, the resources involved, and the action involved.


Detailed policy Description:
The system shall protect the contents of the audit trails against unauthorized access, modification, or deletion.


Descriptive Name:
Notification of threats and vulnerabilities

Detailed policy Description:
Notification of threats and vulnerabilities shall be addressed.


Detailed policy Description:
Notify user of the time and date of the last modification of data.

Policy-Selection Guidance:
This is a generic policy that needs to be instantiated to say which data needs notification.


Detailed policy Description:
A configuration management plan shall be implemented by the system. The system shall implement configuration management to assure storage integrity, identification of system connectivity (software, hardware, and firmware), and identification of system components (software, hardware, and firmware).
The system shall implement strong integrity mechanisms (integrity locks, encryption).


Detailed policy Description:
The system shall provide procedures and features to assure that system recovery is done in a trusted and secure manner. Any circumstances that could result in an untrusted recovery shall be documented.


Detailed policy Description:
The system shall provide security parameters associated with information exchanged between systems.


Detailed policy Description:
The system shall provide Identification and authentication (I&A) procedures which uniquely identify and authenticate users.


Detailed policy Description:
The system shall implement strong integrity mechanisms (integrity locks, encryption).


Descriptive Name:
Operational integrity system function testing

Detailed policy Description:
Provide system functional tests to periodically test the integrity of the hardware and code running system functions.


Detailed policy Description:
Security shall be addressed throughout the system's lifecycle.


Detailed policy Description:
The system administrators shall provide preventive maintenance.


Detailed policy Description:
Procedures and mechanisms to prevent the introduction of malicious code into the system shall be provided.


Detailed policy Description:
The system shall function so that each user has access to all of the information and functions that the user requires to perform duties, but no more.


Detailed policy Description:
The system shall provide non-repudiation capabilities.

Policy-Selection Guidance:
An example of a non-repudiation mechanism is an implementation of digital signatures.


Detailed policy Description:
Documentation shall include guides or manuals for the system's privileged users.


Detailed policy Description:
The system shall provide a screen lock mechanism.


Descriptive Name:
Assurance of effective storage integrity

Detailed policy Description:
The system shall provide assurance that storage integrity is effective.


Detailed policy Description:
The system shall notify users prior to gaining access that the user's actions may be monitored and recorded, that using the system consents to such monitoring, and that unauthorized use may result in criminal or civil penalties.


Descriptive Name:
Validation of security function integrity

Detailed policy Description:
Features and procedures to validate the integrity and the expected operation of the security-relevant software, hardware, and firmware shall be provided by the system.


Detailed policy Description:
Provide the capability to restore the system to a secure state after discontinuities of system operations.


Detailed policy Description:
The system shall provide backup procedures to allow restoration of the system with minimal loss of service or data.


Detailed policy Description:
The system shall provide procedures to ensure both the existence of sufficient backup storage capability and effective restoration (incremental and complete) of the backup data.


Detailed policy Description:
The system shall provide appropriate physical and technical protection of the backup and restoration hardware, firmware, and software.

Safeguard Application:
The objective O.Sys_Backup_Verify does not provide complete coverage of this policy.  Additional objectives need to be defined. Currently detection of failure is accounted for but not prevention of failure.


Descriptive Name:
Protection from security function modification

Detailed policy Description:
Provide features or procedures for protection of the system from improper changes.


Detailed policy Description:
Provide procedures and features to assure that system recovery is done in a trusted and secure manner.


Descriptive Name:
Physical tampering detection and notification

Detailed policy Description:
The system shall detect physical tampering and notify the appropriate authority.


Descriptive Name:
Enhanced user identification and authentication

Detailed policy Description:
The system shall require the use of enhanced authentication for privileged users who either reside outside of the system's perimeter or whose communications traverse data lines outside of the system's perimeter.


Detailed policy Description:
The system shall provide data transmission using an encryption mechanism appropriate for the sensitivity of the data.


Detailed policy Description:
The system shall provide appropriate storage, continuous personnel access control storage, or encrypted storage of data based on the sensitivity of the data.

Safeguard Application:
O.User_Data_Integrity covers part of this policy, but an additional objective dealing with confidentiality may be needed.


Detailed policy Description:
The system shall provide a protected distribution system for data transmitted.


Detailed policy Description:
The system shall provide a Discretionary Access Control (DAC) function (i.e., a user can grant access authorization to other users for data they control).

Policy Editorial:
"Data" is a compromise between "information" and "object". The issue is that DAC does not necessarily control access to information.


Detailed policy Description:
Documentation shall include a user's guide for the general user.


# DKORs

Observation:
To write a Domain Knowledge Observation Report, 
     * Select a table to report on (choose * for a general observation)
     * Select a record in the table (choose * for a general observation)
     * Fill in the Summary field
     * Check to be sure that the Author field describes yourself
     * Optionally, fill in the Observation, Solution and other fields.

Recommendation:
Observations about the deisgn of the knowledge base may be e-mailed to the authors at cc-pkb@nist.gov.


# General Assumptions

Description:
The TOE relies on an IT system software environment, and TOE users cannot unintentionally overwrite any system programs, logs, or data.

Selection Guidance:
This assumption is appropriate if the TOE is a trusted application, e.g., a trusted database system.


Description:
Physical protection of the communications to the system is adequate to guard against unauthorized access or malicious modification by users.


Description:
TOE password files are protected so that users can neither access nor modify them outside of authorized TOE functions.

Selection Guidance:
Depricated (See Toolbox User Manual).  Consider replacing this with suitable threats, e.g., attackers might steal the password file as part of a masquerade attack, or might corrupt the password file as part of a denial-of-service attack.

Assumption Editorial:
The idea here is to provide a caution in the User's manual to the effect that some Assumptions, though legal, are considered highly undesirable.


Description:
System Administrators have the ability to corrupt data that is in transit to/from the system.

Selection Guidance:
This is a TOE Assumption: consider placing it in the TOE Description section rather than the Environment section.

Assumption Editorial:
We didn't really understand this one.  
Examples — TOE is depending on outside sources (e.g., firewalls) that are corruptible by administrators.  Real problem:  TOE is relying on corruptible outside systems for data.  Recast as a threa


Description:
System Administrators follow the policies and procedures defined in the TOE documentation for secure administration of the TOE.

Selection Guidance:
Consider combining this with similar Assumptions such as Competent_Admin, No_Abuse_by_Admin, and Well_Behaved_Admin.  Consider adding CC Requirement AGD_ADM.

Assumption Editorial:
Good example of an assumption. Doesn't work as a policy by itself, as the policy might not be followed.


Description:
System administrators are fallible and occasionally make errors that compromise security.

Selection Guidance:
Clarify either by adding Threats such as Admin_Err_Commit and Admin_Err_Omit, or by explicitly stating that such threats are considered beyond the scope of the PP.  Consider combining with the Negligent_Admin and Poor_Trained_Admin Assumptions.

Assumption Editorial:
The intent of this Assumption is unclear as stated.  The Attitude, Motive, and Sophistication Attributes need to be combined.  These distinctions may be important for dealing with the threat agents themselves, but are less useful for distinguishing the attacks that they commit, as can be seen from which combinations of attributes occur frequently in the database Attribute table.


Description:
System Administrators follow policies and procedures to prevent TOE contamination by software viruses.

Selection Guidance:
Consider casting this as an Organizational Security Policy. Doing so will more clearly indicate the consequences for TOE Description and will more clearly distinguish this from competing policies such as privilege based on physical access to the TOE.  Consider Threats in the Admin Threat Category.


Description:
System Administrators are authenticated and held accountable for their actions.

Selection Guidance:
Consider casting this as a general Policy statement rather than as an Assumption.
Note consequences for TOE Description.


Description:
System administrators are competent to manage the TOE and the security of the information it contains.

Selection Guidance:
Consider combining this with similar Assumptions such as Admin_Docs, No_Abuse_by_Admin, and Well_Behaved_Admin.


Description:
Users cooperate with those responsible for managing the TOE to maintain TOE security.

Selection Guidance:
Note similarity to the slightly stronger Trusted_User Assumption.

Assumption Editorial:
Doesn't work as a policy, since users might not follow the policy.


Description:
System Administrators properly dispose of user data after access has been removed (e.g., due to job termination, change in responsibility).

Selection Guidance:
Note that this assumption constrains both the TOE and its administrators.  Consider adding a corresponding assumption to the TOE description.  Consider treating as a Policy rather than an Assumption.

Assumption Editorial:
Miscast, as the user may have access to data that he/she didn't own.Policy: when users leave, administrators terminate their accounts. Pair with the threat of an ex-user stealing or corrupting data.


Description:
Data sent across external communications lines are protected to ensure that they are unintelligible to outsiders using data capturing techniques (e.g., sniffers).

Selection Guidance:
Consider recasting as a threat against communications lines. As stated, this appears to be a TOE Description Statement: consider placing it in the TOE Description section rather than the Environment section.

Assumption Editorial:
Lots of ambiguities here. Distributed TOE? Incoming: encrypted?  Outgoing: Protected in the environment?


Description:
System Administrators cannot be trusted and are considered to be hostile.

Selection Guidance:
Consider treating as a General Threat rather than as an Assumption.

Assumption Editorial:
Consider treating as a General Threat rather than as an Assumption.  Consider Threats in the Admin Threat Category.


Description:
Users cannot be trusted and are considered to be hostile.

Selection Guidance:
Consider treating as a General Threat rather than as an Assumption. Consider threats in the User Threat Category.

Assumption Editorial:
Difficult to fully counter.  Better as a policy?  Why not as an Assumption: the statement isn't too helpful because we don't know if the system is supposed to counter the ill-effects of misbehaving users.  Secondary question: if they're hostile, do you care?


Description:
System Administrators managing security-relevant data may be negligent and therefore cannot be relied upon to perform their job in a way that guarantees the security of the system.

Selection Guidance:
Clarify either by adding Threats such as Admin_Err_Commit and Admin_Err_Omit, or by explicitly stating that such threats are considered beyond the scope of the PP.  Consider combining with the Admin_Errors and Poor_Trained_Admin Assumptions.


Description:
System Administrators are trusted not to abuse their authority.

Selection Guidance:
Consider combining this with similar Assumptions such as Admin_Docs, Competent_Admin, and Well_Behaved_Admin.


Description:
The TOE environment is divided into trusted and untrusted systems.  All communication between trusted and untrusted systems is mediated by the TOE.  Thus, users cannot bypass the security mechanisms of the TOE.

Selection Guidance:
This assumption on the IT Environment is useful if the TOE is responsible for protecting assets outside of the TOE, as when the TOE is a firewall.

Assumption Editorial:
This originally came from a firewalls PP.  The wording needs to make it clear that it this is not intended as a summary of FDP_SEP.


Description:
The TOE is subject to deliberate attack by experts with advanced knowledge of security principles and concepts employed by the TOE.

Selection Guidance:
Consider treating as a General Threat rather than as an Assumption.  Deliberate attack is possible from both users and outsiders, more likely the latter.


Description:
The TOE is subject to deliberate attack by laymen with no particular expertise.


Description:
The TOE is subject to deliberate attack by threat agents proficient in the security behavior of the system.


Descriptive Name:
Password management promoting user compliance

Description:
System Administrators follow password management policies and procedures to ensure users comply with password policies.

Selection Guidance:
Combine with a Password Policy and a General Threat covering user failure to follow the policy.

Assumption Editorial:
This is an Assumption that relies on a threat and a policy.


Description:
Any other systems with which the TOE communicates are assumed to be under the same management control and operate under the same security policy constraints.

Selection Guidance:
This Assumption is useful and enforceable within a local organization that is under centralized control, but not between organizations.  Recast this as a Policy, if direct TOE support is envisioned (e.g., TOE checks input for obvious policy discrepancies).  In any case, this Assumption has consequences for TOE Administrative documentation.


Description:
The TOE is located within controlled access facilities that prevent unauthorized physical access by outsiders.

Selection Guidance:
This may be treated either as an Assumption or as a Policy allocated to the non-IT environment.


Description:
Systems administrators do not have adequate security training.

Selection Guidance:
Clarify either by adding Threats such as Admin_Err_Commit and Admin_Err_Omit, or by explicitly stating that such threats are considered beyond the scope of the PP.  Consider combining with the Admin_Errors and Negligent_Admin Assumptions.


Description:
The system is adequately protected against natural disasters such as fires and floods (e.g., sprinkler systems, alarms, etc.).

Selection Guidance:
This is relevant in systems where availability is a concern.  Tailor to clarify whether this is an assumption about the TOE or about the environment or both.


Description:
The system has adequate backup power sources to ensure that sudden losses of power do not affect availability of service or loss of data.

Selection Guidance:
This is relevant in systems where availability is a concern.  This may be treated either as an Assumption or as a Policy supported by the non-IT environment.


Description:
The system is adequately protected against loss of communications.


Description:
The TOE hardware and software involved in security policy enforcement will be physically protected from unauthorized modification by potentially hostile outsiders.

Selection Guidance:
This is relevant when the TSF is physically separate form the non-TSF portion of the TOE.  Note that the Phys_Acs_to_Out Assumption is simpler and preferable in most cases. This assertion may be treated either as an Assumption or as a Policy supported by the Non-IT environment.


Description:
Users are permitted to access the TOE from remote locations.

Selection Guidance:
Consider treating as a Policy with consequences for both TOE and environment.  Consider adding a note to the TOE description regarding support for remote access.  Consider threats involving remote access by hackers.

Assumption Editorial:
The relevant TOE-Description statement might be: The TOE interacts with its IT environment in such a way as to allow remote use.


Description:
System Administrators have remote access and are able to view and modify security-relevant data.

Selection Guidance:
Consider treating as a Policy with consequences for both TOE and environment.  Consider adding note to TOE description regarding support for remote access.  Consider threats involving remote access by hackers.


Description:
System Administrators review audit logs regularly.

Selection Guidance:
Consider treating this as an Objective that supports higher-level concerns such as the need to detect various kinds of threats.  Alternatively, consider treating this as the combination of an audit Policy (with consequences for administrative documentation) and an Assumption (like the Admin_Docs Assumption).

Assumption Editorial:
Some have claimed that Auditing is not an inherent security concern, but merely a derived objective that stems from other more direct matters.


Description:
Authorized users are trusted not to compromise security.

Selection Guidance:
Note similarity to the slightly weaker Coop_User Assumption.


Description:
Users possess the necessary privileges to access the security-relevant information managed by the TOE.

Selection Guidance:
This assumption has consequences for the TOE Description -- the TOE does not protect management information from the users.

Assumption Editorial:
On the surface, this seems to be saying that the TOE doesn't do a very good job of protecting security-critical data.


Description:
Users are fallible and occasionally make errors that compromise security.

Selection Guidance:
Clarify this Assumption, either by adding Threats such as User_Err_Conf, User_Err_Inaccess, User_Err_Integrity, and User_Err_Slf_Protect, or else by explicitly stating that such threats are considered beyond the scope of the PP.

Assumption Editorial:
Note similarity to Admin_Errors.  Might want to have a question on the extent to which users do their own administration:  Are users permitted (or relied on) to administer their own systems, or is there a true separate administrative role that accomplishes administrative activities (e.g., having an out-of-date browser is an administrative error).


Description:
Users scan software sent from outside the TOE for software viruses.

Selection Guidance:
Consider treating this as an Objective that supports countering a general threat along the lines of Malicious_Code.  Alternatively, consider treating this as the combination of a user Policy (with consequences for user documentation) and an Assumption along the lines of Trusted_User or Coop_User.


Description:
System Administrators are trusted not to compromise security.

Selection Guidance:
Consider combining this with similar Assumptions such as Admin_Docs, Competent_Admin, and No_Abuse_by_Admin.


# General Policy Statements

General Policy Statement Description:
Individuals shall be held accountable for their actions.


Descriptive Name:
Notification of threats and vulnerabilities

General Policy Statement Description:
Appropriate authorities shall be immediately notified of any threats or vulnerabilities impacting systems that process their data.


General Policy Statement Description:
Information shall be used only for its authorized purpose(s).


General Policy Statement Description:
Information shall be available to satisfy mission requirements.


General Policy Statement Description:
Guidance shall be provided for the secure installation and use of the system.


General Policy Statement Description:
Information shall be accessed only by authorized individuals and processes.


General Policy Statement Description:
Information shall retain its content integrity.


Descriptive Name:
System lifecycle phases integrate security

General Policy Statement Description:
Information systems security shall be an integral part of all system lifecycle phases.


General Policy Statement Description:
Information shall be appropriately marked and labeled.


General Policy Statement Description:
Information shall be physically protected to prevent unauthorized disclosure, destruction, or modification.


# General Threats

Threat Description:
An administrator commits errors that directly compromise organizational security objectives or change the technical security policy enforced by the system or application.

Selection Guidance:
Examples of possible administrator errors include entry of erroneous data, erroneous software executions, and careless use of output devices.


Threat Description:
The system administrator fails to perform some function essential to security.

Selection Guidance:
This threat is especially important in systems where administration of security functions is largely manual, and in organizations where system administrators are not well trained or have other responsibilities that are not related to security.
For example, the system administrator does not update system configurations or user account information to reflect current policies, assigned privileges, or user authorizations.


Descriptive Name:
Hostile administrator modification of user or system data

Threat Description:
An administrator maliciously obstructs organizational security objectives or modifies the system's configuration to allow security violations to occur.

Selection Guidance:
This threat is relevant in environments where not all administrators are fully trustworthy and/or are able to make mistakes that could jeopardize security.
Security violations include both direct abuse of privilege (e.g. deleting user files) and administrative actions that allow violations of the intended security policy (e.g., incorrectly changing user attributes).

Coverage Rationale:
The detailed attacks are based on an enumeration of security services from part 2 of the CC.  If the PP includes additional security services, then the coverage is incomplete.  In the likely case that the PP does not include all security functions from Part 2 of the CC, some attacks will be irrelevant and should be ignored.

Threat Editorial:
Separation. This attack is unique in the fact that administrators have very open ability to effect most or any thing within the TSC. Therefore different and unique safeguards may be necessary to automate security functions to prevent the possible administrator's attacks.
Attacks may be grouped in various ways.  The following grouping is a synthesis from the TnC material and the resulting new taxonomy.
     Availability
          Unauthorized Modification of TSF Data
          User Security Attributes set to Obstruct Legitimate User ...
     Confidentiality
          System Administrator Steals User Data
     Integrity
          Modification of Audit Data and Attributes
          Destruction or Modification of Audit Data
     Security Protection
          Inappropriate Modification of Audit Attributes
          Modification of Audit Data and Attributes
          Modification of TSF Code or Data
          Destruction or modification of Audit Data -- done
          Unauthorized Modification of TSF Data
                  of object security attributes -- sort of done


Descriptive Name:
Administrator violates user privacy policy

Threat Description:
An administrator learns the identity (or other privacy related information) of user(s) in violation of user privacy policy. Privacy-related information is sensitive information associated with the identity of a user.


Threat Description:
Failure of one or more system components results in the loss of system-critical functionality.

Selection Guidance:
This threat is relevant when there are components that may fail due to hardware and/or software imperfections and when the availability of system functionality is important.


Threat Description:
A system or applications developer delivers code that does not perform according to specifications or contains security flaws.

Selection Guidance:
An important special case of this threat is when the security flaws prevent the system's security mechanism (TSF) from adequately protecting itself.

Threat Editorial:
Note that component-flaws are treated separately.


Descriptive Name:
Failure of a distributed system component

Threat Description:
Failure of a component that is part of a distributed system will cause other parts of the distributed system to malfunction or provide unreliable results.


Threat Description:
A hacker gains undetected access to a system due to missing, weak and/or incorrectly implemented access control causing potential violations of integrity, confidentiality, or availability.

Selection Guidance:
Improper access can be gained via several methods. One example is a weak password mechanism that allows unintended system access.


Descriptive Name:
Hacker attempts resource denial of service

Threat Description:
A hacker executes commands, sends data, or performs other operations that make system resources unavailable to system users.  Resources that may be denied to users include bandwidth, processor time, memory, and data storage.

Selection Guidance:
One example of this threat is denial of service caused by hacker actions that disrupt the system's ability to manage its resources.


Descriptive Name:
Hacker eavesdrops on user data communications

Threat Description:
Hacker obtains user data by eavesdropping on communications lines.

Selection Guidance:
This threat is relevant when the system must exchange user data with a remote system, and the confidentiality of that data is important.


Threat Description:
A hacker performs cryptoanalysis on encrypted data in order to recover message content.

Threat Editorial:
This threat could easily be broadened to include cryptoanalysis used for other purposes, e.g., to discover a signature key that allows forgery.


Descriptive Name:
Hacker masquerading as a legitimate user or as system process

Threat Description:
A hacker masquerades as an authorized user to perform operations that will be attributed to the authorized user or a system process.

Selection Guidance:
Masquerade normally involves concealment of identity through false pretenses.  It often involves gaining access to a system under a false identity. This threat differs from a hostile insider's abuse of privilege in which a legitimate user takes unfair advantage of system weaknesses.


Threat Description:
A hacker modifies information intercepted from a communication link between two unsuspecting entities before passing it on, thereby deceiving the intended recipient.

Selection Guidance:
The communication link may be between two unrelated systems, between two parts of a distributed system, or between two users of a single system. The consequence of this threat is that the receiver will be receiving information other than that which was intended by the sender, namely information provided by the hacker.


Descriptive Name:
Exploitation of vulnerabilities in the physical environment of the system

Threat Description:
A hacker physically interacts with the system to exploit vulnerabilities in the physical environment, resulting in arbitrary security compromises.

Selection Guidance:
The security compromises could include loss of availability, confidentiality, integrity, and/or security protection. For example, a hacker physically damages the IT system.


Threat Description:
A hacker uses social engineering techniques to gain information about system entry, system use, system design, or system operation.

Selection Guidance:
This threat always exploits non-IT vulnerabilities, possibly in conjunction with IT vulnerabilities.


Threat Description:
An authorized user, IT system, or hacker downloads and executes malicious code, which causes abnormal processes that violate the integrity, availability, or confidentiality of system assets.

Coverage Rationale:
An authorized user, IT system, or hacker downloads an object either deliberately or accidentally.  The user does this primarily in order to gain assets that will assist in their job performance.  The IT system may do this to meet informational requirements.  The hacker may do this in an effort to satisfy destructive goals.  The malicious code is then executed via a trigger mechanism.  The trigger mechanism can be executed automatically after download, manually by the hacker, or unknowingly by the authorized user. The results of the attack affect the target system or any other system that the target system can influence.

Threat Editorial:
Separation. This attack is unique in the fact that administrators have very open ability to effect most or any thing within the TSC. Therefore different and unique safeguards may be necessary to automate security functions to prevent the possible administrator's attacks.
Attacks may be grouped in various ways.  The following grouping is a synthesis from the TnC material and the resulting new taxonomy.
     Availability
          Unauthorized Modification of TSF Data
          User Security Attributes set to Obstruct Legitimate User ...
     Confidentiality
          System Administrator Steals User Data
     Integrity
          Modification of Audit Data and Attributes
          Destruction or Modification of Audit Data
     Security Protection
          Inappropriate Modification of Audit Attributes
          Modification of Audit Data and Attributes
          Modification of TSF Code or Data
          Destruction or modification of Audit Data -- done
          Unauthorized Modification of TSF Data
                    of object security attributes -- sort of done


Descriptive Name:
Unexpected disruption of system or component power

Threat Description:
A human or environmental agent disrupts power causing the system to lose information or security protection.


Threat Description:
The recipient of a message denies receiving the message, to avoid accountability for receiving the message or to avoid obligations incurred as a result of receiving the message.


Threat Description:
The sender of a message denies sending the message to avoid accountability for sending the message or to avoid obligations incurred as a result of sending the message.


Descriptive Name:
A participant denies performing a transaction

Threat Description:
A participant in a transaction denies participation in the transaction to avoid accountability for the transaction or for resulting obligations.


Threat Description:
An attacker tricks users into interacting with spurious system services.

Selection Guidance:
The attack method may involve writing software to spoof users or modifying message protocol information in transit.


Descriptive Name:
Hostile user acts cause confidentiality breaches

Threat Description:
A user collects sensitive or proprietary information and removes it from the system.

Selection Guidance:
Examples include the following:
   * placing confidential information on a removable disk 
   * transmitting data outside the organization.


Descriptive Name:
User abuses authorization to collect data

Threat Description:
User abuses granted authorizations to improperly collect sensitive or security-critical data.

Selection Guidance:
An example of sensitive data is proprietary information. An example of security-critical data is user authentication data.


Descriptive Name:
User errors cause confidentiality breaches

Threat Description:
A user commits errors that cause information to be delivered to the wrong place or wrong person.

Selection Guidance:
This threat is a concern in any system that holds sensitive or classified information and has human users (including administrators). User errors include entry of erroneous data, erroneous software execution, and careless use of output devices.


Threat Description:
A user accidentally deletes user data or changes system data rendering user data inaccessible.


Threat Description:
A user commits errors that induce erroneous actions by the system and/or erroneous statements its users.

Selection Guidance:
This threat is a concern in any system that produces content-critical information and has human users (including administrators). User errors include entry of erroneous data, erroneous software execution (e.g., using uncertified software), and poor choices in the selection of available input data.


Descriptive Name:
User errors undermine the system's security features

Threat Description:
A user commits errors that cause the system or one of its applications to undermine the system's security features.

Selection Guidance:
User errors include entry of erroneous data (including security data), as well as erroneous software execution (e.g., running a program with incorrect privilege settings).


Threat Description:
A user's unauthorized use of resources causes an undue burden on an affected resource.

Selection Guidance:
Improper use by a user is normally deliberate even though the attack results are generally accidental.  A user simply uses the capabilities of the TOE beyond set usage guidelines, possibly without understanding the attack ramifications.

Both this threat and T.User_Err_Inaccess deal with non-malicious loss of availability. This threat has been scoped to system resource availability. By contrast, T.User_Err_Inaccess includes threats to user file availability.

Threat Editorial:
Threat Source: The threat source would be a accidental human being that either is not following policy in efforts to complete action they feel are in the organization's best interest.
Attack Method: The attack method is to create multiple processes or data files in quantities that puts an undue strain on the systems or communication resources.
Results: The results are primarily reduction or denial in availability of resources to legitimate users and applications.
Separation:

Therefore, to scope this threat, the user's attitude in relation to the attack results is generally accidental in nature, their sophistication level as a threat agent is low, and their primary role is that of an application user even though they may have local administrative privileges.  Even though the user may have administrative privileges, to further scope this threat, administrative attacks will be left out and described in either the malicious or accidental administrator threats.

It is worth keeping the threats T.User_Misuse_Avl_Resc and T.User_Err_Inaccess separate because the countermeasures are distinct.


Descriptive Name:
User abuses authorization to modify data

Threat Description:
A user abuses granted authorizations to improperly change or destroy sensitive or security-critical data.

Threat Editorial:
Source: Authorized user
Method: modify
Effect: loss of integrity, loss of availability, loss of security protection


Threat Description:
A user abuses granted authorizations to improperly send sensitive or security-critical data.

Threat Editorial:
Source: Authorized user
Method: send
Effect: loss of confidentiality, loss of integrity


# Objective Extensions (Temporary)

Application:
Support with a CC-Extending component along the following lines: 
Name. FPT_PHP_EMSEC_Design, Physical Emanations Security
Overview. IT equipment that processes sensitive user data may need to avoid the unintended transmission of information-bearing sounds or electromagnetic signals.
Justification of explicit statement.  FDP_UCT.1.1 is similar, but is clearly aimed at deliberate communications, appearing not to cover unintended emanations.  FPT_PHP claims generally to deal with physical protection, but the individual components all address physical modification rather than eavesdropping.
Applicability of Assurance Requirements.  Special skills may well be needed to evaluate satisfaction of this requirement.  However, there are commercial and government testing laboratories that could be consulted.
FPT_PHP_EMSEC_D.1. The TOE shall not emit [assignment: types of emissions] in excess of [assignment: specified limits].
FPT_PHP_EMSEC_D.2. The TOE connecting cables (power supply, communications lines) shall not emit [assignment: types of emissions] in excess of [assignment: specified limits].
Types of emanations: intelligible
Limits:  sufficient to mitigate intelligible emanations when used in conjunction with other objectives.
Objective Rationale. $


Application:
Support with a CC-Extending component along the following lines: 
Name. F_PhysEnv_Cnf.1, Emanations Security
Overview. The physical TOE environment shall provide an effective container that prevents the escape of intelligible electromagnetic and sound vibrations generated by the TOE.
Justification of explicit statement.  This is explicitly an environmental requirement, in contrast to existing Part 2 CC components.
Applicability of Assurance Requirements.  Special skills may well be needed to evaluate satisfaction of this requirement.  However, there are commercial and government testing laboratories that could be consulted.
F_PhysEnv_Cnf.1.1. The physical TOE environment shall not permit the escape of [assignment: type of TOE emissions] in excess of [assignment: specified limit].
Type of emissions: intelligible
Limits:  sufficient to mitigate intelligible emanations when used in conjunction with other objectives.
Objective Rationale. $


Application:
Support with a CC-Extending component along the following lines: 
Name. FPT_PHP_EMSEC_Design, Physical Emanations Security
Overview. IT equipment that processes sensitive user data may need to avoid the unintended transmission of information-bearing sounds or electromagnetic signals.
Justification of explicit statement.  FDP_UCT.1.1 is similar, but is clearly aimed at deliberate communications, appearing not to cover unintended emanations.  FPT_PHP claims generally to deal with physical protection, but the individual components all address physical modification rather than eavesdropping.
Applicability of Assurance Requirements.  Special skills may well be needed to evaluate satisfaction of this requirement.  However, there are commercial and government testing laboratories that could be consulted.
FPT_PHP_EMSEC_D.1. The TOE shall not emit [assignment: types of emissions] in excess of [assignment: specified limits].
FPT_PHP_EMSEC_D.2. The TOE connecting cables (power supply, communications lines) shall not emit [assignment: types of emissions] in excess of [assignment: specified limits].
Types of emissions: intelligible
Limits:  sufficient to mitigate intelligible emanations when used in conjunction with other objectives.
Objective Rationale. $


Application:
Support with a CC-Extending component along the following lines: 
Name. FPT_PHP_EMSEC_Design, Physical Emanations Security
Overview. IT equipment that processes sensitive user data may need to avoid the unintended transmission of information-bearing sounds or electromagnetic signals.
Justification of explicit statement.  FDP_UCT.1.1 is similar, but is clearly aimed at deliberate communications, appearing not to cover unintended emanations.  FPT_PHP claims generally to deal with physical protection, but the individual components all address physical modification rather than eavesdropping.
Applicability of Assurance Requirements.  Special skills may well be needed to evaluate satisfaction of this requirement.  However, there are commercial and government testing laboratories that could be consulted.
FPT_PHP_EMSEC_D.1. The TOE shall not emit [assignment: types of emissions] in excess of [assignment: specified limits].
FPT_PHP_EMSEC_D.2. The TOE connecting cables (power supply, communications lines) shall not emit [assignment: types of emissions] in excess of [assignment: specified limits].
Types of emissions: electromagnetic emissions from TOE and cables.
Limits:  specify to establish a well-defined limit for emanations.
Objective Rationale. The objective deals only with electromagnetic emanations, which is covered by application of FPT_PHP_EMSEC_Design.


# Objective/Component Mapping

Objective/Component Editorial:
Effectiveness depends on accuracy of stored security attributes, on user compliance with procedural constraints on the use of output devices, and on correct functioning of TSF access control mechanisms.


Component Application:
Apply using attributes relevant to labeling on export.


Component Application Rationale:
Authentication is critical for the individual that is capabable of assuming a role that can: (a) modify the user/subject binding mechanism, or (b) delete binding information.


Component Application Rationale:
An unauthorized modification of the user/subject binding mechanism could deny auditing mechanisms from tracing actions made by a subject acting on the behalf of an unauthorized user.


Component Application Rationale:
An unauthorized deletion of user/subject information could deny auditing mechanisms from tracing actions made by a subject acting on the behalf of an unauthorized user.


Component Application:
Refine to specify which user attributes should not be modified by an administrator, in order to protect a user from a malicious or error-prone administrator.


Component Application:
Apply this component to the authentication of the administrator prior to allowing legitimate modification of user attributes.


Component Application:
The administrators should be excluded from modification of user defined attributes.


Component Application:
Access control SFP: software control policy

List of subjects, objects, and operations covered by the SFP: all potentially executable objects


Component Application:
Access control SFP: software control policy

Security attributes: subject attribute value of "installer;" object attribute values "executable" and "installer program"

Rules governing access: 

Rules that explicitly authorise access: only an "installer" subject can make an object "executable"

Rules that explicitly deny access: subjects that are not "installer" subjects can not run "installer program" object


Component Application:
SFP: software control policy. 
Ability: set. 
Attributes: executable, installer. 
Role: sanitization-control officer.


Component Application:
SFP: software control policy. 
Default attribute values:  restrictive.


Component Application:
The authorised identified role: sanitization-control officer


Component Application:
Administrators in the TSF-maintenance role have a responsibility to modify the security behavior of the system by applying developer-supplied code fixes according to developer-specified procedures. TSF-maintenance administrators shall make sure that security attributes are properly maintained and upgraded as code fixes are applied.


Component Application:
Create a TSF-maintenance role with the ability to modify the behavior of arbitrary TSF functions.


Component Application:
Security policies enforced by the TSF need to allow necessary maintenance of security attributes by TSF-maintenance administrators.


Component Application:
To support the implementation of this requirement, the developer must provide a definition of "secure state" so that the reguirement can be evaluated. This definition can be provided through the associated dependecy on ADV_SPM.1.

Component Application Rationale:
The definition of a "secure state" should provided by the security model documentation (ADV_SPM.1) when a model is required by the PP.  If the requirement for a security model is not present, it is still necessary for the developer to provide this definition in some manner. How this definition is provided should be identified in the rationale that defends the exclusion of ADV_SPM.1.


Component Application:
Level of auditing: This should generally not be determined on the basis of a single application of this component, but through consideration of audit requirements in their entirety.

Other auditable events: modification of system entry parameters

Other audit-relevant information: the values of new system entry parameters

Objective/Component Editorial:
The person being audited in this case should be different than the person controlling the audit records.


Component Application:
System entry parameters must be specified.

Component Application Rationale:
System entry parameters must be enforced by management so the parameters are within what is deemed to be secure (e.g. - # of authentication attempts)


Component Application:
Level of auditing: This should generally not be determined on the basis of a single application of this component, but through consideration of audit requirements in their entirety. 

The intent of this objective strongly implies that a level above "not specified" should be chosen, to ensure that some level of auditing is performed for security-relevant components. The exact level chosen will depend on higher-level goals for system-wide auditing.  Depending on these goals, any of the defined levels could be appropriate.

Other auditable events: additional security-relevant events as defined with respect to specific system applications

Other audit-relevant information: security-relevant information associated with security-relevent events


Component Application:
Selection: searches

Criteria with logical relations: user identity and time of event

Refine: Only users acting in the identified audit role may perform these searches.


Component Application:
Selection: user identity

List of additional attributes that audit selectivity is based upon: specified time intervals


Component Application:
Ability: Enable or disable. 
Functions: Review audit data. 
Roles: Audit Administration role.


Component Application:
The Audit administrator is responsible for guiding the TOE in the collection of needed audit data, for seeing that the audit data is properly stored and protected, and for reviewing collected audit data.

Roles are assigned so that an audit administrator does not have any other administrative roles.


Component Application:
Note that FAU_STG.3 may be used in place of FAU_STG.2.


Component Application:
Abilities: to manage. 
Role: Audit Administration.
Data: audit data.


Component Application:
The authorised identified role: Create an Audit Administration role that does not overlap other administrative roles. 

Conditions for the different roles: No user ID may be associated with both the Audit Administration role and some other administrative role.


Component Application:
The TSF shall record within each audit record the information that is identifies successful and unsuccessful access to the system.


Component Application:
The TOE should display to the user a message that indicates their access is being recorded as a deterrent to hackers or unauthorized users.


Component Application:
Level of auditing: This should generally not be determined on the basis of a single application of this component, but through consideration of audit requirements in their entirety.


Component Application:
Select prevent and, at a minimum, select attack.


Objective/Component Editorial:
Consider other components in FAU_SAA.  Some preventive mechanisms (e.g. FTA_TSE.1) are useful for discovering unusual activities.


Component Application:
Apply this in such a way as to make sure data needed for backup is reliably exported and marked to prevent confusing it with invalid backup data.  In the case of an intelligent remote backup device, this coponent may also be applied to control information used to retrieve backup data, to prevent spoofing.


Component Application:
Apply this in such a way as to make sure that the restored backup data is not corrupted.


Component Application:
Apply this component to cover operations that may corrupt an object.  For example, operations performed by malicious code that has been accidentally loaded onto a system.


Component Application:
Restrict the use of rollback facilities to an appropriate administrative role.


Component Application:
Specify restoration of TSF code and data as onditions under which self test should occur, in order to check that the TSF has been restored properly.


Component Application:
Environment:  Apply FDP_ETC.2 to require signatures on code exported by the developer.


Component Application:
Apply this component to require checking of digital signatures on imported code.


Component Application:
Allocation: FDP_UIT.1.2 is for the TOE; 
FDP_UIT.1.1 is for the Environment. Apply this element to specify that the digital signature process is effective; i.e. prevents spoofing or masquerading.


Component Application:
It will be specified through this component's operations whether the local, remote, or both the local and remote shall be capable of establishing the trusted channel.


Component Application:
Apply this component in such a way as to achieve operational configuration management.  Use as a model for this, the corresponding configuration management requirements for the development environment, e.g. ACM_AUT.1.


Component Application:
Refine this component by specifying that correctness means the TSF operates as designed.

Objective/Component Editorial:
For further ideas on how to do this, consult the Part 2: Annexes of the CC, section J16.


Component Application:
Identify a policy for the protection of cryptographic assets, including cryptographic keys.  Cover all operations between subjects and cryptographic assets.


Component Application:
Specify attributes for objects, such as the object’s function (e.g., whether it is encrypted), associated roles, user ownership, and validity period (if appropriate).  For the special case of cryptographic keys, specify additional attributes such as key type (e.g. public, private, secret), validity period, and intended use (e.g. digital signature, key encryption, key agreement, data encryption). 

Specify rules governing access to cryptographic assets, including rules governing the allowed use of cryptographic operations on relevant objects (e.g., plaintext, ciphertext, red or black cryptographic keys).


Component Application:
Refine to specify red data, black data, and key handling modules in the cryptographic engine.  It must be obvious from the design that the only data flow between the red data module and the black data module is through encryption or decryption.  It should also be apparent that no red keys can find their way into the data module.


Component Application:
Specify data flow policies concerning red/black data separation and data/key separation.


Component Application:
Specify policies concerning red/black data separation and data/key separation.


Component Application:
Require description of the cryptographic portion of the TSF in terms of major structural units (i.e. sub-systems) and relating these units to the functions that they contain.


Component Application:
Require description of the cryptographic portion of the TSF in terms of major structural units (i.e. sub-systems) and relating these units to the functions that they contain.  Require distinguishing the cryptographic boundary of the TOE from the overall TOE boundary.


Component Application:
Require a description of the internal workings of the cryptographic TSF in terms of modules and their interrelationships and dependencies.


Component Application:
Require demonstration of the correspondence between various representations of the cryptographic design.


Component Application:
Require that the development of cryptographic functional desin be performed in accordance with a defined implementation standard (e.g. coding standard).


Component Application:
Instruct administrators on the sensitivity of cryptographic assets and on the importance of not mix them with other information.


Component Application:
Instruct users on the sensitivity of cryptographic assets and on the importance of not mix them with other information.


Component Application:
Specify constraints on I/O devices to facilitate separation of cryptographic assets and to protect them from improper distribution.


Component Application:
Specify constraints on I/O devices to protect them from improper distribution.  Specify labels to facilitate separation of cryptographic assets from other assets.


Component Application:
Specify constraints to avoid loading of weakened or corrupted cryptographic assets.


Component Application:
Use to facilitate protected communication of cryptographic assets.


Component Application:
Require a high level description of the user-visible interface and behaviour of the cryptographic components of the TSF.


Component Application:
Include if there is a requirement for security policy model.


Component Application:
Check for ways to evade cryptographic access control policy.  Specifically, consider ways for unauthorized personnel to recover plaintext cryptographic keys and authentication data (e.g., from audit records, temporary objects, free storage areas).

Objective/Component Editorial:
The CC does not provide a means to specify, e.g., what should NOT be audited.  Indeed, it is difficult to cast a purely functional requirement along these lines.  
A plain-text key or user password could accidently enter the audit trail for many reasons having little to do with the TSF design.  For example, a user might accidentally enter a password in place of a user ID, as the user is likely to be thinking about both during an I&A session.


Component Application:
Allocate to the TOE if the TOE performs key generation.


Component Application:
Allocate to the TOE if the TOE performs key distibution.


Component Application:
Allocate to the TOE if the TOE performs any cryptographic operations.  Besides access for use by cryptographic operations, backup, archiving, escrow and recovery may need to be dealt with.


Component Application:
Allocate to the TOE if the TOE performs any cryptographic operations.


Component Application:
Specify an access control policy for protection of cryptographic keys.

Objective/Component Editorial:
The Crypto Guidance paper CSWG-97/02 suggests using FDP_ACC, FDP_ACF, and/or FPT_SEP to protect user and TSF keys in storage.  Obviuosly, FDP_ACC.1 can be refined to require access control be accomplished by encrypting all keys in storage.  Also FCS_COP.1.1 requires that the TSF shall perform an Assigned list of cryptographic operations.  Encryption of keys while in storage should be included in this Assignment.  However, this seems a backhanded way to state an important requirement, a requirement that should have its own CC Component.


Component Application:
Using the access control policy for protection of cryptographic keys, require that the TSF store keys in encrypted form and protect them from unauthorized use.


Component Application:
Use the access control policy for protection of cryptographic keys to control key entry.  Specify, e.g., whether keys are to be entered in unencrypted, encrypted, or split-knowledge forms.


Component Application:
Specify management of cryptographic key attributes such as key type (e.g. public, private, secret), validity period, and intended use (e.g. digital signature, key encryption, key agreement, data encryption).


Component Application:
Cover import/entry of TSF cryptographic keys, key escrow (if relevant), key generation, etc.


Component Application:
Require separation of domains to protect stored cryptographic keys.


Component Application:
Identify roles for managing cryptographic capabilities, e.g., Cryptgraphic Account Manager, System Security Officer, Certification Authority Manager, Registration Authority Manager, Cryptography User.  Associate privileges and responsibilities with these roles using other components in class FMT, as appropriate.


Component Application:
Require specification of the presentation of syntax and semantics of all extenal cryptographic TSF interfaces.  Require evidence deomonstrating that the cryptographic functions in the TSF are completely represented.


Component Application:
Require a high level design for the cryptographic functions in the TSF.


Component Application:
Require that cryptographic data is accessed only by the components of the TOE that need it.


Component Application:
Ensure that the cryptographic inputs, outputs, plaintext, and cyphertext are accessed only by the components of the TOE that need them.


Component Application:
Include if the TOE performs any perform the cryptographic operations.  Note that encryption of keys while in storage is one of the cryptographic operations that must be listed.


Component Application:
Apply so as to detect cryptographic data integrity errors.


Component Application:
Apply to testing the cryptographic portion of the underlying abstract state machine.


Component Application:
Refine to cover tests to ensure that the cryptographic functions are operating correctly. Tests conducted during start-up and/or periodically may include known-answer tests of cryptographic operations, as well as statistical tests on random number generators.  Additional tests may involve generation of private / public key pairs, pair-wise consistency tests of encryption and decryption, key-entry tests, and key integrity tests.


Component Application:
Provide independent testing of cryptographic functionality.


Component Application:
Complete this component's operations in a manner compatible with the associated FCS_CKM components.

List of cryptographic operations: a function for encrypting and/or decrypting user data that is exported and/or imported


Component Application Rationale:
Explain how the enforcement of the identified security policy for exported data achieves some security protection need that caused the inclusion of the related objective.


Component Application Rationale:
Explain how the enforcement of the identified security policy for exported data achieves some security protection need that caused the inclusion of the related objective.

The binding of security attributes to exported data strongly implies some security-relevant use of those attributes in the destination environment.  Note that in may cases the exported environment is local, as in the case of printed documents and/or removable media. Explain how the use of those attributes in the destination environment will achieve part of the necessary security protection that caused the inclusion of the related objective.


Component Application Rationale:
Provide export of user data from the TOE with security attributes that limit the number of locations and specify which locations that the data can be sent to.


Component Application Rationale:
Impose information control policies that do not allow specified export or import of specified data or from specified locations.


Component Application Rationale:
A user could send unauthorized information. Therefore limits should be placed on the types of acceptable information flows and the limits on information flows.  This would reduce bandwidth utilization and enforce organizational policy.


Component Application Rationale:
Provide import of user data from the TOE with security attributes that limit the locations that a user can accept data from.


Component Application:
Types of emanations: intelligible
Limits:  sufficient to mitigate intelligible emanations when used in conjunction with other objectives.


Component Application:
Access control SFP: ciphertext protection
List of subjects, objects, and operations covered by the SFP: all operations between all subjects and encrypted objects


Component Application:
Access control SFP: ciphertext protection
Security attributes: attributes telling which objects are encrypted
Rules governing access:  the only operations that may be performed on encrypted objects are encryption, deletion, and perhaps digital signature; only subjects that are trusted to properly handle ciphertext can perform these operations


Component Application:
SFP(s): ciphertext protection
Additional exportation control rules: ciphertext exported from the TOE shall be doubly encrypted
Attributes:  minimal information needed to unwrap the doubly encrypted object.


Component Application:
Note:  to get the desired effect, it may be necessary to apply this requirement several times for different kinds of ciphertext (e.g., singly and doubly encrypted text).

Complete this component's operations in a manner compatible with the associated FCS_CKM components.

Refinement: The algorithm to be built or used in such a way that plain text is padded with random text prior to encryption.


Component Application:
Information flow control SFP: plaintext-ciphertext correspondence

List of subjects, information, and operations: data that is or will be encrypted; subjects that handle such information.

Note: In most cases, the access-control decisions may be made statically, with no need for runtime decision making about where plaintext and encrypted objects may be found.


Component Application:
SFP: plaintext-ciphertext correspondence.  
Attributes:  whether an object is encrypted, whether its sensitivity merits encryption, location (e.g., whether it on a network, in a particular computer), and for each location, whether it is for ciphertext, for encryption-worthy plaintext, or neither.  
Rules:  encryption-worthy plaintext may only reside in locations designated as encryption worthy; ciphertext may only reside in locations designated as ciphertext worthy.

Note: In most cases, the access-control decisions may be made statically, with no need for runtime decision making about where plaintext and encrypted objects may be found.


Component Application:
Access control SFP: an export-sanitization policy

List of subjects, objects, and operations covered by the SFP: objects that may contain hidden data.

Component Application Rationale:
Rationale for omitting dependency on FDP_ACF.1. FDP_ACF.1 isn't needed for this objective - access mediation is performed only on export from the TOE, so FDP_ETC.1 takes its place.


Component Application:
SFP(s): export sanitization. 

Rule:  Apply the sanitization function specified by the sanitization control officer to each exported message, according to its message type.


Component Application:
To support the implementation of this requirement, the developer must provide a definition of "secure state" so that the requirement can be evaluated. This definition can be provided through the associated dependency on ADV_SPM.1.


Component Application Rationale:
The objective expresses the CC component in narrative form.


Component Application:
List the types of failures to which all TOE capabilities are fault tolerant.

Component Application Rationale:
The objective captures the CC component in narrative form.  In addition, FRU_FLT.2 strengthens the objective by providing fault tolerance for all of the TOE's capabilities for some failures.


Component Application Rationale:
If the audit storage has the potential to be overwritten by exceeding the audit storage limitations the PP/ST author should define actions in case of audit storage exhaustion.  In the case where the action would give audit storage priority over user data storage data on the same device, the PP author should give consideration to actions required to preserve user data (e.g., via application of FDP_SDI.1).


Component Application:
Include guidance for the security administrator to reflect the organization's policy for limiting hacker sessions. For example, this guidance would give the administrator information for setting thresholds to counter a "SYN flood" attack.


Component Application:
Apply this component to SFP's dealing with communications ports. For example, the TSF may prevent creation of ports or redirect suspected hacker traffic to a harmless destination for analysis.


Component Application:
Rules for the number of maximum concurrent sessions:

The rules might link detected anomalies for a user to concurrent session limits for that user.

If the user is discovered to be a hacker then the number of session might potentially be zero.  If sending hacker traffic to a "fish bowl" to observe hacker activity then limits may be more than zero but less than an amount that puts a resource burden against legitimate users and services.


Component Application:
Relevant attributes may be an individual identity, a host identity, a location, or time of day.

Component Application Rationale:
If the organization require that no hacker sessions should be present this component should be used.  However, caution must be taken, if a hacker finds out his connection attempts are being blocked, they may attempt to initiate mass quantities of sessions, thus creating a denial of service on the processing resources.


Component Application:
Information flow control SFP: discard policy of hacker traffic

Component Application Rationale:
Specific traffic of a hacker may need to be rerouted or redirected to a non-intrusive location for security analysis purposes.  Information flow policy must address hacker traffic control.

One way of discarding traffic is not to allow it based on known hacker attributes (i.e. - IP address).

Possible supporting components would be found in the objective Hack_Limit_Sessions.


Component Application:
The TSF shall enforce hacker traffic control in accordance with the hacker traffic control policy.


Component Application:
The list of feedback to the user should be "no meaningful feedback." An specific implementation (e.g., displaying an asterisk for each letter the user types in) that conveys no meaningful feedback is an acceptable refinement of the intent expressed here.

Component Application Rationale:
Eliminating feedback to the user ensures that the system cannot convey to a possible attacker any information that is relevant to the authentication data of a valid system user.


Component Application:
The TSF shall allow only the display of the TOE's access banner (see FTA_TAB.1) on behalf of the user before the user is identified.

Component Application Rationale:
This requirement establishes accountability for potential intruders and alerts authorized users that they are entering a protected domain.


Component Application:
Apply using the events in a transaction as objects.  Refine by requiring that authentication involve correct assignment of a transaction identity.

Component Application Rationale:
Arguably, FDP_DAU. is something of a force fit.  A more convincing implementation of the objective could be given using a CC-extending component that covered data identification as well as data authentication.


Component Application:
The Accounts Administrator shall ensure that each authorized user is assigned a unique user identifier and related authentication data sufficient for user identification and authentication.

Component Application Rationale:
FMT_MOF.1, together with the refinement of AGD_ADM.1, provide a reliable mechanism for associating users and unique IDs.


Component Application:
Users are responsible for actions required to ensure successful authentication, including protection of any personal authentication data.

Component Application Rationale:
FIA_UAU.2 and the refinement of AGD_USR.1 ensure that the user session is associated with the user who is associated with user ID given by the login mechanism.


Component Application Rationale:
FIA_USB.1 assures that actions resulting from user requests are also associated with the user's ID.  For added assurance, require trusted path (FTP_TRP) to ensure that user requests associated with the login session actually come from the user who logged in.


Component Application:
Role:  Accounts Administrator. 
Ability: maintenance. 
Functions: maintain valid user accounts and associate them with authorized users and related authentication data.


Component Application:
This component should be implemented to provide a policy that would eliminate an administrator from redirecting traffic to an unauthorized location.


Component Application:
This component should implement the information flow to authorized location only.


Component Application:
This management function should be implemented to assure that the Information Flow Control Policy and Information Flow Control Functions can not be bypassed by an administrator attempting to redirect traffic to an unauthorized location.


Component Application:
List of subjects, objects, and operations covered by the SFP: downloaded, executable objects


Component Application:
Use this component to specify downloaded executables as a class of objects to be covered by security function requirements.


Component Application:
Provide an importation control rule requiring inspection of downloads.


Component Application:
Type of emissions: intelligible
Limits:  sufficient to mitigate intelligible emanations when used in conjunction with other objectives.


Component Application:
Types of emissions: intelligible
Limits:  sufficient to mitigate intelligible emanations when used in conjunction with other objectives.


Component Application:
Specify attributes and rules that will (a) constrain subjects that are likely to be malicious from executing code in general, and/or (b) constrain the operations that may be performed on objects (and potentially damage them) to only authorized subjects.


Component Application:
Types of emissions: electromagnetic emissions from TOE and cables.
Limits:  specify to establish a well-defined limit for emanations.

Component Application Rationale:
The objective deals only with electromagnetic emanations, which is covered by application of FPT_PHP_EMSEC_Design.


Component Application:
List the objects containing data to be protected by this application of access controls. Ensure that "write" and "delete" (or other damaging) operations are specified for the types of data to be protected. Specified subjects will be those constrained by this application of access controls.


Component Application Rationale:
The executables are initially marked for protected domain ("sandbox") execution only.


Component Application:
The system should limit the number of multiple sessions to the amount that is expected to maximize any resource utilization.

Component Application Rationale:
The resource that the threat agent is attacking should be the primary metric for the maximum number of multiple sessions.


Component Application Rationale:
If the threat agent is a user, that user should have a limit on the number of sessions that can be generated by that user.


Component Application Rationale:
The system should deny threat agents from establishing sessions that use service(s) or port(s) that tend to put undo strain on a resource. The limitation may be in conjunction with multiple concurrent sessions.


Component Application:
List the authorized users that are allowed, given their duties, to observe the use of each service or resource that is protected under this objective.

Component Application Rationale:
The specified authorized users must be allowed to see the service or resource use in order to perform their duties.


Component Application:
Abilities: enable, disable. 
Functions:  Vendor access privileges (e.g., use of "Trap doors"). 
Role:  Maintenance Administrator.


Component Application:
The authorised identified role: Maintenance Administrator


Component Application:
Attributes: Vendor access privileges (e.g., use of "Trap doors"). 
Role: Maintenance Administrator


Component Application:
Provide guidance to the user that would define the level of security attribute modification they are allowed and what the ramifications are for violating that policy.


Component Application:
Level of auditing: This should generally not be determined on the basis of a single application of this component, but through consideration of audit requirements in their entirety.

Maintain an audit trail of resource security attribute modifications or additions.

Component Application Rationale:
Maintain an audit trail of resource security attribute modifications or additions.


Objective/Component Editorial:
Provide management of the resource attributes that would deny any given user to modify those attributes which would deny legitimate access to the resource.


Component Application:
FMT_MTD.2.1/If data storage can be exceeded, the roles of who can modify limits on TSF data should be defined.

FMT_MTD2.2/If data storage can be exceeded, the actions required upon storage limits being exceeded should be defined.


Objective/Component Editorial:
Select one of FDP_RIP.1 or FDP_RIP.2 to specify the scope of protection against disclosure of residual information.


Component Application:
In the event that remote third parties are involved in enforcing nonrepudiation, provide guidance on proper use of the nonrepudiation functions.

Component Application Rationale:
In the event that a third party is responsible for marshalling gathered evidence to enforce accountability, there needs to be a requirement for performing this duty.


Component Application:
In the event that senders are involved in enforcing nonrepudiation, provide guidance on proper use of the nonrepudiation functions.

Component Application Rationale:
In the event that a senders are responsible for marshalling gathered evidence to enforce accountability, there needs to be user documentation on how to do this.


Component Application:
Information types: possibly none, as evidence is generated by the receiving TSF.
Requestors, recipients of evidence: specify originator, recipient, or third parties.
Attributes, Information fields: those supported by the receiving TSF.
Limitations on evidence of receipt:  TSF must rely on receiving TSF to supply evidence of receipt.

Component Application Rationale:
The TOE must rely on the recipient's TSF to generate evidence, which is then assessed by the TOE in light of any additional information available.

Objective/Component Editorial:
FCO_NRR.2 isn't appropriate here, as it says more about generation of evidence than the TOE is able to enforce.


Component Application:
In the case where nonlocal third parties are involved in handling nonrepudiation evidence, provide identified roles for those parties.

Component Application Rationale:
In the event that a third party is responsible for marshalling gathered evidence to enforce accountability, this requirement provides appropriate role support.


Component Application:
In the event that nonrepudiation evidence is handled by remote third parties, provide documentation on the responsibilities of those who handle this evidence.


Component Application:
In the event that nonrepudiation evidence is handled by the message recipient, provide user documentation on the use of nonrepudiation features.

Component Application Rationale:
In the event that recipients are responsible for marshalling gathered evidence to enforce accountability, there needs to be user documentation on how to do this.


Component Application:
Transmitted information types: possibly none, as the TOE must rely on the sending TSF for generated evidence.
Requestors, Recipients of evidence: specify originator, recipient, or third parties.
Attributes, information fields: those supported by the sending TSF.
Limitations on the evidence of origin: The TOE must rely on the sending TSF for evidence of message generation.

Component Application Rationale:
The TOE must rely on the sender's TSF to generate evidence, which is then assessed by the TOE in light of any additional information available.

Objective/Component Editorial:
FCO_NRO.2 isn't appropriate here, as it says more about generation of evidence than the TOE is able to enforce.


Component Application:
If nonrepudiation is handled by remote third parties, apply FMT_MOF.1 Management of security functions behavior to provide identified roles for the parties who determine the use of nonrepudiation functions.


Component Application:
In the event that third parties are involved in enforcing nonrepudiation, provide guidance on proper use of the nonrepudiation functions.

Component Application Rationale:
In the event that a third party is responsible for marshalling gathered evidence to enforce accountability, there needs to be a user requirement for performing this duty.


Component Application:
List the information types for which the threat is significant, the parties responsible for countering the threat (typically the sender or a trusted third party), the attributes of the recipient that are subject to nonrepudiation (e.g., individual identity, employing organization), information fields subject to nonrepudiation (e.g., message headers and text), parties to whom nonrepudiation evidence is presented (e.g., those responsible for countering the attack), and any limitations on the evidence provided.

Component Application Rationale:
This requirement ensures that nonrepudiation evidence can be provided.


Component Application Rationale:
This requirement ensures that evidence of nonrepudiation is provided.


Component Application:
In the event that third parties are involved in enforcing nonrepudiation, provide identified roles for these parties.


Component Application:
In the event that nonrepudiation evidence is handled by third parties at the sender's system, provide documentation on the responsibilities of those who handle this evidence.


Component Application:
List the information types for which the threat is significant, parties responsible for countering the threat (typically the recipient or a trusted third party), the attributes of the originator that are subject to nonrepudiation (e.g., individual identity, employing organization), information fields subject to nonrepudiation (some fields may be added by the TOE and not under the sender's control), parties to whom nonrepudiation evidence is presented (e.g., those responsible for countering the attack), and any limitations on the evidence provided.


Component Application Rationale:
This requirement ensures that nonrepudiation evidence is generated.


Component Application:
If nonrepudiation is handled by third parties at the sender's system, apply FMT_MOF.1 Management of security functions behavior to provide identified roles for the parties who use the nonrepudiation functions.


Component Application:
Enforce an SFP that prevents modification of user data. (However, note that this requirement, on the one hand, applies to all data rather than just nonrepudiation data, and on the other, applies only to data transmitted between separate parts of the TOE – some alteration may be needed.)

Component Application Rationale:
This requirement ensures that evidence provided under FCO_NRR.1 or FCO_NRR.2 is not compromised through inadequate protection by the TSF.


Component Application:
Provide identified roles for the parties who determine the use of nonrepudiation functions.


Component Application:
In the event that nonrepudiation evidence is handled by third parties, provide user documentation on the responsibilities of those who handle this evidence.


Component Application Rationale:
This requirement ensures that evidence provided under FCO_NRO.1 or FCO_NRO.2 is not compromised through inadequate protection by the TSF.


Component Application:
If nonrepudiation is handled by third parties, apply FMT_MOF.1 Management of security functions behavior to provide identified roles for the parties who determine the use of nonrepudiation functions.


Component Application Rationale:
This component provides an extremely flexible mechanism for selective generation of proof-of-origin evidence.

Explain how the specific completion of this component's operations provides the necessary protection mechanisms.


Component Application Rationale:
This component provides an extremely flexible mechanism for mandated generation of proof-of-receipt evidence.

Explain how the specific completion of this component's operations provides the necessary protection mechanisms.


Component Application Rationale:
This component provides an extremely flexible mechanism for mandated generation of proof-of-origin evidence.

Explain how the specific completion of this component's operations provides the necessary protection mechanisms.


Component Application:
Access control SFP: attribute-management policy

List of subjects, objects, and operations covered by the SFP: those objects covered by other SFPs; attribute-maintenance operations, characterized by their ability to modify security attributes incorrectly; those subjects capable of applying attribute-maintenance operations, referred to as attribute-maintenance subjects


Component Application:
Access control SFP: attribute management

Security attributes: object owner (a.k.a. object-attribute manager)

Rules governing access: only an object owner may apply attribute-maintenance operations to that object, and only via attribute-maintenance subjects acting on that user's behalf; all attribute-maintenance subjects are certified to reflect user intent when modifying object attributes.


Component Application:
Role:  data security administrator.  
Ability: change_default, modify, delete attributes.


Component Application:
Policy: attribute-management. 
Default values: safe values - determined separately for each attribute per its associated SFP. 
Roles authorized to specify initial values for object data and attributes:  TOE developer and/or the TOE data security administrator.


Component Application:
The authorised identified role:  data security administrator.


Component Application:
List of subjects, objects, and operations covered by the SFP: any modifications to trusted objects must be by trusted subjects


Component Application:
Limit ability to modify trusted objects to a trusted role


Component Application:
Create a trusted role for the maintenance of trusted objects.


Component Application Rationale:
The objective captures the CC component in narrative form. In addition, FPR_PSE.2 enhances the objective by providing accountability through the use of reversible aliases.


Component Application Rationale:
The objective captures the CC component in narrative form. In addition, FPR_PSE.3 enhances the objective by providing accountability through the use of selectively reusable aliases.


Component Application Rationale:
The objective expresses the CC component in narrative form. In addition, FPR_ANO.2 strengthens the objective by prohibiting the collection of some user-related privacy information.


Component Application Rationale:
FPR_UNO.1 ensures that the use of a service or resource cannot be observed by unauthorized users.


Component Application Rationale:
FPR_UNO.2 ensures that the use of a service or resource cannot be observed by unauthorized users. In addition, it is used to specify that information related to the privacy of the user is distributed within the TOE such that attackers might not know which part of the IT system or product to target, or they need to attack multiple parts of the TOE.


Component Application:
The resource(s) and subject(s) related to the detailed attack should be identified as the resource upon which priority of service is enforced.


Component Application:
All sharable resources should be subjected to priority of service as the specific resource being attacked may effect other sharable resources.


Component Application:
Ability: query. 
TSF data: Vendor access privileges (e.g., use of "Trap doors"). 
Role:  Maintenance administrator


Component Application:
TOE: Specify received
Environment: Specify sent


Component Application:
TOE:  specify receive messages
Environment:  Specify send messages.  If FDP_UIT.2 is chosen, then refine FDP_UIT.1 for the environment to include retransmission of damaged messages.


Component Application:
A maximum resource quota should be applied toward the threat agent causing the resource overload.


Component Application:
Should services require minimum resources to operate, both minimum and maximum quotas should be set so the threat agent invoking a service that potentially overloads a resource does not overload that resource and critical services have enough resources to operate.


Component Application:
Complete this component's operations in a manner compatible with the associated FCS_COP.1 component.


Component Application:
Complete this component's operations in a manner compatible with the associated FCS_CKM components.

List of cryptographic operations: general encryption function


Component Application:
Administrative guidance will need to describe configuration options and to perform secure modifications to configuration data.


Component Application:
All TSF functions whose behavior is determined by configuration data should be specified, along with permitted operations and those roles that the system will allow to perform those operations.


Component Application:
All TSF data that requires control should be specified, along with permitted operations and those roles that the system will allow to perform those operations.

Component Application Rationale:
This component provides the basic capability to update TSF data. Additional procedural controls may be required to supplement the controls provided by this component.  For instance, there should be a procedural control to ensure administrators learn of necessary changes to the configuration. FMT_MTD.2 and FMT_MTD.3 could be considered to provide additional controls over security-relevant configurations.


Component Application:
Environment:  specify receive messages
TOE:  Specify send messages.  If FDP_UIT.2 is chosen, then refine FDP_UIT.1 for the TOE to include retransmission of damaged messages.


Component Application:
Refine: The evaluators need to identify a subset of the source code for examination.

Component Application Rationale:
ADV_IMP.1 captures the internal workings of the of the TSF in the form of source code to allow for it's examination.


Component Application Rationale:
To be used as a dependency for ADV_IMP.1 in O.Source_Code_Exam


Component Application Rationale:
To be used as a dependency for ADV_IMP.2 in O.Source_Code_Exam.


Component Application:
Apply this component in such a way as to address frequency of system backup and restoration.


Component Application:
Apply this component in such a way as to achieve operational system backup and restoration.


Component Application:
Explain how to detect and report physical tampering or errors.  At least for the [Detect] variant of Tamper_ID, also explain when to look (e.g., periodically, when a user suspects tampering, when an unexpected error or specific type of breach has occurred, when a user may have violated responsibilities for the physical protection of the TOE).


Component Application:
Environment: Some capability to determine when a physical tampering attack has occurred must be provided, but it is not necessary for the TOE to provide this functionality. The method provided should be supported by appropriate documentation.

Component Application Rationale:
FPT_PHP.1 provides basic physical tampering detection features. 

Physical attacks may go undetected for longer periods of time.


Component Application:
List of TSF devices/elements for which active detection is required: list those devices and elements for which active detection is critical

Designated user/role: list those individuals that are most appropriate for responding to physical attacks against the identified devices

Component Application Rationale:
FPT_PHP.2: The TOE provides additional functionality by automatically notifying designated individuals of detected physical tampering attacks.

This functionality is important when a successful physical tampering attack is likely to (a) incur unacceptable losses soon after the attack, and/or (b) significantly increase exposure to new vulnerabilities.

This function has the disadvantages of being moderately difficult to implement, especially with respect to successful physical attacks that could affect the notification function.  This aspect is partially mitigated by allowing the function to be applied to only designated portions of the TOE.


Component Application:
Use ADV_SPM.1 Informal TOE security policy model to specify that operational and maintenance modes may co-exist in most cases.


Component Application:
Use ADV_SPM.1 Informal TOE security policy model to specify that operational and maintenance modes may co-exist in most cases.  Specify those failures for which normal operation may continue while in a maintenance mode.


Component Application:
Use ADV_SPM.1 Informal TOE security policy model to specify that operational and maintenance modes may co-exist in most cases.  Specify those failures for which normal operation may continue while in a maintenance mode.  Finally, specify limits on the amount of damage that may occur when various failures occur.


Objective/Component Editorial:
It doesn't matter who initiates the trusted path since, by definition, its presence cannot be faked.  In many environments, trusted path is more of a concern for remote users than for local users.


Component Application Rationale:
This component is relevant when a user or administrator might use another IT device to attempt to gain TSF security attribute information that they are not authorized to access.


Component Application Rationale:
This component is relevant when a user or administrator might attempt to directly gain information about a TSF security attribute which they are not authorized to access.


Component Application Rationale:
The definition of a "secure state" should provided by the security model documentation (ADV_SPM.1) when a model is required by the PP.  If the requirement for a security model is not present, it is still necessary for the developer to provide this definition in some manner. How this definition is provided should be identified in the rationale that defends the exclusion of ADV_SPM.1.

In addition, it is necessary to ensure that the system is protected from untrusted user access while it is in maintenance mode.


Component Application Rationale:
The definition of a "secure state" should provided by the security model documentation (ADV_SPM.1) when a model is required by the PP.  If the requirement for a security model is not present, it is still necessary for the developer to provide this definition in some manner. How this definition is provided should be identified in the rationale that defends the exclusion of ADV_SPM.1.

The degree of this self-protection is directly proportional to the scope of failures for which the TOE provides automatic recovery in relation to the scope of all possible errors.


Component Application Rationale:
The definition of a "secure state" should provided by the security model documentation (ADV_SPM.1) when a model is required by the PP.  If the requirement for a security model is not present, it is still necessary for the developer to provide this definition in some manner. How this definition is provided should be identified in the rationale that defends the exclusion of ADV_SPM.1.

The degree of this self-protection is directly proportional to the scope of failures for which the TOE provides automatic recovery in relation to the scope of all possible errors.

This component provides additional protection by limiting the loss of TSF data (to a quantified limit) and providing a capability to determine which TSF data cannot be recovered.


Component Application:
Provide administrative guidance to allow the administrators to determine when recovery fails.


Component Application:
Provide a set of secure security attributes levels to allow administrators the ability to modify only specific TSF code or data.

Objective/Component Editorial:
Specific code modification by an administrator must be eliminated by some means to disallow the weakening of the TSF.  This could be accomplished through specified levels of secure attributes.


Component Application:
FMT_MTD.1 should be used to specify those who have access to TSF data.


Component Application:
FMT_MTD.2 should be used to limit TSF modification to administratively necessary actions.


Component Application:
The administrator must be limited on the security roles for modifying specific TSF code and data.

A separation of administrative functions to multiple administrators with cross checking would be an alternative.

Component Application Rationale:
The administrator must be limited on the security roles for modifying specific TSF code and data as to not diminish TSF functionality.


Component Application:
For the TOE: Modification metric: specify desired strength of function for received messages (must be compatible with that used by the remote site).  
Action if modification of imported data is detected:  Specify any desired responses made by the TSF. 

For the IT Environment: Modification metric: specify desired strength of function for exported data. (The modification metric for sent TSF data must be compatible with that used by the TOE.)  
Action if modification of exported data is detected: none necessary.


Component Application:
For the TOE: Modification metric: specify desired strength of function for received messages.  (The modification metric for received TSF data must be compatible with that used by the remote site.)  
Action if modification of imported data is detected:  Specify notification of the remote site, and any other desired responses made by the TSF. 

For the IT Environment: Modification metric: specify desired strength of function for exported data.  
Action if modification of exported data is detected (and reported to the remote site by the remote site): Specify desired action.


Component Application:
For the Environment: Modification metric: specify desired strength of function for exported data.  
Action if modification of exported data is detected: not necessary.


Component Application:
For the TOE: Modification metric: specify desired strength of function for received messages.  (The modification metric for received TSF data must be compatible with that used by the Environment.)  
Action if modification of imported data is detected:  Specify any desired responses to be made by the TOE. 
Modifications to be made:  Specify correction algorithm.


Component Application:
For the TOE: Modification metric: specify desired strength of function for received messages.  (The modification metric for received TSF data must be compatible with that used by the remote site.)   
Action if modification of imported data is detected:  Specify notification of the remote site, and any other desired responses made by the TSF.

For the IT Environment: Modification metric: specify desired strength of function for exported data.  
Action if modification of exported data is detected (and reported to the remote site by the TOE): Retransmission (for adaptive protocols, a more robust encoding might be used for the retransmission).
Defined modification metric: any

Component Application Rationale:
In the case of adaptive protocols, the retransmitted version might have higher redundancy to facilitate error correction by the TOE.


Component Application:
For the TOE: Modification metric: specify desired strength of function for exported data.  
Action if modification of exported data is detected (and reported to the TOE by the remote trusted product): Notify the remote site.  This may be either automated or manual.  In the latter case, there needs to be an administrative role for maintaining TSF data integrity.

For the IT Environment: Modification metric: specify desired strength of function for received messages.  (The modification metric for received TSF data must be compatible with that used by the TOE.)   
Action if modification of imported data is detected:  Specify notification of the TOE, and any other desired responses made by the remote site.

Defined modification metric:

Action to be taken:


Component Application:
For the TOE: Modification metric: specify desired strength of function for exported data.  
Action if modification of exported data is detected: not necessary. 

For the IT Environment: Modification metric: specify desired strength of function for received messages.  (The modification metric for received TSF data must be compatible with that used by the TOE.)   
Action if modification of imported data is detected:  Specify any desired responses made by the remote site.

Defined modification metric:

Action to be taken:


Component Application:
For the TOE:  Modification metric: specify desired strength of function for exported data. 
Action if modification of exported data is detected (and reported to the TOE by the remote trusted product): Retransmission; for adaptive protocols specify improved strength of encoding.

For the IT Environment: Modification metric: specify desired strength of function for received messages.  (The modification metric for received TSF data must be compatible with that used by the TOE.)  
Action if modification of imported data is detected:  Specify notification of the TOE, and any other desired responses made by the remote site.

Defined modification metric:

Action to be taken:


Component Application:
For the TOE: Modification metric: specify desired strength of function for exported data. 
Action if modification of exported data is detected: not necessary.


Component Application:
For the IT Environment: Modification metric: specify desired strength of function for received messages.  (The modification metric for received TSF data must be compatible with that used by the TOE.) 
Action if modification of imported data is detected:  Specify any desired responses to be made by the remote site. 
Modifications to be made: Specify correction algorithm.


Component Application:
The type of mechanism (either preventive, detective, or both) will be specified through the provided operations.

Component Application Rationale:
This component ensures that an attacker cannot succeed at presenting valid user authentication data and gaining access to the system without being detected.


Component Application:
Single-use authentication will be associated with specific authentication mechanisms through available operations for this component.


Component Application:
The administrator must be provided guidance on how to properly adjust a user's authorization status.

Component Application Rationale:
This administrative guidance is needed to support secure user authorization management.


Component Application:
All user security attributes that requires control should be specified, along with permitted operations and those roles that the system will allow to perform those operations.

Component Application Rationale:
This component provides the basic capability to update user security attributes. Additional procedural controls may be required to supplement the controls provided by this component.  For instance, there should be a procedural control to ensure administrators learn of necessary changes a user's authorization status.


Component Application:
This component provides users and or administrators with the capability to revoke attributes for users (or possibly the resources they may access), as specified.

Component Application Rationale:
This component provides the basic capability for an administrator to revoke security attributes to objects controlled by that user.


Component Application:
Specify security attributes that the system will expire after a certain amount of time.

Component Application Rationale:
This function eases the administrative burden and provides an additional margin of security.


Component Application:
List of multiple authentication mechanisms: list all authentication mechanisms


Component Application:
The TSF shall restrict the ability to disable, modify the behavior of authentication mechanisms to authorized administrators.


Component Application:
Access control SFP: observation-control policy

List of subjects, objects, and operations covered by the SFP: all objects that may hold sensitive information, including I/O devices; subjects capable of reading sensitive information


Component Application:
Information flow control SFP: an observation-control policy

List of subjects, information, and operations: all subjects that may read or hold sensitive information, including I/O device drivers; confidential information governed by the observation-control policy, including information handled via I/O devices; all relevant operations.

Component Application Rationale:
Note: Although objects are not one of the parameters specified in this component, it has traditionally been the case that information flow control policies cover information flow to and from objects as well as subjects. Subjects are usually treated as a special case of objects.


Component Application:
Information flow control SFP: the above observation-control policy

The minimum number and type of security attributes: readership attributes denoting a set of allowed readers or a set of allowed roles

For each operation, the security attribute-based relationship that must hold:

Additional information flow control SFP rules: a subject may observe or receive information only if it is acting on behalf of a user possessing the information's readership attributes; a subject may transmit or send information only if the readership of the information contains the readership of all the information that the subject has acquired

Component Application Rationale:
These security attributes may take the form of sensitivity labels drawn from a partially ordered set of security levels.

The attributes apply to both subjects and information. In traditional implementations, information attributes are not derived from the information itself, but reside with the information in storage objects.


Component Application:
Access control SFP: Provide an identifier for an access control SFP for to which the scope of policy enforcement (defined below in terms of subjects, objects, and operations) applies.  Other component specified throughout the PP will use this identifier as a means to associate applicability.  In particular, 
the dependent FDP_ACF component will define the applicable policy enforcement by referencing this identifier.

List of subjects, objects, and operations covered by the SFP: List the specific subjects, objects, and operations that are within the scope of this policy.

Component Application Rationale:
This component identifies and defines a scope for the identified policy. The policy identifier is used to associate related TSFs (e.g., that are constrained by the same scope and rules).  The rationale should explain the relevance of listed subjects, objects, and operations in terms of Security Environment abstractions.

The rationale should explain how the specifications within the completed operations serve to address the goals of the associated Objective, as well as any specific coverage of Security Environment concerns that they may provide.


Component Application:
Access control SFP: Provide an identifier for an access control SFP for to which the scope of policy enforcement (defined in terms of subjects and objects, below) applies.  Other component specified throughout the PP will use this identifier as a means to associate applicability.  In particular, 
the dependent FDP_ACF component will define the applicable policy enforcement by referencing this identifier.

List of subjects and objects: List the specific subjects and objects that are within the scope of this policy.

Component Application Rationale:
This component identifies and defines a scope for the identified policy. The policy identifier is used to associate related TSFs (e.g., that are constrained by the same scope and rules).  The rationale should explain the relevance of listed subjects, and objects in terms of Security Environment abstractions.  All operations between the listed subjects and objects are subject to the defined SFP.

The rationale should explain how the specifications within the completed operations serve to address the goals of the associated Objective, as well as any specific coverage of Security Environment concerns that they may provide.


Component Application:
Access control SFP: Name the associated access control policy (as identified within the dependent FDP_ACC component) that are applicable for the attributes, rules, etc. specified below.

Security attributes: List the attributes here that must be used to support enforcement of the rules listed below.

Rules governing access:  List the rules that express the intent and scope of that policy component.

Rules that explicitly authorize access: List the rules that demonstrate conditions (e.g., specific security attribute values) that result in an explicit "grant" authorization.

Be sure to avoid and/or clarify any contradictions or ambiguities that may result between an explicit "grant" rule and an explicit "deny" rule.

Component Application Rationale:
The policy enforcement specified in this component serves to associate the completed operations that list attributes, rules, etc. with the policy identified in the dependent FDP_ACC component. These completed operations are essentially the defined enforcement requirements for the associated policy.

The nature of the rules that must be specified will vary depending on which policy (FDP_ACC) component is chosen. 

This operation allows a convenient expression of "grant" exceptions to the general rules above.  Care should be taken that the intent and scope of the associated policy are not violated with automatic grant exceptions.  However, this operation allows the efficient expression of some rules that are generally considered safe (e.g., always granting access to "owner" subjects).

The explicit "denial" rules allow specification of the exceptions to the general rules above. Unlike exceptional "grant" rules, these types of exceptions are generally safe in that the scope of typical policy enforcement cannot be circumvented through denials of access. This may not be the case when Availability concerns are taken into account.

Contradictions and/or ambiguities in the rules specification may result in ineffective policy enforcement.

The rationale should explain how the specifications within the completed operations serve to address the goals of the associated Objective, as well as any specific coverage of Security Environment concerns that they may provide.


Component Application:
Associated information must appear in User Guidance documentation.

Component Application Rationale:
The rationale should address how the specific information that is to be provided in user guidance documentation will address the Security Environment concerns to which the  O.User_Guidance objective is mapped.


# Objectives

Descriptive Name:
Limitation of administrative access control

Objective Description:
Design administrative functions in such a way that administrators do not automatically have access to user objects, except for necessary exceptions. For an accounts administrator, the necessary exceptions include allocation and de-allocation of storage.  For an audit administrator, the necessary exceptions include observation of audited actions. In general, the exceptions tend to be role specific.

Objective Editorial:
Objective Parameter: When applying the general objective to specific attacks, the general objective needs to be refined, to state what the necessary exceptions are for a particular role.


Descriptive Name:
Object security attributes and exportation

Objective Description:
Provide object security attributes in exported data with moderate to high effectiveness. The attributes are those associated with specific security function policies.

Objective Editorial:
Allocation:  TOE

This objective has been implemented using FDP_ACC and FDP_ACF.  An alternate implementation using FDP_IFC and FDP_IFF is also possible.


Objective Description:
Display information related to the most recent successful and unsuccessful attempts to establish a user session, once a user successfully establishes a user session.


Descriptive Name:
Limit an administrator's ability to modify user-subject bindings

Objective Description:
Limit the administrator from modification of user-subject bindings in an effort to deter users acting without accountability.

Objective-Selection Guidance:
If the ability to modify or disable user-subject bindings is not constrained, the system will not be able to maintain accurate audit information.  
An unauthorized user should not be able to use a subject without being identified in an audit trail.

Implementation Application:
Choose FIA_USB.1, FIA_UAU.2, and FMT_MTD.1 to implement the objective.

Objective Editorial:
<specific objective>
FIA_UAU.2 must be used in conjunction with FIA_USB.1 to ensure that the user is authenticated prior to having a subject act on their behalf.  This would assist in limiting the possibility of an unauthorized user from invoking a subject's use.


Descriptive Name:
Limit administrator's modification of user attributes

Objective Description:
Deter the administrator from maliciously modifying users' attributes. Such modifications could allow unauthorized user actions or denial of service to a legitimate user.

Implementation Application:
Choose FIA_ATD.1, FIA_UAU.2, and FMT_MSA.1 to implement the objective.

Objective Editorial:
<specific objective>

Consider using the O.Audit_Account objective in conjunction with this objective.

 FIA_UAU.2 needs to be used in conjunction with FIA_ATD.1 so a malicious administrator can not masquerade as the authorized user, thus gaining the ability to change the user's attributes.


Objective Description:
Validate executable objects prior to allowing execution. Validation needs to be done by someone with an expertise to recognize malicious code and the authority and means to prevent its execution.

Implementation Application:
Choose FDP_ACC.1, FDP_AFF.1, FDP_ACC.1, FMT_MSA.1, and FPT_TST.1 to implement the objective.

Objective Editorial:
<specific objective>


The access control mechanism could be implemented with FDP_IFF and FDP_IFC. The user data integrity component could be supplemented with TSF data integrity. Identification and authentication may need to be addressed.


Descriptive Name:
Software validation for absence of steganography

Objective Description:
Validate exported objects for absence of steganographic content prior to allowing exportation.  Validation needs to be done by someone with an expertise to recognize hidden content and the authority and means to prevent its export.

Implementation Application:
Choose FDP_ACC.1, FDP_ACF.1, FMT_MSA.1, FMT_MSA.3, and FMT_SMR.1 to implement the objective.

Objective Editorial:
<specific objective><looks generic>

This objective is dependent on the O.Admin_Code_Val objective.

Use O.Admin_Code_Val_Sten to counter the steganographic smuggling attack.


Objective Description:
Deter administrator errors by providing adequate administrator guidance.


Objective Description:
Apply patches to fix the code when vulnerabilities in code allow unauthorized and undiscovered access.

Objective-Selection Guidance:
This objective should be used when a code fix is prepared for a vulnerability in security-relevant code.

Implementation Application:
Any of the ALC_FLR components may be used when implementing this objective, with resultant differences in effectiveness of the objective.

Currently, the implementing components apply primarily to the TOE environment.  However, the PP author may wish to also consider requirements for the TSF to actively support maintenance via safe installation programs and/or TOE version control mechanisms.


Descriptive Name:
Complete security functions or recover to previous state

Objective Description:
Recover automatically to a consistent, secure state if a security function does not complete successfully in the presence of certain types of failures.

Objective-Selection Guidance:
This objective is relevant when a system failure can occur during the processing of a security function, corrupting TSF data and leading to an insecure state. This function provides both recovery and prevention features.  These features are intrinsic in that for identified SFs and failure scenarios, the SF automatically recovers to a secure state, and prevents the subsequent vulnerabilities that would occur as a result of operating in an insecure state.

The types and number of functions that the TOE implements atomically will determine the costs to provide this protection; however, there are many scenarios where this mechanism is extremely effective and relatively inexpensive to implement.

Implementation Application:
Choose FPT_RCV.4 to implement the objective.


Descriptive Name:
Audit changes of system entry parameters

Objective Description:
Deter an administrator from changing system entry parameters to allow an unauthorized user access to organizational assets to which they are forbidden.

Objective-Selection Guidance:
This objective is required if an administrator could allow an unauthorized user the ability to take advantage of the system entry parameters to gain unauthorized access.  This objective is relevant for systems that include functionality such as that specified by FIA_AFL.1.


Objective Description:
Provide information about past user behavior to an authorized user through system mechanisms.  Specifically, during any specified time interval, the system is able to report to a user acting in an identified audit role selected auditable actions that a user has performed, and as a result, what auditable objects were affected and what auditable information was received by that user.

Objective-Selection Guidance:
Audit mechanisms can be used for several different legitimate purposes.  This use addresses user accountability.

Effectiveness: low-to-moderate, depending on the threat being countered and the integrity of the audit mechanism. 

Dependent Objectives: O.I&A_User.

This objective contains several implicit parameters: the audit role, the auditable actions, the audited objects, and auditable information passed to the user.

Objective Editorial:
<specific objective>

TOE Requirement: FMT_SMR.1


Objective Description:
Deter modification or destruction of audit data through the creation of an audit-administration role.

Objective-Selection Guidance:
This objective prevents modification or destruction of audit data by limiting possible threat sources.

Implementation Application:
---
Only the audit administrator can control the audit trail, per FMT_SMR.2 and FMT_MTD.1.  Necessary audit data to implicate attacks by other administrators is delivered, per FAU_STG.2.  The audit administrator has no conflict of interest in effectively using such data and will do so, per refinement of AGD_ADM.1.

Objective Editorial:
<specific objective>
Dependent Objectives:  O.I&A_User.


Objective Description:
Audit system access to discover system misuse and provide a potential deterrent by warning the user.

Objective-Selection Guidance:
If a hacker can get in to a system without administrator knowledge then this objective should be considered as a means to discover the access and implement additional access control measures (e.g., access control lists on routers).  Also, it might be considered to let the users know that their access is being monitored and recorded for deterrence measures.

Objective Editorial:
<specific objective>

In some cases, the same objective may be implemented in several different ways.
This is true, e.g., of the I&A objective.


Objective Description:
Provide individual accountability for audited events. Uniquely identify each user so that auditable actions can be traced to a user.


Objective Description:
Record in audit records: date and time of action, location of the action, and the entity responsible for the action.


Descriptive Name:
Respond to possible loss of stored audit records

Objective Description:
Respond to possible loss of audit records when audit trail storage is full or nearly full.


Objective Description:
Protect audit records against unauthorized access, modification, or deletion to ensure accountability of user actions.

Implementation Application:
There are two variants of this objective (choose one):
[Basic]: Choose FAU_STG.1.
[Availability]: Choose FAU_STG.2.


Descriptive Name:
User notification of data content changes

Objective Description:
Notify users of changes to data content in order to make any adjustments to their own data.


Descriptive Name:
Object and data recovery free from malicious code

Objective Description:
Recover to a viable state after malicious code is introduced and damage occurs, removing the malicious code as part of the process.

Objective-Selection Guidance:
The term "clean" is used here to refer to absence of malicious code, e.g., a virus or worm.


Objective Description:
Check verification of signed downloaded code prior to execution. A well-known example is checking digital signatures on signed Java applets.


Descriptive Name:
Physical protection of the communications line

Objective Description:
Protect communications lines from physical tampering.


Descriptive Name:
Trusted channel to remote trusted system

Objective Description:
Provide a communications channel between the system and a remote trusted system for the performance of security-critical operations.


Objective Description:
Implement a configuration management plan.  Implement configuration management to assure storage integrity, identification of system connectivity (software, hardware, and firmware), and identification of system components (software, hardware, and firmware).


Objective Description:
Provide the ability for the authorized user to verify that the system operates as designed.

Implementation Application:
To ensure that tests in FPT_TST.1 are reliable, select EAL2 or greater assurance.


Objective Description:
Restrict user access to cryptographic IT assets in accordance with a specified user access control policy.


Objective Description:
Provide secure session establishment between the system and remote systems using encryption functions.

Objective-Selection Guidance:
This objective assumes authorization for the local system to communicate with specific remote systems and compatible cryptographic support from those remote systems.  These assumptions may require additional requirements to be levied on the local and/or remote systems. This components associated with this objective might be considered as a specific implementation of other secure channel requirements.  It is likely that all the components specified for this objective must be provided by the system in order to implement a robust solution.  The set of associated components is preventive.

Implementation Application:
Application of the cryptographic components will vary depending on the session protocol, not all components are relevant to all protocols.

Objective Editorial:
<specific objective>
This objective differs from O.Data_Exchange_Conf in that the encryption function for this objective is required to establish the session. That is, some of the lower-level protocol headers may themselves be encrypted.


Objective Description:
Provide complete separation between plaintext and encrypted data and between data and keys.  This requires separate channels and separate storage areas.  The only place any data can pass between the plaintext and encrypted data modules is in the cryptographic engine.  There should be no way for plaintext keys to reach either data module and no way for data to enter the key handling module.  Eencrypted keys can be handled as encrypted data, but with limited user access.

Implementation Application:
Choose ADV_INT.1, FPT_SEP.2, and FDP_IFF.3; apply using a technical policy on separation of encrypted and plaintext data (sometimes referred to as red-black separation).


Objective Description:
Minimize or even eliminate design and implementation errors in the cryptographic modules and functions.

Objective-Selection Guidance:
The PP/ST should demonstrate that the TOE provides at least a high level architecture appropriate to implement the claimed cryptographic functional requirements.  Demonstration that lower levels of design correctly implement the highest design level may also be appropriate.


Objective Description:
Specify security functional requirements (SFRs) that are expected to be satisfied by other software, firmware or hardware that is external to the TOE.

Objective-Selection Guidance:
In certain circumstances, the TOE may have dependencies on other software, firmware or
hardware (e.g. on the security functionality of an underlying operating system).

Objective Editorial:
No supporting components -- this objective is unfinished.


Descriptive Name:
Cryptographic import, export, and inter-TSF transfer

Objective Description:
Protect cryptographic data assets when they are being transmitted to and from the TOE, either through intervening untrusted components or directly to/from human users.

Objective-Selection Guidance:
Cryptographic assets that may need protection include cryptographic keys that are unencrypted or are weakly encrypted with a password, cryptographic security parameters, and plaintext authentication data.

Implementation Application:
Three different implementations may achieve the intent of this objective (and combinations are possible):

1. Use FTP_TRP.1 and/or FTP_TRC.1 to specify trusted paths and channels for communicating cryptographic assets.

2. Require a separate physical port for input and output of such information; use FDP_ETC.1 and FDP_ITC.1 for this. 

3. Require security labeling of cryptographic data; in this case, use FDP_ETC.2 and FDP_ITC.2 instead.  

All three implementations assume user cognizance.  Specify this using AGD_ADM.1 and/or AGD_USR.1.


Objective Description:
Fully define cryptographic components, functions, and interfaces.  Ensure appropriate protection for cryptographic keys throughout their lifecycle, covering generation, distribution, storage, use, and destruction.

Objective-Selection Guidance:
If cryptographic functions are supported, then their management and protection needs to be clearly specified.

Implementation Application:
Cryptographic function may be specified either directly via functional requirements or indirectly via assurance requirements.  Directly specify key management using components of the FCS_CKM family, with the following additions, depending on the nature of the keys:
   protection of stored user keys:  use FDP_ACC and FDP_ACF, refine AVA_VLA.1
   user key attributes:  use FMT_MSA, FDP_ACC, and FDP_ACF.
   user key entry: use FDP_ITC.
   protection of stored TSF keys:  use FPT_SEP.
   TSF key entry: use FMT_MTD.

Alternatively or additionally, require the TOE developer to specify cryptographic key management by using ADV_FSP and ADV_SPM.

Objective Editorial:
Cryptographic function includes not only key management but cryptographic operation -- see O.Crypto_Operation.


Objective Description:
Provide one or more roles to manage cryptographic assets and attributes.

Objective-Selection Guidance:
Choose in order to limit dangers resulting from widespread access to the control of cryptographic assets.


Objective Description:
Prevent errors in one part of the TOE from influencing other parts, especially cryptographic parts.  To this end, noncryptographic I/O paths must be well defined and logically independent of circuitry and processes performing key generation, manual key entry, key zeroising, and similar key-related operations.

Implementation Application:
---
This objective helps insure that the TOE is designed using sound engineering principles and, hence, that data is accessed only by the components of the TOE that need it.  The low-level design requirements that support this objective can be used to ensure that the inputs, outputs, plaintexts, and ciphertexts are accessed only by components of the TOE that need them.


Objective Description:
Cryptographic components, functions, and interfaces shall be fully defined.

Objective-Selection Guidance:
If cryptographic functions are supported, then the definition of the cryptographic functionality should be clearly present, as should definitions of the cryptographic and physical/logical boundaries.

Implementation Application:
Cryptographic function may be specified either directly via functional requirements or indirectly via assurance requirements.  Directly specify cryptographic operations using components of the FCS_COP family.  Alternatively or additionally, require the TOE developer to specify cryptographic operation by using ADV_FSP and ADV_SPM.

Objective Editorial:
Cryptographic function includes key management as well as cryptographic operation -- see O.Crypto_Key_Man.


Objective Description:
Provide the ability to verify that the cryptographic functions operate as designed.

Objective-Selection Guidance:
Select this objective if O.Secure_State is specialized to protect cryptographic operation. (Implicit from the need to preserve a secure state when cryptographic errors occur, is the need for functionality to detect when such errors occur.)


Objective Description:
Test cryptographic operation and key management.

Implementation Application:
Testing requirements should be selected based on the sensitivity of the application and vulnerability of the TOE to attack.  In particular, greater depth of testing may provide better assurance of correct function, and may well be feasible, as cryptographic functions are often fairly simple and modular.


Objective Description:
Protect user data confidentiality when exchanging data with a remote system.

Objective-Selection Guidance:
This objective can support several types of data exchange policies, including those that do not allow communications between the local system and specific remote sites, as well as those that constrain the types of information that can be sent over communications lines.


Objective Description:
Impose information control policies that do not allow export of specified data and/or export to specified locations.

Objective-Selection Guidance:
This objective is relevant when exporting user data is considered to be a sensitive operation.  Data exportation may exist in many forms, including printing, removable media storage, sending e-mail, and/or transferring files to an external network via network protocols.

Implementation Application:
There are two variants of this objective (choose one):
[Unmarked]: Choose FDP_ETC.1.
[Marked]: Choose FDP_ETC.2.

The choice of whether to export data with or without security attributes will depend on several considerations.  The predominant considerations are the potential and actual uses of the security attributes in the destination environment. The less potential for use in the destination environment, the less motivation to mark exported data with security attributes, even if such attributes are maintained internally.
---
The [Unmarked] variant applies a policy enforcement to the export of user data, but does not require security attributes to be associated with the exported data itself. The term "unmarked" indicates that the data is not associated with any security attributes whatsoever, avoiding possible misconceptions that might be implied by the term "unlabeled."

The [Marked] variant applies policy enforcement to the export of user data. In addition, the implementation provides security attributes that are associated, with moderate to high effectiveness, with instances of exported data.  The attributes are those associated with specific security function policies. The term "marked" indicates that the security attributes may not actually represent security labels in its common usage.

Objective Editorial:
<generic objective>

This objective has been implemented using FDP_ACC and FDP_ACF.  An alternate implementation using FDP_IFC and FDP_IFF is also possible.


Descriptive Name:
Data import/export to/from system control

Objective Description:
Protect data from being sent to erroneous places and more places external to the system than allowed by the organization's security policy.  Conversely the import of data into the system should be protected from illicit information or information not allowed by the organization's security policy.

Objective-Selection Guidance:
This objective is relevant in the following scenarios:
1. When a user has the ability to give out information that could cause an outsider to send data that is not deemed acceptable by the organization's policy or from a location unacceptable by the organization's policy this objective should be considered (e.g. adult only web sites). 

2. When a user has the ability to send data to inappropriate locations or to more locations than the organization's policy allows this objective should be considered.

3. When a hacker can flood the system (TOE) with illicit data, import control should be enforced.


Objective Description:
Design and build the system in such a way as to control the production of intelligible emanations within specified limits.

Objective-Selection Guidance:
Select this objective when there is a need to control intelligible emanations before they leave the TOE itself.

Objective Editorial:
[assignment: specified limit]. This objective is a minor variant of O.IntelEman_Control.


Objective Description:
Deter cryptoanalysis of ciphertext by denying unauthorized access to encrypted objects.


Descriptive Name:
Protection of corresponding plaintext-ciphertext pairs

Objective Description:
Prohibit the transmission of a ciphertext message over any network where the corresponding plaintext might be available. Include cryptographic padding (i.e., random plaintext) to hide the correspondence between segments of real ciphertext and their known plaintexts.

Objective Editorial:
<specific objective><apply generics>

Hierarchical to:  O.Robust_Encryption

This objective is implemented via an access-control policy.


Descriptive Name:
Sanitize data objects containing hidden or unused data

Objective Description:
Sanitize data objects that may contain hidden data when they are exported from the TOE in order to inhibit steganographic smuggling.


Descriptive Name:
Label or mark information for external systems

Objective Description:
Label or mark information for external systems to prevent the exchange of inappropriate data between systems.


Descriptive Name:
Preservation of secure state for failures in critical components

Objective Description:
Preserve the secure state of the system in the event of a secure component failure.

Objective-Selection Guidance:
This objective is relevant if the TOE needs to continue some form of operation in the presence of failures. The scope of the identified failures for which the system will fail secure will, in general, directly impact the feasibility and cost of implementing this protection feature.

Implementation Application:
Choose FPT_FLS.1 to implement this objective.
---
This objective applies to the secure state of the system in its entirety.


Descriptive Name:
Provide fault tolerant operations for critical components

Objective Description:
Provide fault tolerant operations for critical components and continue to operate in the presence of specific failures in one or more system components.

Objective-Selection Guidance:
This objective enhances the availability and/or integrity of some or all of the TOE's capabilities.  These may be functional capabilities and need not be a part of the TSF, itself. The scope of the identified failures for which the system provides fault tolerance will, in general, directly impact the feasibility and cost of implementing this protection feature.

Implementation Application:
There are two variants of this objective (choose one):
[Basic]: Choose FRU_FLT.1
[Resistant]: Choose FRU_FLT.2

Choose the [Basic] variant if only some system capabilities need to be fault tolerant to some failures. 
Choose the [Resistant] variant if all system capabilities need to be fault tolerant to some failures. In general, the [Resistant] variant is much more difficult to implement than the [Basic] variant.
---
However, the TSF must guarantee that tolerance (e.g., continuing operation) of the TSF in the presence of the identified failures does not at the expense of the TSF's secure state (see FPT_FLS.1). The types of failures and the related TOE capabilities listed in this component should be strongly correlated with the resultant risk, otherwise the degree of protection provided may be inadequate or not cost effective.


Objective Description:
Provide periodic integrity checks on both system and user data.


Descriptive Name:
Guarantee the availability of audit storage space

Objective Description:
Maintain audit data and guarantee space for that data.

Objective-Selection Guidance:
Should user or hacker unauthorized actions potentially cause processes to exceed storage limitations, guaranteeing audit storage space should eliminate service shutdown associated with running out of audit storage space.

Objective Editorial:
<generic objective - may require specialization for use in countering particular attacks>


Objective Description:
Limit the number of sessions available to outside users.  A hacker can initiate multiple communication sessions that could cause an overload on resources, for example, half open session starts as is seen in "SYN flood" attacks.


Objective Description:
Control (e.g. reroute or discard) hacker communication traffic to prevent potential damage.

Objective-Selection Guidance:
Various kinds of hacker attacks can be detected or prevented by rerouting or discarding suspected hacker traffic. By rerouting hacker communication traffic predictive analysis can be performed to discover potential future hacker attacks.


Descriptive Name:
Identify and authenticate a user to support accountability

Objective Description:
Provide the basic I&A functions that will support user accountability.

Implementation Application:
Choose FIA_UID.1, FIA_UAU.2, FIA_UAU.7, FIA_ATD.1, FIA_USB.1, and FTA_TAB.1 to implement the objective.


Objective Description:
Associate each transaction between a user and a system/application with a unique transaction ID, allowing events associated with a given transaction to be distinguished from other events involving the user and/or system/application.

Objective-Selection Guidance:
Select this objective when it is necessary to recognize when two or more events belong to the same transaction.


Objective Description:
Uniquely identify and authenticate each user of the system.

Objective Editorial:
<specific objective><too simple - just "I" - no "A">


Objective Description:
Associate each user-requested action with the user who requested the action.

Objective Editorial:
Dependent Objectives:  O.Trusted_Path and/or  O.Trusted_Channel
Treatment of this objective is incomplete. There are a good many more I&A strategies than presented here.


Objective Description:
Identify unusual user activity on the system.

Objective-Selection Guidance:
In addition to heuristics aimed at identifying unusual activities, there are a wide variety of preventive measures that can help identify unusual activities as a side effect. For example, suppose that the ability to login is restricted (e.g., via FTA_LSA.1, FTA_MCS.1). Users who attempt to evade these restrictions may be identified, and the need to enforce these restrictions may be evidence of unusual activity by such users.

Objective Editorial:
<specific objective><too simple - may have been changed>


Objective Description:
Enforce an information flow policy whereby users are constrained from allowing access to information they control, regardless of their intent (e.g., mandatory access control).
This lattice property of security attributes is commonly associated with the U.S. DoD implementations of Mandatory Access Control (MAC).

Implementation Application:
Four variants of this objective exist (choose one).
[Subset-Simple] Choose FDP_IFC.1 and FDP_IFF.1.
[Subset-Lattice] Choose FDP_IFC.1 and FDP_IFF.2.
[Complete-Simple] Choose FDP_IFC.2 and FDP_IFF.1.
[Complete-Lattice] Choose FDP_IFC.2 and FDP_IFF.2.



Each of the four variants has an FDP_IFC component to define the policy and an FDP_IFF component to describe how the policy is to be enforced. FDP_IFC.1 and FDP_IFC.2 differ in the scope of the information flow policy. FDP_IFF.1 and FDP_IFF.2 differ in the scope of the information flow policy and the structure of the security attributes used.  In the latter case, the attribute values must be partially-ordered in a relationship called a "lattice."


Descriptive Name:
Provide information flow control administration

Objective Description:
Manage information flow control policy and functions to allow only specified administrators to have the ability to manipulate the information flow control.

Objective-Selection Guidance:
This objective is relevant when an administrator could cause misdirected traffic.


Descriptive Name:
Require inspection for absence of malicious code.


Objective Description:
Ensure that data markings are included with data that is exported to another trusted product.


Descriptive Name:
Integrity of system data transferred externally

Objective Description:
Ensure the integrity of system data exchanged externally with another trusted product by using a protocol for data transfer that will permit error detection and correction. 

This includes detecting and possibly correcting errors in data received and encoding outgoing data to make it possible for the receiver to detect and possibly correct errors.  The method for detecting and correcting errors is based on some method (protocol) that is agreed upon by participating parties.


Descriptive Name:
Integrity of system data transferred internally

Objective Description:
Ensure the integrity of system data transferred internally.

Implementation Application:
Two variants of this objective can be implemented: 
[CASE-A] Choose FPT_ITT.1 and FPT_SSP.1. 
[CASE-B] Choose FPT_ITT.1 and FPT_SSP.2. 

FPT_SSP.1: This component is recommended when the system is distributed.  This requirement provides simple acknowledgement by the data recipient.

FPT_SSP.2: This component is recommended when the system is distributed.  This requirement provides mutual acknowledgement of the data exchange.


Descriptive Name:
Protect user data during internal transfer

Objective Description:
Ensure the integrity of user data transferred internally within the system.

Objective Editorial:
<specific objective><re-do as generic><wrong ID/words - not the integrity components from this family>


Descriptive Name:
Correct attribute exchange with another trusted product

Objective Description:
Ensure that the system correctly exchanges security-attribute information with another trusted IT product.


Descriptive Name:
Integrity protection for user data and software

Objective Description:
Provide integrity protection for user data and software.


Objective Description:
Ensure that when system data replication occurs across the system the data is consistent for each replication.

Objective-Selection Guidance:
This objective is relevant to a distributed system as well as standalone systems.  Ensure that data updates are consistent when one or more parts of a distributed system are not available.


Descriptive Name:
Operational integrity system function testing

Objective Description:
Provide system functional tests to periodically test the integrity of the hardware and code running system functions.


Objective Description:
Confine system-produced intelligible emanations to within a specified limit.

Objective-Selection Guidance:
Select when there is a need to control intelligible emanations in the TOE environment.

Implementation Application:
This objective should be allocated to the TOE environment.


Objective Description:
Limit system-produced intelligible emanations to within a specified limit.

Objective-Selection Guidance:
Select when there is a need to control intelligible emanations before the leave the TOE itself.

Objective Editorial:
[assignment: specified limit].  This objective is a minor variant of O.EMSEC_Design.


Objective Description:
Limit system-produced electromagnetic emanations to within a specified limit.

Objective-Selection Guidance:
Select when there is danger that the emanations from the TOE may interfere with surrounding equipment.

Objective Editorial:
This objective is hierarchical to the O.IntelEman_Control objective.


Objective Description:
Run executable code in a protected domain where the code's potential errors or malicious code will not significantly impact other system functions of other valid users of the system.

Objective-Selection Guidance:
For example, in the case of Java applets the protected domain is referred to as a "sandbox".


Objective Description:
Provide tools, techniques, and security employed during the development phase.  Detect and resolve flaws during the operational phase.  Provide safe destruction techniques.

Objective Editorial:
<specific objective>

This objective is dependent on O.Config_Management.


Objective Description:
Restrict the actions a user may perform before the TOE verifies the identity of the user.


Descriptive Name:
Limit the number of user initiated communication sessions

Objective Description:
Provide mechanisms to limit the number of sessions that the user can initiate, if the user initiates multiple sessions that exceed the processors ability to perform in a reliable and efficient manner. These sessions could ether be communication (TCP/IP) sessions or user login sessions.

Objective-Selection Guidance:
This objective is relevant if the processor can not effectively handle many concurrent sessions.  If the processor time and memory are in abundance and will potentially never be overtaxed by multiple concurrent sessions then this objective might not be necessary.

Objective Editorial:
<specific objective><could be generic><close to duplicate of O.Limit_Mult_Sessions>


Objective Description:
Provide the capability to limit the number of sessions that a user may have open at one time.


Descriptive Name:
Limit observation of service usage to authorized users

Objective Description:
Provide authorized users with the capability to observe the usage of specified services or resources as necessary to perform their duties.

Objective-Selection Guidance:
When observation of service or resource usage is limited, choose this objective to mandate which authorized users are exempted from those limitations.

Implementation Application:
Choose FPR_UNO.4 to implement the objective.


Objective Description:
Maintain at least one security domain for system (TOE) execution to protect the TOE from interference and tampering.


Descriptive Name:
Controlled access by maintenance personnel

Objective Description:
Control access to the system by maintenance personnel who troubleshoot the system and perform system updates.


Objective Description:
Terminate maintenance user system access privilege automatically after expiration of assigned timed interval.

Objective Editorial:
<specific objective>

Hierarchical to:  O.Prvlg_IF_Status


Descriptive Name:
Procedures for preventing malicious code

Objective Description:
Incorporate malicious code prevention procedures and mechanisms.


Objective Description:
Provide management on resource security attributes.

Objective-Selection Guidance:
If a user had the capability to modify attributes of any given resource to the extent that a legitimate user does not have access to that resource this objective should be considered.

Examples or relevant resources include data files, communication resources, and other system objects.

Objective Editorial:
<specific objective>

A user can modify or add attributes of a resource, which would deny access to the resource for other legitimate users (e.g. - change drive share password).  It is paramount that the resource be protected against any user that would cause a denial of a resource based on an attribute modification or addition.


Descriptive Name:
Manage security-critical data to avoid storage space being exceeded

Objective Description:
Manage security-critical (TSF) data to ensure that the size of the data does not exceed the space allocated for storage of the data.

Objective-Selection Guidance:
Should storage space be limited and a potential exist for a user's unauthorized action cause the storage limits to be exceeded, then specific management of the storage space may be critical. Therefore, management of the storage space is needed.


Objective Description:
Ensure there is no "object reuse;" i.e., ensure that there is no residual information in some information containers or system resources upon their reallocation to different users.

Implementation Application:
Select one of FDP_RIP.1 or FDP_RIP.2 to specify the scope of protection against disclosure of residual information.


Descriptive Name:
Non-repudiation support for received information by a nonlocal sender's TSF

Objective Description:
Support nonrepudiation for received information by supporting remote handling of nonrepudiation evidence if needed.

Objective-Selection Guidance:
Use this objective to help ensure that the recipient of a message cannot successfully deny receiving the message from its sender.

Complete the operations in a component from the FCO_NRR family to address your specific security needs. Specify whether the TOE or a remote trusted product generates evidence that a message was received. Specify whether the TOE or a remote trusted product requests such evidence.

Objective Editorial:
Objective is stated as if the TOE were remote.


Descriptive Name:
Non-repudiation support for sent information by the nonlocal receiving TSF.

Objective Description:
Support nonrepudiation for sent information by supporting remote handling of nonrepudiation evidence if needed.

Objective-Selection Guidance:
Use this objective to ensure that the sender of a message cannot successfully deny sending the message.

Complete the operations in a component from the FCO_NRO family to address your specific security needs. Specify whether the TOE or a remote trusted product generates evidence that a message was sent. Specify whether the TOE or a remote trusted product requests such evidence.


Descriptive Name:
Non-repudiation support for received information by the recipient's TSF

Objective Description:
Prevent a receiving user from avoiding accountability for receiving a message by providing evidence that the user received the message.

Objective-Selection Guidance:
Use this objective to ensure that the recipient of a message cannot successfully deny receiving the message.

Complete the operations in a component from the FCO_NRR family to address your specific security needs. Specify whether the TOE or a remote trusted product generates evidence that a message was received. Specify whether the TOE or a remote trusted product requests such evidence.

Implementation Application:
The objective has multiple implementations.  Using FCO_NRR.2 is a special case of using FCO_NRR.1 and may be stronger.  FMT_MOF.1 and AGD_ADM.1 are needed if threat countering is to be performed by third parties using the same system as the recipient.


Descriptive Name:
Non-repudiation support for sent information by the sender's TSF.

Objective Description:
Prevent a user from avoiding accountability for sending a message to a recipient at a different site by providing evidence that the user sent the message.

Implementation Application:
The objective has multiple implementations.  Using FCO_NRO.2 is a special case of using FCO_NRO.1 and may be stronger.  FMT_MOF.1 and AGD_ADM.1 are needed only if threat countering is to be performed by third parties (i.e., people other than the recipient).


Descriptive Name:
Non-repudiation for received information, local users

Objective Description:
Prevent user from avoiding accountability for receiving a message from another user on the same system by providing evidence that the user received the message.

Objective-Selection Guidance:
Use this objective to ensure that the recipient of a message cannot successfully deny receiving the message.

Implementation Application:
The objective has multiple implementations.  Using FCO_NRR.2 is a special case of using FCO_NRR.1 and may be stronger.  FMT_MOF.1 is needed only if threat countering is to be performed by third parties (i.e., people other than the sender). Impose additional requirements, e.g., FDP_ITT.1 in order to strengthen nonrepudiation by ruling out the possibility that the message received differs from the message that was sent.


Descriptive Name:
Non-repudiation for sent information, local users

Objective Description:
Prevent user from avoiding accountability for sending a message to another user on the same system by providing evidence that the user sent the message.

Implementation Application:
The objective has multiple implementations.  Using FCO_NRO.2 is a special case of using FCO_NRO.1 and may be stronger.  FMT_MOF.1 is needed only if threat countering is to be performed by third parties (i.e., people other than the recipient). FDP_ITT.1 strengthens nonrepudiation by ruling out the possibility that a different message is received than was sent.


Objective Description:
Provide evidence that a user received information.

Objective-Selection Guidance:
This objective is relevant when a user must be held accountable for having received information that has been delivered to that user (e.g., a message).

Implementation Application:
Choose either FCO_NRR.1 or FCO_NRR.2 (but not both) for each application of this objective.
----
FCO_NRR.1: Choose this component when the application requiring evidence of receipt does not always require the evidence, but when one or more of the parties may selectively invoke the generation of evidence on a case-by-case basis.
----
FCO_NRR.2: Choose this component when the application requiring evidence of receipt must always generate the evidence.


Objective Description:
Provide evidence that a user sent information.

Objective-Selection Guidance:
This objective is relevant when a user must be held accountable for having sent a specific instance of information (e.g., a message).

Implementation Application:
Choose either FCO_NRO.1 or FCO_NRO.2 (but not both) for each application of this objective.
----
FCO_NRO.1: Choose this component when the application requiring evidence of origin does not always require the evidence, but when one or more of the parties may selectively invoke the generation of evidence on a case-by-case basis.
----
FCO_NRO.2: Choose this component when the application requiring evidence of origin must always generate the evidence.


Objective Description:
Maintain object security attributes with moderate to high accuracy (under the guidance of qualified users).


Objective Description:
Require domain protection for objects. Specify object classes (domains), user groups, and operation classes.  Use these to specify which operations may be performed on which objects by which users.  Basically this controls what users can do in a given group.

Objective-Selection Guidance:
This differs from traditional access control policy. In traditional access control policies there is a separate object class for each object, and there are just three operation classes: read, write, and execute.


Descriptive Name:
Permit users to use services under aliases

Objective Description:
Permit some users to maintain partial anonymity when using specified services or resources by means of aliases.

Objective-Selection Guidance:
The intent of this objective is to ensure that a user may use a service or resource without disclosing the user's identity, but can still be accountable for that use. This objective allows subject activity to be tracked without necessarily associating subjects with users.

Implementation Application:
There are three variants of this objective (choose one):
[Basic]: Choose FPR_PSE.1
[Reversible]: Choose FPR_PSE.2.
[Reusable]: Choose FPR_PSE.3.
---
The [Reversible] and [Reusable] variants add limited accountability to the [Basic] variant.


Descriptive Name:
Permit users to use services anonymously

Objective Description:
Permit some users to maintain anonymity when using specified services or resources.

Objective-Selection Guidance:
The intent of this objective is to ensure that a user may use a service or resource without disclosing the user's identity. This objective can be used to ensure that the system provides some services anonymously for some users.

Implementation Application:
There are two variants of this objective (choose one):
[Basic]: Choose FPR_ANO.1.
[Enhanced]: Choose FPR_ANO.2.


Descriptive Name:
Prevent system from collecting user privacy information

Objective Description:
Provide some services or resources to specified users without soliciting from the user information that is relevant to the user's privacy.

Objective-Selection Guidance:
The intent of this objective is to permit users to use services without being observed by preventing the IT system or product from soliciting information that might be used to compromise users' privacy.

Implementation Application:
Choose FPR_UNO.3 to implement the objective.


Objective Description:
Ensure that a user may make multiple uses of a service or resource without other specified users being able to link these uses together.

Objective-Selection Guidance:
The intent of this objective is to protect the user identity against the use of profiling of operations.

Implementation Application:
Choose FPR_UNL.1 to implement the objective.


Objective Description:
Ensure that a user may use a service or resource without other specified users being able to observe that the service or resource is being used.

Objective-Selection Guidance:
This objective is relevant when the system (TOE) is required to protect the privacy of users.

Implementation Application:
There are two variants of this objective (choose one):
[Basic]: Choose FPR_UNO.1.
[Distribution]: Choose FPR_UNO.2.
---
FPR_UNO.2 is generally more effective than FPR_UNO.1 given appropriate implementation.


Objective Description:
Control access to resources so that lower-priority activities do not unduly interfere with or delay higher-priority activities.

Objective-Selection Guidance:
This objective is needed when a potential exists for a shareable resource to be overburdened.  Note that any user and any threat agent potentially overloads resources.

Implementation Application:
FRU_PRS.1 applied on a specific resource should provide protection for critical subjects and services that require that specific resource. FRU_PRS.2 applied against all resources should provide higher reliability for critical subject(s) and service(s) to receive the resources that they require.

The specific source (threat agent and method of attack) should be used as a guide to determine the usage of the requirements used to apply priority of service to the resource being overloaded or impacted.


Objective Description:
Provide capability for an administrator to determine the use status of all privileged interfaces.  This would include interfaces used by maintenance personnel.

Objective Editorial:
<specific objective>

Hierarchical to: O.Maintenance_Access


Descriptive Name:
Identify message modification in messages received

Objective Description:
The TSF recognizes changes to messages that occurred in transit, including insertion of spurious messages and deletion or replay of legitimate messages.


Descriptive Name:
Recovery from modification of received messages

Objective Description:
The TSF detects and corrects changes in messages received from a remote trusted site.

Objective-Selection Guidance:
Choose FDP_UIT.1 and either FDP_UIT.2 or FDP_UIT.3.  FDP_UIT.3 provides less dependence on the environment.


Objective Description:
Implement automated notification or other reactions to the TSF-discovered attacks in an effort to identify attacks and to create an attack deterrent.

Objective-Selection Guidance:
This objective is relevant if actions that the organization deems essential also pose a potential attack that could be exploited. Of particular interest for discovering attacks would be application of mapped components to failures in the following functions: FIA_AFL.1, FPT_RPL.1, FTA_LSA.1, FDP_IFF.1, FDP_ACF.1.


Objective Description:
Always invoke mechanisms that enforce security policies (i.e., as for a traditional reference monitor).


Objective Description:
Disable a remote entity's ability to execute local code.


Objective Description:
Use resource quotas to limit user and service use of system resources to a level that will prevent degradation or denial of service to other critical users and services.

Objective-Selection Guidance:
If resources are subject to overload due to a subject or service using more than it's share of the resource this objective should be used. This is relevant for a potential user misuse or hacker Denial of Service attack.  Both component choices are preventative, although they may also facilitate detection and/or recovery features.
FRU_RSA.1 is a simpler form of quota mechanism use.
FRU_RSA.2 builds on the functionality of FRU_RSA.1 with the additional of minimum use quotas, which is important availability and guaranteed service considerations.
In general, FRU_RSA.2 would be much more difficult to ensure than FRU_RSA.1.


Objective Description:
Produce cipher text that cannot be decrypted without either massive computational power or knowledge of the encryption key through robust encryption techniques.

Objective-Selection Guidance:
This objective captures the PP authors' preferences for encryption techniques.  Evaluation of the objective does not cover inherent strength of encryption.

Objective Editorial:
<specific objective>

This objective might better be listed as, or accompanied by an assumption regarding what passes for sufficiently strong encryption.


Larger keys make encryption more difficult. The degree of redundancy in the associated plaintext and the size of the plaintext may have bearing here as well.  Frequent key replacement minimizes the damage done by an attacker who discovers a key.


Objective Description:
Recover from user operations by undoing some user operations (i.e., "rolling back") to restore a previous known state.


Objective Description:
Provide a screen lock function to prevent an unauthorized user from using an unattended computer where a valid user has an active session.

Objective Editorial:
<generic objective><missing third component in family - separate objective>


Objective Description:
Manage and update system security policy data and enforcement functions, and other security-relevant configuration data, in accordance with organizational security policies.

Implementation Application:
All the FMT components here are preventive and enable secure configuration management.

FMT_MTD.1 will almost always be required to satisfy this objective, as it provides the capability for system administrators to manage the configuration of the system.
FMT_MOF.1 will be relevant for those functions whose behavior is determined by configuration data (e.g., security policy enforcement).
AGD_ADM.1 is required to support either of the FMT components.


Descriptive Name:
Protect and maintain secure system state

Objective Description:
Maintain and recover to a secure state without security compromise after system error or other interruption of system operation.

Objective-Selection Guidance:
There are tradeoffs between functions that fail secure and those in which failures can be recovered from securely.

Implementation Application:
In applying this objective, provide a secure state definition that captures the notion of being able to enforce the TSP.  If the TSP isn't conveniently described in terms of a secure-state model, the PP author may wish to introduce a CC-extending component that recasts FPT_RCV to accommodate the PP's TSP description.

Objective Editorial:
<specific objective><redo as generic combo>


Objective Description:
Manage the initialization of, values for, and allowable operations on security attributes.

Implementation Application:
Three variants of this objective exist (choose any):

[Restrict]: Choose FMT_MSA.1.
[Secure]: Choose FMT_MSA.2.
[Init]: Choose FMT_MSA.3.


Objective Description:
Manage the initialization of, limits on, and allowable operations on security-critical data.

Implementation Application:
Three variants of this objective exist (choose any):

[Restrict]: Choose FMT_MTD.1.
[Limits]: Choose FMT_MTD.2.
[Secure]: Choose FMT_MTD.3.


Objective Description:
Provide management mechanisms for security mechanisms.

Implementation Application:
Choose FMT_MOF.1 to implement this objective.


Objective Description:
Maintain security-relevant roles and the association of users with those roles.

Objective-Selection Guidance:
Select this objective whenever it is necessary to define one or more security roles.

Implementation Application:
Two variants of this objective exist.

[Basic] Choose FMT_SMR.1. This variation provides the basic capability to define different roles among users of the system.

[Restricted] Choose FMT_SMR.2. This variation provides the additional capability of placing constraints on use of the defined roles within the system.


Descriptive Name:
System terminates session for inactivity

Objective Description:
System terminates a session after a given interval of inactivity.

Implementation Application:
Choose FTA_SSL.3 to implement the objective.


Descriptive Name:
Identify message modification in messages sent

Objective Description:
The TSF supports recognition of changes to transmitted messages that occurred in transit, including insertion of spurious messages and deletion or replay of legitimate messages.


Descriptive Name:
Support recovery from modification of sent messages

Objective Description:
The TSF supports detection and correction changes in messages sent to a remote trusted site.


Descriptive Name:
Examine the source code for developer flaws

Objective Description:
Examine for accidental or deliberate flaws in code made by the developer.  The accidental flaws could be lack of engineering detail or bad design.  Where the deliberate flaws would include building trapdoors for later entry as an example.

Objective-Selection Guidance:
This objective will not fully ensure that code is not flawed in some manner. The flaws may not be noticed until actual execution of the code.

Objective Editorial:
<specific objective>

This objective would be a non-IT objective where code examination would most likely require a human to look at the code.


Objective Description:
Present each possible output value in a standard form.

Objective-Selection Guidance:
This objective is feasible when software can produce highly structured output.

Objective Editorial:
This objective is dependent on the  O.Admin_Code_Val objective.


Objective Description:
Inform the user of the possibility of the system monitoring his actions, and that misuse of the system may result in criminal or civil penalties.


Objective Description:
Ensure that security-relevant software, hardware, and firmware are correctly functioning through features and procedures.


Objective Description:
Provide backup procedures to ensure that the system can be reconstructed.

Objective Editorial:
<specific objective><duplicate?><redo as call to generic?>


Descriptive Name:
Frequent backups to prevent minimal loss

Objective Description:
Provide through frequent backups, restoration of security-relevant changes to the system between backup and restore, and restoration of the security-relevant system state (e.g. access control list) without destruction of other system data.


Descriptive Name:
Sufficient backup storage and effective restoration

Objective Description:
Provide sufficient backup storage and effective restoration to ensure that the system can be recreated.


Descriptive Name:
Detect modifications of backup hardware, firmware, software

Objective Description:
Detect modifications to backup hardware, firmware, and software.

Implementation Application:
The component FPT_PHP.1 would be used to provide the physical protection of the backup hardware, firmware, and software.  The components FPT_TST.1 and FPT_AMT.1 would be used to test whether the secure state of the backup hardware, firmware, and software is maintained and restored if necessary.


Objective Description:
Protect the system security functions through technical features.

Objective Editorial:
<generic objective><for generic, missing 3rd component>


Objective Description:
Provide system features that detect physical tampering of a system component, and use those features to limit security breaches.

Objective-Selection Guidance:
O.Tamper_ID provides capabilities to detect physical attacks against specified parts of the TOE.

Implementation Application:
Two variations of this objective exist (choose one).
[Detect] This variation provides basic capabilities to detect physical tampering attacks. It relies more on user responsibility to follow procedures for identifying and acting upon detected physical tampering attacks. 
[Notify] This variant increases TOE responsibility and decreases user responsibility, because the TSF alerts a designated individual when it has been tampered with.

Objective Editorial:
<generic objective>


The O.Tamper_Resistance objective may also be relevant.


Objective Description:
Prevent or resist physical tampering with specified system devices and components.

Objective-Selection Guidance:
O.Tamper_Resistance provides capabilities to automatically respond to physical attacks against specified parts of the TOE, thereby resisting such attacks. The automatic response may take varying forms, but generally involves direct actions (e.g., shutting a system down) rather than notification actions.

Should the environment lend itself to being vulnerable to physical attack and resources are ultimately critical then this objective should be considered. For example, communications resources can be jeopardized through a physical attack.

Implementation Application:
[FPT_PHP.3] Provides automatic response to physical attacks against resources deemed critical, thereby resisting those attacks.


Objective Description:
Ensure that a replaced failed component when re-integrated into the system will recover such that it will not cause errors or security breaches in other parts of the system.

Implementation Application:
Select one of FPT_RCV.1, FPT_RCV.2, or FPT_RCV.3.  FPT_RCV.4 may be used to augment any of these other components.


Objective Description:
Provide a trusted path between the user and the system. Execution of a user-requested action must be made via a trusted path with the following properties:
  * The path is logically distinct from, and cannot be confused with other communication paths (by either the user or the system). 
  * The path provides assured identification of its end points.

Objective-Selection Guidance:
By definition, trusted-path threats are those that interfere with the trusted path objective. However, trusted-path threats are also masquerade threats because I&A depends on trusted path. 

Use the trusted-path objective for all trusted communication between the user and the TSF.  trusted path for information exchanged via the path. It doesn't matter who initiates the trusted path since by definition, its presence cannot be faked.

Objective Editorial:
<generic done as specific?>

This component is relevant when a user or administrator might use another IT device to attempt to gain TSF security attribute information that they are not authorized to access.


Objective Description:
Provide a trusted path to security-critical (TSF) data in which both end points have assured identities. For the remote user, there needs to be a trusted channel as well.


Descriptive Name:
Trusted recovery of security functionality

Objective Description:
Recovery to a secure state, without security compromise, after a discontinuity of operations.

Objective-Selection Guidance:
This objective is relevant when system failures could result in insecure states that, when the system returns to operational mode (or continues to operate), could lead to security compromises.

This objective is primarily related to recovery, although it might also be thought of as preventive in the sense of preventing additional losses incurred by running the TOE in an insecure state.

Implementation Application:
There are three variants of this objective (choose one):
[Manual]: Choose FPT_RCV.1
[Automated]: Choose FPT_RCV.2
[Quantified]: Choose FPT_RCV.3

The [Manual] variant should be chosen when manual procedures for recovery are acceptable.
The [Automated] variant should be chosen when the TOE must recover from some failure scenarios without human intervention. 
The [Quantified] variant should be chosen following the same criteria as for the Automated variant, but in addition there is a strong need to limit the loss of TSF data during failure scenarios to strictly defined limits, and/or to be able to determine exactly what TSF data could not be restored.
---
For the [Manual] variant, failure scenarios should have a relatively infrequent occurrence and longer "down times" must be acceptable. 
The [Automated] variant is justified when: (a) there is a higher risk from failure scenarios, (b) it is less acceptable for the TOE to occasionally transit from an operational mode to a manual mode, and (c) it is less feasible for human operators to intervene.


Descriptive Name:
Documentation of untrusted data recovery

Objective Description:
Provide trusted recovery to ensure that data cannot be lost or misplaced.  Any circumstances which can cause untrusted recovery to be documented with mitigating procedures established.


Descriptive Name:
Limit administrator's modification of security-critical code or data

Objective Description:
Limit the malicious modification of security-critical (TSF) code and data to include specific system code to prevent the system security protection capabilities from being diminished or weakened.

Implementation Application:
All the components should be applied within the context of restricting which administrators can modify TSF code and data, and how they can perform those modifications.


Descriptive Name:
Local detection of received security-critical data modified in transit

Objective Description:
Identification by the system (TOE) of modification of security-critical (TSF) data occurring in transit from a remote trusted site must occur.

Objective-Selection Guidance:
Effectiveness depends heavily on strength of function.

Objective Editorial:
Effectiveness depends heavily on strength of function.


Descriptive Name:
Remote detection of received security-critical data modified in transit

Objective Description:
Identification by the remote site of the modification of security-critical (TSF) data occurring in transit from the remote site must occur.

Objective Editorial:
Hierarchical to:  O.TSF_Rcv_Err_ID_Loc
Effectiveness depends heavily on strength of function.


Descriptive Name:
Local correction of received security-critical data that is modified in transit

Objective Description:
Identification and correction of modification of security-critical (TSF) data occurring in transit from a remote site by the system shall occur.


Descriptive Name:
Remote correction of security-critical data that is received by the system and modified in transit

Objective Description:
Identification and modification of security-critical (TSF) data occurring in transit to the system (TOE) by a remote trusted site must occur, and the remote site shall be able to recover by transmitting a correct version.

Objective Editorial:
Hierarchical to:  O.TSF_Rcv_Err_ID_Rem
Effectiveness depends heavily on strength of function.


Descriptive Name:
Local detection of sent security-critical data modified in transit

Objective Description:
Identification of modification of security-critical (TSF) data occurring in transit to a remote site by the TSF must occur.

Objective Editorial:
Hierarchical to:  O.TSF_Snd_Err_ID_Rem
Effectiveness depends heavily on strength of function.


Descriptive Name:
Remote detection of sent security-critical data modified in transit.

Objective Description:
Identification of modification of security-critical (TSF) data occurring in transit to a remote site by the remote site must occur.


Descriptive Name:
Local Correction of sent security-critical data modified in transit

Objective Description:
Identification of modification of security-critical (TSF) data occurring in transit to a remote site by the remote site must occur, and shall be able to recover by retransmitting a correct version.


Descriptive Name:
Remote correction of sent security-critical data modified in transit

Objective Description:
Identification and correction of modification of security-critical (TSF) data occurring in transit to the remote site by the remote site must occur.


Objective Description:
Maintain a set of security attributes (which may include group membership, clearance, access rights, etc.) associated with individual users in addition to user identity.


Objective Description:
Execute enhanced measures to ensure that either user authentication data cannot be stolen or when it is stolen, it cannot be used to gain access to the system.

Implementation Application:
Both FIA_UAU.3 and FIA_UAU.4 can be either preventive, detective, or both.  However, the latter component could only provide detection with the aid of appropriate auditing functions. These components can be selected individually for specific types of protection, or jointly to provide supplemental protection.


Objective Description:
Manage and update user authorization and privilege data in accordance with organizational security and personnel policies.


Objective Description:
Invoke multiple authentication mechanisms, which will provide confidence that the user is who they say they are.

Objective-Selection Guidance:
This objective can require simultaneous or sequential use of the multiple authentication mechanisms. Simultaneous, multiple use of authentication mechanisms is considered a stronger form of use.

Implementation Application:
Choose FIA_UAU.5 and FMT_MOF.1 to implement the objective.


Objective Description:
Prevent unauthorized export of confidential information from the TOE with moderate effectiveness.

Implementation Application:
This objective is implemented in terms of a technical security policy, which is referred to as the observation-control policy. This observation-control policy may be cast as either an access control or information-flow policy. When cast as an access control policy, use the components from FDP_ACC and FDP_ACF. When cast as an information flow policy, use the components from FDP_IFC and FDP_IFF. In both cases, use of FDP_ETC is required to meet this objective.


Objective Description:
Allow dial-in access through secure mechanisms only.


Descriptive Name:
Integrity protection of stored user data

Objective Description:
Provide appropriate integrity protection for stored user data.


Objective Description:
Provide the ability to have physically protected communications lines, intrusion detection for communications lines, and/or need-to-know isolation for communications lines.

Objective Editorial:
<specific objective?>

This objective depends on the O.Identify_Unusual_Act objective for intrusion detection.


Objective Description:
Enforce an access control policy whereby users may determine who may access information they control.

Objective-Selection Guidance:
An essential aspect of this form of access control is the idea that "owners" or "managers" of information will make decisions about who can access the data they own or control. An example of this form of access control is commonly called Discretionary Access Control (DAC), which originated within the U.S. government. Although DAC is a very prevalent form of access control in existence today, there are many variations in its implementation. Examples of DAC-like implementations include access control lists and UNIX permission bits.

Implementation Application:
Two variants of this objective can be implemented:
[Subset] Choose FDP_ACC.1 and FDP_ACF.1. This variant allows subsets within the system to be constrained by the defined controls while others need not be. Subsets are defined by specific data types, users, and/or operations, or combinations thereof.  This variant provides flexibility at the expense of more comprehensive and consistent protection.

[Complete] Choose FDP_ACC.2 and FDP.ACF.1. This variant provides access control between all users, data types, and operations on the system, although the exact controls that must be applied need not be identical.  For example, the controls placed on "public" files need not be equivalent with those placed on "project" files. This variant attempts to provide comprehensive and consistent protection but generally requires much more rigor to implement.


Objective Description:
Provide documentation for the general user.

Objective-Selection Guidance:
Deter or prevent user errors by providing adequate user guidance.


# Policy Categories

Editorial Note:
This category contains all other policy categories.


# Prompts

PromptString:
Are there System Administrators who will be responsible for secure configuration, maintenance, and upgrade?


PromptString:
Are the System Administration staff authenticated?


PromptString:
Can administration functions be performed remotely?


PromptString:
Are System Administrator's motives a concern?


PromptString:
Are System Administrators considered to be trusted, hostile, or negligent?


PromptString:
Is the attitude/level of competence of System Administrators a factor?


PromptString:
Are System Administrators competent, improperly trained or error prone?


PromptString:
Are System Administrators trusted to be well-behaved and act constructively?


PromptString:
Are users relied upon as part of ensuring the secure operation of the TOE?


PromptString:
Is a cooperating secure IT environment needed?


PromptString:
Do users have the necessary privilege to access the information in the TOE?


PromptString:
Are users considered to be competent, error prone, or hostile?


PromptString:
Are users able to bypass the security mechanisms?


PromptString:
Is access/modification of security data a concern?


PromptString:
Can System Administrators potentially modify data in transit?


PromptString:
Is the modification of system data a concern?


PromptString:
Are procedural security measures important?


PromptString:
Can System Administrators review security logs?


PromptString:
Can System Administrators properly dispose of user data after access has been removed?


PromptString:
Will System Administrators follow documented policies and procedures?


PromptString:
Are procedures established to protect against viruses?


PromptString:
Are communications to/from the TOE protected?


PromptString:
Is physical protection of the communications provided?


PromptString:
Can outsiders read data sent across communications lines?


PromptString:
Is connectivity to other systems a concern?


PromptString:
Are there physical security constraints that are important to protecting your product or system?


PromptString:
Can an unauthorized user (e.g., Hacker) gain physical access to the system?


PromptString:
Is physical protection of TOE security functions ensured?


PromptString:
Is the system protected against such natural disasters as fires and floods?


PromptString:
Is the system protected against a sudden loss of power?


PromptString:
Is the system protected against a loss of communications?


PromptString:
Do you wish to consider common assumptions of operation?


PromptString:
Do you wish to consider organizational security policies derived from public DoD policy sources?


PromptString:
Does organizational security policy require that individuals be held accountable for their actions?


PromptString:
Does organizational security policy require that appropriate authorities be immediately notified of any threats or vulnerabilities impacting systems that process their data?


PromptString:
Does organizational security policy require that information be used only for its authorized purpose(s)?


PromptString:
Does organizational security policy require that information be available to satisfy mission requirements?


PromptString:
Does organizational security policy require that guidance documentation be provided for the secure installation and use of the system?


PromptString:
Does organizational security policy require that only authorized individuals and processes access information?


PromptString:
Does organizational security policy require that information retain its content integrity?


PromptString:
Does organizational security policy require that information systems security be an integral part of all system lifecycle phases?


PromptString:
Does organizational security policy require that information be appropriately marked and labeled?


PromptString:
Does organizational security policy require that information be physically protected to prevent unauthorized disclosure, destruction, or modification?


PromptString:
Do you wish to consider common organizational security policies that could apply to the TOE?


PromptString:
Hidden starting point for the CC Toolbox Interview.

Editorial:
The Answer List, Effect List, and Prompt String fields of this record are not used by the CC Toolbox.  Only the child list is relevant, and it must have the indicated value, namely P99999, A999999, T99999.


PromptString:
Do you wish to consider threats originating from those responsible for the administration of the TOE?


PromptString:
Do you wish to consider threats that originate from those who are not authorized to access the TOE?


PromptString:
Do you wish to consider threats that originate from natural disasters such as fire, flood, earthquake, unplanned power disruptions, etc?


PromptString:
Do you wish to consider threats that originate from the TOE developer, both accidental and intentional?

Editorial:
Deleted T00011, as it is no longer in the GFI database


PromptString:
Do you wish to consider threats that originate in software or hardware flaws?


PromptString:
Do you wish to consider threats that originate with authorized users of the TOE


PromptString:
Can an administrator commit errors that change the intended security policy of the system or application?


PromptString:
Can the system administrator fail to perform some function essential to security?


PromptString:
Can an administrator maliciously modify the system's configuration to allow security violations to occur?


PromptString:
Can failure of one or more system components result in the loss of system-critical functionality?


PromptString:
Can a system or applications developer deliver code that does not perform according to specifications or contains security flaws?


PromptString:
Can failure of a component that is part of a distributed system cause other parts of the distributed system to malfunction or provide unreliable results?


PromptString:
Can missing, weak and/or incorrectly implemented access control allow a hacker to gain undetected access to the system causing potential violations of integrity, confidentiality, or availability?


PromptString:
Can a hacker execute commands, send data, or performs other operations that make system resources unavailable to system users? Resources that may be denied to users include bandwidth, processor time, memory, and data storage.


PromptString:
Can an outsider obtain user data by eavesdropping on communications lines?


PromptString:
Can a hacker perform cryptoanalysis on encrypted data in order to recover message content?


PromptString:
Can a hacker masquerade as an authorized user to perform operations that will be attributed to the authorized user or a system process?


PromptString:
Can a hacker modify information that he intercepts from a communication link between two unsuspecting entities before passing it on to the intended recipient?


PromptString:
Can a hacker physically damage the IT system, leading to loss of ability to enforce the system security policy (TSP), possibly accompanied by loss of availability, incorrect processing of data, or exposure of system-resident data?


PromptString:
Can a hacker use social engineering techniques to gain information about system entry, system use, system design or system operation?


PromptString:
Can an authorized user, IT system, or hacker download and execute malicious code, which causes abnormal processes that violate the integrity, availability, or confidentiality of system assets?


PromptString:
Can a human or environmental agent disrupt power causing the system to lose information or security protection?


PromptString:
Can the recipient of a message deny receiving the message to avoid accountability for receiving the message and for subsequent action or inaction?


PromptString:
Can the sender of a message deny sending the message to avoid accountability for sending the message and for subsequent action or inaction?


PromptString:
Can a participant in a transaction deny participation in the transaction to avoid accountability for the transaction and for subsequent action or inaction?


PromptString:
Can an attacker write software or modify protocol information in transit to trick users into interacting with spurious system services?


PromptString:
Can a user collect sensitive or proprietary information and remove it from the system, either by putting it on a disk or by transmitting it outside the organization?


PromptString:
Can a user abuse granted authorizations to improperly collect sensitive or security-critical data?


PromptString:
Can a user commit errors of use that cause information to be delivered to the wrong place or wrong person?


PromptString:
Can a user accidentally delete user data or change system data rendering user data inaccessible?


PromptString:
Can a user commit errors of use that induce erroneous statements or actions by the system and/or its users?


PromptString:
Can a user commit errors of use that cause the system or one of its applications to undermine the system's security features?, e.g., by giving the user privileges for which he is not authorized.


PromptString:
Can a users unauthorized use of resources causes undue burden on an affected resource?


PromptString:
Can a user abuse granted authorizations to improperly change or destroy sensitive or security-critical data?


PromptString:
Can a user abuse granted authorizations to improperly send sensitive or security-critical data?


PromptString:
Can an administrator learn or disclose user identities in violation of a privacy policy?


PromptString:
Do you wish to consider threats that may be addressed via the TOE?


# TableOfTables

Table Name:
Assumption Categories / Assumptions Mapping

Form Name:
Assumption Category / Assumption Mapping


Table Name:
General Policy / Objective Mapping Query


Table Name:
General Policy Stmt/Detailed Policy Stmt Mapping

Form Name:
General Policy Stmt/Detailed Policy Stmt Mapping


Table Name:
Policy Category/General Policy Statement Mapping

Form Name:
Policy Category/General Policy Statement Mapping


# Threat Categories

Threat Category Description:
This category covers installation, operation, maintenance, and replacement of the TOE.  It includes both well-intended and hostile administrators.

Category Editorial:
Undetermined:  whether this category should include application administrators as well as system administrators.


Threat Category Description:
A hacker is generally considered to be an external unauthorized user. More generally, any individual who attempts to gain unauthorized access may be regarded as a hacker.  While a malicious insider may be covered under other categories such as Admin or User, it is also the case that malicious insiders are generally able to perform Hacker attacks.


Descriptive Name:
The physical environment is the threat agent

Threat Category Description:
Natural Disasters and other entities that are not human or an IT device would fall into this category. This would include but not be limited to heat, cosmic rays, and other factors that might contribute to hardware aging.


Threat Category Description:
Accidents, misuse and abuse that degrade the quality of the TOE.

Category Editorial:
This category contains all other threat categories.


Threat Category Description:
The system developer is the organization or person responsible for the development of the target of evaluation (TOE).

Category Editorial:
Potentially, this includes not only designers, managers, implementers, and testers of the TOE, but potentially TOE evaluators, PP authors, as well.


Threat Category Description:
This category describes threats that are tightly bound to flaws or faults in a system's hardware, firmware, or software.

Category Editorial:
IT devices have to be programmed or tasked to complete an action.  However, an IT device acting responsibly and doing its prescribed job can propagate a threat (e.g. - a mail server transporting virus-infected email) and thus might be considered a colluding threat agent.


Threat Category Description:
Authorized users are the threat source for each threat.


# TX Env / Attributes

Action:
Modification of user data or applications


Action:
Modification of Information Flow Control

Editorial:
Results: Loss of integrity allowing unauthorized user to view the data and loss of availability where the user does not have availability to the data as it is sent to the wrong location.


Editorial:
Results: loss of security protection, potential loss of availability, confidentiality, and integrity due to actions that can be taken after unauthorized access is gained


Editorial:
Result: Loss of object integrity and accountability


Action:
Modification of user attributes and/or roles

Editorial:
Threat Results: Loss of availability if modification of the user's attributes causes inability for the user to perform authorized actions.  Loss of integrity or confidentiality if a user is given unauthorized access to assets due to attributes or roles inappropriately given them.


Editorial:
Effect: Loss of accountability, loss of integrity


Editorial:
Threat Source: Developer, pre-deployment or operational phase
Threat results:  loss of TOE security protection
Exploited vulnerabilities:  developer frailty, inadequate product evaluation


Action:
Maliciously circumvents access control through a code vulnerability

Editorial:
Results: Varies depending on the hackers actions after the break-in.


Editorial:
Results: Vary depending on hacker actions after break-in.


Vulnerabilities:
inadequate strength of function, inadequate separation of plaintext and ciphertext


Vulnerabilities:
Inadequate strength of function, inadequate separation of plaintext and ciphertext


Editorial:
Threat source: a hacker with the opportunity to steal an active, remote session of an authorized user.
Method:  hacker physically interposes himself by cutting a communication link or by manipulating communications at an intermediate network node.
Results:  loss of confidentiality and  integrity, erroneous accountability, denial of service to the  session originator.


Action:
Usurp an active session on a workstation

Editorial:
Threat source: user with access to unattended, active workstation
Results:  loss of accountability, confidentiality, integrity


Editorial:
Results: Loss of integrity if the masquerader changes objects that they are not authorized to, Loss of availability if the masquerader deletes an object they should not have, Loss of confidentiality if the masquerader sees information they should not have.


Vulnerabilities:
Inadequate TSF data protection by the remote site and/or inadequate data validation by the TOE


Vulnerabilities:
Inadequate user data protection by the remote site and/or inadequate data validation by the TOE


Vulnerabilities:
Inadequate TSF data protection by the TOE and/or inadequate data validation by the remote site


Vulnerabilities:
Inadequate user data protection by the TOE and/or inadequate data validation by the remote site


Editorial:
Method: Repeatedly dumps data unwontedly into TOE data storage through processes that use storage space.


Vulnerabilities:
Human frailty, inadequate data protection


Vulnerabilities:
Human ignorance or inattention, inadequate data labeling


Vulnerabilities:
Human ignorance or inattention, inadequate data labeling mechanism

Editorial:
Vulnerabilities: Human ignorance or inattention, inadequate data labeling mechanism, inadequate security documentation


Action:
Prevent Use of Storage by exploiting storage capacity limits


Editorial:
No non-null attributes received from SPARTA, so record is currently blank.


Editorial:
The policy is sufficiently broad, that virtually all attributes are relevant.


Editorial:
The policy is sufficiently broad that most attributes are relevant.


Editorial:
Threat Source: The threat source would be a deliberate human being that either is not following policy in efforts to complete action they feel are in the organization's best interest or is malicious in intent.
Attack Method: The attack method is to modify or destroy security attributes or security mechanisms that would allow effects that are contrary to the organization's security policy.
Results: The results vary depending on the effect of the destruction or modification.  Confidentiality, Integrity, and Availability can be effected


Editorial:
SPARTA didn't provide a result type here, but it seems clear that privacy is a kind of confidentiality.


Vulnerabilities:
Inadequate authentication mechanisms and inadequate protection of communications media.


