Internet Backbone PP

CW-USA
INTERNET BACKBONE NETWORK PP
12/29/1998
Contents
1.
INTRODUCTION TO THE PROTECTION PROFILE................................................................................2

1.1
1.2
PP IDENTIFICATION...........................................................................................................................................2
PP OVERVIEW...................................................................................................................................................2
2.
TARGET OF EVALUATION (TOE) DESCRIPTION....................................................................................2
3.
SECURITY ENVIRONMENT..........................................................................................................................4
3.1 INTRODUCTION..................................................................................................................................................4
3.1.1
Critical Assets.........................................................................................................................................4
3.1.2 Protection Needs..............................................................................................................................5
3.1.3
Threat Agents....................................................................................................................................5
3.2 ASSUMPTIONS...................................................................................................................................................6
3.3 THREATS............................................................................................................................................................7
3.4 ORGANIZATIONAL SECURITY POLICES..............................................................................................................8
4.
SECURITY OBJECTIVES................................................................................................................................9
4.1
4.2
5.
SECURITY OBJECTIVES FOR THE TOE...............................................................................................................9

SECURITY OBJECTIVES FOR THE ENVIRONMENT............................................................................................10
IT SECURITY REQUIREMENTS.................................................................................................................10
5.1 TOE SECURITY FUNCTIONAL REQUIREMENTS...............................................................................................10
5.2 TOE SECURITY ASSURANCE REQUIREMENTS.................................................................................................21
5.2.1
Configuration Management Assurance Requirements.........................................................................22
5.2.2
Delivery and Operation Assurance Requirements...............................................................................22
5.2.3
Development Assurance Requirements.................................................................................................23
5.2.4
Guidance Documents Assurance Requirements...................................................................................24
5.2.5
Tests Assurance Requirements..............................................................................................................26
5.2.6
Vulnerability Assessment Assurance Requirements..............................................................................27
6.
RATIONALE.....................................................................................................................................................29
6.1
6.2
6.3
SECURITY REQUIREMENTS RATIONALES.........................................................................................................29

FUNCTIONAL DEPENDENCIES..........................................................................................................................30
RATIONALE FOR NOT SATISFYING ALL DEPENDENCIES..................................................................................32
7.
ACRONYMS.....................................................................................................................................................33
8.
REFERENCES..................................................................................................................................................34
Emir Arslanagic
ENTS UMCP
CW-USA
12/29/1998
1. INTRODUCTION TO THE PROTECTION PROFILE

1.1
PP Identification
Title: Cable and Wireless USA Internet Backbone Protection Profile for Low-Risk
Environments.
Registration: <TBD>.
Keywords: Internet Backbone, Point of Presence (POP), Packet flow control, network security,
protection profile.
1.2
PP Overview
This Protection Profile specifies the Cable and Wireless minimum-security requirements for an
Internet Backbone network. The Protection Profile defines the assumptions about the security
aspects of the environment in which the POP will be located. It also defines the threats, the
implementation-independent security objectives of the POPs network nodes, and the functional
and assurance requirements to meet those objectives. Finally, PP provides a rationale
demonstrating how the requirements meet the security objectives.
2. TARGET OF EVALUATION (TOE) DESCRIPTION

A Point of Presence (POP) is the most visible part in the Internet Backbone network. The main
purpose of a POP is to provide Internet connectivity to Internet Service Providers and other
Internet users who have needs for high speed dedicated links to the Internet Backbone network.
In addition to the plain connection to the Internet, POP could provide additional services to its
customers such as:
The Domain Name System (DNS)
The Simple Mail Transport Protocol (SMTP)
The Network Time Protocol (NTP)
The File Transfer Protocol (FTP, TFTP)
The Network News Transfer Protocol (NNTP)
Some POPs are also responsible for traffic exchange between different networks, called
Autonomous Systems (AS). In addition to the above connection, each POP has to be connected
to two or more POPs of the same AS in other to form Internet Backbone.
From the security point of view, the POP is the most critical place for the Internet Backbone
service providers. In order to provide services to its customers, the POP has to be highly visible
Emir Arslanagic
ENTS UMCP
CW-USA
12/29/1998
to the rest of the Internet community. In addition to services, it must support both inbound and
outbound management accesses.
Overall, the security function of the POP is to provide controlled and audited access to its
network nodes and services. It has to provide access from both inside and outside its own AS by
allowing or rejecting packet flow. In addition, it has to reject transit traffic coming into the AS as
well as prevent violent attacks to its customers. Figure 2.1 shows a logical representation of POP
network connections.
Internet Backbone Network Architecture Diagram
OSPF
Backbone Link
POP
C
POP
Backbone Link OSPF

POP
----------Server
Server
Server
Server
BGP
ring
Pee
rnet
Inte
Customer
POP
Customer
POP
Customer
Equipment
Customer Link
Customer Link
Customer Link
Router
Router
Router
UU-net
Mae-East
Mae-West
Sprint
Figure 2.1.
This Protection Profile specifies the minimum-security requirements for TOEs composed of
network nodes in the POPs, regardless of hardware-software implementation, capacity or internal
architecture.
The TOE describes data flows between:
Interface I Two POPs of the same AS (Inside)

Interface C POP and Customer Equipment (Customer)
Interface P Two POPs with different ASs. (Peering)
In addition to data flow TOE describes inbound and outbound management of the POP.
Users of the TOE consist of human users and external network nodes. Human users may or may
not be associated with the single role on the TOE. Network Access Security Policy defines
human user access and permissions for all three originating points (Inside I, Customer C and
Peering P). Data Flow Security Policy rules define which data packets may be accepted and
Emir Arslanagic
ENTS UMCP
CW-USA
12/29/1998
processed by TOE for each individual originating points (Inside I, Customer C and Peering P). If
the Network Access Security Policy permits human users who are not privileged users may send
and receive information to FTP, e-mail, news or DNS servers in POP, than such users will have
to be identified and authenticated by the TOE before requests are authorized. From the set of
human users, only privileged users may access the TOE through remote means (telnet, rlogin,
etc). If a privileged user accesses the TOE remotely, after successful identification and
authentication (using a one-time authentication mechanism) a trusted channel using some type of
encryption with securely generated and distributed key values must be used. In addition to
remote access, authorized administrators may access the TOE through local means without
encryption, such as through a console in such case successful identification and authentication is
required.
External network nodes sending information through the TOE do not have to be identified and
authenticated, unless those functions are supported by the underlying service (e.g., FTP).
However, external network nodes attempting to send information to the TOE must always be
identified and authenticated. Those external network nodes that are successfully identified and
authenticated (using a one-time authentication mechanism) are authorized external network
nodes.
When recorded, audit trail data is stamped with a dependable date and time. Audit events include
modifications to the group of users associated with the privileged user role and use of the
identification and authentication mechanisms including any attempted of reuse of authentication
data. The TOE according to the Network Access Security Policy rules and the use of all security
functions makes information flow control decisions.
3. SECURITY ENVIRONMENT
3.1
Introduction
Protection Profile-compliant TOEs are meant to be used in an environment in

