Tenable Network Security, Inc. Tenable Security Center 3.2 and Components

needmorebaitΔίκτυα και Επικοινωνίες

20 Νοε 2013 (πριν από 3 χρόνια και 6 μήνες)

257 εμφανίσεις




Tenable Network Security, Inc.
Tenable Security Center 3.2 and Components
Security Target
Version 1.0


January 15, 2010

















Prepared for:
Tenable Network Security, Inc.

7063 Columbia Gateway Drive, Suite 100
Columbia, MD 21046




Prepared By:
Science Applications International Corporation
Common Criteria Testing Laboratory

7125 Columbia Gateway Drive, Suite 300
Columbia, MD 21046

Security Target Version 1.0, 01/15/10


2


1. SECURITY TARGET INTRODUCTION ........................................................................................................... 4

1.1

S
ECURITY
T
ARGET
,

TOE
AND
CC

I
DENTIFICATION
........................................................................................ 4

1.2

C
ONFORMANCE
C
LAIMS
................................................................................................................................. 5

1.3

C
ONVENTIONS AND
A
CRONYMS
..................................................................................................................... 5

1.3.1

Conventions ........................................................................................................................................... 5

1.3.2

Acronyms ............................................................................................................................................... 5

2.

TOE DESCRIPTION .......................................................................................................................................... 7

2.1

TOE

O
VERVIEW
............................................................................................................................................. 8

2.1.1

Tenable Security Center (SC3) .............................................................................................................. 8

2.1.2

3D Tool (3DT) ..................................................................................................................................... 11

2.1.3

Log Correlation Engine (LCE) ............................................................................................................ 11

2.1.4

Passive Vulnerability Scanner (PVS) ................................................................................................... 12

2.1.5

Nessus Scanner (Nessus) ..................................................................................................................... 12

2.2

TOE

A
RCHITECTURE
.................................................................................................................................... 13

2.2.1

TOE Physical Boundaries .................................................................................................................... 13

2.2.2

TOE Logical Boundaries ..................................................................................................................... 15

2.3

TOE

E
NVIRONMENT
..................................................................................................................................... 18

2.3.1

Protection of TOE communication ...................................................................................................... 18

2.3.2

Non-bypassability of the TSP ............................................................................................................... 19

2.3.3

Domain Separation .............................................................................................................................. 19

2.3.4

Reliable Time Stamps........................................................................................................................... 19

2.3.5

Trusted Path......................................................................................................................................... 19

2.4

TOE

D
OCUMENTATION
................................................................................................................................ 19

3.

SECURITY ENVIRONMENT ......................................................................................................................... 20

3.1

T
HREATS
...................................................................................................................................................... 20

3.1.1

TOE Threats......................................................................................................................................... 20

3.1.2

IT System Threats ................................................................................................................................ 20

3.2

O
RGANIZATIONAL
S
ECURITY
P
OLICIES
........................................................................................................ 21

3.3

S
ECURE
U
SAGE
A
SSUMPTIONS
..................................................................................................................... 21

3.3.1

Intended Usage Assumptions ............................................................................................................... 21

3.3.2

Physical Assumptions .......................................................................................................................... 21

3.3.3

Personnel Assumptions ........................................................................................................................ 21

4.

SECURITY OBJECTIVES .............................................................................................................................. 23

4.1

S
ECURITY
O
BJECTIVES FOR THE
TOE ........................................................................................................... 23

4.2

S
ECURITY
O
BJECTIVES FOR THE
E
NVIRONMENT
........................................................................................... 23

5.

IT SECURITY REQUIREMENTS .................................................................................................................. 25

5.1

TOE

S
ECURITY
F
UNCTIONAL
R
EQUIREMENTS
............................................................................................. 25

5.1.1

FAU - Security Audit............................................................................................................................ 25

5.1.2

FIA - Identification and Authentication ............................................................................................... 27

5.1.3

FMT - Security Management ............................................................................................................... 27

5.1.4

FPT – Protection of the TSF ................................................................................................................ 28

5.1.5

IDS – Intrusion Detection System ........................................................................................................ 28

5.2

IT

E
NVIRONMENT
S
ECURITY
F
UNCTIONAL
R
EQUIREMENTS
......................................................................... 30

5.2.1

FAU - Security Audit............................................................................................................................ 30

5.2.2

FPT - Protection of the TOE Security Functions ................................................................................. 30

5.2.3

FTP – Trusted path/channels ............................................................................................................... 30

5.2.4

IDS – Intrusion Detection System ........................................................................................................ 31

5.3

TOE

S
ECURITY
A
SSURANCE
R
EQUIREMENTS
............................................................................................... 31

5.3.1

ACM - Configuration management ...................................................................................................... 32

5.3.2

ADO - Delivery and operation ............................................................................................................. 32

Security Target Version 1.0, 01/15/10


3

5.3.3

ADV - Development ............................................................................................................................. 32

5.3.4

AGD - Guidance documents ................................................................................................................ 33

5.3.5

ALC - Life cycle support ...................................................................................................................... 34

5.3.6

ATE - Tests ........................................................................................................................................... 35

5.3.7

AVA - Vulnerability assessment ........................................................................................................... 36

6.

TOE SUMMARY SPECIFICATION .............................................................................................................. 37

6.1

TOE

S
ECURITY
F
UNCTIONS
.......................................................................................................................... 37

6.1.1

Security Audit ....................................................................................................................................... 37

6.1.2

Identification and Authentication ........................................................................................................ 38

6.1.3

Security Management .......................................................................................................................... 39

6.1.4

Protection of the TSF ........................................................................................................................... 40

6.1.5

Intrusion Detection System .................................................................................................................. 40

6.2

TOE

S
ECURITY
A
SSURANCE
M
EASURES
...................................................................................................... 42

6.2.1

Configuration management ................................................................................................................. 42

6.2.2

Delivery and operation ........................................................................................................................ 42

6.2.3

Development ........................................................................................................................................ 42

6.2.4

Guidance documents ............................................................................................................................ 43

6.2.5

Life cycle support ................................................................................................................................. 43

6.2.6

Tests ..................................................................................................................................................... 44

6.2.7

Vulnerability assessment ...................................................................................................................... 44

7.

PROTECTION PROFILE CLAIMS ............................................................................................................... 45

8.

RATIONALE ..................................................................................................................................................... 47

8.1

S
ECURITY
O
BJECTIVES
R
ATIONALE
.............................................................................................................. 47

8.1.1

Complete Coverage – Environmental Assumptions ............................................................................. 47

8.1.2

Complete Coverage – Organizational Security Policies...................................................................... 49

8.1.3

Complete Coverage – Threats ............................................................................................................. 51

8.2

S
ECURITY
R
EQUIREMENTS
R
ATIONALE
........................................................................................................ 55

8.2.1

Security Functional Requirements Rationale....................................................................................... 55

8.3

S
ECURITY
A
SSURANCE
R
EQUIREMENTS
R
ATIONALE
.................................................................................... 60

8.4

S
TRENGTH OF
F
UNCTIONS
R
ATIONALE
......................................................................................................... 60

8.5

R
EQUIREMENT
D
EPENDENCY
R
ATIONALE
.................................................................................................... 60

8.6

E
XPLICITLY
S
TATED
R
EQUIREMENTS
R
ATIONALE
........................................................................................ 61

8.7

TOE

S
UMMARY
S
PECIFICATION
R
ATIONALE
................................................................................................ 61

8.8

PP

C
LAIMS
R
ATIONALE
................................................................................................................................ 62


Security Target Version 1.0, 01/15/10


4


