General Assumptions

Identifier	Acc_Ovrwrit_SysData
Descriptive Name	Corruption of system data
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.
Editorial
Identifier	Acc_to_Comms
Descriptive Name	Physical protection of communications
Description	Physical protection of the communications to the system is adequate to guard against unauthorized access or malicious modification by users.
Selection Guidance
Editorial
Identifier	Access_to_Passwords
Descriptive Name	User access to passwords
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.
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.
Identifier	Admin_Cor_Usr_Data
Descriptive Name	Corruption of data in transit
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.
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
Identifier	Admin_Docs
Descriptive Name	Documentation for administrators
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.
Editorial	Good example of an assumption. Doesn't work as a policy by itself, as the policy might not be followed.
Identifier	Admin_Errors
Descriptive Name	Potential for administrator errors
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.
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.
Identifier	Admin_Virus_Check
Descriptive Name	Virus checking procedures
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.
Editorial	Classic Assumption.
Identifier	Auth_Sys_Admin
Descriptive Name	Authenticated administrators
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.
Editorial
Identifier	Competent_Admin
Descriptive Name	Competent system administrators
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.
Editorial
Identifier	Coop_User
Descriptive Name	Cooperative users
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.
Editorial	Doesn't work as a policy, since users might not follow the policy.
Identifier	Dispose_User_Data
Descriptive Name	Disposal of user data
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.
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.
Identifier	Eavesdrop_by_Out
Descriptive Name	Eavesdropping by outsiders
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.
Editorial	Lots of ambiguities here. Distributed TOE? Incoming: encrypted?  Outgoing: Protected in the environment?
Identifier	Hostile_Sys_Admin
Descriptive Name	Hostile system administrators
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.
Editorial	Consider treating as a General Threat rather than as an Assumption.  Consider Threats in the Admin Threat Category.
Identifier	Hostile_User
Descriptive Name	Hostile users
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.
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?
Identifier	Negligent_Admin
Descriptive Name	Negligent system administrators
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.
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.
Identifier	No_Abuse_By_Admin
Descriptive Name	No abusive system administrators
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.
Editorial
Identifier	No_Bypass_Security
Descriptive Name	TOE-Environment separation
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.
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.
Identifier	Outsider_Hi
Descriptive Name	Expert threat agents
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.
Editorial
Identifier	Outsider_Low
Descriptive Name	Laymen threat agents
Description	The TOE is subject to deliberate attack by laymen with no particular expertise.
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.
Editorial
Identifier	Outsider_Med
Descriptive Name	Proficient threat agents
Description	The TOE is subject to deliberate attack by threat agents proficient in the security behavior of the system.
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.
Editorial
Identifier	Password_Management
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.
Editorial	This is an Assumption that relies on a threat and a policy.
Identifier	Peer
Descriptive Name	Connectivity to other systems
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.
Editorial
Identifier	Phys_Acs_to_Out
Descriptive Name	Physical access
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.
Editorial
Identifier	Poor_Trained_Admin
Descriptive Name	Untrained system administrators
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.
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.
Identifier	Prot_Against_Nature
Descriptive Name	Natural disaster protection
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.
Editorial
Identifier	Prot_Agnst_Pwr_Fail
Descriptive Name	Power failure protection
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.
Editorial
Identifier	Prot_of_Comm
Descriptive Name	Communications protection
Description	The system is adequately protected against loss of communications.
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.
Editorial
Identifier	Protect_From_Out
Descriptive Name	TOE protection from outsiders
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.
Editorial
Identifier	Remote_Access
Descriptive Name	Remote users
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.
Editorial	The relevant TOE-Description statement might be: The TOE interacts with its IT environment in such a way as to allow remote use.
Identifier	Remote_Admin
Descriptive Name	Remote adminstration
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.
Editorial
Identifier	Review_Audit_Log
Descriptive Name	Administrators review audit logs
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).
Editorial	Some have claimed that Auditing is not an inherent security concern, but merely a derived objective that stems from other more direct matters.
Identifier	Trusted_User
Descriptive Name	Trusted users
Description	Authorized users are trusted not to compromise security.
Selection Guidance	Note similarity to the slightly weaker Coop_User Assumption.
Editorial	Doesn't work as a policy, since users might not follow the policy.
Identifier	User_Access
Descriptive Name	User access
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.
Editorial	On the surface, this seems to be saying that the TOE doesn't do a very good job of protecting security-critical data.
Identifier	User_Mistakes
Descriptive Name	Mistakes by users
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.
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).
Identifier	User_Virus_Scan
Descriptive Name	Software virus scanning
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.
Editorial
Identifier	Well_Behaved_Admin
Descriptive Name	Well behaved system administrators
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.
Editorial