which critical, but unclassified, information is processed. Systems that
comply with this Protection Profile are expected to utilize cryptographic
mechanisms or one time password for remote authentication.
In order to define security environment for TOE in compliance with this PP, critical assets,
protection needs, and threat agents has to be defined.
3.1.1 Critical Assets
Critical assets of the TOE for this Protection Profile are:
Routing Information
Network Bandwidth
Access List
User Accounts
Customer Accounts
Emir Arslanagic
ENTS UMCP
CW-USA
12/29/1998
Processor cycles
3.1.2 Protection Needs
Protection needs for the above mentioned assets are protection against:
Confidentiality (i.e., Sensitivity, Secrecy) attack.

Integrity (i.e., Accuracy, Authenticity, Authentication, Authorization,
Accounting) attack.
Availability (i.e., Fault Tolerance, Recovery, Utility) attack.

3.1.3 Threat Agents
For this Protection Profile compliant TOE threat agents are:
Privileged User or Authorized Administrator

Authorized User
Attacker
Emir Arslanagic
ENTS UMCP
CW-USA
3.2
12/29/1998
Assumptions
The following conditions are assumed to exist in the operational

environment.
Formal Assumption Specifications.

Name
Description
A.Personnel.1
It is assumed that one or more privileged users with high level of expertise are
assigned to manage the TOE and the security of the information it contains on
an on-going basis. Also privileged users should be trusted, not to deliberately
abuse their privileges so as to undermine security.
A.Personnel.2
Authorized users of the TOE are assumed to possess the necessary privileges to
access the information managed by the TOE.
A.Personnel.3
Authenticated users are generally trusted to perform discretionary actions in

accordance with security policies.
A.Personnel.4
Authenticated users recognize the need for a secure IT environment.
A.Physical.1
The processing resources of the TOE are assumed to be located within

controlled access facilities, which will present unauthorized physical access.
A.Physical.2
The TOE hardware and software critical to security policy enforcement are
assumed to be physically protected from unauthorized modification by
potentially hostile outsiders.
A.Physical.3
Human users within the physically secure boundary protecting the TOE may
access the TOE from some direct connection.
A.Physical.4
The processing resources of the TOE that depend on hardware security features
will be located within controlled access facilities that mitigate unauthorized,
physical access.
A.Usage.1
The TOE provides services to authorized users.
A.Usage.2
Authorized administrators may access the TOE remotely inbound and

outbound.
Emir Arslanagic
ENTS UMCP
CW-USA
3.3
12/29/1998
Threats
A threat (as defined in the CC) is an undesirable event possibly caused by an identified threat
agent. They cause or may cause unauthorized disclosure, modification, or loss of use information
or infrastructure which we trying to protect.
Formal Threats Specifications.
Name
T.Availability.1
Description
An attacker may cause the TOE to temporarily or
permanently become unavailable for the service that it is
intended to provide.
T.Confidentiality An attacker may be able to gather some conclusion about

.1
the TOE by obtaining publicly available information about
TOE.
T.Confidentiality An attacker may be able to view information being sent
.2
from and to the TOE.
T.Integrity.1
An attacker user may access the TOE by impersonating an

authorized user of the TOE.
T.Integrity.2
A user may cause audit records to be lost or prevent future

records from being recorded by taking actions to exhaust
audit storage capacity.
T.Integrity.3
An attacker may bypass routing information stored in TOE.

A TCP connection, where the loose source route option is
enabled, allows an attacker to explicitly route packet,
through the network to a destination without following the
usual routing process.
T.Integrity.4
An attacker may change routing information stored in TOE,

by injecting bogus routing information in the network.
T.Integrity.5
An attacker or unauthorized user may read, modify, or

destroy TOE internal data.
T.Integrity.6
A user may not be accountable for the actions that they

conduct.
T.Integrity.E.1.
An attacker user may access the TOE by impersonating an

authorized user of the TOE.
Emir Arslanagic
ENTS UMCP
CW-USA
3.4
12/29/1998
Organizational Security Polices
Bandwidth as critical asset for this TOE ant it is protected by applying

security police in the TOE.
From the figure 2.1. we can define access list for packet filtering based on origination and
destination IP address.
Origination
IP
Cin
Destination
IP
IP
Cip
Cout
Cip
IP
Iin/ou
t
IP
IP
IP\Cwip
CWip
CWip
IP\CWip
Pin
Pout
Figure 2.1.
Cin Interface to the customer, direction towards the customer
Cout Interface to the customer, direction from the customer
Iin/out Interface to the another POP
Pin Interface to the peering partner, direction towards the peering
partner
Pout Interface to the peering partner, direction from the peering
partner
IP Set of all valid IP addresses
CWip Cable and Wireless IP set; CWip is subset of the IP
Cip Customers IP set; Cip is subset of the CWip.
Formal Policy Specifications

Name
Description
P.1.
Only privileged user and authorized user should be able to

connect to the TOE
P.2.
All configuration changes to the TOE have to be recorded.
P.3.
All security functions changes to the TOE have to be recorded
Emir Arslanagic
ENTS UMCP
CW-USA
12/29/1998
and monitored.
P.3.
All attempts to gain access to TOE have to be recorded.
P.4
Inbound management services have to be accessible only from

the CWip set.
Emir Arslanagic
ENTS UMCP
CW-USA
12/29/1998
4. SECURITY OBJECTIVES
4.1
Security Objectives for the TOE

Formal Objectives Specifications
Name
Description
O.Availability.1
The TOE must provide functionality that enables an authorized user to use
all services provided by the TOE for the authorize user without unpredicted
interruptions of services.
O.Availability.2
The TOE must provide functionality, which enables privileged user to

manage the TOE and its security functions.
O.Confidentiality.1
The TOE must prevent the reuse of authentication data.
O.Confidentiality.2
The TOE must protect the confidentiality of its dialogue with an authorized
administrator.
O.Confidentiality.3
The TOE must provide the means of allowing a subject to use resources or
services without the user identity being disclosed to other entities.
O.Integrity.1
The TOE must uniquely identify all users, and must authenticate the
claimed identify before granting a user access to the TOE services.
O.Integrity.2
The TOE must provide user accountability for privileged user use of
security functions.
O.Integrity.3
The TOE must provide user accountability for authorized use of all
services provided.
O.Integrity.4
The TOE must provide a means to record a readable audit trail of securityrelated events, with accurate dates and times, and a means to search and
sort the audit trail based on relevant attributes.
O.Integrity.5
The TOE must detect attempts by unauthorized users to bypass, deactivate,