1. Security Target Introduction
This section identifies the Security Target (ST) and Target of Evaluation (TOE) identification, ST conventions, ST
conformance claims, and the ST organization.
The Target of Evaluation (TOE) is the Tenable Security Center 3.2 and Components. It consists of the Tenable
Security Center 3.2 (SC3); 3D Tool 1.2 (3DT); Log Correlation Engine 2.0.2. (LCE); Passive Vulnerability Scanner
3.0 (PVS); Nessus Scanner 3.0.4. (Nessus). The TOE consists of five (5) distinct products and the evaluated
configuration includes all of the Tenable products working together. Tenable’s product suite provides an integrated
environment for managing security events and vulnerabilities where all products tie together; the scanning products
are updated with new and modified plugins as appropriate for the individual application; and, integrate with other
third party products that are not part of this evaluation. The TOE facilitates administration and organization of
security workflow and management that includes reporting automatic notices for affected parties; division of duties;
separate access to data; and, update and tracking of vulnerability closure.
The Security Target contains the following sections:
Section 1 Security Target Introduction
This section identifies the Security Target (ST) and Target of Evaluation (TOE) identification,
ST conventions, ST conformance claims, and the ST organization.
Section 2 Target of Evaluation (TOE) Description
This section gives an overview of the TOE, describes the TOE in terms of its physical and
logical boundaries, and states the scope of the TOE.
Section 3 TOE Security Environment
This section details the expectations of the environment, the threats that are countered by TOE
and IT environment, and the organizational policy that TOE must fulfill.
Section 4 TOE Security Objectives
This section details the security objectives of the TOE 4.3 and IT environment.
Section 5 IT Security Requirements
The section presents the security functional requirements (SFR) for TOE and IT Environment
that supports the TOE, and details the assurance requirements for EAL2.
Section 6 TOE Summary Specification
The section describes the security functions represented in the TOE that satisfy the security
requirements.
Section 7 Protection Profile Claims
This section presents any protection profile claims.
Section 8 Rationale
This section closes the ST with the justifications of the security objectives, requirements and
TOE summary specifications as to their consistency, completeness, and suitability.
1.1 Security Target, TOE and CC Identification
ST Title

Tenable Network Security, Inc. Tenable Security Center 3.2 and Components Security Target
ST Ver sion
– Version 1.0
ST Date
– January 15, 2010
TOE Identification
– Tenable Security Center 3.2 and Components. The TOE consists of: Tenable Security Center
3.2 plus Components 3D Tool 1.2 (3DT); Log Correlation Engine 2.0.2 (LCE); Passive Vulnerability Scanner 3.0
(PVS); and Nessus Scanner 3.0.4 (Nessus).
CC Identification
– Common Criteria for Information Technology Security Evaluation, Version 2.3, August 2005.
Security Target Version 1.0, 01/15/10


5

1.2 Conformance Claims
This TOE is conformant to the following CC specifications:
• Common Criteria for Information Technology Security Evaluation Part 2: Security Functional
Requirements, Version 2.3, August 2005.
• Part 2 Extended
• Common Criteria for Information Technology Security Evaluation Part 3: Security Assurance
Requirements, Version 2.3, August 2005.
• Part 3 Conformant
• Assurance Level: EAL2 augmented with ALC_FLR.3 and AVA_MSU.1.
• This TOE is conformant to the following Protection Profile (PP):
• Intrusion Detection System System Protection Profile, Version 1.6, April 4, 2006 (IDSSYPP)
1.3 Conventions and Acronyms
This section specifies the formatting conventions used in the Security Target and provides a glossary of acronyms.
1.3.1 Conventions
The following conventions have been applied in this document:
• Security Functional Requirements – Part 2 of the CC defines the approved set of operations that may be
applied to functional requirements: iteration, assignment, selection, and refinement.
o Iteration: allows a component to be used more than once with varying operations. In the ST, a
letter placed at the end of the component indicates iteration. For example FDP_ACC.1a and
FDP_ACC.1b indicate that the ST includes two iterations of the FDP_ACC.1 requirement.
o Assignment: allows the specification of an identified parameter. Assignments are indicated using
bold and are surrounded by bold brackets (e.g., [
assignment
]). However, the text is not bolded
when a CC assignment was completed by a Protection Profile from which the SFR was drawn as
part of a conformance claim, so that no assignment was exercised in writing the ST.
o Selection: allows the specification of one or more elements from a list. Selections are indicated
using bold italics and are surrounded by bold brackets (e.g., [
selection
]). An assignment inside a
selection is indicated using bold italics surrounded by bold italics brackets surrounded by bold
brackets (e.g., [[
selection
]]). However, the text is not bolded when a CC selection was completed
by a Protection Profile from which the SFR was drawn as part of a conformance claim, so that no
selection was exercised in writing the ST.
o Refinement: allows the addition of details. Refinements are indicated using bold, for additions,
and strike-through, for deletions (e.g., “…
all
objects …” or “… some

big
things …”).
• Explicitly stated Security Functional Requirements (i.e., those not found in Part 2 of the CC) are identified
with “
(EXP)
”.
• Other sections of the ST – Other sections of the ST use bolding to highlight text of special interest, such as
captions.
1.3.2 Acronyms

3DT

3D Tool

CC

Common Criteria

Security Target Version 1.0, 01/15/10


6

CCTL

CC Testing Laboratory

CI

Configuration Item

CLI

Command Line Interface

CM

Configuration Management

CMP

Configuration Manageme
nt Plan

CVE

Common Vulnerabilities and Exposures

CVS

Concurrent Versioning System

DHCP

Dynamic Host Configuration Protocol

DoD

Department of Defense

DoS

Denial of Service

EAL

Evaluation Assurance Level

EU

End User (a TOE role)

EXP

Explicitly stat
ed SFR

FQDN

Fully Qualified Domain Name

FSP

Functional Specification

GUI

Graphical User Interface

HLD

High
-
level Design

HTTP

Hyper
-
text Transfer Protocol

ID

Identity/Identification

IDS

Intrusion Detection System

IDSSYPP

IDS System PP, Version 1.6,
April 4, 2006.

IP

Internet Protocol

IT

Information Technology

ITT

Internal TOE TSF Data Transfer family of FPT

LCE

Log Correlation Engine

NASL

Nessus Attack Scripting Language

NIAP

National Information Assurance Partnership

NIDS

Network IDS

NIST

National Institute of Standards and Technology

NSA

National Security Agency

OS

Operating System

PKI

Public Key Infrastructure

PP

Protection Profile

PSM

Primary Security Manager (a TOE role)

PVS

Passive Vulnerability Scanner 2.2

SA

System Administr
ator (a TOE environment role)

SAIC

Science Applications International Corporation

SAR

Security Assurance Requirement

SC3

Security Center 3.0

SCA

Security Center Administrator (a TOE role)

SFR

Security Functional Requirement

SM

Security Manager (a T
OE role)

SMB

Server Message Block

SNMP

Simple Network Management Protocol

SOF

Strength of Function

SSH

Secure Shell

SSL

Secure Sockets Layer

ST

Security Target

TASL

Tenable Application Scripting Language

TCP

Transmission Control Protocol

TOE

Tar
get of Evaluation

TSF

TOE Security Functions

TSS

TOE Summary Specification

US

United States

XML

Extensible Markup Language

Security Target Version 1.0, 01/15/10


7

2. TOE Description
The Target of Evaluation (TOE) is Tenable Security Center 3.2 (SC3) and Components: 3D Tool 1.2 (3DT); Log
Correlation Engine 2.0.2 (LCE); Passive Vulnerability Scanner 3.0 (PVS); and, Nessus Scanner 3.0.4 (Nessus). The
TOE consists of only these five Tenable products, as shown in the Figure 1. The configuration of the TOE subject
to evaluation consists of a single SC3 and at least one instance each of the Nessus, PVS, LCE, and 3DT products.
Support for other intrusion detection system (IDS) products (e.g., scanners) is provided by the product but is not part
of the evaluated configuration (i.e., their security functions were not evaluated).


Figur e
1



The Tenable pr oducts compr ising the TOE.

Figure 1 shows the external interfaces to the TOE. The TOE initiates all except the user interfaces. None are used
to provide IDS information to external IT entities. The external interfaces are:
OS IDS Inter face
– Interface to monitored operating systems to collect IDS information.
Passive Networ k IDS Inter face
– Interface to monitored networks to collect IDS information.
System Logs (
SYSLOG Ser ver
) IDS Inter face
– Interface to monitored servers to collect IDS information. The
interface uses the SYSLOG protocol to accept events from other components of the TOE.
Tenable Nessus Signatur e and Plug
-
in Download Ser ver
– Interface to Tenable Nessus server to download
signatures and NASL plug-ins that allow Nessus to detect the latest known attacks and vulnerabilities against
operating systems. The downloaded signatures and plug-ins are configuration data that keep the product current
with known vulnerabilities. They update the signatures and plug-ins that are shipped with the TOE.
Tenable PVS Signatur e and Plug
-
in Download Ser ver
– Interface to Tenable PVS server to download signatures
and TASL plug-ins that allow PVS to detect the latest known attacks and vulnerabilities from its network
perspective. The downloaded signatures and plug-ins are configuration data that keep the product current with
known vulnerabilities. They update the signatures and plug-ins that are shipped with the TOE.

