Specifications

Cisco ISR-800 Security Target
58
TOE SFRs
How the SFR is Met
action associated with the rule is to pass traffic). Rules are enforced on a first
match basis from the top down. As soon as a match is found the action associated
with the rule is applied. These rules are entered in the form of access lists at the
CLI (via ‘access list’ and ‘access group’ commands).
These interfaces reject traffic when the traffic arrives on an external TOE
interface, and the source address is an external IT entity on an internal network;
These interfaces reject traffic when the traffic arrives on an internal TOE interface,
and the source address is an external IT entity on the external network;
These interfaces reject traffic when the traffic arrives on either an internal or
external TOE interface, and the source address is an external IT entity on a
broadcast network;
These interfaces reject traffic when the traffic arrives on either an internal or
external TOE interface, and the source address is an external IT entity on the
loopback network;
These interfaces reject requests in which the subject specifies the route for
information to flow when it is in route to its destination; and
For application protocols supported by the TOE (e.g., DNS, HTTP, SMTP, and
POP3), these interfaces deny any access or service requests that do not conform to
its associated published protocol specification (e.g., RFC). This is accomplished
through protocol filtering proxies that are designed for that purpose. Otherwise,
these interfaces pass traffic only when its source address matches the network
interface originating the traffic through another network interface corresponding to
the traffic’s destination address.
During the boot cycle, the TOE first powers on hardware, loads the image, and
executes the power on self-tests. Until the power on self tests successfully
complete, the interfaces to the TOE are deactivated. Once the tests complete, the
interfaces become active and the rules associated with the interface become
immediately operational. There is no state during initialization/ startup that the
access lists are not enforced on an interface.
FPT_FLS.1
Whenever a failure occurs within the TOE that results in the TOE ceasing
operation, the TOE securely disables its interfaces to prevent the unintentional
flow of any information to or from the TOE. The TOE reloads and will continue to
reload as long as the failures persist. This functionally prevents any failure of
power-on self-tests, failure of integrity check of the TSF executable image, failure
of noise source health tests from causing an unauthorized information flow. There
are no failures that circumvent this protection.
FPT_SKP_EXT.1
The TOE stores all private keys in a secure directory that is not readily accessible
to administrators. All pre-shared and symmetric keys are stored in encrypted form
using AES encryption to additionally obscure access. This functionality is
configured on the TOE using the ‘password encryption aes’ command.
The TOE is configured to not display configured keys as part of configuration files
using the ‘hidekeys’ command.
FPT_APW_EXT.1
The TOE includes a Master Passphrase features that can be used to configure the
TOE to encrypt all locally defined user passwords. In this manner, the TOE
ensures that plaintext user passwords will not be disclosed even to administrators.
FPT_STM.1
The TOE provides a source of date and time information used in audit event