or tamper with TOE security functions.
O.Integrity.6
The TOE must detect loss of integrity affecting security functions.
O.Integrity.7
Upon initial start-up of the TOE or recovery from an interruption in TOE

service, the TOE must not compromise its resources or those of any
connected network.
O.DataFlow.1
The TOE must provide the means of allowing and denying data flow based
on organizational security policy.
Emir Arslanagic
10
ENTS UMCP
CW-USA
4.2
12/29/1998
Security Objectives for the Environment
The following are non-IT security objectives that are to be satisfied without imposing technical
requirements on the TOE. They will not require the implementation of functions in the TOE
hardware and/or software. Therefore, they will be satisfied largely through application of
procedural or administrative measures.
Name
Description
O.Personel.1
Those responsible for the TOE must ensure that the TOE is delivered, installed,
administered, and operated in a manner that maintains security.
O.Personel.2
Privileged users are trained to establish and maintain the sound security policies
and practices.
5. IT SECURITY REQUIREMENTS
The IT Security Requirements define the security functional requirements and assurance
requirement that must be satisfied by a Protection Profile compliant TOE. Functional
components from the part 2 of the CC are used for functional requirement and evaluation.
Assurance level components from the part 3 of the CC are used assurance requirements.
5.1
TOE Security Functional Requirements
The security functional requirement for the TOE in compliance with this PP are represented in
the following table:
Key Functional Components
Name
Description
FAU_ARP.1
Security alarms
FAU_SAA.1
Potential violation analysis
FAU_GEN.1
Audit data generation
FAU_SAR.1
Audit review
FAU_SAR.3
Selectable audit review
FAU_STG.1
Protected audit trail storage
FAU_STG.4
Prevention of audit data loss
FCS_CKM.1
Cryptographic key generation
FCS_CKM.2
Cryptographic key distribution
Emir Arslanagic
11
ENTS UMCP
CW-USA

FCS_CKM.4
Cryptographic key destruction
FCS_COP.1
Cryptographic operation
FDP_ACC.1
Subset access control
FDP_ACF.1
Security attribute based access control
FDP_IFC.1
Subset information flow control
FDP_IFF.1
Simple security attributes
FIA_AFL.1
Authentication failure handling
FIA_ATD.1
User attribute definition
FIA_UAU.1
Timing of authentication
FIA_UAU.4
Single-use authentication mechanisms
FIA_UID.1
Timing of identification
FMT_MOF.1
Management of security functions behavior
FMT_MSA.1
Management of security attributes
FMT_MSA.2
Secure security attributes
FMT_MSA.3
Static attribute initialization
FMT_SMR.1
Security roles
FPR_ANO.1
Anonymity
FPT_FLS.1
Failure with preservation of secure state
FPT_SEP.1
TSF domain separation
FPT_STM.1
Reliable time stamps
FRU_FLT.2
Limited fault tolerance
FTA_TAB.1
Default TOE access banners
12/29/1998
FAU_ARP.1 Security alarms

Security alarms, the TSF shall take actions in case a potential security violation is
detected.
FAU_ARP.1.1 The TSF shall take [inform privileged user] upon detection of a
potential security violation.
Emir Arslanagic
12
ENTS UMCP
CW-USA
12/29/1998
FAU_GEN.1 Audit data generation

Audit data generation defines the level of audit-able events, and specifies the list
of data that shall be recorded in each record.
FAU_GEN.1.1 The TSF shall be able to generate an audit record of the following
audit-able events:
a) Start-up and shutdown of the audit functions;
b) All auditable events for the [minimum or basic as specified in table 5.1] level
of audit.
FAU_GEN.1.2 The TSF shall record within each audit record at least the
following information:
a) Date and time of the event, type of event, subject identity, and the outcome
(success or failure) of the event; and
b) For each audit event type, based on the auditable event definitions of the
functional components included in the PP/ST, [as specified in table 5.1]
Auditable Event Table

Functional Component
Level
Auditable Event
FAU_ARP.1
Minimal
Actions taken due to imminent security violations.
FAU_SAA.1
Minimal
Enabling and disabling of any of the analysis

mechanisms;
Automated responses performed by the tool.
FAU_SAR.1
Basic
Reading of information from the audit records.
FAU_STG.4
Basic
Actions taken due to the audit storage failure.
FCS_CKM.1
Minimal
Success and failure of the activity.
FCS_CKM.2
Minimal
Minimal: Success and failure of the activity.
FCS_CKM.4
Minimal
Success and failure of the activity.
FCS_COP.1
Minimal
Success and failure, and the type of cryptographic

operation.
FDP_IFF.1
Minimal
Decisions to permit requested information flows.
FDP_IFF.1
Basic
All decisions on requests for information flow.
FIA_AFL.1
Minimal
The reaching of the threshold for the unsuccessful
Emir Arslanagic
13
ENTS UMCP
CW-USA
12/29/1998
authentication attempts and the actions (e.g. disabling of

a terminal) taken and the subsequent, if appropriate,
restoration to the normal state (e.g. re-enabling of a
terminal).
FIA_UAU.1
Minimal
Unsuccessful use of the authentication mechanism;

b) Basic: All use of the authentication mechanism;
c) Detailed: All TSF mediated actions performed before
authentication of the user.
FIA_UAU.1
Basic
All use of the authentication mechanism;
FIA_UAU.4
Minimal
Attempts to reuse authentication data.
FIA_UID.1
Minimal
Unsuccessful use of the user identification mechanism,

including the user identity provided;
FIA_UID.1
Basic
All use of the user identification mechanism, including

the user identity provided.
FMT_MOF.1
Basic
All modifications in the behavior of the functions in the

TSF.
FMT_MSA.1
Basic
All modifications of the values of security attributes.
FMT_MSA.2
Minimal
All offered and rejected values for a security attribute.
FMT_MSA.3
Basic
All modifications of the initial values of security

attributes.
FMT_SMR.1
Minimal
modifications to the group of users that are part of a role;
FPR_ANO.1
Minimal
The invocation of the anonymity mechanism.
FPT_FLS.1
Basic
Failure of the TSF.
FPT_STM.1
Minimal
changes to the time;
FRU_FLT.2
Minimal
Any failure detected by the TSF.
FAU_SAA.1 Potential violation analysis