NIST ICAT Database
– Descriptions of vulnerabilities from NIST’s ICAT (now the National Vulnerability
Database) are added to SC3’s vulnerability descriptions when presented to users.
3DT User Inter face
– User interface to SC3 using 3DT for an enhanced view of the IDS scan results.
Security Target Version 1.0, 01/15/10


8

Web Br owser User Inter face
– User interface to SC3 using a standard web browser with an SSL connection.
Note that while in theory the Nessus, PVS, and LCE components include interfaces intended for use of the
component independent of the other components, it is assumed that those components will be configured and used in
a manner where those interfaces would not be used. Rather, the SC3 would be used (sometimes via the 3DT
component) to integrate and centralize those component capabilities.
The TOE provides administrators with tools to facilitate network security by providing the following services:
• Vulnerability discovery and management,
• Security event management and incident response,
• Measuring and demonstrating configuration management, and
• Dynamic and static asset discovery.
The TOE provides an integrated environment for managing security events and vulnerabilities. The Nessus, PVS,
and LCE TOE components contain plug-ins (or scripts) that provide functionality specific to the TOE component.
The TOE facilitates the administration and organization of security workflow and management tasks, including
automatic reporting to affected parties; division of duties; access control for application data; and update and
tracking of vulnerability closure.
Information gathered by the TOE for the above tasks is stored in a centralized database. The reporting, ticketing,
user interface, and security model are designed to ensure that the right people in the organization can access the
information they need to make informed network security and performance decisions.
The TOE consists of the five components shown above configured as an Intrusion and Vulnerability Detection
System. The Security Center 3 component collects event and vulnerability data from one or more instances of PVS
sensors and one or more instances of Nessus scanners. It analyzes the data and presents the results to its users, with
the help of one or more instances of LCE and 3DT components. This fits the IDS System structure specified in the
IDSSYPP, to which this ST claims conformance, as follows:
• IDS Analyzer: SC3 with LCE and 3DT.
• IDS Scanner: Nessus.
• IDS Sensor: PVS.
The TOE consists of the five software components (SC3, LCE, 3DT, Nessus, and PVS) running on hardware and
operating systems that are not part of the TOE. The components do not need to all be run on the same kind of
platform. The networks that connect these components are not part of the TOE.
The SC3 component is able to interface with additional 3
rd
party generators of IDS event data, but that capability is
not tested in this evaluation. .
2.1 TOE Overview
This section describes the various TOE components and how they work together.
2.1.1 Tenable Security Center (SC3)
The Tenable Security Center provides proactive, asset-based security risk management. It unifies the process of
asset discovery, vulnerability detection, event management and compliance reporting by integrating the functions of
the other TOE components. The primary functions of SC3, operating in conjunction with the other TOE
components further described below, include
1

:


1
Note that since SC3 serves to consolidate and present a unified view of the available functions regardless of
supporting components, there has been no attempt to specifically distinguish the functions, or aspects thereof,
specifically implemented by the SC3 component from the functions made accessible via SC3.
Security Target Version 1.0, 01/15/10


9

• Risk management: SC3 supports risk management through the use of periodic Nessus vulnerability scanning;
continuous passive PVS vulnerability scanning; automated custom administrator notification; and vulnerability
projection onto network topology

• Threat management: SC3 performs real-time IDS event aggregation and distribution; real-time IDS and
vulnerability correlation; automated alerting
2

of affected administrators; and projection of IDS events onto
network topology.
• Asset discovery and management: SC3 allows combining the knowledge of existing asset inventories with the
vulnerability and compliance information discovered by Nessus and the Passive Vulnerability Scanner. SC3
performs asset discovery with active and passive vulnerability scanners. Resources are classified on type,
location and description. It also performs vulnerability reporting, remediation and false positive management
by asset type.

• Workflow management: SC3 includes a ticketing and workflow system. Vulnerability and compliance issues
can have a ticket opened against them. Tickets can be applied to just the vulnerable system, any system having a
vulnerability, or any vulnerable system in an asset group. Administrators can accept the risk on one or more
vulnerabilities or raise or lower its severity level. SC3 also determines which users should receive notification
of new tickets.

• Executive reporting: SC3 provides several methods to report and visualize vulnerability, compliance and event
data: asset lists, 3D visualization using 3DT, and user customizable reports. Managers can view security
threats, risks and workflows for each business unit and group of business units. Trending reports are provided
for vulnerabilities and intrusion events. Resource allocation tracking is per business unit. The security of
various business units can be compared.

• Minimal resource impact: SC3 configuration requirements are minimal, requiring shallow learning curves and
minimal training requirements. The full-time passive scanning has no direct network visibility though the
impact on network performance will vary depending on the extent of configured scans. Distributed active
scanning has minimal network impact. Users interact with the TOE via a web interface and all data stays within
the host network boundaries.

The SC3 TOE component can manage one or more Nessus and PVS network scanners. Scans can discover new
hosts, new applications and new vulnerabilities or verify policy compliance. Nessus scans can be scheduled and
automatically distributed to multiple scanners. SC3 manages the Nessus scanners and determines which are best
suited to scan a particular host. It can use a remote Nessus scanner to simulate what an external attacker might see
from outside the network. SC3 can manage user credentials for access control. Note that while access management
may be linked to an external LDAP or Windows Domain, this use of third party authentication is not included in the
scope of this evaluation.

SC3 receives Intrusion Detection System (IDS) events from multiple sources. It analyzes the event data against its
vulnerability database to determine whether the target of an event is vulnerable to the attack. If it is, it reports the
information to the relevant system administrators and (optionally) to users via e-mail. SC3 includes a set of
common audit guides implemented by Tenable for use in various government, financial, and health care compliance
audits. SC3 captures the time that system components and vulnerabilities were first discovered and when they were
last seen. This allows users to demonstrate to auditors when security issues were first identified, what was done to
inform system owners of their required actions (i.e., such as disabling an unauthorized service), and how long it took
to close an issue.

SC3 performs IDS event correlation. It can send alerts to designated, authorized SC3 users to indicate that a
protected system is being attacked, and it can be configured to only send that alert if the subject system is vulnerable


2
Note that each component generates alerts independently relative to the events they process. For the most part
Nessus and PVS just present their results to the other TOE components. LCE TASL scripts can be defined to issue
alerts and SC3 can issue alerts based on normalized data that it receives.
Security Target Version 1.0, 01/15/10


10

to that specific attack. Further, PVS can be configured to detect both encrypted and clear interactive sessions and to
identify these sessions by IP address, port and network protocol. It can recognize when any system inside the
protected network begins to launch port scans or network sweeps.

For more accurate vulnerability to IDS event correlation, the SC3 should be configured to synchronize with the
latest rules engine (as described in Appendix 1 of the Security Center 3.2 Documentation) and have the latest
vulnerability information as possible. If scans are only being performed once in a great while, performing
correlation on them could be of marginal value. Using daily scans or implementing passive network monitoring can
greatly increase the accuracy of the correlated events.

SC3 uses five daemons (lightningd, lightning-proxy, importd, logd and maild) to perform communications,
importation of security data, and user alerting. lightningd conducts all scheduled events such as launching
vulnerability scans and downloading new IDS signatures and Nessus plugins. The lightning-proxy simulates a
Nessus daemon and a Nessus client so that when a scan is launched by the Security Center, it can perform all the
functions necessary for distributing the scan parameters and aggregating the results. lightning-proxy also pushes
new vulnerability information out to the remote scanners. importd formats and imports raw vulnerability scan data
into the Security Center’s database. logd listens for SNMP traps and SYSLOG messages. maild is a dedicated
outbound email tool that the Security Center uses instead of sendmail.

An Apache web server is included in the product distribution but is not part of the TOE. It can be used in the TOE
environment to provide secure user and administration interfaces.

The SC3 stores all configuration data including
customer, user, vulnerability and intrusion data in
an embedded database that is optimized for data
storage and indexing. SC3 uses Secure Shell
(SSH) to make LCE queries. All reporting and
data analysis is performed remotely by the LCE
and presented to the user by the SC3. If the LCE
discovers an anomaly or a specific type of event
correlation it sends an alert to the SC3, which
treats it as if it came from an IDS device.

