Symantec Data Loss Prevention (DLP)
25.1
Security Target
Evaluation Assurance Level (EAL): EAL2+
Document Version: 2.3
Symantec Data Loss Prevention 25.1 Security Target
2
Copyright © 2025 Broadcom. All Rights Reserved. The term “Broadcom” refers to Broadcom Inc. and/or
its subsidiaries. For more information, go to www.broadcom.com. All trademarks, trade names, service
marks, and logos referenced herein belong to their respective companies.
Broadcom reserves the right to make changes without further notice to any products or data herein to
improve reliability, function, or design. Information furnished by Broadcom is believed to be accurate
and reliable. However, Broadcom does not assume any liability arising out of the application or use of
this information, nor the application or use of any product or circuit described herein, neither does it
convey any license under its patent rights nor the rights of others
Symantec Data Loss Prevention 25.1 Security Target
3
Table of Contents
1 INTRODUCTION............................................................................................................ 6
1.1 Security Target and TOE Reference................................................................................................................. 6
1.2 TOE Overview .................................................................................................................................................. 6
1.2.1 Enforce Server............................................................................................................................................. 7
1.2.2 Detection Server ......................................................................................................................................... 7
1.2.3 DLP Agent.................................................................................................................................................... 7
1.3 TOE DESCRIPTION............................................................................................................................................ 8
1.3.1 Physical Scope............................................................................................................................................. 8
1.3.2 TOE Environment ...................................................................................................................................... 10
1.3.3 Logical Scope............................................................................................................................................. 11
1.3.4 Functionality Excluded from the Evaluated Configuration ....................................................................... 12
2 CONFORMANCE CLAIMS ............................................................................................ 13
2.1 Common Criteria Conformance Claim........................................................................................................... 13
2.2 Assurance Package Claim .............................................................................................................................. 13
2.3 Protection Profile Conformance Claim.......................................................................................................... 13
3 SECURITY PROBLEM DEFINITION................................................................................ 14
3.1 Threats........................................................................................................................................................... 14
3.2 Organizational Security Policies..................................................................................................................... 14
3.3 Assumptions .................................................................................................................................................. 15
4 SECURITY OBJECTIVES................................................................................................ 16
4.1 Security Objectives for the TOE..................................................................................................................... 16
4.2 Security Objectives for the Operational Environment .................................................................................. 16
4.3 Security Objectives Rationale........................................................................................................................ 17
4.3.1 Security Objectives Rationale Related to Threats..................................................................................... 17
4.3.2 Security Objectives Rationale Related to OSPs ......................................................................................... 19
4.3.3 Security Objectives Rationale Related to Assumptions ............................................................................ 20
5 EXTENDED COMPONENTS DEFINITION....................................................................... 22
5.1 Security Functional Requirements................................................................................................................. 22
5.1.1 Class FPT: PROTECTION OF THE TSF.......................................................................................................... 22
5.2 Security Assurance Requirements................................................................................................................. 23
6 SECURITY REQUIREMENTS ......................................................................................... 24
6.1 Conventions................................................................................................................................................... 24
6.2 TOE Security Functional Requirements ......................................................................................................... 24
6.2.1 Security Audit (FAU).................................................................................................................................. 25
6.2.2 User Data Protection (FDP) ....................................................................................................................... 25
6.2.3 Identification and Authentication (FIA)..................................................................................................... 26
6.2.4 Security Management (FMT) .................................................................................................................... 27
6.2.5 Protection of the TSF (FPT)........................................................................................................................ 28
6.2.6 Trusted Path/Channels (FTP)..................................................................................................................... 29
6.3 Security Functional Requirements Rationale ................................................................................................ 30
6.3.1 SFR Rationale Related to Security Objectives ........................................................................................... 30
6.4 Dependency Rationale................................................................................................................................... 32
6.5 TOE Security Assurance Requirements.......................................................................................................... 33
7 TOE SUMMARY SPECIFICATION.................................................................................. 35
7.1 TOE Security Functions.................................................................................................................................. 35
7.1.1 Security Audit............................................................................................................................................ 35
Symantec Data Loss Prevention 25.1 Security Target
4
7.1.2 User Data Protection................................................................................................................................. 35
7.1.3 Identification and Authentication............................................................................................................. 36
7.1.4 Security Management............................................................................................................................... 37
7.1.5 Protection of the TSF................................................................................................................................. 37
7.1.6 Trusted Path/Channels.............................................................................................................................. 38
8 TERMINOLOGY AND ACRONYMS ............................................................................... 39
8.1 Terminology................................................................................................................................................... 39
8.2 Acronyms....................................................................................................................................................... 39
Symantec Data Loss Prevention 25.1 Security Target
5
List of Tables
Table 1 – TOE/ST Identification .....................................................................................................................................6
Table 2 – TOE Supporting Hardware and Software.....................................................................................................10
Table 3 – Operational Environment Supporting Hardware and Software...................................................................10
Table 4 – Logical Scope of the TOE..............................................................................................................................11
Table 5 – Threats .........................................................................................................................................................14
Table 6 – Organizational Security Policy......................................................................................................................15
Table 7 – Assumptions.................................................................................................................................................15
Table 8 – Security Objectives for the TOE ...................................................................................................................16
Table 9 – Security Objectives for the Operational Environment.................................................................................16
Table 10 – Mapping Between Objectives, Threats, OSPs, and Assumptions...............................................................17
Table 11 – Summary of Security Functional Requirements.........................................................................................24
Table 12 – Mapping of SFRs to Security Objectives.....................................................................................................30
Table 13 – Functional Requirement Dependencies.....................................................................................................32
Table 14 – Security Assurance Requirements..............................................................................................................34
Table 15 – Terminology ...............................................................................................................................................39
Table 16 – Acronyms ...................................................................................................................................................39
List of Figures
Figure 1 – TOE Boundary ...............................................................................................................................................9
Figure 2 – FPT_MIS_EXT: Monitoring of Installed Software Component Levelling.....................................................22
Symantec Data Loss Prevention 25.1 Security Target
6
1 Introduction
The Security Target (ST) serves as the basis for the Common Criteria (CC) evaluation and identifies the
Target of Evaluation (TOE), the scope of the evaluation, and the assumptions made throughout. This
document will also describe the intended operational environment of the TOE, and the functional and
assurance requirements that the TOE meets.
1.1 Security Target and TOE Reference
This section provides the information needed to identify and control the TOE and the ST.
Table 1 – TOE/ST Identification
Category Identifier
ST Title Symantec Data Loss Prevention (DLP) 25.1 Security Target
ST Version 2.3
ST Date 26-Nov-2025
ST Author Symantec Corporation, A Division of Broadcom
TOE Identifier Symantec Data Loss Prevention (DLP)
TOE Version Server: 25.1.00000.60229 (This includes all the Server side TOE components – Enforce,
Detection Servers)
Agent: 25.1.00000.60234
TOE Developer Symantec Corporation, A Division of Broadcom
Key Words Data, Loss, Protection, Prevention
1.2 TOE Overview
Symantec Data Loss Prevention (DLP) is used by organizations to safeguard sensitive data such as
company information, customer data, and intellectual property. Sensitive data may include credit card
numbers, names, addresses, identification numbers, social security numbers, financial data, blueprints,
medical records, or any data a company deems proprietary. Symantec DLP enables an organization to:
● Discover and locate confidential information in repositories, on file and web servers, in
databases, and on endpoints (desktop and laptop systems)
● Protect confidential information through quarantine
● Monitor network traffic for transmission of confidential data
● Monitor the use of sensitive data on endpoints
● Prevent transmission of confidential data to outside locations
● Automatically enforce data security and encryption policies
The central component for a DLP implementation is the DLP Enforce Server, which provides a
management interface for defining the policies that are enforced throughout the network. The Enforce
Server works with one or more Detection servers to protect data and report on violations (called
incidents). Detection servers may be deployed on a single server or in a distributed architecture,
depending upon the organization’s network requirements. The following paragraphs describe the DLP
components subject to this evaluation.
Symantec Data Loss Prevention 25.1 Security Target
7
1.2.1 Enforce Server
The Symantec Data Loss Prevention Enforce Server is the central management platform that enables
you to define, deploy, and enforce data loss prevention and security policies. The Enforce Server
administration console provides a centralized, web-based interface for managing the lifecycle of
Detection servers, authoring policies, remediating incidents, and managing the DLP infrastructure.
1.2.2 Detection Server
The Detection Server hosts the different discovery and detection capabilities described below in
sections 1.2.2.1 to 1.2.2.5.
1.2.2.1 Endpoint Discover and Endpoint Prevent
The Endpoint Discover and Endpoint Prevent Detection server components work with DLP agents
installed on the endpoint desktops and networked laptops.
Endpoint Discover detects sensitive data on desktop and laptop endpoints. Endpoint Prevent then
monitors that sensitive data and detects when it is being copied or transferred from those devices to
removable storage and network shares. When a policy violation is detected, the transfer may be
blocked, or the user may be notified of the violation in a pop-up window.
1.2.2.2 Network Discover and Network Protect
Network Discover scans networked file shares, web content servers, databases, document repositories,
and endpoint systems at high speeds to detect exposed data and documents. Network Protect reduces
risk by removing exposed confidential data, intellectual property, and classified information from open
file shares on network servers or desktop computers.
1.2.2.3 Network Monitor
Network Monitor is placed on the network between an internal switch or router and an external switch
or router to capture and analyze the information that is being sent outside of the organization. It
detects data that has been identified as sensitive over the designated protocols.
1.2.2.4 Network Prevent for Email
Network Prevent for Email is integrated with the Mail Transfer Agent (MTA) to provide in-line
monitoring of Simple Mail Transfer Protocol (SMTP) mail. Email may be blocked in accordance with the
established security policies.
1.2.2.5 Network Prevent for Web
The Network Prevent for Web component is integrated with a web proxy server using Internet Content
Adaptation Protocol (ICAP). This allows the Network Prevent for Web component to detect confidential
data in HTTP, HTTPS or FTP content. Policies may be established to cause the proxy to reject requests or
remove the sensitive content.
1.2.3 DLP Agent
The DLP Agent stops sensitive data from moving off endpoints and supported virtual desktops. For
example, the DLP Agent can stop a file that contains credit card numbers from being transferred to
eSATA, USB, or FireWire-connected media. The DLP Agent stops sensitive files from being transferred to
Symantec Data Loss Prevention 25.1 Security Target
8
network shares. The DLP Agent also monitors and prevents data from being transferred to applications
that the DLP Administrator configures.
The TOE is a software only TOE.
1.3 TOE DESCRIPTION
1.3.1 Physical Scope
1.3.1.1 Hardware
This is a software only TOE. No hardware is included in the TOE Boundary.
1.3.1.2 Firmware
This is a software only TOE. No firmware is included in the TOE Boundary.
1.3.1.3 Guidance
The TOE guidance documentation, the Symantec Data Loss Prevention Help Center 25.1 is available as a
.pdf, dated August 18 2025. The TOE guidance can be accessed and downloaded as a PDF by accessing
the page here: https://techdocs.broadcom.com/us/en/symantec-security-software/information-
security/data-loss-prevention/25-1.html by clicking the button.
The Common Criteria Guidance Supplement is available as a .pdf and is versioned:
• Symantec™ Data Loss Prevention 25.1 Common Criteria Guidance Supplement, Evaluation
Assurance Level (EAL): EAL2+, Document Version 0.6
The Common Criteria Guidance Supplement is accessible on the “Related Documents” page:
https://techdocs.broadcom.com/us/en/symantec-security-software/information-security/data-loss-
prevention/25-1/related-documents.html
1.3.1.4 Software
The TOE consists of two (2) software packages: one that includes Enforce and the Detection server (2
variants for Windows and Linux), and one that includes the Agent. These may be installed in multiple
configurations and with various licensing options. The software packages can be downloaded from the
Broadcom Software downloads website: https://support.broadcom.com/group/ecx/downloads.
Customers must have an active entitlement to access the DLP downloads. The files are downloaded as
.zip files.
Note that all licensing options include the use of the Enforce Server 25.1.00000.60229 component. The
evaluated configuration of the TOE is Symantec DLP 25.1.00000.60229 installed in a two-tier
configuration with the following licenses:
● Endpoint Discover
● Endpoint Prevent
● Network Discover
● Network Protect
● Network Monitor
● Network Prevent for Email
● Network Prevent for Web
Symantec Data Loss Prevention 25.1 Security Target
9
The Symantec DLP Agent v25.1.00000.60234 component is made available through the licensing of the
Endpoint Discover and Endpoint Prevent components.
Figure 1 – TOE Boundary
Symantec Data Loss Prevention 25.1 Security Target
10
1.3.2 TOE Environment
The following operating system, hypervisor, hardware and networking components are required to
directly support the TOE components in the evaluated configuration.
Table 2 – TOE Supporting Hardware and Software
TOE Component Description Hypervisor Operating
System
(non-TOE)
Virtual Machine Specifications
(non-TOE)
Enforce Server
(25.1.00000.60229)
This is a virtual
machine
supporting the TOE
Enforce server
component
VMware ESXi
v8.0.3
Windows
Server
2019
Standard
Edition
Four-core CPU, 16 GB RAM, 200 GB
hard drive storage, One copper or
fiber 1 GB/100 MB Ethernet NIC to
communicate with detection
servers.
Symantec DLP Detection
Server (25.1.00000.60229)
with licenses for:
● Network Prevent for
Email
● Network Prevent for
Web
● Network Discover
● Network Protect
● Network Monitor
● Endpoint Discover
● Endpoint Prevent
This is a virtual
machine
supporting the
Network Prevent
for Email, Network
Prevent for Web,
Endpoint, Network
Discover TOE
components
VMware ESXi
v8.0.3
Windows
Server
2019
Standard
Edition
Four-core CPU, 8 GB RAM, 200 GB
hard drive storage, Two copper or
fiber 1 GB/100 MB Ethernet NICs to
communicate with Enforce server.
VMware ESXi
v8.0.3
Red Hat
Enterprise
Linux 8
Four-core CPU, 4 GB RAM, 50 GB
hard drive storage, Two copper or
fiber 1 GB/100 MB Ethernet NICs to
communicate with Enforce server.
Note: The network monitor
component must be installed on a
system with two Network Interface
Controllers (NICs).
Symantec DLP Agent
(25.1.00000.60234)
This is a virtual
machine
supporting the
Symantec DLP
Agent
VMware ESXi
v8.0.3
Windows
11
Enterprise
64-bit (x86_64), two-core CPU, 8 GB
RAM, 69 GB hard drive storage
Note: customers should be diligent to ensure the physical host hardware has adequate processing,
storage, and memory allocations to support the above virtual machines.
The following components are required to be present in the operational environment in order to
support the TOE in the evaluated configuration.
Table 3 – Operational Environment Supporting Hardware and Software
Non-TOE Component Details
Enforce Management Console The Enforce Management Console is a general purpose computing
platform running a DLP-compatible browser. Firefox is used in the
evaluated configuration.
Switch/Router The Network Monitor component is connected to a network
switch/router in order to monitor the data leaving the internal
network.
Symantec Data Loss Prevention 25.1 Security Target
11
Non-TOE Component Details
MTA In the evaluated configuration, the Network Prevent for Email
component is installed in Reflecting Mode. In this mode, the Detection
Server acts as an SMTP proxy that receives messages from an MTA,
analyzes the messages and sends them back to the MTA.
Network Discover and Network Prevent scan for sensitive data on
network resources, including mail servers.
File Server Network Discover and Network Prevent scan for sensitive data on
network resources, including file servers. In the evaluated
configuration, a Windows 2019 Server acts as a file server.
SharePoint Server Network Discover and Network Prevent scan for sensitive data on
network resources, including SharePoint servers. In the evaluated
configuration, a SharePoint Server 2019 is used.
Web Proxy The Network Prevent for Web is supported by an ICAP compatible web
proxy, situated between the Detection Server and the Internet.
Oracle Database The Enforce Management installation requires Oracle Database 19c to
be installed in the TOE operational environment.
Packet Capture Tool Either NPCAP (Windows) or Packet_MMAP (Linux) is required to be
installed on the Detection Server component.
1.3.3 Logical Scope
The logical boundary of the TOE includes all interfaces and functions within the physical boundary. The
logical boundary of the TOE may be broken down by the security function classes described in Section 6.
The following breakdown also provides the description of the security features of the TOE, and loosely
follows the security functional classes described in Section 6. Table 4 summarizes the logical scope of
the TOE.
Table 4 – Logical Scope of the TOE
Functional Classes Description
Security Audit Audit entries are generated for security related events.
User Data Protection The TOE will detect and block the transfer of data identified as sensitive.
Identification and
Authentication
Administrative users are identified and authenticated prior to being
allowed access to the Enforce Management Console. The TOE maintains
username, role, and password information on each administrative user.
Strong passwords are enforced and users are locked out after a number of
consecutive unsuccessful authentication attempts.
Security Management The TOE provides management capabilities via a Web-based GUI, accessed
via HTTPS. Management functions allow the administrators to view
incidents, manage administrative user accounts, and create and manage
Symantec Data Loss Prevention 25.1 Security Target
12
Functional Classes Description
policies and responses. A number of roles are available to support
separation of duties.
Protection of the TSF The communications links between the parts of the TOE are protected
using Transport Layer Security (TLS) 1.2 and 1.3. The DLP agent software is
monitored for tampering and the TOE reports if the agent has been
removed.
Trusted Path/Channels The communications links between the TOE components are protected
using HTTPS (TLS 1.3).
1.3.4 Functionality Excluded from the Evaluated Configuration
Symantec DLP provides a number of mechanisms for identifying data as sensitive. For the purposes of
this evaluation, keyword matching, data identifiers and Indexed Document Matching (IDM) are used to
demonstrate this functionality.
The following Symantec DLP data identification mechanisms are supported but not included for the
purposes of this evaluation:
● Exact Data Matching (EDM)
● Vector Machine Learning (VML)
● Directory Group Matching (DGM)
● Described Content Matching (DCM)
● User Risk-based Detection
● Form Recognition
● Regular Expressions
● International language content
● File properties
● Email subject
● Sender/recipient patterns
● MIP classification
● Optical Character Recognition (OCR)
Symantec Data Loss Prevention 25.1 Security Target
13
2 Conformance Claims
2.1 Common Criteria Conformance Claim
This Security Target claims to be conformant to CC:2022 of Common Criteria for Information Technology
Security Evaluation according to:
● Common Criteria for Information Technology Security Evaluation, Part 1: Introduction and
General Model; CCMB-2022-11-001, CC:2022, Revision 1, November 2022
● Common Criteria for Information Technology Security Evaluation, Part 2: Security Functional
Components; CCMB-2022-11-002, CC:2022, Revision 1, November 2022
● Common Criteria for Information Technology Security Evaluation, Part 3: Security Assurance
Components CCMB-2022-11-003, CC:2022, Revision 1, November 2022
● Common Criteria for Information Technology Security Evaluation, Part 4: Framework for the
Specification of Evaluation Methods and Activities CCMB-2022-11-004, CC:2022, Revision 1,
November 2022
● Common Criteria for Information Technology Security Evaluation, Part 5: Pre-defined Packages
of Security Requirements CCMB-2022-11-005, CC:2022, Revision 1, November 2022
● Errata and Interpretation for CC:2022 (Release 1) and CEM:2022 (Release 1), V1.1, 202407-22
As follows:
● CC Part 2 extended
● CC Part 3 conformant
The Common Methodology for Information Technology Security Evaluation CCMB-2022-11-006,
CC:2022, Revision 1, November 2022 has to be taken into account.
2.2 Assurance Package Claim
This Security Target claims conformance to Evaluation Assurance Level 2 augmented with ALC_FLR.2
Flaw Reporting Procedures.
2.3 Protection Profile Conformance Claim
This ST does not claim conformance of the TOE with any Protection Profile (PP).
Symantec Data Loss Prevention 25.1 Security Target
14
3 Security Problem Definition
3.1 Threats
Table 5 lists the threats addressed by the TOE. Potential threat agents are authorized TOE users, and
unauthorized persons. The level of expertise of both types of attacker is assumed to be unsophisticated.
TOE users are assumed to have access to the TOE, extensive knowledge of TOE operations, and to
possess a high level of skill. They have moderate resources to alter TOE parameters, but are assumed
not to be willfully hostile. Unauthorized persons have little knowledge of TOE operations, a low level of
skill, limited resources to alter TOE parameters and no physical access to the TOE.
Mitigation to the threats is through the objectives identified in Section 4.1, Security Objectives for the
TOE.
Table 5 – Threats
Threat Description
T.ACCOUNT An unauthorized user could gain access to TOE configuration information or
security management functions and use this to allow unauthorized access to
information protected by the TOE.
T.AUDACC Persons may not be held accountable for their changes to the TSF data because
their actions are not recorded.
T.BYPASS An authorized user of the TOE may attempt to bypass a security mechanism
resulting in disclosure of TSF data.
T.DATALEAK An authorized user of the internal network may attempt to transmit sensitive
data outside of the internal network, exposing it to unauthorized viewers.
T.DISCLOSE An unauthorized user may be able to able to read or modify sensitive data
transmitted between TOE components, the TOE and an administrator, or
between the TOE component and an external IT entity.
T.REMOVE An authorized user of the internal network may attempt to remove the agent
software to bypass the TOE security functionality.
3.2 Organizational Security Policies
Organizational Security Policies (OSPs) are security rules, procedures, or guidelines imposed on the
operational environment. Table 6 lists the OSPs that are presumed to be imposed upon the TOE or its
operational environment by an organization that implements the TOE in the Common Criteria evaluated
configuration.
Symantec Data Loss Prevention 25.1 Security Target
15
Table 6 – Organizational Security Policy
OSP Description
P.ADMIN The TOE shall be managed only by authorized administrators.
3.3 Assumptions
The assumptions required to ensure the security of the TOE are listed in Table 7.
Table 7 – Assumptions
Assumptions Description
A.LOCATE The TOE will be located within controlled access facilities, which will prevent
unauthorized physical access.
A.MANAGE There are one or more competent individuals assigned to manage the TOE.
A.NOEVIL Authorized administrators are non-hostile, appropriately trained, and follow all
TOE guidance documentation.
Symantec Data Loss Prevention 25.1 Security Target
16
4 Security Objectives
The purpose of the security objectives is to address the security concerns and to show which security
concerns are addressed by the TOE, and which are addressed by the environment. Threats may be
addressed by the TOE or the security environment or both. Therefore, the CC identifies two categories
of security objectives:
● Security objectives for the TOE
● Security objectives for the environment
4.1 Security Objectives for the TOE
This section identifies and describes the security objectives that are to be addressed by the TOE.
Table 8 – Security Objectives for the TOE
Security Objective Description
O.ADMIN The TOE will provide all the functions and facilities necessary to support the
administrators in their management of the security of the TOE, and restrict these
functions and facilities from unauthorized use.
O.AGENT The TOE must monitor for the removal of the agent software from the endpoint.
In the event the software is not detected, the TOE will report that the software is
not reporting and may have been removed.
O.AUDIT The TOE must record use of the TOE functions, and transmission of the resources
protected by the TOE.
O.IDENTAUTH The TOE must be able to identify and authenticate users prior to allowing access
to the administrative functions and data of the TOE.
O.PASS The TOE must ensure that passwords used to protect TOE access are sufficiently
strong, and that a limit is placed on unsuccessful authentication attempts.
O.PROTECT The TOE must protect organizational data identified as sensitive by detecting or
blocking its transmission by network users.
O.SENDATA The TOE must protect sensitive TSF data from disclosure and modification when
transmitted between parts of the TOE, between the TOE and the administrator,
or between the TOE and an external IT entity.
4.2 Security Objectives for the Operational Environment
This section identifies and describes the security objectives that are to be addressed by the IT
environment or by non-technical or procedural means.
Table 9 – Security Objectives for the Operational Environment
Security Objective Description
OE.AUTHADMIN 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. There
are an appropriate number of authorized administrators trained to maintain
the TOE, including its security policies and practices. Authorized administrators
are non-hostile and follow all administrator guidance.
OE.PHYSICAL Those responsible for the TOE must ensure that the TOE is protected from any
physical attack.
Symantec Data Loss Prevention 25.1 Security Target
17
Security Objective Description
OE.TIMESTAMP The operational environment will provide reliable timestamp information for
the use of the TOE.
4.3 Security Objectives Rationale
The following table maps the security objectives to the assumptions, threats, and organizational policies
identified for the TOE.
Table 10 – Mapping Between Objectives, Threats, OSPs, and Assumptions
T.A
CCO
UNT
T.A
UD
ACC
T.B
YPA
SS
T.D
ATA
LEA
K
T.DI
SCL
OSE
T.R
EM
OVE
P.A
DMI
N
A.L
OC
ATE
A.M
AN
AGE
A.N
OE
VIL
O.ADMIN X X X
O.AGENT X
O.AUDIT X X
O.IDENTAUTH X X
O.PASS X X
O.PROTECT X
O.SENDATA X
OE.AUTHADMIN X X
OE.PHYSICAL X
OE.TIMESTAMP X X
4.3.1 Security Objectives Rationale Related to Threats
The security objectives rationale related to threats traces the security objectives for the TOE and the
Operational Environment back to the threats addressed by the TOE.
Threat: T.ACCOUNT An unauthorized user could gain access to TOE configuration information or security
management functions and use this to allow unauthorized access to information
protected by the TOE.
Symantec Data Loss Prevention 25.1 Security Target
18
Objectives: O.ADMIN The TOE will provide all the functions and facilities
necessary to support the administrators in their
management of the security of the TOE, and restrict these
functions and facilities from unauthorized use.
O.IDENTAUTH The TOE must be able to identify and authenticate users
prior to allowing access to the administrative functions
and data of the TOE.
O.PASS The TOE must ensure that passwords used to protect TOE
access are sufficiently strong, and that a limit is placed on
unsuccessful authentication attempts.
Rationale: O.ADMIN mitigates this threat by restricting the use of administrative functions to
authorized users.
O.IDENTAUTH helps to mitigate the threat by ensuring that only credentialed users
have access to the TOE.
O.PASS mitigates the threat of unauthorized access by ensuring the use of strong
passwords, and a limit on the number of unsuccessful authentication attempts.
Threat:
T.AUDACC
Persons may not be held accountable for their changes to the TSF data because
their actions are not recorded.
Objectives: O.AUDIT The TOE must record use of the TOE functions, and
transmission of the resources protected by the TOE.
OE.TIMESTAMP The operational environment will provide reliable
timestamp information for the use of the TOE.
Rationale: O.AUDIT mitigates this threat by ensuring that the audit records log the use of TOE
functions, and transmission of the resources protected by the TOE.
OE.TIMESTAMP mitigates the threat by ensuring that the TOE is able to make use of
reliable timestamps for audit records.
Threat:
T.BYPASS
An authorized user of the TOE may attempt to bypass a security mechanism
resulting in disclosure of TSF data.
Objectives: O.ADMIN The TOE will provide all the functions and facilities
necessary to support the administrators in their
management of the security of the TOE, and restrict these
functions and facilities from unauthorized use.
O.AUDIT The TOE must record use of the TOE functions, and
transmission of the resources protected by the TOE.
O.IDENTAUTH The TOE must be able to identify and authenticate users
prior to allowing access to the administrative functions
and data of the TOE.
O.PASS The TOE must ensure that passwords used to protect TOE
access are sufficiently strong, and that a limit is placed on
unsuccessful authentication attempts.
Symantec Data Loss Prevention 25.1 Security Target
19
OE.TIMESTAMP The operational environment will provide reliable
timestamp information for the use of the TOE.
Rationale: O.ADMIN mitigates this threat by ensuring that access to TSF data is protected from
unauthorized use.
O.AUDIT mitigates this threat by ensuring that use of TOE functions is audited,
reducing the risk that bypass of security could continue undetected.
O.IDENTAUTH mitigates the threat by ensuring that users must be identified and
authenticated in order to gain access to the TOE.
O.PASS mitigates the threat of bypassing TOE security by ensuring the use of strong
passwords, and a limit on the number of unsuccessful authentication attempts.
OE.TIMESTAMP mitigates the threat by ensuring that the TOE is able to make use of
reliable timestamps for audit records.
Threat: T.DATALEAK An authorized user of the internal network may attempt to transmit sensitive data
outside of the internal network, exposing it to unauthorized viewers.
Objectives: O.PROTECT The TOE must protect organizational data identified as
sensitive by detecting or blocking its transmission by
network users.
Rationale: O.PROTECT mitigates the threat by detecting or preventing the transmission of
sensitive data.
Threat: T.DISCLOSE An unauthorized user may be able to able to read or modify sensitive data
transmitted between TOE components.
Objectives: O.SENDATA The TOE must protect sensitive TSF data from disclosure
and modification when transmitted between parts of the
TOE, between the TOE and the administrator, or between
the TOE and an external IT entity.
Rationale: O.SENDATA mitigates the threat by protecting sensitive data transmitted between
parts of the TOE, between the TOE and the administrator, or between the TOE and
an external IT entity.
Threat:
T.REMOVE
An authorized user of the internal network may attempt to remove the agent
software to bypass the TOE security functionality.
Objectives: O.AGENT The TOE must monitor for the removal of the agent
software from the endpoint.
Rationale: O.AGENT mitigates the threat by reporting that the agent software has been
removed from the endpoint for a TOE Administrator to take action.
4.3.2 Security Objectives Rationale Related to OSPs
The security objectives rationale related to OSPs traces the security objectives for the TOE back to the
OSPs applicable to the TOE.
Symantec Data Loss Prevention 25.1 Security Target
20
Policy:
P.ADMIN
The TOE shall be managed only by authorized administrators.
Objectives: O.ADMIN The TOE will provide all the functions and facilities
necessary to support the administrators in their
management of the security of the TOE, and restrict these
functions and facilities from unauthorized use.
Rationale: O.ADMIN supports this policy by restricting access to TOE management functionality
to authorized users.
4.3.3 Security Objectives Rationale Related to Assumptions
The security objectives rationale shall trace each security objective for the operational environment
back to threats countered by that security objective, and assumptions upheld by that security objective.
Assumption:
A.LOCATE
The TOE will be located within controlled access facilities, which will prevent
unauthorized physical access.
Objectives: OE.PHYSICAL Those responsible for the TOE must ensure that the TOE is
protected from any physical attack.
Rationale: OE.PHYSICAL supports this assumption by protecting the TOE from physical attack.
Assumption:
A.MANAGE
There are one or more competent individuals assigned to manage the TOE.
Objectives: OE.AUTHADMIN 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. There are an
appropriate number of authorized administrators trained
to maintain the TOE, including its security policies and
practices. Authorized administrators are non-hostile and
follow all administrator guidance.
Rationale: OE.AUTHADMIN supports this assumption by ensuring that trained individuals are in
place to manage the TOE.
Assumption:
A.NOEVIL
Authorized administrators are non-hostile, appropriately trained, and follow all
TOE guidance documentation.
Objectives: OE.AUTHADMIN 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. There are an
appropriate number of authorized administrators
trained to maintain the TOE, including its security
policies and practices. Authorized administrators are
non-hostile and follow all administrator guidance.
Symantec Data Loss Prevention 25.1 Security Target
21
Rationale: OE.AUTHADMIN supports this assumption by ensuring that the trained individuals
who manage the TOE are non-hostile and follow administrative guidance.
Symantec Data Loss Prevention 25.1 Security Target
22
5 Extended Components Definition
5.1 Security Functional Requirements
This section specifies the extended Security Functional Requirements (SFR) used in this ST. The extended
component is:
FPT_MIS_EXT.1 End user software monitoring
5.1.1 Class FPT: PROTECTION OF THE TSF
A new family and a new SFR have been added to the Protection of the TSF class. FPT_MIS_EXT is a new
family, Monitoring of installed software, and is modelled after FPT_PHP TSF physical protection.
FPT_MIS_EXT.1 End user software monitoring is modelled after FPT_PHP.2 Notification of physical
attack.
5.1.1.1 FPT_MIS_EXT Monitoring of installed software
Family Behaviour
This family defines the requirements for the detection and reporting of removed software.
Component Levelling
FPT_MIS_EXT: Monitoring of installed
software
1
Figure 2 – FPT_MIS_EXT: Monitoring of Installed Software Component Levelling
Management
There are no management activities foreseen.
Audit
The following actions should be auditable if FAU_GEN Security audit data generation is included in the
PP, PP-Module, functional package, or ST:
a) minimal: detection that the DLP Agent is not present on a designated endpoint.
5.1.1.2 FPT_MIS_EXT.1 End user software monitoring
Hierarchical to: No other components.
Dependencies: No dependencies.
FPT_MIS_EXT.1.1
The TSF shall monitor the [assignment: software component] and detect that the software has been
removed.
FPT_MIS_EXT.1.2
When the removal of software has been detected, the TSF shall report on the removal of the
[assignment: software component].
Symantec Data Loss Prevention 25.1 Security Target
23
5.2 Security Assurance Requirements
This ST does not include extended Security Assurance Requirements.
Symantec Data Loss Prevention 25.1 Security Target
24
6 Security Requirements
Section 6 provides security functional and assurance requirements that must be satisfied by a compliant
TOE. These requirements consist of functional components from Part 2 of the CC, an extended
component, and an Evaluation Assurance Level (EAL) that contains assurance components from Part 3 of
the CC.
6.1 Conventions
The CC permits four types of operations to be performed on functional requirements: selection,
assignment, refinement, and iteration. These operations, when performed on requirements that derive
from CC Part 2, are identified in this ST in the following manner:
● Selection: Indicated by surrounding brackets, e.g., [selected item].
● Assignment: Indicated by surrounding brackets and italics, e.g., [assigned item].
● Refinement: Refined components are identified by using bold for additional information, or
strikeout for deleted text.
● Iteration: Indicated by assigning a number in parenthesis to the end of the functional
component identifier as well as by modifying the functional component title to distinguish
between iterations, e.g., ‘FDP_ACC.1(1), Subset access control (administrators)’ and
‘FDP_ACC.1(2) Subset access control (devices)’.
6.2 TOE Security Functional Requirements
The security functional requirements for this ST consist of the following components from Part 2 of the
CC and extended components defined in Section 5, summarized in Table 11.
Table 11 – Summary of Security Functional Requirements
Class Identifier Name
Security Audit (FAU) FAU_GEN.1 Audit data generation
User Data Protection (FDP) FDP_IFC.1 Subset information flow control
FDP_IFF.1 Simple security attributes
Identification and
Authentication (FIA)
FIA_AFL.1 Authentication failure handling
FIA_ATD.1 User attribute definition
FIA_SOS.1 Verification of secrets
FIA_UAU.2 User authentication before any action
FIA_UID.2 User identification before any action
Security Management (FMT) FMT_MSA.1 Management of security attributes
FMT_MSA.3 Static attribute initialisation
Symantec Data Loss Prevention 25.1 Security Target
25
FMT_SMF.1 Specification of management functions
FMT_SMR.1 Security roles
Protection of the TSF (FPT) FPT_ITT.1 Basic internal TSF data transfer protection
FPT_MIS_EXT.1 End user software monitoring
Trusted path/channels (FTP) FTP_ITC.1 Trusted channel
FTP_TRP.1 Trusted path
6.2.1 Security Audit (FAU)
6.2.1.1 FAU_GEN.1 Audit data generation
Hierarchical to: No other components.
Dependencies: FPT_STM.1 Reliable time stamps
FAU_GEN.1.1
The TSF shall be able to generate audit data of the following auditable events:
a) Start-up and shutdown of the audit functions;
b) All auditable events for the [not specified] level of audit;
c) [creation/modification/deletion of Response Rules, creation/modification/deletion of Policy,
detection that the DLP Agent is not present on a designated endpoint].
FAU_GEN.1.2
The TSF shall record within each audit record at least the following information:
a) Date and time of the auditable event, type of event, subject identity (if applicable), and the
outcome (success or failure) of the event;
b) For each audit event type, based on the auditable event definitions of the functional components
included in the PP, PP-Module, functional package or ST, [no other audit relevant information]
6.2.2 User Data Protection (FDP)
6.2.2.1 FDP_IFC.1 Subset information flow control
Hierarchical to: No other components.
Dependencies: FDP_IFF.1 Simple security attributes
FDP_IFC.1.1
The TSF shall enforce the [DLP information flow control SFP] on [Subjects: Users of the internal network
Information: Content identified as sensitive Operations: send, copy].
6.2.2.2 FDP_IFF.1 Simple security attributes
Hierarchical to: No other components.
Dependencies: FDP_IFC.1 Subset information flow control
FMT_MSA.3 Static attribute initialisation
FDP_IFF.1.1
The TSF shall enforce the [DLP information flow control SFP] based on the following types of subject and
information security attributes: [Subjects: Users of the internal network Subject attributes: none
Symantec Data Loss Prevention 25.1 Security Target
26
Information: Content identified as sensitive Information attributes: information identified as sensitive
based on keyword matches, data identifier matches, and Indexed Document Matching].
FDP_IFF.1.2
The TSF shall permit or deny an information flow between a controlled subject and controlled
information via a controlled operation if the following rules hold: [When an attempt to send or copy
information identified as sensitive outside the organization is detected, the detection server will log a
record of the violation, quarantine the file, block the transfer of the data or display an on-screen
notification of the violation, as configured in the response rules for that violation].
FDP_IFF.1.3
The TSF shall enforce the [no additional information flow control SFP rules].
FDP_IFF.1.4
The TSF shall explicitly authorize an information flow based on the following rules: [no additional rules].
FDP_IFF.1.5
The TSF shall explicitly deny an information flow based on the following rules: [no additional rules].
6.2.3 Identification and Authentication (FIA)
6.2.3.1 FIA_AFL.1 Authentication failure handling
Hierarchical to: No other components.
Dependencies: FIA_UAU.1 Timing of authentication
FIA_AFL.1.1
The TSF shall detect when [[6]] unsuccessful authentication attempts occur related to [administrator
logon].
FIA_AFL.1.2
When the defined number of unsuccessful authentication attempts has been [met], the TSF shall [lock
the user out until the account is reset by an administrator].
6.2.3.2 FIA_ATD.1 User attribute definition
Hierarchical to: No other components.
Dependencies: No dependencies.
FIA_ATD.1.1
The TSF shall maintain the following list of security attributes belonging to individual administrative
users: [username, role, password].
6.2.3.3 FIA_SOS.1 Verification of secrets
Hierarchical to: No other components.
Dependencies: No dependencies.
FIA_SOS.1.1
TSF shall provide a mechanism to verify that secrets meet [the following rules:
● passwords must be at least 8 characters in length
● passwords must contain at least one uppercase letter
Symantec Data Loss Prevention 25.1 Security Target
27
● passwords must contain at least one number
● passwords must not include more than two consecutive repeated characters].
6.2.3.4 FIA_UAU.2 User authentication before any action
Hierarchical to: FIA_UAU.1 Timing of authentication
Dependencies: FIA_UID.1 Timing of identification
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.
6.2.3.5 FIA_UID.2 User identification before any action
Hierarchical to: FIA_UID.1 Timing of identification
Dependencies: No dependencies.
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.
6.2.4 Security Management (FMT)
6.2.4.1 FMT_MSA.1 Management of security attributes
Hierarchical to: No other components.
Dependencies: [FDP_ACC.1 Subset access control, or
FDP_IFC.1 Subset information flow control]
FMT_SMR.1 Security roles
FMT_SMF.1 Specification of Management Functions
FMT_MSA.1.1
The TSF shall enforce the [DLP information flow control SFP] to restrict the ability to [modify, delete,
[identify]] the security attributes [keywords, data identifiers, indexed document content] to [an
administrator with the ‘author policies’ privilege].
Note: The DLP information flow control SFP does not control access to the security attributes used in the
SFP.
Note: In the evaluated configuration, the System Administrator and Policy Administrator roles have this
privilege.
6.2.4.2 FMT_MSA.3 Static attribute initialisation
Hierarchical to: No other components.
Dependencies: FMT_MSA.1 Management of security attributes
FMT_SMR.1 Security roles
FMT_MSA.3.1
The TSF shall enforce the [DLP information flow control SFP] to provide [permissive] default values for
security attributes that are used to enforce the SFP.
FMT_MSA.3.2
The TSF shall allow the [System Administrator] to specify alternative initial values to override the default
values when an object or information is created.
Symantec Data Loss Prevention 25.1 Security Target
28
6.2.4.3 FMT_SMF.1 Specification of Management Functions
Hierarchical to: No other components.
Dependencies: No dependencies.
FMT_SMF.1.1
The TSF shall be capable of performing the following management functions: [
● viewing incident information
● user account management
● policy creation and management
● response rule management].
6.2.4.4 FMT_SMR.1 Security roles
Hierarchical to: No other components.
Dependencies: FIA_UID.1 Timing of identification
FMT_SMR.1.1
The TSF shall maintain the roles [System Administrator, User Administrator, Policy Administrator, and
Incident Responder].
FMT_SMR.1.2
The TSF shall be able to associate users with roles.
6.2.5 Protection of the TSF (FPT)
6.2.5.1 FPT_ITT.1 Basic internal TSF data transfer protection
Hierarchical to: No other components.
Dependencies: No dependencies.
FPT_ITT.1.1
The TSF shall protect TSF data from [disclosure, modification] when it is transmitted between separate
parts of the TOE.
6.2.5.2 FPT_MIS_EXT.1 End user software monitoring
Hierarchical to: No other components.
Dependencies: No dependencies.
FPT_MIS_EXT.1.1
The TSF shall monitor the [the DLP agent software] and detect that the software has been removed.
FPT_MIS_EXT.1.2
When the removal of software has been detected, the TSF shall report on the removal of the [the DLP
agent software].
Symantec Data Loss Prevention 25.1 Security Target
29
6.2.6 Trusted Path/Channels (FTP)
6.2.6.1 FTP_ITC.1 Trusted channel
Hierarchical to: No other components.
Dependencies: No dependencies.
FTP_ITC.1.1
The TSF shall provide a communication channel between itself and another trusted IT product that is
logically distinct from other communication channels and provides assured identification of its end
points and protection of the channel data from modification or disclosure.
FTP_ITC.1.2
The TSF shall permit [the TSF] to initiate communication via the trusted channel.
FTP_ITC.1.3
The TSF shall initiate communication via the trusted channel for [File server and SharePoint scanning].
6.2.6.2 FTP_TRP.1 Trusted path
Hierarchical to: No other components.
Dependencies: No dependencies.
FTP_TRP.1.1
The TSF shall provide a communication path between itself and [remote] users that is logically distinct
from other communication paths and provides assured identification of its end points and protection of
the communicated data from [modification, disclosure].
FTP_TRP.1.2
The TSF shall permit [remote users] to initiate communication via the trusted path.
FTP_TRP.1.3
The TSF shall require the use of the trusted path for [[remote administration]].
Symantec Data Loss Prevention 25.1 Security Target
30
6.3 Security Functional Requirements Rationale
The following table provides a mapping between the SFRs and Security Objectives.
Table 12 – Mapping of SFRs to Security Objectives
O.AD
MIN
O.AGE
NT
O.AUD
IT
O.IDE
NTAU
TH
O.PAS
S
O.PRO
TECT
O.SEN
DATA
FAU_GEN.1 X
FDP_IFC.1 X
FDP_IFF.1 X
FIA_AFL.1 X
FIA_ATD.1 X
FIA_SOS.1 X
FIA_UAU.2 X
FIA_UID.2 X
FMT_MSA.1 X
FMT_MSA.3 X
FMT_SMF.1 X
FMT_SMR.1 X
FPT_ITT.1 X
FPT_MIS_EXT.1 X
FTP_ITC.1 X
FTP_TRP.1 X
6.3.1 SFR Rationale Related to Security Objectives
The following rationale traces each SFR back to the Security Objectives for the TOE.
Objective:
O.ADMIN
The TOE will provide all the functions and facilities necessary to support the
administrators in their management of the security of the TOE, and restrict these
functions and facilities from unauthorized use.
Security Functional
Requirements:
FMT_MSA.1 Management of security attributes
FMT_MSA.3 Static attribute initialization
Symantec Data Loss Prevention 25.1 Security Target
31
FMT_SMF.1 Specification of Management Functions
FMT_SMR.1 Security roles
Rationale: FMT_MSA.1 provides the functionality to manage the security attributes used in the
DLP information flow control SFP.
FMT_MSA.3 provides the default values for the security attributes used in the DLP
information flow control SFP.
FMT_SMF.1 describes the security management functions required to support the
claimed TOE functions.
FMT_SMR.1 provides roles, which are used to restrict security management
functions to authorized users.
Objective:
O.AGENT
The TOE must monitor for the removal of the agent software from the endpoint.
Security Functional
Requirements:
FPT_MIS_EXT.1 End user software monitoring
Rationale: FPT_MIS_EXT.1 ensures that the agent software’s installation status is monitored. If
the TOE detects that the agent software has been removed, the agent software
status is reported to the TOE Administrator.
Objective:
O.AUDIT
The TOE must record use of the TOE functions, and transmission of the resources
protected by the TOE.
Security Functional
Requirements:
FAU_GEN.1 Audit data generation
Rationale: FAU_GEN.1 ensures that the audit logs capture use of the TOE and actions on
resources protected by the TOE.
Objective:
O.IDENTAUTH
The TOE must be able to identify and authenticate users prior to allowing access to
the administrative functions and data of the TOE.
Security
Functional
Requirements:
FIA_ATD.1 User attribute definition
FIA_UAU.2 User authentication before any action
FIA_UID.2 User identification before any action
Rationale: FIA_ATD.1 maintains user attributes used to identify and authenticate users.
FIA_UAU.2 ensures that users are authenticated before being allowed access to TOE
functions.
FIA_UID.2 ensures that users are identified before being allowed access to TOE
functions.
Symantec Data Loss Prevention 25.1 Security Target
32
Objective: O.PASS The TOE must ensure that passwords used to protect TOE access are sufficiently
strong, and that a limit is placed on unsuccessful authentication attempts.
Security Functional
Requirements:
FIA_AFL.1 Authentication failure handling
FIA_SOS.1 Verification of secrets
Rationale: FIA_AFL.1 enforces a limit on the number of unsuccessful authentication attempts.
FIA_SOS.1 ensures that strong passwords are used.
Objective:
O.PROTECT
The TOE must protect organizational data identified as sensitive by detecting or
blocking its transmission by network users.
Security Functional
Requirements:
FDP_IFC.1 Subset information flow control
FDP_IFF.1 Simple security attributes
Rationale: FDP_IFC.1 and FDP_IFF.1 ensure that the transmission of sensitive information by
internal network users may be detected and blocked.
Objective:
O.SENDATA
The TOE must protect sensitive TSF data from disclosure and modification when
transmitted between parts of the TOE, between the TOE and the administrator, or
between the TOE and an external IT entity.
Security Functional
Requirements:
FPT_ITT.1 Basic internal TSF data transfer protection
FTP_ITC.1 Trusted channel
FTP_TRP.1 Trusted path
Rationale: FPT_ITT.1 ensures that TSF data is protected as it is transmitted between parts of
the TOE.
FTP_ITC.1 ensures the protection of the path between the TOE and external IT
entities.
FTP_TRP.1 ensures the protection of the path between the TOE and the
administrator.
6.4 Dependency Rationale
Table 14 identifies the Security Functional Requirements from Part 2 of the CC and their associated
dependencies. It also indicates whether the ST explicitly addresses each dependency.
Table 13 – Functional Requirement Dependencies
SFR Dependency
Dependency
Satisfied Rationale
FAU_GEN.1 FPT_STM.1 x The dependency is satisfied by the
environment, as described by the
objective OE.TIMESTAMP.
FDP_IFC.1 FDP_IFF.1 ✔
Symantec Data Loss Prevention 25.1 Security Target
33
SFR Dependency
Dependency
Satisfied Rationale
FDP_IFF.1 FDP_IFC.1 ✔
FMT_MSA.3 ✔
FIA_AFL.1 FIA_UAU.1 ✔ FIA_UAU.2 is hierarchical to
FIA_UAU.1; this dependency has
been satisfied.
FIA_ATD.1 None N/A
FIA_SOS.1 None N/A
FIA_UAU.2 FIA_UID.1 ✔ FIA_UID.2 is hierarchical to
FIA_UID.1; this dependency has
been satisfied.
FIA_UID.2 None N/A
FMT_MSA.1 FDP_ACC.1 or
FDP_IFC.1
Satisfied by
FDP_IFC.1
FMT_SMR.1 ✔
FMT_SMF.1 ✔
FMT_MSA.3 FMT_MSA.1 ✔
FMT_SMR.1 ✔
FMT_SMF.1 None N/A
FMT_SMR.1 FIA_UID.1 ✔ FIA_UID.2 is hierarchical to
FIA_UID.1; this dependency has
been satisfied
FPT_ITT.1 None N/A
FPT_MIS_EXT.1 None N/A
FTP_ITC.1 None N/A
FTP_TRP.1 None N/A
6.5 TOE Security Assurance Requirements
The TOE assurance requirements for this ST consist of the requirements corresponding to the EAL 2 level
of assurance, as defined in the CC Part 3, augmented by the inclusion of Flaw reporting procedures
(ALC_FLR.2). EAL 2 was chosen for competitive reasons. The developer is claiming the ALC_FLR.2
augmentation since there are a number of areas where current practices and procedures exceed the
minimum requirements for EAL 2.
The assurance requirements are summarized in Table 15.
Symantec Data Loss Prevention 25.1 Security Target
34
Table 14 – Security Assurance Requirements
Assurance Class
Assurance Components
Identifier Name
Development (ADV) ADV_ARC.1 Security architecture description
ADV_FSP.2 Security-enforcing functional specification
ADV_TDS.1 Basic design
Guidance Documents (AGD) AGD_OPE.1 Operational user guidance
AGD_PRE.1 Preparative procedures
Life-Cycle Support (ALC) ALC_CMC.2 Use of a CM system
ALC_CMS.2 Parts of the TOE CM coverage
ALC_DEL.1 Delivery procedures
ALC_FLR.2 Flaw reporting procedures
Security Target Evaluation
(ASE)
ASE_CCL.1 Conformance claims
ASE_ECD.1 Extended components definition
ASE_INT.1 ST introduction
ASE_OBJ.2 Security objectives
ASE_REQ.2 Derived security requirements
ASE_SPD.1 Security problem definition
ASE_TSS.1 TOE summary specification
Tests (ATE) ATE_COV.1 Evidence of coverage
ATE_FUN.1 Functional testing
ATE_IND.2 Independent testing - sample
Vulnerability Assessment
(AVA) AVA_VAN.2 Vulnerability analysis
Symantec Data Loss Prevention 25.1 Security Target
35
7 TOE Summary Specification
This section provides a description of the security functions and assurance measures of the TOE that
meet the TOE security requirements.
7.1 TOE Security Functions
A description of each of the TOE security functions follows.
7.1.1 Security Audit
Audit entries are created for events at both the Agent and the Servers. The Detection Server pulls the
logs from the Agent based on the configured schedule. The logs may then be collected from the
Detection Server onto the Enforce Server, where they are stored in a secure database. The logs are
removed from the Detection Server once they are sent to the Enforce Server. All management of Policy
and Response Rules is audited.
The logs include the date and time of the event, a description of the event, including success or failure
and the name of the entity causing the event, where applicable.
TOE Security Functional Requirements addressed: FAU_GEN.1.
7.1.2 User Data Protection
In order to detect sensitive data, it must first be determined what data is to be considered sensitive.
Symantec DLP provides a number of mechanisms for identifying data as sensitive. For the purposes of
this evaluation, keyword matching, data identifiers, and Indexed Document Matching are used to
demonstrate this functionality.
Keyword matching allows matches to be made based on an identified word.
Data identifiers are algorithms that combine pattern matching with data validators to detect content.
For example, the ‘Credit Card Number’ system data identifier detects numbers that match a specific
pattern. The matched pattern is validated using a Luhn check algorithm. In this case, the validation is
performed on the first 15 digits of the number that evaluates to equal the 16th digit. DLP supports this
pattern matching for the personal identifiers used by various countries, as well as identifiers using in
banking and healthcare.
Indexed Document Matching (IDM) is used to protect confidential information that is stored as
unstructured data in documents and files. During the indexing process the system uses an algorithm to
fingerprint each file or file contents. If a file is found to include enough of the same information, it will
be considered a match.
Once a detection server has detected a policy violation, it will respond according to the response rules
for that policy. For the purposes of this evaluation, the possible responses are:
● For all detection servers:
o Log a record of the policy violation
● For Endpoint Detection
Symantec Data Loss Prevention 25.1 Security Target
36
o Quarantine a discovered sensitive file
● For Endpoint Prevent
o Block the transfer of data that violates the policy
o Display an on-screen notification to the endpoint user when confidential data is
transferred
● For Network Prevent for Web
o Block FTP request
o Block HTTP/S postings
● For Network Prevent for Email
o Block SMTP email
● For Network Protect
o Quarantine files
TOE Security Functional Requirements addressed: FDP_IFC.1, FDP_IFF.1.
7.1.3 Identification and Authentication
For the purposes of the evaluation, Symantec DLP password authentication is used. With password
authentication, the Enforce Management Console authenticates each user by determining if the
supplied user name and password combination matches an active user account in the Enforce Server
configuration. An active user account is authenticated if it has been assigned a valid role.
When using this authentication mechanism, users enter their credentials into the Enforce Management
Console's logon page and submit them over an HTTPS connection to the Enforce Server.
No functionality is available to the user prior to identification and authentication through the Enforce
Management Console.
For each user, DLP maintains a username (the name that the user enters to logon to the Enforce Server),
password hash and a list of roles. A user may have more than one role; each user must have at least one
role to be allowed to logon to the Enforce Server.
A user is locked out after six unsuccessful logon attempts. The user is locked out until an administrator
re-enables the account by deselecting the ‘Account Disabled’ option on the user’s account information.
(Note that this is the default behavior. An administrator may configure lockout after any number of
unsuccessful login attempts.)
In the evaluated configuration, strong passwords are used. The use of strong passwords is set under the
General System Settings, and once configured requires that passwords be at least eight characters in
length, contain at least one number and at least one uppercase letter. Strong passwords cannot have
more than two consecutive repeated characters.
TOE Security Functional Requirements addressed: FIA_AFL.1, FIA_ATD.1, FIA_SOS.1, FIA_UAU.2,
FIA_UID.2.
Symantec Data Loss Prevention 25.1 Security Target
37
7.1.4 Security Management
The default attributes used in the DLP information flow control SFP are permissive. No information is
identified as sensitive prior to an administrator doing so. The administrator identifies information as
sensitive based on keywords, data identifiers and indexed document content. Administrators are able to
identify, modify and delete keywords, identifiers and indexed document content. It should be noted that
the administrator does not modify the document content itself, but controls which content is indexed.
Only administrators with the ‘author policies’ privilege are able to perform this function. This default
functionality may not be changed.
Symantec DLP does not include any preconfigured roles. During installation, an Administrator account
(called “Administrator”) is created during installation. This account has all system privileges and role
options do not apply. For the purposes of this evaluation, this account will be referred to as the
Administrator. The Administrator will then create the custom roles that can be assigned when creating
new users. This provides very fine grained access control of the DLP functionality. In the evaluated
configuration, the Administrator will create 4 custom roles: the System Administrator, User
Administrator, Policy Administrator, and Incident Responder. The permissions assigned to reach role are
as follows:
• System Administrator
o Has System->User Administrator (Superuser), Server Administrator, and Agent
Management (automatically checked) all selected
o User Privileges -> all set to "Edit"
o Under Incidents->Customer Attributes set to “Edit All,”
o All other checkboxes can remain as-is.
• User Administrator
o Has only System->User Administrator (Superuser) set to "Edit"
• Policy Administrator
o Has System->Server Administrator set to “Edit”
o Under Policy Management tab, has all Privileges set to “Edit”
o Policy Management-> Import is selected.
• Incident Responder
o All checkboxes under Incidents are selected,
o Custom Attributes is set to "Edit All,”
o Under People-> “User Reporting (Risk Summary, User Snapshot)” is selected
TOE Security Functional Requirements addressed: FMT_MSA.1, FMT_MSA.3, FMT_SMF.1, FMT_SMR.1.
7.1.5 Protection of the TSF
Data that travels between the DLP Agent and the Detection Server is protected using TLS 1.3 and data
that travels between the Detection Server and the Enforce Server is protected using TLS 1.2. TLS is
implemented in the DLP Agent using an OpenSSL v3.0.8 module which uses CAVP-validated
cryptographic algorithms. TLS is implemented in the Enforce Server and Detection Server using the
Bouncy Castle v2.0.0 module which also uses CAVP-validated cryptographic algorithms. The TLS 1.3
connections use the TLS_AES_128_GCM_SHA256 ciphersuite by default, but this may be changed to use
another TLS 1.3 supported ciphersuite. The TLS 1.2 connection between the Enforce Server and
Symantec Data Loss Prevention 25.1 Security Target
38
Detection Server uses the TLS_ECDHE_RSA_AES_128_GCM_SHA256 ciphersuite. The TLS connection
protects the TSF data from disclosure and modification as it passes between the TOE components.
The DLP agent software invokes both an agent service and a watchdog service on the endpoint. As a
tamper-proofing measure, it is not possible for a user to individually stop either the DLP Agent or
watchdog service. The Detection Server monitors the agent, and if it detects that the agent software has
been uninstalled, it is identified as non-reporting.
TOE Security Functional Requirements addressed: FPT_ITT.1, FPT_MIS_EXT.1.
7.1.6 Trusted Path/Channels
Data that travels between the Detection Server and the Microsoft SharePoint server or file server is
protected using TLS. The SharePoint or file server dictates whether it will be TLS v1.2 or v1.3 and the
ciphers. The Detection Server implements TLS using CAVP-validated algorithms from the Bouncy Castle
v2.0.0 module. The TLS connection protects the discovered data from disclosure and modification as it
passes from the file server or SharePoint Server to the TOE. The Detection Server is assured of the
SharePoint server id or file server entity as explicit configuration is required along with credentials that
must be supplied.
Data that travels between the Enforce Server and the administrator using the Enforce Management
Console is protected using TLS 1.3. TLS 1.3 is implemented in the Enforce Server using CAVP-validated
cryptographic algorithms from the Bouncy Castle v2.0.0 module. The TLS connection uses the
TLS_AES_128_GCM_SHA256 ciphersuite by default, but this may be changed to another TLS 1.3
supported ciphersuite. The TLS connection protects the TSF data from disclosure and modification as it
passes between the TOE components. The administrator is assured of the end point by entering the
known URL of the Enforce Server. The Enforce Server is assured of the user’s identity by the username
and password presented at login. Only the authorized users may initiate a session.
TOE Security Functional Requirements addressed: FTP_ITC.1, FTP_TRP.1.
Symantec Data Loss Prevention 25.1 Security Target
39
8 Terminology and Acronyms
8.1 Terminology
The following terminology is used in this ST:
Table 15 – Terminology
Term Description
Administrator An administrator is any user with administrative privileges. A user in any role
with access to the Enforce Management Console is considered to be an
administrator.
Primary Administrator This is the administrative user account created during DLP installation. This
account has full system privileges.
Security policy The term ‘security policy’ is used in this ST to describe the policies
implemented within the DLP product to enforce the claimed functionality. It
does not refer to the specific policies enforced by FDP_IFC.1 and FDP_IFF.1.
8.2 Acronyms
The following acronyms are used in this ST:
Table 16 – Acronyms
Acronym Definition
ANSI American National Standards Institute
CAVP Cryptographic Algorithm Validation Program
CC Common Criteria
CLI Command Line Interface
DES Data Encryption Standard
DLP Data Loss Prevention
EAL Evaluation Assurance Level
FTP File Transfer Protocol
GUI Graphical User Interface
HMAC Hash Message Authentication Code
HTTP Hypertext Transfer Protocol
HTTPS Hypertext Transfer Protocol Secure
ICAP Internet Content Adaptation Protocol
Symantec Data Loss Prevention 25.1 Security Target
40
Acronym Definition
IDM Indexed Document Matching
IPS Intrusion Prevention System
IPsec Internet Protocol Security
IT Information Technology
MS Exchange Microsoft Exchange
MTA Mail Transfer Agent
NIC Network Interface Controller
NTP Network Time Protocol
PKCS Public-Key Cryptography Standards
PP Protection Profile
RSA Rivest, Shamir and Adleman
SFP Security Function Policy
SFR Security Functional Requirement
SHA Secure Hash Algorithm
SMTP Simple Mail Transfer Protocol
SSH Secure Shell
ST Security Target
TCP Transmission Control Protocol
TLS Transport Layer Security
TOE Target of Evaluation
TSF TOE Security Functionality
UDP User Datagram Protocol
USB Universal Serial Bus