Potential violation analysis, basic threshold detection on the basis of a fixed rule
set is required.
FAU_SAA.1.1 The TSF shall be able to apply a set of rules in monitoring the
audited events and based upon these rules indicate a potential violation of the
TSP.
FAU_SAA.1.2 The TSF shall enforce the following rules for monitoring audited
events:
Emir Arslanagic
14
ENTS UMCP
CW-USA
12/29/1998
a) Accumulation or combination of [all events from Auditable Event Table]

known to indicate a potential security violation.
FAU_SAR.1 Audit review
Audit review provides the capability to read information from the audit records.
This component will provide authorized users the capability to obtain and
interpret the information. In case of human users this information needs to be in a
human understandable presentation. In case of external IT entities the information
needs to be unambiguously represented in an electronic fashion.
FAU_SAR.1.1 The TSF shall provide [Privileged users] with the capability to
read [all audit information] from the audit records.
FAU_SAR.1.2 The TSF shall provide the audit records in a manner suitable for
the user to interpret the information.
FAU_SAR.3 Selectable audit review
Selectable audit review requires audit review tools to select the audit data to be
reviewed based on criteria.
FAU_SAR.3.1 The TSF shall provide the ability to perform [searches and,
sorting] of audit data based on
a) [user identity
b) range of dates
c) range of times
d) ranges of address].
FAU_STG.1 Protected audit trail storage
Protected audit trail storage, requirements are placed on the audit trail. It will be
protected from unauthorized deletion and/or modification.
FAU_STG.1.1 The TSF shall protect the stored audit records from unauthorized
deletion.
FAU_STG.1.2 The TSF shall be able to [prevent] modifications to the audit
records.
FAU_STG.4 Prevention of audit data loss

Prevention of audit data loss specifies actions in case the audit trail is full.
FAU_STG.4.1 The TSF shall [overwrite the oldest stored audit records] and
[notify privileged user] if the audit trail is full.
FCS_CKM.1 Cryptographic key generation
Emir Arslanagic
15
ENTS UMCP
CW-USA
12/29/1998
Cryptographic key generation requires cryptographic keys to be generated in

accordance with a specified algorithm and key sizes which can be based on an
assigned standard.
FCS_CKM.1.1 The TSF shall generate cryptographic keys in accordance with a
specified cryptographic key generation algorithm [assignment: cryptographic key
generation algorithm] and specified cryptographic key sizes [minimum 56 bits]
that meet the following: [assignment: list of standards].
FCS_CKM.2 Cryptographic key distribution
Cryptographic key distribution requires cryptographic keys to be distributed in
accordance with a specified distribution method which can be based on an
assigned standard.
FCS_CKM.2.1 The TSF shall distribute cryptographic keys in accordance with a
specified cryptographic key distribution method [assignment: cryptographic key
distribution method] that meets the following: [assignment: list of standards].
FCS_CKM.4 Cryptographic key destruction
Cryptographic key destruction requires cryptographic keys to be destroyed in
accordance with a specified destruction method which can be based on an
assigned standard.
FCS_CKM.4.1 The TSF shall destroy cryptographic keys in accordance with a
specified cryptographic key destruction method [assignment: cryptographic key
destruction method] that meets the following: [assignment: list of standards].
FCS_COP.1 Cryptographic operation
Cryptographic operation requires a cryptographic operation to be performed in
accordance with a specified algorithm and with a cryptographic key of specified
sizes. The specified algorithm and cryptographic key sizes can be based on an
assigned standard.
FCS_COP.1.1 The TSF shall perform
a) [encryption of remote authorized privileged user session
b) encryption of remote authentication] in accordance with a specified
cryptographic algorithm [assignment: cryptographic algorithm] and
cryptographic key sizes [minimum 56 bits] that meet the following:
[assignment: list of standards].
FDP_IFC.1 Subset information flow control
Subset information flow control requires that each identified information flow
control SFPs be in place for a subset of the possible operations on a subset of
information flows in the TOE.
FDP_IFC.1.1 The TSF shall enforce the [Identified SFP] on
Emir Arslanagic
16
ENTS UMCP
CW-USA
12/29/1998
a) [subject: identified external IT entities that send and receive packets through
the TOE
b) information: IP originating and terminating IP address and service
c) operations: pass packet or block packet]
FDP_IFF.1 Simple security attributes
Simple security attributes requires security attributes on information, and on
subjects that cause that information to flow and on subjects that act as recipients
of that information. It specifies the rules that must be enforced by the function,
and describes how security attributes are derived by the function.
FDP_IFF.1.1 The TSF shall enforce the [Identified SFP] based on the following
types of subject and information security attributes:
a) [subject security attributes:
presumed IP address;
other subject security attributes to be determined by the

Security Target writer);
b) information security attributes:
source subject;
destination subject;
transport layer protocol;
TOE interface on which traffic arrives and departs;
service;
other information security attributes to be determined by the

Security Target writer(s)].
FDP_IFF.1.2 The TSF shall permit an information flow between a controlled

subject and controlled information via a controlled operation if the following rules
hold: [Source and destination subjects are in compliance with Security Policy].
FDP_IFF.1.3 The TSF shall enforce the [none required].
FDP_IFF.1.4 The TSF shall provide the following [none required].
FDP_IFF.1.5 The TSF shall explicitly authorize an information flow based on the
following rules: [assignment: rules, based on security attributes, that explicitly
authorize information flows].
FDP_IFF.1.6 The TSF shall explicitly deny an information flow based on the
following rules: [assignment: rules, based on security attributes, that explicitly
deny information flows].
Emir Arslanagic
17
ENTS UMCP
CW-USA
12/29/1998
FIA_AFL.1 Authentication failure handling

Requirement that the TSF be able to terminate the session establishment process
after a specified number of unsuccessful user authentication attempts. It also
requires that, after termination of the session establishment process, the TSF be
able to disable the user account or the point of entry (e.g. workstation) from
which the attempts were made until an administrator-defined condition occurs.
FIA_AFL.1.1 The TSF shall detect when [a settable, non-zero number, to be
settable by privileged user ] unsuccessful authentication attempts occur related to
a) [authorized user attempting to make authentication as privileged user
b) Attacker attempting to impersonate authorized or privileged user].
FIA_AFL.1.2 When the defined number of unsuccessful authentication attempts
has been met or surpassed, the TSF shall
a) [disabled account
b) notify privileged user, method to be settable by privileged user].
FIA_ATD.1 User attribute definition
User attribute definition, allows user security attributes for each user to be
maintained individually.
FIA_ATD.1.1 The TSF shall maintain the following list of security attributes
belonging to individual users:
a) [identity;
b) association of human user with the privileged user role
FIA_UAU.1 Timing of authentication
Timing of authentication, allows a user to perform certain actions prior to the
authentication of the users identity.
FIA_UAU.1.1 The TSF shall allow [assignment: list of TSF mediated actions] on
behalf of the user to be performed before the user is authenticated.
FIA_UAU.1.2 The TSF shall require each user to be successfully authenticated
before allowing any other TSF-mediated actions on behalf of that user.
Emir Arslanagic
18
ENTS UMCP
CW-USA
12/29/1998
FIA_UAU.4 Single-use authentication mechanisms