SC3 can receive trap analysis events directly from
IDS sensors using SYSLOG and Simple Network
Management Protocol (SNMP) protocols. SC3 is
configured to receive IDS signature updates via
direct or proxy access to the Internet. It can
access the support sites or management consoles
of the various IDS solutions it supports in order to
build an up-to-date reference model of all the
signature events it might find in logs from those
IDS solutions. Correlation of event signatures
from the various sensors is done by matching
Common Vulnerabilities and Exposures (CVE)
(
http://cve.mitre.org
) and bugtraq
(
http://www.securityfocus.com
) IDs with Tenable
Nessus and PVS plug-in information. SC3 also
provides optional web-based reporting and
analytical functions. 3DT can also be used for
some analytical and presentation activities. SC3
uses the collected scan data to build dynamic asset lists of system vulnerability and configuration information using
dynamic rules. These lists include account addresses, open ports numbers, specific vulnerabilities, IDs, and
descriptions of discovered vulnerabilities from the know bug databases. Dynamic asset lists can be augmented with
existing static asset lists collected externally to the SC3.


Figure 2. An example network showing the placement of Nessus
scanners (yellow eyes). The routers (blue boxes) isolate local traffic
on subnets, so full coverage requires a scanner on each subnet. The
scanner on the external connection allows scanning traffic at the
enterprise boundary. The figure also shows one Tenable SC3
component collecting and reporting events from all of the scanners
and three PVSs (yellow triangles).
Security Target Version 1.0, 01/15/10


11

Although the TOE also supports a single scanner configuration (i.e., SC3 and Nessus), the evaluated configuration
of the TOE is for multiple scanner configurations. Figure 2 depicts SC3 deployed on a server (lower right) and
multiple Nessus scanners deployed across the small network. The triangle icons show three PVSs deployed on
various network links.
2.1.2 3D Tool (3DT)
3DT is a 3D Visualization tool that runs on a user workstation and displays network topology and the relative
distribution of security information in three dimensions. It runs on Windows and requires a Security Center account
to access the data. It’s only form of communication with the Security Center is via an SSL communication path.
Users launch the 3DT tool, establish an SSL connection with the Security Center and then authenticate to the
Security Center. It supports two reporting modes: network topology and a hosts-to-vulnerabilities trend comparison
matrix. 3DT users can make one or more queries to populate the 3DTdata sets and the tool plots topology data for
discovered routing and devices, interconnections and correspondence among network servers and clients. Two data
sets can be compared using this tool. 3DT plots and explores the results of one query against another and allows the
browsing of data (events) and topology. It also provides rapid visual feedback about event frequency.
2.1.3 Log Correlation Engine (LCE)
LCE aggregates, normalizes, correlates and analyzes event log data from the various devices within the network
infrastructure. It is closely integrated with the Security Center, allowing the centralization of log analysis and
vulnerability management.

Each Security Center can manage multiple LCEs and each LCE can receive system logs, netflows, IDS events,
firewall events, honeypot events, and other types of records from multiple sources. Only Nessus Scanner and PVS
IDS sources are included in the evaluated configuration, however. Security Center users see only the LCE events
they are authorized to see.

The LCE implements a SYSLOG interface that it exports to clients for the purpose of accepting events to analyze
and correlate. While LCE could potentially accept SYSLOGs from multiple sources, the TOE includes LCE agents
for specific OSs (including the TOE component hosts) that serve to monitor those systems and generate SYSLOG
findings to LCE. When an LCE receives an event, it can save the raw event data, and it can also perform
customized analysis on it. When an event is to be sent to SC3, the data is normalized and forwarded. LCE enables
the Security Center to perform high-speed analysis and reporting for many types of events.

The LCE includes an event scripting language, based on Tenable Nessus’ NASL language, known as Tenable
Application Scripting Language (TASL) that can be used to specify complex correlation tasks for execution in real
time. TASL scripts can be written or installed by any of the system administrator roles, but can be executed only on
the network segments to which each system administrator has access.

LCE allows SC3 functionality to be expanded to any log device, where the primary focus is to offload aggregation,
normalization, analysis and reporting of security events to one or more servers other than the SC3. SC3 can be
extended with one or more LCEs. The LCE runs on a separate server from the SC3. LCE can collect events using a
SYSLOG interface and can make use of other generic protocols for behavioral and event correlation and can send
the alerts to the SC3.

LCE includes client agents for Unix, Windows, netflow, OPSEC, RDEP and network sniffing that can be used to log
a variety of network traffic. LCE clients can be placed on key servers and at network choke points to aggregate as
many logs as possible. LCE implements a mode for each monitored host that includes: client or server behavior;
inbound, outbound and Internet connection rates; and per event rates.

Although the TOE can be configured to accept IDS events from other sources, the evaluated configuration only
includes the Tenable IDS event sources that are part of the TOE. This restriction is enforced by the ability to filter
event sources based on IP Address.
Security Target Version 1.0, 01/15/10


12

2.1.4 Passive Vulnerability Scanner (PVS)
PVS continuously monitors network traffic, searching for vulnerable systems, watching for potential application
compromises, observing client and server trust relationships, and tracking open or browsed network protocols in use.
PVS monitors network traffic for a variety of security related information including:

• Client and server application vulnerabilities
• Detection of compromised or subverted applications
• Detecting when new hosts are added to the network
• Detecting when an internal system begins to port scan other systems
• Highlighting all interactive and encrypted network sessions
• Tracking exactly which systems communicate with other internal systems
• Detecting which ports are served and which ports are browsed for each individual system
• Passively determining the type of operating system of each active host

SC3 fuses this information with the active or credentialed scan results from Tenable Nessus. Note that the period of
PVS logging is configured and SC3 gets the available data when it connects for that purpose. As such, PVS and SC3
should be coordinated appropriately. SC3 communication is facilitated via a proxy enabling the use of web-based
SSL interactions When a credential scan is performed the credentials are protected by the SSL channel.

PVS is not a typical Network IDS (NIDS) in that it does not run large signature sets of known network attack or
probe activity. Instead, as the PVS learns about a network’s applications, it looks for compromise events in traffic
originating from those systems. PVS detects when systems are compromised based on application intrusion
detection; selectable rule libraries and filtering rules to look for overflows, web attacks, etc., and sniffs out
vulnerabilities from network session traffic. Most protocols carry internal version and identity information.

PVS uses its own signatures and plugins for passive analysis (i.e. it does not have an agent on any of its targets). It
can collect information about client-side and server-side vulnerabilities, detect rogue and non-routable hosts,
discover network assets by active IP address, detect TCP SYN packets (indicating client-side usage and providing
passive OS fingerprinting), TCP SYN-ACK (open services and “show-connections”). PVS is constantly updating
its model of the networks it is monitoring, noting which hosts are active; which ports are open; and which plugins
have matched on particular IP address.

Note that while the PVS could be configured to share its scanned data with alternate or multiple clients, the
evaluated configuration restricts its sharing to other TOE components, specifically the SC3. Similarly, while the
PVS can be configured to forward vulnerability and alert data via SYSLOG to other components, this capability is
disabled in the evaluated configuration.

Furthermore, PVS can be configured to take actions to mitigate some IDS-related events. For example, it can send
TCP resets when disallowed traffic is detected. However, given that the enforcement of such directives is outside the
control of the TOE this feature has not been subject to security claims and as such has not been evaluated in this
regard.
2.1.5 Nessus Scanner (Nessus)
Nessus is an active scanner that provides agent-less host auditing of both UNIX and Windows servers. It features
network node discovery, asset profiling, and vulnerability analysis. Nessus scanners can be distributed throughout a
large network, on DMZs, and across distributed networks. It can be used for ad-hoc scanning, daily scans, and
quick-response audits. When managed with SC3, vulnerability recommendations can be sent to responsible parties,
remediation can be tracked, and security patches can be audited.
Nessus discovery scans include ARP ping, Syn ping, ICMP ping, TCP CONNECT (full TCP handshake), TCP
SYN. OS detection methods include port scanners that send packets in a specific way and listen for minute changes
that would identify the type of server responding. Service detection scanning identifies servers by the banners they
present and how they respond to probes. Vulnerability analysis scans servers for known vulnerabilities using the
information about the server resulting from the port scanner, OS detection and banner detection routines. The
Nessus client/server architecture has the flexibility to deploy the scanner and the Graphical User Interface (GUI) in
Security Target Version 1.0, 01/15/10