Single-use authentication mechanisms, requires an authentication mechanism that
operates with single-use authentication data.
FIA_UAU.4.1 The TSF shall prevent reuse of authentication data related to
a) [privileged user
b) authorized user]
FIA_UID.1 Timing of identification
Timing of identification, allows users to perform certain actions before being
identified by the TSF.
FIA_UID.1.1 The TSF shall allow [no any actions] on behalf of the user to be
performed before the user is identified.
FIA_UID.1.2 The TSF shall require each user to be successfully identified before
allowing any other TSF-mediated actions on behalf of that user.
FMT_MOF.1 Management of security functions behavior
Management of security functions behavior allows the authorized users (roles) to
manage the behavior of functions in the TSF that use rules or have specified
conditions that may be manageable.
FMT_MOF.1.1 - The TSF shall restrict the ability to perform the
functions:
a) [start-up and shutdown;
b) create, delete, modify, and view information flow security
policy rules that permit or deny information flows;
c) modify and set the threshold for the number of permitted
authentication attempt failures;
d) restore authentication capabilities for users that have met or
exceeded the threshold for permitted authentication attempt
failures;
e) enable and disable external IT entities from communicating
with the TOE
f) modify and set the time and date;
g) archive, create, delete, and empty the audit trail;
h) backup of user attribute values, information flow security
policy rules, and audit trail data, where the backup capability
shall be supported by automated tools;
Emir Arslanagic
19
ENTS UMCP
CW-USA
12/29/1998
i) recover to the state following the last backup;

j) m) other security-relevant administrative functions to be
determined by the Security Target writer(s)].
to [an privileged user].
FMT_MSA.1 Management of security attributes
Management of security attributes allows authorized users (roles) to manage the
specified security attributes.
FMT_MSA.1.1 The TSF shall enforce the [assignment: access control SFP,
information flow control SFP] to restrict the ability to [selection: change_default,
query, modify, delete, [assignment: other operations]] the security attributes
[assignment: list of security attributes] to [assignment: the authorized identified
roles].
FMT_MSA.2 Secure security attributes
Secure security attributes ensures that values assigned to security attributes are
valid with respect to the secure state.
FMT_MSA.2.1 The TSF shall ensure that only secure values are accepted for
security attributes.
FMT_MSA.3 Static attribute initialization
Static attribute initialization ensures that the default values of security attributes
are appropriately either permissive or restrictive in nature.
FMT_MSA.3.1 The TSF shall enforce the [packet flow control] to provide
[restrictive,] default values for security attributes that are used to enforce the SFP.
FMT_MSA.3.2 The TSF shall allow the [privileged user] to specify alternative
initial values to override the default values when an object or information is
created.
FMT_SMR.1 Security roles
Security roles specifies the roles with respect to security that the TSF recognizes.
FMT_SMR.1.1 The TSF shall maintain the roles [privileged user].
FMT_SMR.1.2 The TSF shall be able to associate human users with the
privileged user role.
FPR_ANO.1 Anonymity
Anonymity requires that other users or subjects are unable to determine the
identity of a user bound to a subject or operation.
Emir Arslanagic
20
ENTS UMCP
CW-USA
12/29/1998
FPR_ANO.1.1 The TSF shall ensure that [authorized user] are unable to
determine the real user name bound to [privileged use and other authorized
users].
FPT_FLS.1 Failure with preservation of secure state
Failure with preservation of secure state, which requires that the TSF preserve a
secure state in the face of the identified failures.
FPT_FLS.1.1 The TSF shall preserve a secure state when the following types of
failures occur: [assignment: list of types of failures in the TSF].
FPT_SEP.1 TSF domain separation
TSF domain separation, provides a distinct protected domain for the TSF and
provides separation between subjects within the TSC.
FPT_SEP.1.1 The TSF shall maintain a security domain for its own execution
that protects it from interference and tampering by untrusted subjects.
FPT_SEP.1.2 The TSF shall enforce separation between the security domains of
subjects in the TSC.
FPT_STM.1 Reliable time stamps
Reliable time stamps, which requires that the TSF provide reliable time stamps for
TSF functions.
FPT_STM.1.1 The TSF shall be able to provide reliable time stamps for its own
use.
FRU_FLT.2 Limited fault tolerance
Limited fault tolerance requires the TOE to continue correct operation of all
capabilities in the event of identified failures.
FRU_FLT.2.1 The TSF shall ensure the operation of all the TOEs capabilities
when [assignment: list of type of failures] occur.
FTA_TAB.1 Default TOE access banners
Default TOE access banners provides the requirement for a TOE Access Banner.
This banner is displayed prior to the establishment dialogue for a session.
FTA_TAB.1.1 Before establishing a user session, the TSF shall display an
advisory warning message regarding unauthorized use of the TOE.
Emir Arslanagic
21
ENTS UMCP
CW-USA
5.2
12/29/1998
TOE Security Assurance Requirements
The assurance security requirements for TOE to satisfy this Protection Profile, are derived from
Part 3 of the CC. Those assurance security requirements compose EAL2 and could be broken
into 6 categories
1)Configuration management
ACM_CAP.2 Configuration items
2) Delivery and operation
ADO_DEL.1 Delivery procedures
ADO_IGS.1 Installation, generation, and start-up procedures
3) Development
ADV_FSP.1 Informal functional specification
ADV_HLD.1 Descriptive high-level design
ADV_RCR.1 Informal correspondence demonstration
4) Guidance documents
AGD_ADM.1 Administrator guidance
AGD_USR.1 User guidance
5) Tests
ATE_COV.1 Evidence of coverage
ATE_FUN.1 Functional testing
ATE_IND.2 Independent testing - sample
6) Vulnerability assessment
AVA_SOF.1 Strength of TOE security function evaluation
AVA_VLA.1 Developer vulnerability analysis
Emir Arslanagic
22
ENTS UMCP
CW-USA
12/29/1998
5.2.1 Configuration Management Assurance Requirements