13

multiple configurations and with various reports to reflect the risk level of each security vulnerability found (i.e.,
from Low to High) and provides guidance on how to prevent them from being exploited.

Scan types include:

• Local (credentialed): Nessus scans the local host for security vulnerabilities, identifying missing security
patches, checks client software versions, and audits policy compliance using a valid logon on the target
machine. A local scan is less intrusive than a network scan and can provide information about installed
software.
• Remote (network): Nessus scans remotely for vulnerabilities using its standard methodology of port scans
followed up by vulnerability scans. It can identify open ports, recognize underlying OSs, and discover
vulnerabilities in network services.
• Hybrid (both network and credentialed): A combination of local and remote scans that provides the most
comprehensive scan of a network host.

Nessus contains service specific plugins that determine the services that are running behind specified ports, based on
defined parameters. This minimizes the impact of security scans on printers and other devices that cannot support
multiple open ports simultaneously. Nessus contains more than 11,000 plugins, each of which checks for one or
more unique vulnerabilities. Plugins are organized into Families.

The administrator can opt to enable all security checks or to enable all security checks except the checks that are
potentially harmful. (Unsafe checks are not supported in the evaluated configuration.) Administrators also have
options to define new security check policies and to activate a pre-defined policy.

Nessus reporting focuses on the severity of vulnerabilities. Warnings are mild flaws or vulnerabilities that may
increase the severity of other vulnerabilities. Holes are severe flaws or vulnerabilities that may have a major impact
on host or network security. Nessus security reports automatically pop up as a new instance of Microsoft Internet
Explorer. All reports are archived and available for later viewing and printing.

Nessus saves all of its vulnerability data in various file formats (notably XML and “nbe” which is a custom file
format). The Nessus scanner includes the Nessus Attack Scripting Language (NASL) designed to allow the
development of new security tests easily and quickly. NASL scripts can be written or installed by any of the system
administrator roles, but can be executed only on the network segments to which each system administrator has
access.

Nessus can be invoked as a command in a host system shell. This command line interface (CLI) support allows
arguments on the command line so that scans can be launched via batch files or scripts. This provides support for
concurrent scanning because each CLI runs as a separate process. CLI reports can be saved as NBE, NSR, XML
and TXT formats. The CLI supports UNIX and some Windows functionality.

In the evaluated configuration, Nessus is configured such that it is used only via the SC3. As such, SC3 utilizes the
Nessus CLI and references to the administrator, above, apply to the SC3 administrator and not a Nessus-specific
role. While Nessus could be configured for multiple means of user authentication, the evaluated configuration
includes only the use of passwords for authentication. This account information is configured within the SC3 for the
purpose of interacting with the Nessus component(s).

2.2 TOE Architecture
This section describes the TOE physical and logical boundaries.
2.2.1 TOE Physical Boundaries
The TOE physical boundary includes the following components:

Security Target Version 1.0, 01/15/10


14

• SC3 – Tenable Security Center 3.2
• 3DT – 3D Tool 1.2
• LCE – Log Correlation Engine 2.0.2
• PVS – Passive Vulnerability Scanner 3.0
• Nessus – Nessus Scanner 3.0.4

Each bulleted item is licensed separately. The following sub-sections describe the platforms supported for each of
the TOE components. These platforms are part of the TOE environment, not part of the TOE. Each system must be
dedicated to the appropriate Tenable applications (Security Center, Nessus, LCE or PVS) and contain no other
applications except what is required to operate the system in a secure manner. Tenable applications can co-exist on
the same host.
2.2.1.1 SC3
SC3 consists of the Tenable Security Center 3.2 software component.

SC3 is supported on the following platforms: Red Hat Enterprise Server 3 and Enterprise Server 4. It must be
configured with a Fully Qualified Domain Name (FQDN).
SC3 installation requirements:
Scenar io

Recommended Har dwar e

SC3 and Nessus Scanner 3.0
managing 500 to 2,500 active IPs

Single P4 3 GHz CPU, 1 GB memory, 40 GB hard drive

SC3 managing 2,500 to 10,000 active
Ips

Single P4 3 GHz CPU, 2 GB memory, 60 GB hard drive

SC3 ma
naging more than 10,000 IPs

Single P4 3 GHz CPU, 4 GB memory, 80 GB hard drive

2.2.1.2 3DT
3DT consists of the Tenable 3D Tool 1.2 software component.
3DT supported platforms: Windows XP Professional with Service Pack 3.
2.2.1.3 PVS
PVS is the Tenable Passive Vulnerability Scanner 3.0 software component, which can be installed on Windows
Server 2003 SP2, Windows XP Professional SP3, Red Hat Linux ES3 and ES4. It can be deployed on existing
network IDS devices, firewalls, e-mail servers, Dynamic Host Configuration Protocol (DHCP) servers, etc. without
effecting the underlying system’s operation. It can also be deployed as a stand-alone device for dedicated
monitoring.
PVS hardware guidelines are depicted in the following table:
Networ k Pr ofile

Requir ed Har dwar e

Less tha
n 50 Mb/s

P3 1 GHz CPU

50 Mb/s to 100 Mb/s

P3/P4 1.5 GHz

More than 100 Mb/s

P4 2.0 GHz

Less than 10,000 hosts

512 MB memory

10,000 to 25,000 hosts

1 GB memory

More than 25, 000 hosts

2 GB memory


2.2.1.4 LCE
LCE consists of the Tenable Log Correlation Engine 2.0 software component. It is supported on the following
platforms: Red Hat Linux Enterprise Server 3 and Enterprise Server 4.
Security Target Version 1.0, 01/15/10


15

2.2.1.5 Nessus
Nessus server includes the Nessus Scanner 3.0 software component. It is supported on the following Windows,
Unix, and Unix-like systems:
• Windows: Windows Server 2003 SP2, Windows XP Professional SP3 and Windows Server 2000 SP4.
• Unix: FreeBSD 5 and 6
• Unix-like: Red Hat Linux Enterprise Server 3 and Enterprise Server 4; Debian Linux 3; SuSE 9 and 10; Solaris
10 Sparc; and Mac OS X 10.4
2.2.2 TOE Logical Boundaries
This section identifies the security functions that the Tenable TOE provides
.
The following features are not included in the TOE evaluated configuration:
• The evaluated configuration requires at least one instance of each identified TOE component.
• Use of Nessus, PVS, or LCE components directly rather than via the SC3 interfaces is excluded from the
evaluated configuration.
• Use of third party authentication servers, such as LDAP, is not allowed in the evaluated configuration.
• Exporting data (from any TOE component) via SYSLOG outside the TOE is not allowed in the evaluated
configuration.
• The LCE clients that operate within non-TOE components have not been subject to the evaluation.
However, while their impact on their respective hosts is uncertain, they cannot impact the security claims
in this ST and as such are not forbidden in the evaluated configuration.
• The PVS ability to interfere with network traffic has not been subject to the evaluation. Note that while this
function simply has not been subject to specific evaluation claims, it does not interfere with the security of
the TOE or its claimed functions and therefore can be used in the evaluated configuration. This function
simply has been evaluated only to the extent that it doesn’t interfere with other functions and not relative to
explicit security claims of its own.
2.2.2.1 Security Audit
The TOE generates audit events for the basic level of audit. (Note that the IDS_SDC.1 (EXP) and IDS_ANL.1
(EXP) requirements address a different audit mechanism that records the results from IDS scanning, sensing, and
analyzing tasks. This is not that mechanism.) The TOE provides a SC3 GUI that is used by authorized system
administrators to read the audit trail, and to sort audit data. The TOE audit events can be included in or excluded
from reports based on event type. The TOE restricts access to the audit trail to authorized system administrators.
The events that are audited are fixed and no event can be masked so that it is not entered into the audit trail.
The TOE administrator guidance advises the systems administrator how to configure and manage the TOE security
audit storage so that storage exhaustion is prevented. If audit trail storage becomes exhausted, the TOE will
overwrite the oldest record and send an alarm.
2.2.2.2 Identification and Authentication
TOE users are required to login with a unique name and password in order to access the TOE. Only systems
administrators have access to security management functions. The TOE maintains user identities, authentication
data, authorization information and role association. The SC3 provides a web-based logon and users must be
successfully identified and authenticated prior to accessing the reports.
Security Target Version 1.0, 01/15/10


16

2.2.2.3 Security Management
The Security Center restricts the ability to manage functions based on the user role. The roles supported by the
Security Center are Security Center Administrator (SCA), Primary Security Manager (PSM), Security Manager
(SM) and End User (EU), (which collectively conform to the IDSSYPP Authorized Systems Administrator role). A
Systems Administrator (which conforms to the IDSSYPP Authorized Administrator role) manages the environment.
It is up to the TOE user organization to appropriately assign people to roles.
Small organizations may assign all roles to the same person. Larger organizations may assign roles based on their
organizational structure. For example, a large organization might give responsibility for all Security Center
Administration functions and any activity that requires administrative (privileged) access to the Operating System to
the Information Technology group, responsibility for enterprise management of security functions throughout the
business units, including the performance of all Security Center administration tasks to the Information Security
group. If the business unit is a Primary Security Manager or Customer, an Information Security Officer in the
business unit may be responsible for all security functions within that unit and would serve as the Security Manager
for that business unit. A large organization might have multiple Primary Security Managers.
Within the business units End Users may be designated. These End Users are managed by the unit’s Security
Manager and are responsible for a particular network segment.
User access is restricted by the role to which the user is assigned and the assets to which the user has been granted
access. The role indicates what functionality (i.e., which menu options) the TOE presents to each user. The assets
are the machines for which the user can launch IDS scans and access IDS audit records. The SC3 component
provides the tools necessary to define users and configure access. SC3 stores each customer’s data in a separate
directory so access is enforced by separating user data into separate directories. The underlying operating system
limits access to the tenable user but the SC3 product actually performs access control on its users.
A description of the roles supported by the Security Center follows:
Secur i
ty Center Administr ator (SCA)

The Security Center Administrator role is able to configure and manage the Security Center application. No access
to the underlying operating system platform is required. All functions can be performed through the Security Center
GUI. The Security Center Administrator defines and manages customers, specifying which network ranges within
which network traffic may be monitored for each customer. Each customer has a unique name and serial number.
There are three Customer roles: the Primary Security Manager, Security Manager and End User.
The Security Center Administrator’s role includes performing the following functions:
• Manage the Security Center
• Managing Security Center Customer Accounts
• Managing Security Center Components
• Monitoring Security Center Audit Logs
The Security Center Administrator (SCA) cannot access customer data nor initiate IDS scans.
Pr imar y Secur ity Manager (PSM)

The Primary Security Manager has full rights for the entire network space of a customer and cannot be deleted
without removing the entire customer entry. The Primary Security Manager may define additional users for the
address space as either Security Managers or End Users. The Primary Security Manager is typically the security
representative for the customer organization and is responsible for its overall security posture.
A Primary Security Manager (PSM) can access only one customer’s data and can initiate IDS scans on only one
customer’s network.
Secur ity Manager (SM)

The Security Manager has the same rights as the Primary Security Manager. There can be many Security Managers
for a customer, but only one Primary Security Manager.
A Security Manager (SM) can access only one customer’s data and can initiate IDS scans for only one customer.
Security Target Version 1.0, 01/15/10


17

The term “(Primary) Security Manager” is used to refer to both the Primary Security Manager and Security Manager
roles.
End User (EU)

The End User is typically a system or network engineer who has responsibility for running a network. The Security
Manager and End User roles are limited in several ways:
• Each can only see vulnerabilities, IDS events, and logs for a specific range of IP addresses, determined by
the particular asset lists a user has access to.
• Security Managers can add, edit, and delete new users, which may be either security managers or end users.
• Each type of user may be able to conduct vulnerability scanning of their networks, but both types of
accounts can also be “locked out” from scanning either manually or when the threshold for failed login
attempts is reached.
• Security Managers can open tickets for which vulnerabilities need to be mitigated and end users can close
tickets by marking them as fixed. Opening and closing tickets is not a security function.
An End User (EU) can initiate IDS scans on only a part of one customer’s network and can access only the data
relevant to that part of the one customer’s network.
System Administr ator (Envir onmental Role)

The System Administrator manages the TOE environment and is the person responsible for installing and
maintaining the platform Operating System on which the Security Center runs. The Systems Administrator has
administrative (“root”) access to the underlying operating system, but does not have access to any Security Center
user accounts. System Administrator is not a TOE role, but because the System Administrator has root access to the
operating system, that role is capable of accessing and changing anything in the TOE, including audit data. This
role includes all standard System Administration duties, such as the following:
• Operating System Installation
• System Security Hardening
• System Configuration
• Installation of Supporting Applications
• Managing User Access to the OS platform
• Installation of the Security Center Software
• Installation of the Security Center Components (Nessus, PVS, LCE, etc)
• Installation of Client Applications
• OS System Monitoring
• Security Administration of the System
• System Backups
• Generate SSH keys on remote hosts for credential scans

The following table summarizes the TOE roles and the security functions they can perform. The Authorized
Administrator and Authorized System Administrator roles are required by the IDSSYPP.

Security Function

Authorized

Authorized

Customer Accounts

Security Target Version 1.0, 01/15/10


18

Administrator
4

System

Administrator
5

(
Primary)

Security
Manager
End
User
Install and configure SC3
1


X




Manage customer accounts
2


X



Manage user accounts
2



X


Manage SC3 components
2


X



Monitor SC3 logs
3



X

X

Manage audit functions
2


X



Monitor audit data
3


X

X


1
Maps to the IDSSYPP “Query and modify all other TOE data” function.

2
Maps to the IDSSYPP “Modify Behavior of system data collection, analysis, and reaction” function.
3
Maps to the IDSSYPP “Query and add system and audit data” function.
4
This role is required by the
IDSSYPP to administer the platforms that support the TOE. It is a role supported
by the environment here.
5
This role is required by the IDSSYPP to administer the IDS. It is equivalent to the SC3 “Security Center
Administrator” role.

2.2.2.4 Protection of the TSF
The TOE protects itself and ensures that its policies are enforced in a number of ways. While there is dependence on
the underlying operating system to separate its process constructs, enforce file access restrictions, and to provide
communication services, the TOE protects itself by keeping its context separate from that of its users and also by
making effective use of the operating system mechanisms to ensure that memory and files used by the TOE have the
appropriate access settings. Furthermore, the TOE interacts with users through well-defined interfaces designed to
ensure that its security policies are always enforced.
2.2.2.5 Intrusion Detection System
The TOE collects network traffic data for use in scanning, sensing and analyzing functions with the SC3. The TOE
performs signature analysis on collected network traffic data and records corresponding network traffic event data.
Reports are generated using a web-based interface to LCE that provides the ability to examine analytical conclusions
drawn by the TOE that describe the conclusion and identifies the information used to reach the conclusion. Note
that users can only access reports via a web browser where access to TOE data is based on identification and
authentication. The TOE provides the ability to generate alarms and notify an systems administrator using a
configured notification mechanism when an intrusion is detected.
2.3 TOE Environment
The TOE relies on the environment to provide the following security functionality:
2.3.1 Protection of TOE communication
The environment must protect the communication among TOE components. The TOE is shipped with an
implementation of OpenSSLv 0.9.8g. For most communication paths, the TOE should be configured to use the SSL
protections provided in OpenSSL to protect network traffic between TOE components from disclosure and
modification. The one exception is that communication between the SC3 and the LCE is performed using SSH. The
SSH encryption is also supported using the OpenSSL module.
Security Target Version 1.0, 01/15/10


19

2.3.2 Non-bypassability of the TSP
The TOE should be deployed on a network in such a way that it can monitor all potentially malicious traffic,
including any network traffic used to administer the TOE itself. It should ensure that no traffic can circumvent the
TOE’s monitoring functions and thus escape being monitored for malicious content.
2.3.3 Domain Separation
The TOE components run as separate processes in one or more operating systems. However, this separation is not
used to separate users with different access rights. Users of the TOE are not provided access to operating system
shells nor are they able to run arbitrary programs on the operating system as a result of their TOE access. The TOE
controls user access through the functionality provided on its user interfaces.
2.3.4 Reliable Time Stamps
The TOE environment provides a source of reliable time stamps, which the TOE uses in its audit function. The
system administrator needs to be aware that a network time protocol should be used to ensure consistent time across
the different components and associated events.
2.3.5 Trusted Path
The TOE environment supports HTTPS sessions for remote users that protect user authentication and other
information from disclosure.