ACM_CAP.2 Configuration items
Developer action elements:
ACM_CAP.2.1D The developer shall provide a reference for the TOE.
ACM_CAP.2.2D The developer shall use a CM system.
ACM_CAP.2.3D The developer shall provide CM documentation.
Content and presentation of evidence elements:
ACM_CAP.2.1C The reference for the TOE shall be unique to each version of the TOE.
ACM_CAP.2.2C The TOE shall be labeled with its reference.
ACM_CAP.2.3C The CM documentation shall include a configuration list.
ACM_CAP.2.4C The configuration list shall describe the configuration items that
comprise the TOE.
ACM_CAP.2.5C The CM documentation shall describe the method used to uniquely
identify the configuration items.
ACM_CAP.2.6C The CM system shall uniquely identify all configuration items.
Evaluator action elements:
ACM_CAP.2.1E The evaluator shall confirm that the information provided meets all
requirements for content and presentation of evidence.
5.2.2 Delivery and Operation Assurance Requirements
ADO_DEL.1 Delivery procedures
ADO_DEL.1.1D The developer shall document procedures for delivery of the TOE or
parts of it to the user.
ADO_DEL.1.2D The developer shall use the delivery procedures.
ADO_DEL.1.1C The delivery documentation shall describe all procedures that are
necessary to maintain security when distributing versions of the TOE to a users site.
Emir Arslanagic
23
ENTS UMCP
CW-USA
12/29/1998
ADO_DEL.1.1E The evaluator shall confirm that the information provided meets all
ADO_IGS.1 Installation, generation, and start-up procedures
ADO_IGS.1.1D The developer shall document procedures necessary for the secure
installation, generation, and start-up of the TOE.
ADO_IGS.1.1C The documentation shall describe the steps necessary for secure
installation, generation, and start-up of the TOE.
ADO_IGS.1.1E The evaluator shall confirm that the information provided meets all
ADO_IGS.1.2E The evaluator shall determine that the installation, generation, and startup procedures result in a secure configuration.
5.2.3 Development Assurance Requirements
ADV_FSP.1 Informal functional specification
ADV_FSP.1.1D The developer shall provide a functional specification.
ADV_FSP.1.1C The functional specification shall describe the TSF and its external
interfaces using an informal style.
ADV_FSP.1.2C The functional specification shall be internally consistent.
ADV_FSP.1.3C The functional specification shall describe the purpose and method of
use of all external TSF interfaces, providing details of effects, exceptions and error
messages, as appropriate.
ADV_FSP.1.4C The functional specification shall completely represent the TSF.
ADV_FSP.1.1E The evaluator shall confirm that the information provided meets all
ADV_FSP.1.2E The evaluator shall determine that the functional specification is an
accurate and complete instantiation of the TOE security functional requirements.
Emir Arslanagic
24
ENTS UMCP
CW-USA
12/29/1998
ADV_HLD.1 Descriptive high-level design

ADV_HLD.1.1D The developer shall provide the high-level design of the TSF.
ADV_HLD.1.1C The presentation of the high-level design shall be informal.
ADV_HLD.1.2C The high-level design shall be internally consistent.
ADV_HLD.1.3C The high-level design shall describe the structure of the TSF in terms
of subsystems.
ADV_HLD.1.4C The high-level design shall describe the security functionality provided
by each subsystem of the TSF.
ADV_HLD.1.5C The high-level design shall identify any underlying hardware,
firmware, and/or software required by the TSF with a presentation of the functions
provided by the supporting protection mechanisms implemented in that hardware,
firmware, or software.
ADV_HLD.1.6C The high-level design shall identify all interfaces to the subsystems of
the TSF.
ADV_HLD.1.7C The high-level design shall identify which of the interfaces to the
subsystems of the TSF are externally visible.
ADV_HLD.1.1E The evaluator shall confirm that the information provided meets all
ADV_HLD.1.2E The evaluator shall determine that the high-level design is an accurate
and complete instantiation of the TOE security functional requirements.
ADV_RCR.1 Informal correspondence demonstration
ADV_RCR.1.1D The developer shall provide an analysis of correspondence between all
adjacent pairs of TSF representations that are provided.
ADV_RCR.1.1C
For
each adjacent
pair
of
provided
TSF
representations, the analysis shall demonstrate that all relevant
security functionality of the more abstract TSF representation is
correctly and completely refined in the less abstract TSF
representation.
Emir Arslanagic
25
ENTS UMCP
CW-USA
12/29/1998
ADV_RCR.1.1E The evaluator shall confirm that the information provided meets all
5.2.4 Guidance Documents Assurance Requirements
AGD_ADM.1 Administrator guidance
AGD_ADM.1.1D The developer shall provide administrator guidance
addressed to system administrative personnel.
AGD_ADM.1.1C The administrator guidance shall describe the
administrative functions and interfaces available to the administrator
of the TOE.
AGD_ADM.1.2C The administrator guidance shall describe how to
administer the TOE in a secure manner.
AGD_ADM.1.3C The administrator guidance shall contain warnings
about functions and privileges that should be controlled in a secure
processing environment.
AGD_ADM.1.4C The administrator guidance shall describe all
assumptions regarding user behavior that are relevant to secure
operation of the TOE.
AGD_ADM.1.5C The administrator guidance shall describe all security parameters
under the control of the administrator, indicating secure values as appropriate.
AGD_ADM.1.6C The administrator guidance shall describe each type
of security-relevant event relative to the administrative functions that
need to be performed, including changing the security characteristics
of entities under the control of the TSF.
AGD_ADM.1.7C The administrator guidance shall be consistent with
all other documents supplied for evaluation.
AGD_ADM.1.8C The administrator guidance shall describe all security
requirements on the IT environment that are relevant to the
administrator.
AGD_ADM.1.1E The evaluator shall confirm that the information
provided meets all requirements for content and presentation of
evidence.
AGD_USR.1 User guidance
Emir Arslanagic
26
ENTS UMCP
CW-USA
12/29/1998
AGD_USR.1.1D The developer shall provide user guidance.