2.4 TOE Documentation
Tenable offers a series of documents that describe the installation process for the TOE as well as guidance for
subsequent use and administration of the applicable security features. Refer to section 5.2 for information about
these and other documentation associated with the TOE.
Security Target Version 1.0, 01/15/10


20

3. Security Environment
This section summarizes the threats addressed by the TOE (often with help from its environment) and assumptions
about the intended environment of the TOE. Note that while the identified threats are mitigated by the security
functions implemented in the TOE, the overall assurance level (EAL2 augmented with ALC_FLR.3 and
AVA_MSU.1) also serves as an indicator of whether the TOE would be suitable for a given environment.
3.1 Threats
The following are threats identified for the TOE and the IT System the TOE monitors. The TOE itself has threats
and the TOE is also responsible for addressing threats to the environment in which it resides. The assumed level of
expertise of the attacker for all the threats is unsophisticated.
3.1.1 TOE Threats
T.COMINT An unauthorized user may attempt to compromise the integrity of the data collected and produced
by the TOE by bypassing a security mechanism.
T.COMDIS An unauthorized user may attempt to disclose the data collected and produced by the TOE by
bypassing a security mechanism.
T.LOSSOF An unauthorized user may attempt to remove or destroy data collected and produced by the TOE.
T.NOHALT An unauthorized user may attempt to compromise the continuity of the System’s collection and
analysis functions by halting execution of the TOE.
T.PRIVIL An unauthorized user may gain access to the TOE and exploit system privileges to gain access to
TOE security functions and data
T.IMPCON An unauthorized user may inappropriately change the configuration of the TOE causing potential
intrusions to go undetected.
T.INFLUX An unauthorized user may cause malfunction of the TOE by creating an influx of data that the
TOE cannot handle.
T.FACCNT Unauthorized attempts to access TOE data or security functions may go undetected.
3.1.2 IT System Threats
The following identifies threats to the IT System that may be indicative of vulnerabilities in or misuse of IT
resources.
T.SCNCFG Improper security configuration settings may exist in the IT System the TOE monitors.
T.SCNMLC Users could execute malicious code on an IT System that the TOE monitors which causes
modification of the IT System protected data or undermines the IT System security functions.
T.SCNVUL Vulnerabilities may exist in the IT System the TOE monitors.
T.FALACT The TOE may fail to react to identified or suspected vulnerabilities or inappropriate activity.
T.FALREC The TOE may fail to recognize vulnerabilities or inappropriate activity based on IDS data received
from each data source.
T.FALASC The TOE may fail to identify vulnerabilities or inappropriate activity based on association of IDS
data received from all data sources.
T.MISUSE Unauthorized accesses and activity indicative of misuse may occur on an IT System the TOE
monitors.
T.INADVE Inadvertent activity and access may occur on an IT System the TOE monitors.
Security Target Version 1.0, 01/15/10


21

T.MISACT Malicious activity, such as introductions of Trojan horses and viruses, may occur on an IT System
the TOE monitors.

3.2 Organizational Security Policies
An organizational security policy is a set of rules, practices, and procedures imposed by an organization to address
its security needs. This section identifies the organizational security policies applicable to the Intrusion Detection
System System Protection Profile.
P.DETECT Static configuration information that might be indicative of the potential for a future intrusion or
the occurrence of a past intrusion of an IT System or events that are indicative of inappropriate
activity that may have resulted from misuse, access, or malicious activity of IT System assets must
be collected.
P.ANALYZ Analytical processes and information to derive conclusions about intrusions (past, present, or
future) must be applied to IDS data and appropriate response actions taken.
P.MANAGE The TOE shall only be managed by authorized users.
P.ACCESS All data collected and produced by the TOE shall only be used for authorized purposes.
P.ACCACT Users of the TOE shall be accountable for their actions within the IDS.
P.INTGTY Data collected and produced by the TOE shall be protected from modification.
P. PROTCT The TOE shall be protected from unauthorized accesses and disruptions of TOE data and
functions.
3.3 Secure Usage Assumptions
3.3.1 Intended Usage Assumptions
A.ACCESS The TOE has access to all the IT System data it needs to perform its functions.
A.ASCOPE The TOE is appropriately scalable to the IT System the TOE monitors.
A.DYNMIC The TOE will be managed in a manner that allows it to appropriately address changes in the IT
System the TOE monitors.
A.WKSTN All desktop systems used to access security center data (either through the web GUI or through 3D
Tool) must be secured, patched and have the latest anti-virus software installed.
A.OS The operating system for each component, Security Center, Nessus, LCE, and PVS, must be
dedicated to the associated application and configured in a secure manner to ensure the security
controls cannot be bypassed.
3.3.2 Physical Assumptions
A.LOCATE The processing resources of the TOE will be located within controlled access facilities, which will
prevent unauthorized physical access.
A.PROTCT The TOE hardware and software critical to security policy enforcement will be protected from
unauthorized physical modification.
3.3.3 Personnel Assumptions
A.MANAGE There will be one or more competent individuals assigned to manage the TOE and its environment
and the security of the information it contains.
Security Target Version 1.0, 01/15/10


22

A.NOEVIL The authorized administrators are not willfully negligent, or hostile, and will follow and abide by
the instructions provided by the TOE documentation and that of its environment.
A.NOTRST The TOE can only be accessed by authorized users.
Security Target Version 1.0, 01/15/10


23


4. Security Objectives
This section summarizes the security objectives for the TOE and its environment.
4.1 Security Objectives for the TOE
O.PROTCT The TOE must protect itself from unauthorized modifications and access to its functions and data.
O.IDSCAN The Scanner must collect and store static configuration information that might be indicative of the
potential for a future intrusion or the occurrence of a past intrusion of an IT System.
O.IDSENS The Sensor must collect and store information about all events that are indicative of inappropriate
activity that may have resulted from misuse, access, or malicious activity of IT System assets and
the IDS.
O.IDANLZ The Analyzer must accept data from IDS Sensors or IDS Scanners and then apply analytical
processes and information to derive conclusions about intrusions (past, present, or future).
O.RESPON The TOE must respond appropriately to analytical conclusions.
O.EADMIN The TOE must include a set of functions that allow effective management of its functions and
data.
O.ACCESS The TOE must allow authorized users to access only appropriate TOE functions and data.
O.IDAUTH The TOE must be able to identify and authenticate users prior to allowing access to TOE functions
and data.
O.OFLOWS The TOE must appropriately handle potential audit and System data storage overflows.
O.AUDITS The TOE must record audit records for data accesses and use of the System functions.
O.INTEGR The TOE must ensure the integrity of all audit and System data.
4.2 Security Objectives for the Environment
OE.INSTAL Those responsible for the TOE must ensure that the TOE is delivered, installed, managed, and
operated in a manner which is consistent with IT security.
OE.PHYCAL Those responsible for the TOE must ensure that those parts of the TOE and its environment
critical to security policy are protected from any physical attack.
OE.CREDEN Those responsible for the TOE must ensure that all access credentials are protected by the users
in a manner that is consistent with IT security.
OE.TIME The IT Environment will provide reliable timestamps to the TOE.
OE.PROTECT The IT Environment will protect itself and the TOE from external interference or tampering.
OE.INTROP The monitored IT System is interoperable with the TOE.
OE.PERSON Personnel working as authorized administrators shall be carefully selected and trained for proper
operation of the TOE and its environment.
OE.AUDIT_PROTECTION The IT Environment will provide the capability to protect audit information.

OE.SYSTEM_PROTECTION The IT Environment will provide the capability to protect System (i.e., IDS)
information.

Security Target Version 1.0, 01/15/10


24

OE.WKSTN_PROT Those responsible for the administrative destops will ensure they are secured,
patched and have the latest anti-virus software installed.
OE.DEDICATED The operating systems for the TOE components will be dedicated to the
associated TOE component.

Security Target Version 1.0, 01/15/10


25

5. IT Security Requirements
This section defines the Security Functional Requirements (SFRs) and Security Assurance Requirements (SARs) for
the TOE and associated environment components.