AGD_USR.1.1C The user guidance shall describe the functions and
interfaces available to the non-administrative users of the TOE.
AGD_USR.1.2C The user guidance shall describe the use of useraccessible security functions provided by the TOE.
AGD_USR.1.3C The user guidance shall contain warnings about useraccessible functions and privileges that should be controlled in a
secure processing environment.
AGD_USR.1.4C The user guidance shall clearly present all user
responsibilities necessary for secure operation of the TOE, including
those related to assumptions regarding user behavior found in the
statement of TOE security environment.
AGD_USR.1.5C The user guidance shall be consistent with all other
documentation supplied for evaluation.
AGD_USR.1.6C The user guidance shall describe all security requirements for the IT
environment that are relevant to the user.
AGD_USR.1.1E The evaluator shall confirm that the information provided meets all
5.2.5 Tests Assurance Requirements
ATE_COV.1 Evidence of coverage
ATE_COV.1.1D The developer shall provide evidence of the test
coverage.
ATE_COV.1.1C The evidence of the test coverage shall show the
correspondence between the tests identified in the test documentation
and the TSF as described in the functional specification.
ATE_COV.1.1E The evaluator shall confirm that the information
evidence.
ATE_FUN.1 Functional testing
Emir Arslanagic
27
ENTS UMCP
CW-USA
12/29/1998
ATE_FUN.1.1D The developer shall test the TSF and document the
results.
ATE_FUN.1.2D The developer shall provide test documentation.
ATE_FUN.1.1C The test documentation shall consist of test plans, test
procedure descriptions, expected test results and actual test results.
ATE_FUN.1.2C The test plans shall identify the security functions to be
tested and describe the goal of the tests to be performed.
ATE_FUN.1.3C The test procedure descriptions shall identify the tests
to be performed and describe the scenarios for testing each security
function. These scenarios shall include any ordering dependencies on
the results of other tests.
ATE_FUN.1.4C The expected test results shall show the anticipated
outputs from a successful execution of the tests.
ATE_FUN.1.5C The test results from the developer execution of the
tests shall demonstrate that each tested security function behaved as
specified.
ATE_FUN.1.1E The evaluator shall confirm that the information
evidence.
ATE_IND.2 Independent testing - sample
ATE_IND.2.1D The developer shall provide the TOE for testing.
ATE_IND.2.1C The TOE shall be suitable for testing.
ATE_IND.2.2C The developer shall provide an equivalent set of
resources to those that were used in the developers functional testing
of the TSF.
ATE_IND.2.1E The evaluator shall confirm that the information
evidence.
ATE_IND.2.2E The evaluator shall test a subset of the TSF as appropriate to confirm
that the TOE operates as specified.
Emir Arslanagic
28
ENTS UMCP
CW-USA
12/29/1998
ATE_IND.2.3E The evaluator shall execute a sample of tests in the test documentation to
verify the developer test results.
5.2.6 Vulnerability Assessment Assurance Requirements
AVA_SOF.1 Strength of TOE security function evaluation
AVA_SOF.1.1D The developer shall perform a strength of TOE security
function analysis for each mechanism identified in the ST as having a
strength of TOE security function claim.
AVA_SOF.1.1C For each mechanism with a strength of TOE security
function claim the strength of TOE security function analysis shall show
that it meets or exceeds the minimum strength level defined in the
PP/ST.
AVA_SOF.1.2C For each mechanism with a specific strength of TOE
security function claim the strength of TOE security function analysis
shall show that it meets or exceeds the specific strength of function
metric defined in the PP/ST.
AVA_SOF.1.1E The evaluator shall confirm that the information
evidence.
AVA_SOF.1.2E The evaluator shall confirm that the strength claims are correct.
AVA_VLA.1 Developer vulnerability analysis
AVA_VLA.1.1D The developer shall perform and document an analysis
of the TOE deliverables searching for obvious ways in which a user can
violate the TSP.
AVA_VLA.1.2D The developer shall document the disposition of
obvious vulnerabilities.
AVA_VLA.1.1C The documentation shall show, for all identified
vulnerabilities, based on CERT, that the vulnerability cannot be
exploited in the intended environment for the TOE.
Emir Arslanagic
29
ENTS UMCP
CW-USA
12/29/1998
AVA_VLA.1.1E The evaluator shall confirm that the information

evidence.
AVA_VLA.1.2E The evaluator shall conduct penetration testing, building on the
developer vulnerability analysis, to ensure obvious vulnerabilities have been addressed.
Emir Arslanagic
30
ENTS UMCP
CW-USA
12/29/1998
6. RATIONALE
The PP Rationale provides a demonstration that the PP specifies a complete, coherent and
internally consistent set of security objectives and security requirements that are appropriate to
address the identified security problem.
6.1
Security Requirements Rationales

Security Objective
Key Functional Components
O.Availability.1
FTA_TAB.1
FRU_FLT.2
O.Availability.2
FMT_SMR.1
FAU_STG.1
FAU_STG.4
FMT_MOF.1
O.Confidentiality.1
FAU_ARP.1
FIA_ATD.1
FIA_UAU.1
FIA_UAU.4
O.Confidentiality.2
FCS_COP.1
O.Confidentiality.3
FPR_ANO.1
O.Integrity.1
FIA_ATD.1
FIA_ATD.2
FIA_UAU.1
O.Integrity.1
FIA_ATD.1
FIA_ATD.2
FIA_UAU.1
Emir Arslanagic
O.Integrity.2
FAU_GEN.1
O.Integrity.3
FAU_GEN.1
31
ENTS UMCP
CW-USA
O.Integrity.4
12/29/1998
FPT_STM.1
FAU_GEN.1
FAU_SAR.1
FAU_SAR.3
O.Integrity.5
FIA_AFL.1
FPT_SEP.1
FAU_ARP.1
FAU_STG.1
FAU_STG.4
O.Integrity.6
FAU_GEN.1
FAU_SAR.1
6.2
O.Integrity.7
FMT_MAS.3
O.DataFlow.1
FDP_IFC.1
Functional Dependencies
Functional dependencies provide meaningful way to verify all functional dependencies in the PP.
Functional
Name
FAU_ARP.1
To Satisfy
O.Confidentiality.1
Dependence
FAU_SAA.1
O.Integrity.5
FAU_SAA.1
FAU_ARP.1
ADV_SPM.1
FMT_MSA.2
FAU_GEN.1
FPT_FLS.1
FAU_GEN.1
O.Integrity.2
FPT_STM.1
O.Integrity.3
O.Integrity.4
O.Integrity.6
Emir Arslanagic
32
ENTS UMCP
CW-USA
FAU_SAR.1
O.Integrity.4
12/29/1998
FAU_GEN.1
O.Integrity.6
FAU_SAR.3
O.Integrity.4
FAU_SAR.1
FAU_STG.1
O.Availability.2
FAU_GEN.1
O.Integrity.5
FAU_STG.4
O.Availability.2
FAU_STG.1
O.Integrity.5
FCS_CKM.1
FCS_CKM.2
FCS_COP.1
FCS_CKM.2
FCS_CKM.4
FCS_CKM.4
FCS_CKM.2
FMT_MSA.2
FCS_CKM.1
FCS_CKM.1
FCS_CKM.4
FMT_MSA.2
FCS_CKM.4
FCS_COP.1
FCS_CKM.1
FCS_CKM.1
FMT_MSA.2
FCS_CKM.2
FCS_COP.1
O.Confidentiality.2
FCS_CKM.1
FCS_CKM.4
FMT_MSA.2
FDP_ACC.1
FMT_MSA.1
FDP_ACF.1
FDP_ACF.1
FDP_ACF.1
FDP_ACC.1
FDP_ACC.1
FMT_MSA.3
FDP_IFC.1
O.DataFlow.1
FDP_IFF.1
FDP_IFF.1
FDP_IFC.1
FDP_IFC.1
FMT_MSA.3
FIA_AFL.1
Emir Arslanagic
O.Integrity.5
33
FIA_UAU.1
ENTS UMCP
CW-USA
FIA_ATD.1
12/29/1998
O.Confidentiality.1
O.Integrity.1
FIA_UAU.1
O.Confidentiality.1
FIA_UID.1
O.Integrity.1
FIA_UAU.4
O.Confidentiality.1
FIA_UID.1
FIA_UAU.1
FMT_MOF.1
O.Availability.2
FMT_SMR.1
FMT_MSA.1
FMT_MSA.3
FDP_ACC.1
FMT_MSA.2
FMT_SMR.1
FCS_COP.1
ADV_SPM.1
FCS_CKM.1
FDP_IFC.1
FCS_CKM.4
FMT_MSA.1
FCS_CKM.2
FMT_SMR.1
O.Integrity.7
FMT_MSA.1
FMT_MSA.2
FMT_MSA.3
FMT_SMR.1
6.3
FMT_SMR.1
O.Availability.2
FPR_ANO.1
O.Confidentiality.3
FPT_FLS.1
FRU_FLT.2
FPT_SEP.1
O.Integrity.5
FPT_STM.1
O.Integrity.4
FRU_FLT.2
O.Availability.1
FTA_TAB.1
O.Availability.1
FIA_UID.1
ADV_SPM.1
FPT_FLS.1
Rationale for Not Satisfying All Dependencies
Security access control in this TOE is based on information flow control therefore components
that required security attribute based access control FDP_ACC.1, FDP_ACF.1 does not have to
be satisfied.
Emir Arslanagic
34
ENTS UMCP
CW-USA
12/29/1998
7. Acronyms
The following abbreviations from the Common Criteria are used in this
Protection Profile:
CC
Common Criteria
Evaluation
EAL
Evaluation Assurance Level
FTP
File Transfer Protocol
HTTP
Hypertext Transfer Protocol
IT
Information Technology
PP
Protection Profile
SFP
Security Function Policy
ST
Security Target
TOE
Target of Evaluation
TSC
TSF Scope of Control
TSF
TOE Security Functions
TSP
TOE Security Policy
POP
Point Of Presence
AS
Autonomous System
Emir Arslanagic
for
35
Information
Technology
Security
ENTS UMCP
CW-USA
12/29/1998
8. References
Common Criteria for Information Technology Security Evaluation, CCIB-98-026 Version

2, May 1998.
U.S. Government Traffic-Filter Firewall Protection Profile for Low-Risk Environments;

Version 2.0, June 1998.
U.S. Government Application-Filter Firewall Protection Profile for Low-Risk Environments;

Version 1.a, August 1998.
Building Internet Firewalls, Chapman & Zwicky, OReilly & Associates, Inc., November
1995.
Emir Arslanagic
36
ENTS UMCP

Internet Backbone PP

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Internet Backbone PP

Uploaded by

Copyright:

Available Formats

CW-USA

INTERNET BACKBONE NETWORK PP

INTRODUCTION TO THE PROTECTION PROFILE................................................................................2

TARGET OF EVALUATION (TOE) DESCRIPTION....................................................................................2

SECURITY OBJECTIVES FOR THE TOE...............................................................................................................9

SECURITY REQUIREMENTS RATIONALES.........................................................................................................29

INTERNET BACKBONE NETWORK PP

1. INTRODUCTION TO THE PROTECTION PROFILE

2. TARGET OF EVALUATION (TOE) DESCRIPTION

The Domain Name System (DNS)

The Simple Mail Transport Protocol (SMTP)

The Network Time Protocol (NTP)

The File Transfer Protocol (FTP, TFTP)

The Network News Transfer Protocol (NNTP)

INTERNET BACKBONE NETWORK PP

Backbone Link OSPF

Interface I Two POPs of the same AS (Inside)

INTERNET BACKBONE NETWORK PP

Protection Profile-compliant TOEs are meant to be used in an environment in

INTERNET BACKBONE NETWORK PP

Confidentiality (i.e., Sensitivity, Secrecy) attack.

Availability (i.e., Fault Tolerance, Recovery, Utility) attack.

Privileged User or Authorized Administrator

INTERNET BACKBONE NETWORK PP

The following conditions are assumed to exist in the operational

Formal Assumption Specifications.

Authenticated users are generally trusted to perform discretionary actions in

Authenticated users recognize the need for a secure IT environment.

The processing resources of the TOE are assumed to be located within

The TOE provides services to authorized users.

Authorized administrators may access the TOE remotely inbound and

INTERNET BACKBONE NETWORK PP

T.Confidentiality An attacker may be able to gather some conclusion about

An attacker user may access the TOE by impersonating an

A user may cause audit records to be lost or prevent future

An attacker may bypass routing information stored in TOE.

An attacker may change routing information stored in TOE,

An attacker or unauthorized user may read, modify, or

A user may not be accountable for the actions that they

An attacker user may access the TOE by impersonating an

INTERNET BACKBONE NETWORK PP

Organizational Security Polices

Bandwidth as critical asset for this TOE ant it is protected by applying

Formal Policy Specifications

Only privileged user and authorized user should be able to

All configuration changes to the TOE have to be recorded.

All security functions changes to the TOE have to be recorded

INTERNET BACKBONE NETWORK PP

All attempts to gain access to TOE have to be recorded.

Inbound management services have to be accessible only from

INTERNET BACKBONE NETWORK PP

Security Objectives for the TOE

The TOE must provide functionality, which enables privileged user to

The TOE must prevent the reuse of authentication data.

The TOE must detect attempts by unauthorized users to bypass, deactivate,

The TOE must detect loss of integrity affecting security functions.

Upon initial start-up of the TOE or recovery from an interruption in TOE

INTERNET BACKBONE NETWORK PP

Security Objectives for the Environment

TOE Security Functional Requirements

Potential violation analysis

Audit data generation

Selectable audit review

Protected audit trail storage