The TOE also satisfies a minimum strength of function: ‘SOF-basic’. The only applicable (i.e., probabilistic or
permutational) security functions are FIA_UAU.2, which is levied on the TOE.

5.1 TOE Security Functional Requirements
The following table identifies the SFRs that are candidates to be satisfied by the TOE. These are conformant to the
IDSSYPP:


Requirement Class

Requirement Component

FAU: Security Audit

FAU_GEN.1: Audit data gener
ation

FAU_SAR.1: Audit review

FAU_SAR.2: Restricted audit review

FAU_SAR.3: Selectable audit review

FAU_SEL.1: Selective audit

FAU_STG.2a
: Guarantees of audit data availability

FAU_STG.4: Prevention of audit data loss

FIA: Identificatio
n and
Authentication
FIA_AFL.1: Authentication failure handling

FIA_ATD.1: User attribute definition

FIA_UAU.2: User authentication before any action

FIA_UID.2: User identification before any action

FMT: Security Management

FMT_MOF.1: Management

of security functions behavior

FMT_MTD.1: Management of TSF data

FMT_SMF.1: Specification of management functions

FMT_SMR.1: Security roles

FPT: Protection of the TSF

FPT_ITT.1: Basic internal TSF data protection

FPT_RVM.1a: Non
-
bypassability
of the TSP

FPT_SEP.1a: TSF domain separation

IDS: Intrusion Detection
System
IDS_ANL.1 (EXP): Analyzer analysis

IDS_RCT.1 (EXP): Analyzer react

IDS_RDR.1 (EXP): Restricted data review

IDS_SDC.1 (EXP): System data collection

IDS_STG.1a

(EXP):

Guarantee of system data availability

IDS_STG.2 (EXP): Prevention of system data loss


Table 1 TOE Security Functional Components

5.1.1 FAU - Security Audit

FAU_GEN.1 - Audit Data Generation

FAU_GEN.1.1 The TSF shall be able to generate an audit record of the following auditable events: a) Start-up and
shutdown of the audit functions; b) All auditable events for the [basic] level of audit; and c)
[Access to the System and access to the TOE and System data].
Security Target Version 1.0, 01/15/10


26

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, [the additional information specified in the Details column of Table 2
Auditable Events].

Component
Event
Details
FAU_GEN.1

Start
-
up and shutdown of audit functions


FAU_GEN.1

Access to System


FAU_GEN.1 Access to the TOE and System data
Object IDS, requested
access
FAU_SAR.1

Reading of information from the audit records


FAU_SAR.2
Unsuccessful attempts to read information from the audit
records


FAU_SEL.1
All modifications to the audit configura
tion that occur while
the audit collection functions are operating

FIA_UAU.2

All use of the authentication mechanism

User identity, location

FIA_UID.2

All use of the user identification mechanism

User identity, location

FMT_MOF.1

All modifications in t
he behavior of the functions of the TSF


FMT_MDT.1

All modifications to the values of TSF data


FMT_SMR.1

Modifications to the group of users that are part of a role

User identity


Figur e
2
: Auditable Events



FAU_SAR.1 - Audit Review

FAU_SAR.1.1 The TSF shall provide [authorized systems administrator] 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.2 - Restricted Audit Review

FAU_SAR.2.1 The TSF shall prohibit all users read access to the audit records, except those users that have been
granted explicit read-access.

FAU_SAR.3 - Selectable Audit Review

FAU_SAR.3.1 The TSF shall provide the ability to perform [sorting] of audit data based on [date and time,
subject identity, type of event, and success or failure of related event].

FAU_SEL.1 - Selective Audit

FAU_SEL.1.1 The TSF shall be able to include or exclude auditable events from the set of audited events based
on the following attributes: a) [event type] b) [no additional attributes].

FAU_STG.2a - Guarantees of Audit Data Availability

FAU_STG.2a.1 The TSF shall protect the stored audit records from unauthorized deletion.
FAU_STG.2a.2 The TSF shall be able to [detect] modifications to the audit records.
FAU_STG.2a.3 The TSF shall ensure that [the most recent, limited by available System data storage] audit
records will be maintained when the following conditions occur: [audit storage exhaustion].

Security Target Version 1.0, 01/15/10


27

FAU_STG.4 - Prevention of Audit Data Loss

FAU_STG.4.1 The TSF shall [overwrite the oldest stored audit records] and [send an alarm] if the audit trail is
full.
5.1.2 FIA - Identification and Authentication

FIA_AFL.1 - Authentication Failure Handling

FIA_AFL.1.1 The TSF shall detect when [a settable, non-zero number] of unsuccessful authentication attempts
occur related to [external IT products attempting to authenticate].
FIA_AFL.1.2 When the defined number of unsuccessful authentication attempts has been met or surpassed, the
TSF shall [prevent the offending external IT product from successfully authenticating until an
authorized administrator takes some action to make authentication possible for the external IT
product in question].

FIA_ATD.1 - User Attribute Definition

FIA_ATD.1.1 The TSF shall maintain the following list of security attributes belonging to individual users: [a)
User identity b) Authentication data c) Authorizations; and d) [Roles.]].

FIA_UAU.2 – User Authentication before any Action

FIA_UAU.2.1 The TSF shall require each user to be successfully authenticated before allowing any other TSF-
mediated actions on behalf of that user.

FIA_UID.2 – User Identification before any Action

FIA_UID.2.1 The TSF shall require each user to be successfully identified before allowing any other TSF-
mediated actions on behalf of that user.

5.1.3 FMT - Security Management

FMT_MOF.1 - Management of Security Functions Behavior

FMT_MOF.1.1 The TSF shall restrict the ability to [modify the behavior of] the functions of System data
collection, analysis and reaction to [authorized System administrators].

FMT_MTD.1 - Management of TSF Data

FMT_MTD.1.1 The TSF shall restrict the ability to [query and add] [System and audit data], and shall restrict the
ability to [query and modify] [all other TOE data] to [authorized System administrators (to
query and add system and audit data) and the authorized administrators (to query and
modify all other TOE data)].

FMT_SMF.1 Specification of Management Functions
FMT_SMF.1.1 The TSF shall be capable of performing the following security management functions:
[Management of Analyzer data, Management of Audit functions, Management of user
accounts].

FMT_SMR.1 - Security Roles

Security Target Version 1.0, 01/15/10


28

FMT_SMR.1.1 The TSF shall maintain the following roles: authorized administrator, authorized System
administrators, and [no other roles].
FMT_SMR.1.2 The TSF shall be able to associate users with roles.

Application Note: The roles in this requirement are copied from directly from the pp. The TOE realizes these roles
in the following manner. The Authorized Administrator role is a TOE environmental role and is realized by the
Systems Administrator role in the TOE. The Authorized System Administrator role is realized by four roles in the
TOE. Those roles are: Security Center Administrator, Primary Security Manager, Security Manager, and End
User. More information is provided in Section 6.1.3.
5.1.4 FPT – Protection of the TSF

FPT_ITT.1 Basic internal TSF data transfer protection

FPT_ITT.1.1 The TSF shall protect TSF data from [disclosure and modification] when it is transmitted
between separate parts of the TOE.

FPT_RVM.1a - Non-bypassability of the TSP

FPT_RVM.1a.1 The TSF shall ensure that TSP enforcement functions are invoked and succeed before each
function within the TSC is allowed to proceed.

FPT_SEP.1a - TSF domain separation

FPT_SEP.1a.1 The TSF shall maintain a security domain for its own execution that protects it from interference
and tampering by untrusted subjects.
FPT_SEP.1a.2 The TSF shall enforce separation between the security domains of subjects in the TSC.

5.1.5 IDS – Intrusion Detection System

IDS_ANL.1 (EXP) - Analyzer analysis

IDS_ANL.1.1 The System shall perform the following analysis function(s) on all IDS data received: [signature,
statistical, integrity]; and [no other analytical functions]. (EXP)
IDS_ANL.1.2 The System shall record within each analytical result at least the following information: a. Date
and time of the result, type of result, identification of data source; and b. [location and
description]. (EXP)

Application Note: Statistical analysis involves identifying deviations from normal patterns of behavior. For
example, it may involve mean frequencies and measures of variability to identify abnormal usage. Signature
analysis involves the use of patterns corresponding to known attacks or misuses of a System. For example, patterns
of System settings and user activity can be compared against a database of known attacks. Integrity analysis