Dell EMC™ Avamar®
v18.1
Security Target
Evaluation Assurance Level (EAL): EAL2+
Doc No: 2095-000-D102
Version: 1.8
19 September 2019
Dell EMC
176 South Street
Hopkinton, MA, USA
01748
Prepared by:
EWA-Canada, An Intertek Company
1223 Michael Street North, Suite 200
Ottawa, Ontario, Canada
K1J7T2
Dell EMC™ Avamar®
v18.1
Security Target
Doc No: 2095-000-D102 Version: 1.8 Date: 19 September 2019 Page i of iii
CONTENTS
1 SECURITY TARGET INTRODUCTION.............................................1
1.1 DOCUMENT ORGANIZATION.............................................................1
1.2 SECURITY TARGET REFERENCE ........................................................ 1
1.3 TOE REFERENCE.............................................................................2
1.4 TOE OVERVIEW ..............................................................................2
TOE Environment ...........................................................................3
1.4.1
1.5 TOE DESCRIPTION..........................................................................3
Physical Scope ...............................................................................3
1.5.1
Logical Scope.................................................................................7
1.5.2
Functionality Excluded from the Evaluated Configuration.....................7
1.5.3
2 CONFORMANCE CLAIMS...............................................................9
2.1 COMMON CRITERIA CONFORMANCE CLAIM........................................ 9
2.2 PROTECTION PROFILE CONFORMANCE CLAIM .................................... 9
2.3 PACKAGE CLAIM.............................................................................9
2.4 CONFORMANCE RATIONALE.............................................................9
3 SECURITY PROBLEM DEFINITION..............................................10
3.1 THREATS ..................................................................................... 10
3.2 ORGANIZATIONAL SECURITY POLICIES........................................... 10
3.3 ASSUMPTIONS ............................................................................. 10
4 SECURITY OBJECTIVES..............................................................12
4.1 SECURITY OBJECTIVES FOR THE TOE.............................................. 12
4.2 SECURITY OBJECTIVES FOR THE OPERATIONAL ENVIRONMENT ......... 13
4.3 SECURITY OBJECTIVES RATIONALE ................................................ 13
Security Objectives Rationale Related to Threats..............................14
4.3.1
Security Objectives Rationale Related to OSPs .................................16
4.3.2
Security Objectives Rationale Related to Assumptions.......................17
4.3.3
5 EXTENDED COMPONENTS DEFINITION......................................20
5.1 SECURITY FUNCTIONAL REQUIREMENTS ......................................... 20
Family FDP_BCK_EXT: User Data Backup/Restore ............................20
5.1.1
5.2 SECURITY ASSURANCE REQUIREMENTS .......................................... 21
Dell EMC™ Avamar®
v18.1
Security Target
Doc No: 2095-000-D102 Version: 1.8 Date: 19 September 2019 Page ii of iii
6 SECURITY REQUIREMENTS ........................................................22
6.1 CONVENTIONS ............................................................................. 22
6.2 SECURITY FUNCTIONAL REQUIREMENTS ......................................... 22
Security Audit (FAU).....................................................................23
6.2.1
User Data Protection (FDP)............................................................24
6.2.2
Identification and Authentication (FIA)............................................27
6.2.3
Security Management (FMT) ..........................................................27
6.2.4
Protection of the TSF (FPT)............................................................29
6.2.5
6.3 SECURITY ASSURANCE REQUIREMENTS .......................................... 29
6.4 SECURITY REQUIREMENTS RATIONALE ........................................... 30
Security Functional Requirements Rationale.....................................30
6.4.1
SFR Rationale Related to Security Objectives ...................................31
6.4.2
Dependency Rationale ..................................................................35
6.4.3
Security Assurance Requirements Rationale.....................................36
6.4.4
7 TOE SUMMARY SPECIFICATION.................................................37
7.1 SECURITY AUDIT.......................................................................... 37
7.2 USER DATA PROTECTION .............................................................. 37
7.3 IDENTIFICATION AND AUTHENTICATION......................................... 38
7.4 SECURITY MANAGEMENT............................................................... 38
7.5 PROTECTION OF THE TSF .............................................................. 39
8 TERMINOLOGY AND ACRONYMS ................................................39
8.1 TERMINOLOGY ............................................................................. 39
8.2 ACRONYMS .................................................................................. 39
LIST OF TABLES
Table 1 – Non-TOE Hardware and Software .................................................. 3
Table 2 - TOE Components .........................................................................4
Table 3 - TOE Software Files & Format ......................................................... 6
Table 4 – Logical Scope of the TOE ..............................................................7
Table 5 – Threats .................................................................................... 10
Table 6 – Organizational Security Policies ................................................... 10
Table 7 – Assumptions ............................................................................. 11
Dell EMC™ Avamar®
v18.1
Security Target
Doc No: 2095-000-D102 Version: 1.8 Date: 19 September 2019 Page iii of iii
Table 8 – Security Objectives for the TOE................................................... 12
Table 9 – Security Objectives for the Operational Environment...................... 13
Table 10 – Mapping Between Objectives, Threats, OSPs, and Assumptions ..... 14
Table 11 – Summary of Security Functional Requirements............................ 23
Table 12 – Security Assurance Requirements .............................................. 30
Table 13 – Mapping of SFRs to Security Objectives ...................................... 31
Table 14 – Functional Requirement Dependencies ....................................... 36
Table 15 - Terminology ............................................................................ 39
Table 16 – Acronyms ............................................................................... 40
LIST OF FIGURES
Figure 1 – Avamar TOE Diagram .................................................................5
Figure 2 – FDP_BCK_EXT: User Data Backup/Restore Component Levelling .... 20
Dell EMC™ Avamar®
v18.1
Security Target
Doc No: 2095-000-D102 Version: 1.8 Date: 19 September 2019 Page 1 of 40
1 SECURITY TARGET INTRODUCTION
This Security Target (ST) defines the scope of the evaluation in terms of the
assumptions made, the intended environment for the Target of Evaluation
(TOE), the Information Technology (IT) security functional and assurance
requirements to be met, and the level of confidence (evaluation assurance level)
to which it is asserted that the TOE satisfies its IT security requirements. This
document forms the baseline for the Common Criteria (CC) evaluation.
1.1 DOCUMENT ORGANIZATION
Section 1, ST Introduction, provides the Security Target reference, the Target
of Evaluation reference, the TOE overview and the TOE description.
Section 2, Conformance Claims, describes how the ST conforms to the
Common Criteria and Packages. The ST does not conform to a Protection
Profile.
Section 3, Security Problem Definition, describes the expected environment
in which the TOE is to be used. This section defines the set of threats that are
relevant to the secure operation of the TOE, organizational security policies with
which the TOE must comply, and secure usage assumptions applicable to this
analysis.
Section 4, Security Objectives, defines the set of security objectives to be
satisfied by the TOE and by the TOE operating environment in response to the
problem defined by the security problem definition.
Section 5, Extended Components Definition, defines the extended
components which are then detailed in Section 6.
Section 6, Security Requirements, specifies the security functional and
assurance requirements that must be satisfied by the TOE and the IT
environment.
Section 7, TOE Summary Specification, describes the security functions that
are included in the TOE to enable it to meet the IT security functional
requirements.
Section 8 Terminology and Acronyms, defines the acronyms and
terminology used in this ST.
1.2 SECURITY TARGET REFERENCE
ST Title: Dell EMC™ Avamar®
v18.1 Security Target
ST Version: 1.8
ST Date: 19 September 2019
Dell EMC™ Avamar®
v18.1
Security Target
Doc No: 2095-000-D102 Version: 1.8 Date: 19 September 2019 Page 2 of 40
1.3 TOE REFERENCE
TOE Identification: Dell EMC™ Avamar®
v18.1.0.33 with Hotfixes 301590,
300449, 300443, 305019, 309443, and
AvPlatformOsRollup Security Patch
TOE Developer: Dell EMC
TOE Type: Data Backup (Other Devices and Systems)
1.4 TOE OVERVIEW
Dell EMC Avamar performs backups and restores for remote offices, data center
local area networks (LAN), and VMware environments. Using data deduplication
technology, redundancies are identified at the source, saving network and data
storage resources. Backups are based on changes to data and occur at
administrator-scheduled intervals, making each backup a full backup, while
significantly reducing backup time.
Avamar consists of multiple components. The server component provides
centralized storage for the backups, while agent components execute on
platforms being backed up. There are also special categories of agents for
VMware environments and Network Data Management Protocol (NDMP)-based
storage solutions.
The Avamar Server may be deployed on a single-node server that includes
management and storage in one node, or in a multi-node server that uses one
node as the utility management node and up to 16 nodes for storage. Client
communications are dynamically load-balanced across all of the storage nodes
within the server, but all management is done through only the utility node.
Avamar Servers are delivered as physical appliances.
Management of the Server is performed via Java-based GUI application
executing on a Windows or Linux workstation, or via a Command Line Interface
(CLI) remotely accessed on the Server. The management interfaces support
multiple roles so that different access rights can be assigned to different user
accounts. Users can also be assigned to domains to further limit their access.
The GUI application is delivered as software.
The Avamar Agents on end user systems (Clients) run on many operating
systems. Each Client is associated with a domain within Avamar to link related
systems and help in defining user access to their backup data. The Agents execute
backups at pre-configured intervals, or on demand. The Agents determine the data
that needs to be backed up and sends it to the Server. The Avamar Agents are
delivered as software.
Authorized users on Client machines can interact with the Agents to initiate backups
and restores of the Client they are on. Backups may be performed via the Client
application or the Client Web UI, while restores may be performed via the Client Web
UI or the Web Restore interface. When restoring data, only data from Clients within
the same domain can be accessed.
Dell EMC™ Avamar®
v18.1
Security Target
Doc No: 2095-000-D102 Version: 1.8 Date: 19 September 2019 Page 3 of 40
The Avamar NDMP Accelerator acts as a front-end to NDMP-based storage systems
(such as Dell EMC VNX) to enable backups and restores of the data sets on a storage
system with an Avamar Server. Avamar NDMP Accelerators are delivered as
physical appliances running the NDMP Accelerator software.
The Avamar VMware Universal Proxy acts as a proxy backup server and is installed
as a virtual machine on VMware vSphere ESXi platforms. One Universal Proxy
instance can provide backup and restore functionality to multiple other virtual
machines on the same or different ESXi platforms. The Universal Proxy uses the
VMware vStorage API for Data Protection (VADP). The Avamar VMware Universal
Proxy is delivered as software.
The TOE is a combined software and hardware TOE.
TOE Environment
1.4.1
The required components from the TOE Environment are specified in the
following table.
Component Operating System Hardware
Management Workstation Red Hat Enterprise Linux
Release (RHEL) 7 (64-bit)
Microsoft Windows 10
General Purpose
Computing Hardware
Client Systems Windows Server 2016 (64-
bit)
SLES 12 (64-bit)
General Purpose
Computing Hardware
VMWare Servers VMWare vSphere ESXi 6.0 General Purpose
Computer Hardware
NDMP-Based Storage Unity 4.4.0 General purpose storage
device front-ended by the
NDMP Accelerator
Table 1 – Non-TOE Hardware and Software
1.5 TOE DESCRIPTION
Physical Scope
1.5.1
The TOE includes the following components:
Component Version
Avamar Server Appliance Multi-node system with Gen4T Hardware
and supporting the MCCLI
NDMP Accelerator Appliance Gen4T NDMP Accelerator Node
Dell EMC™ Avamar®
v18.1
Security Target
Doc No: 2095-000-D102 Version: 1.8 Date: 19 September 2019 Page 4 of 40
Component Version
Avamar Server Software V18.1.0.33 with Hotfixes 301590, 300449,
300443, 305019, 309443, and
AvPlatformOsRollup Security Patch
Avamar NDMP Accelerator Software V18.1.0.33
Avamar Agent for Windows V18.1.100.33
Avamar Agent for Linux V18.1.100.33
Avamar VMware Universal Proxy V18.1.100.33
Avamar MCGUI for Windows V18.1.0.33
Avamar MCGUI for Linux V18.1.0.33
Table 2 – TOE Components
For the appliances, both the hardware and software are included in the TOE. For
the software instances, only the Avamar-specific software is included in the TOE.
For the Universal Proxy, the entire virtual machine is included in the TOE. Figure
1 illustrates the TOE in its evaluated configuration.
Dell EMC™ Avamar®
v18.1
Security Target
Doc No: 2095-000-D102 Version: 1.8 Date: 19 September 2019 Page 5 of 40
Figure 1 – Avamar TOE Diagram
1.5.1.1 TOE Delivery
The Avamar Server appliances come pre-loaded with the TOE software and are
shipped directly to the customer. All other software components are available for
download to registered customers at: https://support.emc.com/downloads/.
The following table identifies each TOE software component in its delivered
format:
Dell EMC™ Avamar®
v18.1
Security Target
Doc No: 2095-000-D102 Version: 1.8 Date: 19 September 2019 Page 6 of 40
Software Version File Name/Format
Avamar Server Software V18.1.0.33
AvamarBundle_SLES11_64-18.1.0-
33.zip
Avamar Server Hotfix 301590 V18.1.0.33 V18.1.0.33_HF_301590.avp
Avamar Server Hotfix 300449 V18.1.0.33 HF300449.tgz
Avamar Server Hotfix 300443 V18.1.0.33 V18_1_0_33_HF_300443.avp
Avamar Server Hotfix 305019 V18.1.0.33
Gen4TcpuSecurityHotfix-
HF305019.avp
Avamar Server Hotfix 309443 V18.1.0.33 WorkflowUpdate-v1.avp
AvPlatformOsRollup Security
Patch
V18.1.0.33
AvPlatformOsRollup_2019-R1-
v4.avp
Avamar NDMP Accelerator
Software
V18.1.0.33 AcceleratorInstallSles-18.1.0-33.avp
Avamar MCGUI for Windows V18.1.0.33
AvamarConsoleMultiple-windows-
x86_64-18.1.0-33.exe
Avamar MCGUI for Linux V18.1.0.33
AvamarConsole-linux-rhel-x86_64-
18.1.0-33.rpm
Avamar VMware Universal Proxy V18.1.100.33
AvamarCombinedProxy-linux-
sles12sp1_64-18.1.100-33.ova
Avamar Agent for Windows V18.1.100.33
AvamarClient-windows-x86_64-
18.1.100-33.msi
Avamar Agent for SLES V18.1.100.33
AvamarClient-linux-sles11sp1-
x86_64-18.1.100-33.rpm
Table 3 - TOE Software Files & Format
1.5.1.2 TOE Guidance
The TOE includes the following guidance documentation:
• Dell EMC Avamar, Administration Guide, Version 18.1, July 2018
• Dell EMC Avamar Backup Clients, User Guide, Version 18.1, July 2018
• Dell EMC Avamar for VMware, User Guide, Version 18.1, July 2018
• Dell EMC Avamar for Windows Servers, User Guide, Version 18.1, July
2018
• Dell EMC Avamar, Management Console Command Line Interface (MCCLI)
Guide, Version 18.1, July 2018
• Dell EMC Avamar, NDMP Accelerator for Dell EMC NAS Systems, User
Guide, Version 18.1, July 2018
Dell EMC™ Avamar®
v18.1
Security Target
Doc No: 2095-000-D102 Version: 1.8 Date: 19 September 2019 Page 7 of 40
• Dell EMC Avamar, Product Security Guide, Version 18.1, July 2018
• Dell EMC Avamar, Virtual Edition for VMware, Version 18.1, July 2018
All guidance documentation is provided in PDF format and is available for
download to registered users at: https://support.emc.com/products/ .
Logical Scope
1.5.2
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. Table 4 summarizes the logical
scope of the TOE.
Functional Classes Description
Security Audit Audit entries are generated for security related events, and
can be reviewed by authorized users. System time is
maintained and included in all audit records.
User Data Protection The TOE uses the Server Access Control SFP to control
access through the management interfaces on the server.
Users may only access data within their assigned domain.
The user’s role defines the type of operations the user can
perform on the data within their domain.
The Client Access Control SFP controls how users access
the TOE through a client system. Only the data from the
client system and its related audit data can be viewed from
the client system. The user must be assigned to the client
within the TOE and can then perform the actions that the
user’s role allows.
Identification and
Authentication
Users of the management interfaces must identify and
authenticate prior to gaining TOE access.
Security Management The TOE provides management capabilities via the GUI and
CLI interfaces. Multiple roles are supported to provide
varying levels of access to data and functions. Users are
assigned to domains, and their data access is limited to
their assigned domain.
Protection of the TSF The TOE provides reliable time stamps for auditable events.
Table 4 – Logical Scope of the TOE
Functionality Excluded from the Evaluated
1.5.3
Configuration
The following product features are excluded from this evaluation:
• REST API - Disabled (requires installation)
• EMC Secure Remote Services (ESRS) – Not used (requires configuration)
Dell EMC™ Avamar®
v18.1
Security Target
Doc No: 2095-000-D102 Version: 1.8 Date: 19 September 2019 Page 8 of 40
• Enterprise authentication – Disabled (requires configuration)
• Local user access from clients (pass-through authentication) – Not used
(requires configuration)
The MCGUI application is supported on Microsoft Windows 8.x, as well as
Microsoft Windows Server 2003, 2008 and 2012.
Agents are supported on the following operating systems (in addition to those
specified in Table 1): AIX, CentOS, Debian, Free BSD, HP-UX, Mac OS X, Novell
Netware, Novell Open Enterprise Server, Oracle Linux, RHEL, Red Hat Linux,
SCO UNIX, Solaris, SLES, Symantec Enterprise Vault, Ubuntu, Windows, and
Windows Storage Server.
In addition to vSphere ESXi 6.0, the Universal Proxy is supported on ESXi 5.x.
• In addition to internal validation of user credentials by Avamar, external
validation via integration with LDAP servers is also supported. This feature
requires configuration and is not used as part of the evaluation.
Dell EMC™ Avamar®
v18.1
Security Target
Doc No: 2095-000-D102 Version: 1.8 Date: 19 September 2019 Page 9 of 40
2 CONFORMANCE CLAIMS
2.1 COMMON CRITERIA CONFORMANCE CLAIM
This Security Target claims to be conformant to Version 3.1 of Common Criteria
for Information Technology Security Evaluation according to:
• Common Criteria for Information Technology Security Evaluation, Part 1:
Introduction and General Model; CCMB-2017-04-001, Version 3.1,
Revision 5, April 2017
• Common Criteria for Information Technology Security Evaluation, Part 2:
Security Functional Components; CCMB-2017-04-002, Version 3.1,
Revision 5, April 2017
• Common Criteria for Information Technology Security Evaluation, Part 3:
Security Assurance Components CCMB-2017-04-003, Version 3.1,
Revision 5, April 2017
As follows:
• CC Part 2 extended
• CC Part 3 conformant
The Common Methodology for Information Technology Security Evaluation,
Version 3.1, Revision 5, April 2017 has been taken into account.
2.2 PROTECTION PROFILE CONFORMANCE
CLAIM
This ST does not claim conformance of the TOE with any Protection Profile (PP).
2.3 PACKAGE CLAIM
This Security Target claims conformance to Evaluation Assurance Level 2
augmented with ALC_FLR.2 Flaw Reporting Procedures.
2.4 CONFORMANCE RATIONALE
This ST does not claim conformance of the TOE with any PP, therefore a
conformance rationale is not applicable.
Dell EMC™ Avamar®
v18.1
Security Target
Doc No: 2095-000-D102 Version: 1.8 Date: 19 September 2019 Page 10 of 40
3 SECURITY PROBLEM DEFINITION
3.1 THREATS
Table 5 lists the threats addressed by the TOE.
Potential threat agents are unauthorized persons. 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.
Threat Description
T.IMPCON An unauthorized user may inappropriately change the
configuration of the TOE causing potential unauthorized data
accesses to go undetected.
T.PRIVILEGE An unauthorized user may gain access to the TOE and exploit
system privileges to gain access to TOE security functions and
data.
T.UNAUTH_ACCESS An unauthorized user may attempt to access user data (backup
files) which could result in data leakage.
Table 5 – Threats
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.
OSP Description
P.ACCOUNT The authorized users of the TOE shall be held accountable for
their actions within the TOE.
P.BACKUP The TOE shall backup specified client data and make it available
for restore operations.
P.MANAGE The TOE shall be managed only by authorized users.
Table 6 – Organizational Security Policies
3.3 ASSUMPTIONS
The assumptions required to ensure the security of the TOE are listed in Table 7.
Dell EMC™ Avamar®
v18.1
Security Target
Doc No: 2095-000-D102 Version: 1.8 Date: 19 September 2019 Page 11 of 40
Assumptions Description
A.MANAGE There are one or more competent individuals assigned to
manage the TOE.
A.NETWORK The TOE components, front-end hosts, back-end storage and
management workstations will be interconnected by a
segregated network that protects the traffic from disclosure to or
modification by untrusted systems or users.
A.NOEVIL The authorized administrators are not careless, wilfully negligent,
or hostile, are appropriately trained and will follow the
instructions provided by the TOE documentation.
A.PROTECT The hardware and software critical to TOE security policy
enforcement will be protected from unauthorized physical
modification.
Table 7 – Assumptions
Dell EMC™ Avamar®
v18.1
Security Target
Doc No: 2095-000-D102 Version: 1.8 Date: 19 September 2019 Page 12 of 40
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.
Security
Objective
Description
O.ACCESS The TOE must allow authorized users to access only appropriate
TOE functions and data.
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 audit records for security related events.
O.BACKUP The TOE shall backup specified client data and make it available
for restore operations.
O.IDENTAUTH The TOE must be able to identify and authenticate users prior to
allowing access to TOE functions and data.
O.PROTECT The TOE must ensure the integrity of all system and audit data
by protecting itself from unauthorized access.
O.TIME The TOE must provide reliable timestamps.1
Table 8 – Security Objectives for the TOE
1
The O.TIME objective only applies to the Avamar Server and NDMP Accelerator.
Dell EMC™ Avamar®
v18.1
Security Target
Doc No: 2095-000-D102 Version: 1.8 Date: 19 September 2019 Page 13 of 40
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.
Security
Objective
Description
OE.INSTALL Those responsible for the TOE must ensure that the TOE is
delivered, installed, managed, and operated in a manner which is
consistent with TOE guidance documents.
OE.NETWORK The operational environment will provide a segregated network
that protects the traffic between the TOE components and front-
end hosts, back-end storage and management workstations from
disclosure to or modification by untrusted systems or users.
OE.PERSON Personnel working as authorized administrators shall be carefully
selected and trained for proper operation of the system.
OE.PHYSICAL Those responsible for the TOE must ensure that those parts of
the TOE critical to security policy are protected from any physical
attack.
OE.TIME The operational environment will maintain reliable timestamps
for use by TOE components.2
Table 9 – Security Objectives for the Operational Environment
4.3 SECURITY OBJECTIVES RATIONALE
The following table maps the security objectives to the assumptions, threats,
and organizational policies identified for the TOE.
T.IMPCON
T.PRIVILEGE
T.UNAUTH_ACCESS
P.ACCOUNT
P.BACKUP
P.MANAGE
A.MANAGE
A.NETWORK
A.NOEVIL
A.PROTECT
2
The OE.TIME objective only applies to the Avamar Agent and Universal Proxy
components.
Dell EMC™ Avamar®
v18.1
Security Target
Doc No: 2095-000-D102 Version: 1.8 Date: 19 September 2019 Page 14 of 40
T.IMPCON
T.PRIVILEGE
T.UNAUTH_ACCESS
P.ACCOUNT
P.BACKUP
P.MANAGE
A.MANAGE
A.NETWORK
A.NOEVIL
A.PROTECT
O.ACCESS X X X X
O.ADMIN X X
O.AUDIT X X
O.BACKUP X
O.IDENTAUTH X X X X
O.PROTECT X X
O.TIME X
OE.INSTALL X X X
OE.NETWORK X
OE.PERSON X X X
OE.PHYSICAL X X
OE.TIME X
Table 10 – Mapping Between Objectives, Threats, OSPs, and Assumptions
Security Objectives Rationale Related to
4.3.1
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.IMPCON
An unauthorized user may inappropriately change the configuration
of the TOE causing potential unauthorized data accesses to go
undetected.
Objectives: O.ACCESS The TOE must allow authorized users to
access only appropriate TOE functions and
data.
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.
Dell EMC™ Avamar®
v18.1
Security Target
Doc No: 2095-000-D102 Version: 1.8 Date: 19 September 2019 Page 15 of 40
O.IDENTAUTH The TOE must be able to identify and
authenticate users prior to allowing access to
TOE functions and data.
OE.INSTALL Those responsible for the TOE must ensure
that the TOE is delivered, installed, managed,
and operated in a manner which is consistent
with TOE guidance documents.
Rationale: The OE.INSTALL objective states the authorized administrators will
configure the TOE properly. The O.ADMIN objective ensures the
TOE has all the necessary administrator functions to manage the
product. The O.IDENTAUTH objective provides for authentication of
users prior to any TOE function accesses. The O.ACCESS objective
builds upon the O.IDENTAUTH objective by only permitting
authorized users to access TOE functions.
Threat:
T.PRIVILEGE
An unauthorized user may gain access to the TOE and exploit
system privileges to gain access to TOE security functions and data.
Objectives: O.ACCESS The TOE must allow authorized users to
access only appropriate TOE functions and
data.
O.IDENTAUTH The TOE must be able to identify and
authenticate users prior to allowing access to
TOE functions and data.
O.PROTECT The TOE must ensure the integrity of all
system and audit data by protecting itself
from unauthorized access.
Rationale: The O.IDENTAUTH objective provides for authentication of users
prior to any TOE function accesses. The O.ACCESS objective builds
upon the O.IDENTAUTH objective by only permitting authorized
users to access TOE functions. The O.PROTECT objective addresses
this threat by providing TOE self-protection.
Threat:
T.UNAUTH_
ACCESS
An unauthorized user may attempt to access user data (backup
files) which could result in data leakage.
Objectives: O.ACCESS The TOE must allow authorized users to
access only appropriate TOE functions and
data.
O.AUDIT The TOE must record audit records for security
related events.
Dell EMC™ Avamar®
v18.1
Security Target
Doc No: 2095-000-D102 Version: 1.8 Date: 19 September 2019 Page 16 of 40
Rationale: The O.ACCESS objective only permits authorized access TO TOE
data. The O.AUDITS objective supports O.ACCESS by requiring the
TOE to record audit data for unauthorized access attempts.
Security Objectives Rationale Related to OSPs
4.3.2
The security objectives rationale related to OSPs traces the security objectives
for the TOE and the Operational Environment back to the OSPs applicable to the
TOE.
Policy:
P.ACCOUNT
The authorized users of the TOE shall be held accountable for their
actions within the TOE.
Objectives: O.AUDIT The TOE must record audit records for security
related events.
O.IDENTAUTH The TOE must be able to identify and
authenticate users prior to allowing access to
TOE functions and data.
O.TIME The TOE must provide reliable timestamps.
OE.TIME The operational environment will maintain
reliable timestamps for use by TOE
components.
Rationale: The O.AUDIT objective implements this policy by requiring auditing
of all data accesses and use of TOE functions. The O.TIME objective
supports this policy by providing a time stamp for insertion into the
audit records on TOE components that are complete appliances.
The OE.TIME objective supports this policy by providing a time
stamp for the remaining TOE components. The O.IDENTAUTH
objective supports this objective by ensuring each user is uniquely
identified and authenticated.
Policy:
P.BACKUP
The TOE shall backup specified client data and make it available for
restore operations.
Objectives: O.BACKUP The TOE shall backup specified client data and
make it available for restore operations.
Rationale: The O.BACKUP objective requires the TOE to backup specified client
data and makes it available for restore operations.
Policy:
P.MANAGE
The TOE shall be managed only by authorized users.
Objectives: O.ACCESS The TOE must allow authorized users to
Dell EMC™ Avamar®
v18.1
Security Target
Doc No: 2095-000-D102 Version: 1.8 Date: 19 September 2019 Page 17 of 40
access only appropriate TOE functions and
data.
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
TOE functions and data.
O.PROTECT The TOE must ensure the integrity of all
system and audit data by protecting itself
from unauthorized access.
OE.INSTALL Those responsible for the TOE must ensure
that the TOE is delivered, installed, managed,
and operated in a manner which is consistent
with TOE guidance documents.
OE.PERSON Personnel working as authorized
administrators shall be carefully selected and
trained for proper operation of the System.
Rationale: The OE.PERSON objective ensures competent administrators will
manage the TOE and the O.ADMIN objective ensures there is a set
of functions for administrators to use. The OE.INSTALL objective
supports the OE.PERSON objective by ensuring administrators
follow all provided documentation and maintain the security policy.
The O.IDENTAUTH objective provides for authentication of users
prior to any TOE function accesses. The O.ACCESS objective builds
upon the O.IDENTAUTH objective by only permitting authorized
users to access TOE functions. The O.PROTECT objective addresses
this policy by providing TOE self-protection.
Security Objectives Rationale Related to
4.3.3
Assumptions
The security objectives rationale related to assumptions traces the security
objectives for the operational environment back to the assumptions for the
TOE’s operational environment.
Assumption:
A.MANAGE
There are one or more competent individuals assigned to manage
the TOE.
Objectives: OE.PERSON Personnel working as authorized
administrators shall be carefully selected and
trained for proper operation of the System.
Rationale: The OE.PERSON objective ensures all authorized administrators are
Dell EMC™ Avamar®
v18.1
Security Target
Doc No: 2095-000-D102 Version: 1.8 Date: 19 September 2019 Page 18 of 40
qualified and trained to manage the TOE.
Assumption:
A.NETWORK
The TOE components, front-end hosts, back-end storage and
management workstations will be interconnected by a segregated
network that protects the traffic from disclosure to or modification
by untrusted systems or users.
Objectives: OE.NETWORK The operational environment will provide a
segregated network that protects the traffic
between the TOE components and front-end
hosts, back-end storage and management
workstations from disclosure to or modification
by untrusted systems or users.
Rationale: The OE.NETWORK objective ensures that the management traffic
will be protected by a segregated LAN.
Assumption:
A.NOEVIL
The authorized administrators are not careless, wilfully negligent,
or hostile, are appropriately trained and will follow the instructions
provided by the TOE documentation.
Objectives: OE.INSTALL Those responsible for the TOE must ensure
that the TOE is delivered, installed, managed,
and operated in a manner which is consistent
with TOE guidance documents.
OE.PERSON Personnel working as authorized
administrators shall be carefully selected and
trained for proper operation of the system.
OE.PHYSICAL Those responsible for the TOE must ensure
that those parts of the TOE critical to security
policy are protected from any physical attack.
Rationale: The OE.INSTALL objective ensures that the TOE is properly
installed and operated and the OE.PHYSICAL objective provides for
physical protection of the TOE by authorized administrators. The
OE.PERSON objective ensures all authorized administrators are
qualified and trained to manage the TOE.
Assumption:
A.PROTECT
The hardware and software critical to TOE security policy
enforcement will be protected from unauthorized physical
modification.
Objectives: OE.PHYSICAL Those responsible for the TOE must ensure
that those parts of the TOE critical to security
policy are protected from any physical attack.
Dell EMC™ Avamar®
v18.1
Security Target
Doc No: 2095-000-D102 Version: 1.8 Date: 19 September 2019 Page 19 of 40
Rationale: The OE.PHYSICAL objective provides for the physical protection of
the TOE software and the hardware on which it is installed.
Dell EMC™ Avamar®
v18.1
Security Target
Doc No: 2095-000-D102 Version: 1.8 Date: 19 September 2019 Page 20 of 40
5 EXTENDED COMPONENTS DEFINITION
5.1 SECURITY FUNCTIONAL REQUIREMENTS
This section specifies the extended Security Functional Requirements (SFRs)
used in this ST. The following extended SFR has been created to address
additional security features of the TOE:
a. User Data Backup/Restore (FDP_BCK_EXT.1)
Family FDP_BCK_EXT: User Data
5.1.1
Backup/Restore
User Data Backup/Restore provides for the functionality to perform backup and
restore operations as directed by administrators and users. The User Data
Backup/Restore family was modeled after FDP_ACC: Access Control Policy. The
User Data Backup/Restore SFR was loosely modeled after FDP_ACC.1: Subset
access control.
Family Behaviour
This family defines the requirements for the TOE to provide backup and restore
services for IT systems in the operational environment.
Component Levelling
Figure 2 – FDP_BCK_EXT: User Data Backup/Restore Component Levelling
Management
The following actions could be considered for the management functions in FMT:
a) Configuration of the backup and restore operations to be performed.
Audit
There are no auditable events foreseen.
5.1.1.1 FDP_BCK_EXT.1 User Data Backup/Restore
Hierarchical to: No other components.
Dependencies: None
FDP_BCK_EXT.1.1 The TSF shall provide a capability to backup systems as configured
by authorized administrators.
FDP_BCK_EXT.1.2 The TSF shall provide a capability for authorized administrators to
restore files to systems from previously-created backups.
FDP_BCK_EXT: User Data Backup/Restore 1
Dell EMC™ Avamar®
v18.1
Security Target
Doc No: 2095-000-D102 Version: 1.8 Date: 19 September 2019 Page 21 of 40
FDP_BCK_EXT.1.3 The TSF shall provide a capability for authorized users on a system
to restore files from previously-created backups of that same
system, subject to file access control permissions configured on that
system for the user.
5.2 SECURITY ASSURANCE REQUIREMENTS
This ST does not include extended Security Assurance Requirements.
Dell EMC™ Avamar®
v18.1
Security Target
Doc No: 2095-000-D102 Version: 1.8 Date: 19 September 2019 Page 22 of 40
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, extended requirements, 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 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:
Class Identifier Name
Security Audit (FAU) FAU_GEN.1 Audit data generation
FAU_GEN.2 User identity association
FAU_SAR.1 Audit review
FAU_SAR.2 Restricted audit review
Dell EMC™ Avamar®
v18.1
Security Target
Doc No: 2095-000-D102 Version: 1.8 Date: 19 September 2019 Page 23 of 40
Class Identifier Name
User Data Protection
(FDP)
FDP_ACC.1(1) Subset access control (server)
FDP_ACC.1(2) Subset access control (client)
FDP_ACF.1(1) Security attribute based access control
(server)
FDP_ACF.1(2) Security attribute based access control
(client)
FDP_BCK_EXT.1 User data backup/restore
Identification and
Authentication (FIA)
FIA_ATD.1 User attribute definition
FIA_UAU.2 User authentication before any action
FIA_UAU.7 Protected authentication feedback
FIA_UID.2 User identification before any action
Security Management
(FMT)
FMT_MSA.1(1) Management of security attributes
(server)
FMT_MSA.1(2) Management of security attributes
(client)
FMT_MSA.3(1) Static attribute initialisation (server)
FMT_MSA.3(2) Static attribute initialisation (client)
FMT_SMF.1 Specification of management functions
FMT_SMR.1 Security roles
Protection of the TSF
(FPT)
FPT_STM.1 Reliable time stamps
Table 11 – Summary of Security Functional Requirements
Security Audit (FAU)
6.2.1
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 an audit record of the following
auditable events:
a) Start-up and shutdown of the audit functions;
Dell EMC™ Avamar®
v18.1
Security Target
Doc No: 2095-000-D102 Version: 1.8 Date: 19 September 2019 Page 24 of 40
b) All auditable events for the [not specified] level of audit; and
c) [all logins and logouts on the system; and
d) all user actions performed].
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 (if
applicable), 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, [no additional
information].
6.2.1.2 FAU_GEN.2 User identity association
Hierarchical to: No other components.
Dependencies: FAU_GEN.1 Audit data generation
FIA_UID.1 Timing of identification
FAU_GEN.2.1 For audit events resulting from actions of identified users, the TSF shall
be able to associate each auditable event with the identity of the user
that caused the event.
6.2.1.3 FAU_SAR.1 Audit review
Hierarchical to: No other components.
Dependencies: FAU_GEN.1 Audit data generation
FAU_SAR.1.1 The TSF shall provide [Root Administrators and Domain Administrators]
with the capability to read [all audit data] 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.
6.2.1.4 FAU_SAR.2 Restricted audit review
Hierarchical to: No other components.
Dependencies: FAU_SAR.1 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.
User Data Protection (FDP)
6.2.2
6.2.2.1 FDP_ACC.1(1) Subset access control (Server)
Hierarchical to: No other components.
Dependencies: FDP_ACF.1(1) Security attribute based access
control (Server)
FDP_ACC.1.1(1) The TSF shall enforce the [Server Access Control SFP] on [
Subjects: Users on client machines;
Objects: Clients, Backup Files;
Operations: Backup, Restore].
Dell EMC™ Avamar®
v18.1
Security Target
Doc No: 2095-000-D102 Version: 1.8 Date: 19 September 2019 Page 25 of 40
6.2.2.2 FDP_ACC.1(2) Subset access control (Client)
Hierarchical to: No other components.
Dependencies: FDP_ACF.1(2) Security attribute based access
control (Client)
FDP_ACC.1.1(2) The TSF shall enforce the [Client Access Control SFP] on [
Subjects: Users on client machines;
Objects: Clients, Backup Files;
Operations: Backup, Restore].
6.2.2.3 FDP_ACF.1(1) Security attribute based access control
(Server)
Hierarchical to: No other components.
Dependencies: FDP_ACC.1(1) Subset access control (Server)
FMT_MSA.3(1) Static attribute initialisation
(Server)
FDP_ACF.1.1(1) The TSF shall enforce the [Server access control SFP] to objects
based on the following: [
• Subjects: Authorized Users
Security Attributes: UserID, Role, associated Domain
• Objects: User data3
Security Attributes: associated Domain
].
FDP_ACF.1.2(1) The TSF shall enforce the following rules to determine if an
operation among controlled subjects and controlled objects is
allowed: [
1. Users with the Root Administrator, Domain Administrator,
Backup Only Operator, and Backup/Restore Operator roles
may perform a backup operation from a Client in the same
Domain (or one that is subordinate) to the user’s associated
Domain.
2. Users with the Root Administrator, Domain Administrator,
Restore Only Operator, and Backup/Restore Operator roles
may perform a restore operation:
a. from a Backup File in the same Domain (or one that is
subordinate) to the user’s associated Domain
b. to a Client in the same Domain (or on that is subordinate)
to the user’s associated Domain.].
FDP_ACF.1.3(1) The TSF shall explicitly authorise access of subjects to objects
based on the following additional rules: [all Domains are
considered subordinate to the root level and are therefore
accessible to user accounts defined at the root level].
3
User data is categorized as any data on a client machine that can be backed up or
restored by the TOE.
Dell EMC™ Avamar®
v18.1
Security Target
Doc No: 2095-000-D102 Version: 1.8 Date: 19 September 2019 Page 26 of 40
FDP_ACF.1.4(1) The TSF shall explicitly deny access of subjects to objects based
on the following additional rules: [none].
6.2.2.4 FDP_ACF.1(2) Security attribute based access control
(Client)
Hierarchical to: No other components.
Dependencies: FDP_ACC.1(2) Subset access control (Client)
FMT_MSA.3(2) Static attribute initialisation (Client)
FDP_ACF.1.1(2) The TSF shall enforce the [Client access control SFP] to objects
based on the following: [
• Subjects: Authorized Users
Security Attributes: UserID, Role, associated Domain
• Objects: User data
Security Attributes: associated Domain
].
FDP_ACF.1.2(2) The TSF shall enforce the following rules to determine if an
operation among controlled subjects and controlled objects is
allowed: [
1. Users with the Backup Only User and Backup/Restore User
roles may perform a backup operation from the Client on
which the user is executing if the Client’s Domain is in the
User’s Domain.
2. Users with the Restore Only User, Backup/Restore User, and
Restore/Ignore File Permissions User roles may perform a
restore operation (from a backup file in the same (or
subordinate) Domain as the Client on which the user is
executing) to the Client on which the user is executing.].
FDP_ACF.1.3(2) The TSF shall explicitly authorise access of subjects to objects
based on the following additional rules: [no additional rules].
FDP_ACF.1.4(2) The TSF shall explicitly deny access of subjects to objects based
on the following additional rules: [none].
6.2.2.5 FDP_BCK_EXT.1 User data backup/restore
Hierarchical to: No other components.
Dependencies: None
FDP_BCK_EXT.1.1 The TSF shall provide a capability to backup systems as configured
by authorized administrators.
FDP_BCK_EXT.1.2 The TSF shall provide a capability for authorized administrators to
restore files to systems from previously-created backups.
FDP_BCK_EXT.1.3 The TSF shall provide a capability for authorized users on a system
to restore files from previously-created backups of that same
system, subject to file access control permissions configured on that
system for the user.
Dell EMC™ Avamar®
v18.1
Security Target
Doc No: 2095-000-D102 Version: 1.8 Date: 19 September 2019 Page 27 of 40
Identification and Authentication (FIA)
6.2.3
6.2.3.1 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 users: [Username, Password, Role, associated Domain].
6.2.3.2 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.3 FIA_UAU.7 Protected authentication feedback
Hierarchical to: No other components.
Dependencies: FIA_UAU.1 Timing of authentication
FIA_UAU.7.1 The TSF shall provide only [dots for the GUI, no output for the CLI] to
the user while the authentication is in progress.
6.2.3.4 FIA_UID.2 User identification before any action
Hierarchical to: FIA_UID.1 Timing of authentication.
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.
Security Management (FMT)
6.2.4
6.2.4.1 FMT_MSA.1(1) Management of security attributes
(Server)
Hierarchical to: No other components.
Dependencies: [FDP_ACC.1(1) Subset access control (server), or
FDP_IFC.1 Subset information flow control]
FMT_SMR.1 Security roles
FMT_SMF.1 Specification of Management Functions
FMT_MSA.1.1(1) The TSF shall enforce the [Server access control SFP] to restrict
the ability to [query, modify] the security attributes [Users: Role
and Domain; Clients: Domain] to [users with the Root
Administrator or Domain Administrator roles].
6.2.4.2 FMT_MSA.1(2) Management of security attributes (Client)
Hierarchical to: No other components.
Dependencies: [FDP_ACC.1(2) Subset access control (Server), or
FDP_IFC.1 Subset information flow control]
FMT_SMR.1 Security roles
Dell EMC™ Avamar®
v18.1
Security Target
Doc No: 2095-000-D102 Version: 1.8 Date: 19 September 2019 Page 28 of 40
FMT_SMF.1 Specification of Management Functions
FMT_MSA.1.1(2) The TSF shall enforce the [Client access control SFP] to restrict
the ability to [query, modify] the security attributes [Users: Role
and Domain; Clients: Domain] to [users with the Root
Administrator or Domain Administrator roles].
6.2.4.3 FMT_MSA.3(1) Static attribute initialisation (Server)
Hierarchical to: No other components.
Dependencies: FMT_MSA.1(1) Management of security attributes
(server)
FMT_SMR.1 Security roles
FMT_MSA.3.1(1) The TSF shall enforce the [Server Access control SFP] to provide
[restrictive] default values for security attributes that are used to
enforce the SFP.
FMT_MSA.3.2(1) The TSF shall allow the [users with the Root Administrator or
Domain Administrator roles] to specify alternative initial values to
override the default values when an object or information is
created.
6.2.4.4 FMT_MSA.3(2) Static attribute initialisation (Client)
Hierarchical to: No other components.
Dependencies: FMT_MSA.1(2) Management of security attributes
(client)
FMT_SMR.1 Security roles
FMT_MSA.3.1(2) The TSF shall enforce the [Client Access control SFP] to provide
[restrictive] default values for security attributes that are used to
enforce the SFP.
FMT_MSA.3.2(2) The TSF shall allow the [users with the Root Administrator or
Domain Administrator roles] to specify alternative initial values to
override the default values when an object or information is
created.
6.2.4.5 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: [
• User management
• Client and Client Group management
• Domain management
• Operations Processing management
• Scheduled Operations management].
6.2.4.6 FMT_SMR.1 Security roles
Hierarchical to: No other components.
Dependencies: FIA_UID.1 Timing of identification
Dell EMC™ Avamar®
v18.1
Security Target
Doc No: 2095-000-D102 Version: 1.8 Date: 19 September 2019 Page 29 of 40
FMT_SMR.1.1 The TSF shall maintain the roles [Root Administrator, Domain
Administrator, Restore Only Operator, Backup Only Operator,
Backup/Restore Operator, Activity Operator, Backup Only User, Restore
Only User, Backup/Restore User, Restore Only/Ignore File Permissions
User].
FMT_SMR.1.2 The TSF shall be able to associate users with roles.
Protection of the TSF (FPT)
6.2.5
6.2.5.1 FPT_STM.1 Reliable time stamps
Hierarchical to: No other components.
Dependencies: No dependencies.
FPT_STM.1.1 The TSF shall be able to provide reliable time stamps.
Application Note: This SFR applies to the Avamar Server and NDMP Accelerator.
6.3 SECURITY ASSURANCE REQUIREMENTS
The assurance requirements are summarized in Table 12.
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
Dell EMC™ Avamar®
v18.1
Security Target
Doc No: 2095-000-D102 Version: 1.8 Date: 19 September 2019 Page 30 of 40
Assurance Class
Assurance Components
Identifier Name
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
Table 12 – Security Assurance Requirements
6.4 SECURITY REQUIREMENTS RATIONALE
Security Functional Requirements Rationale
6.4.1
The following Table provides a mapping between the SFRs and Security
Objectives.
O.ACCESS
O.ADMIN
O.AUDIT
O.BACKUP
O.IDENTAUTH
O.PROTECT
O.TIME
FAU_GEN.1 X
FAU_GEN.2 X
FAU_SAR.1 X
FAU_SAR.2 X
FDP_ACC.1(1) X X
Dell EMC™ Avamar®
v18.1
Security Target
Doc No: 2095-000-D102 Version: 1.8 Date: 19 September 2019 Page 31 of 40
O.ACCESS
O.ADMIN
O.AUDIT
O.BACKUP
O.IDENTAUTH
O.PROTECT
O.TIME
FDP_ACC.1(2) X X
FDP_ACF.1(1) X X
FDP_ACF,1(2) X X
FDP_BCK_EXT.1 X
FIA_ATD.1 X
FIA_UAU.2 X X
FIA_UAU.7 X X
FIA_UID.2 X X
FMT_MSA.1(1) X X X
FMT_MSA.1(2) X X X
FMT_MSA.3(1) X X
FMT_MSA.3(2) X X
FMT_SMF.1 X
FMT_SMR.1 X X
FPT_STM.1 X X
Table 13 – Mapping of SFRs to Security Objectives
SFR Rationale Related to Security Objectives
6.4.2
The following rationale traces each SFR back to the Security Objectives for the
TOE.
Objective:
O.ACCESS
The TOE must allow authorized users to access only appropriate
TOE functions and data.
Security
Functional
Requirements:
FIA_UAU.2 User authentication before any action
FIA_UAU.7 Protected authentication feedback
FIA_UID.2 User identification before any action
Dell EMC™ Avamar®
v18.1
Security Target
Doc No: 2095-000-D102 Version: 1.8 Date: 19 September 2019 Page 32 of 40
FMT_MSA.1(1) Management of security attributes (server)
FMT_MSA.1(2) Management of security attributes (client)
FMT_SMR.1 Security roles
Rationale: FIA_UID.2 and FIA_UAU.2 require users to complete the I&A
process, which ensures only authorized users gain access and
enables each user session to be bound to a role to limit.
FIA_UAU.7 protects the password from being observed, preventing
unauthorized users from gaining access to the TOE.
FMT_MSA.1(1) and FMT_MSA.1(2) define the access permissions to
TSF data for each role.
FMT_SMR.1 ensures the TOE supports multiple roles so that
appropriate data access can be provided to different users.
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(1) Management of security attributes (server)
FMT_MSA.1(2) Management of security attributes (client)
FMT_SMF.1 Specification of management functions
FMT_SMR.1 Security roles
Rationale: FMT_MSA.1(1) and FMT_MSA.1(2) define the access permissions
required for each role for TSF data.
FMT_SMF.1 specifies the management functionality required for
effective management of the TOE.
FMT_SMR.1 defines the roles required to provide effective
management capabilities for different categories of users.
Objective:
O.AUDIT
The TOE must record audit records for security related events.
Security
Functional
Requirements:
FAU_GEN.1 Audit data generation
FAU_GEN.2 User identity association
FAU_SAR.1 Audit review
FAU_SAR.2 Restricted audit review
FPT_STM.1 Reliable time stamps
Dell EMC™ Avamar®
v18.1
Security Target
Doc No: 2095-000-D102 Version: 1.8 Date: 19 September 2019 Page 33 of 40
Rationale: FAU_GEN.1 and FAU_GEN.2 require audit records to be generated
for specific events and define the contents of the records.
FAU_SAR.1 and FAU_SAR.2 require the audit records to be
available to all authorized users of the TOE, and for access to be
restricted for unauthorized users.
FPT_STM.1 requires accurate time stamps to be available for the
audit records.
Objective:
O.BACKUP
The TOE shall backup specified client data and make it available for
restore operations.
Security
Functional
Requirements:
FDP_ACC.1(1) Subset access control (server)
FDP_ACC.1(2) Subset access control (client)
FDP_ACF.1(1) Security attribute based access control
(server)
FDP_ACF.1(2) Security attribute based access control (client)
FDP_BCK_EXT.1 User data backup/restore
FMT_MSA.1(1) Management of security attributes (server)
FMT_MSA.1(2) Management of security attributes (client)
FMT_MSA.3(1) Static attribute initialisation (server)
FMT_MSA.3(2) Static attribute initialisation (client)
Rationale: FDP_ACC.1(1), FDP_ACC.1(2), FDP_ACF.1(1), and FDP_ACF.1(2)
assure that backup data is created as directed and is available for
restores subject to access rights.
FDP_BCK_EXT.1 ensures that the TOE supports backup and restore
operations by administrators and users.
FMT_MSA.1(1) and FMT_MSA.1(2) ensure that appropriate security
attributes are maintained for the subjects and objects.
FMT_MSA.3(1) and FMT_MSA.3(2) require that restrictive attributes
based on Domain membership are applied.
Objective:
O.IDENTAUTH
The TOE must be able to identify and authenticate users prior to
allowing access to TOE functions and data.
Security
Functional
FIA_ATD.1 User attribute definition
FIA_UAU.2 User authentication before any action
Dell EMC™ Avamar®
v18.1
Security Target
Doc No: 2095-000-D102 Version: 1.8 Date: 19 September 2019 Page 34 of 40
Requirements: FIA_UAU.7 Protected authentication feedback
FIA_UID.2 User identification before any action
Rationale: FIA_UID.2 and FIA_UAU.2 require users to complete the I&A
process, which ensures only authorized users gain access and
defines their access permissions prior to completing the I&A
process.
FIA_UAU.7 protects the password from being observed, preventing
unauthorized users from gaining access to the TOE.
FIA_ATD.1 specifies the security attributes that are supported for
each defined user account.
Objective:
O.PROTECT
The TOE must ensure the integrity of all system and audit data by
protecting itself from unauthorized access.
Security
Functional
Requirements:
FDP_ACC.1(1) Subset access control (server)
FDP_ACC.1(2) Subset access control (client)
FDP_ACF.1(1) Security attribute based access control
(server)
FDP_ACF.1(2) Security attribute based access control (client)
FMT_MSA.3(1) Static attribute initialisation (server)
FMT_MSA.3(2) Static attribute initialisation (client)
Rationale: FDP_ACC.1(1), FDP_ACC.1(2), FDP_ACF.1(1), and FDP_ACF.1(2)
define the access control policy for users of the Server and Agent
management interfaces.
FMT_MSA.3(1) and FMT_MSA.3(2) requires restrictive access to
backup data by default so that no access is granted until explicitly
configured by authorized users.
Objective:
O.TIME
The TOE must provide reliable timestamps.
Security
Functional
Requirements:
FPT_STM.1 Reliable time stamps
Rationale: FPT_STM.1 requires accurate time stamps to be available.
Dell EMC™ Avamar®
v18.1
Security Target
Doc No: 2095-000-D102 Version: 1.8 Date: 19 September 2019 Page 35 of 40
Dependency Rationale
6.4.3
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.
SFR Dependency
Dependency
Satisfied
Rationale
FAU_GEN.1 FPT_STM.1 
FAU_GEN.2 FAU_GEN.1 
FIA_UID.1  FIA_UID.2 is hierarchical to
FIA_UID.1; this dependency
has been satisfied.
FAU_SAR.1 FAU_GEN.1 
FAU_SAR.2 FAU_SAR.1 
FDP_ACC.1(1) FDP_ACF.1(1) 
FDP_ACC.1(2) FDP_ACF.1(2) 
FDP_ACF.1(1) FDP_ACC.1(1) 
FMT_MSA.3(1) 
FDP_ACF.1(2) FDP_ACC.1(2) 
FMT_MSA.3(2) 
FDP_BCK_EXT.1 None N/A
FIA_ATD.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_UAU.7 FIA_UAU.1  FIA_UAU.2 is hierarchical to
FIA_UAU.1; this dependency
has been satisfied.
FIA_UID.2 None N/A
FMT_MSA.1(1) FDP_ACC.1(1) or
FDP_IFC.1

FMT_SMR.1 
FMT_SMF.1 
FMT_MSA.1(2) FDP_ACC.1(2) or
FDP_IFC.1

Dell EMC™ Avamar®
v18.1
Security Target
Doc No: 2095-000-D102 Version: 1.8 Date: 19 September 2019 Page 36 of 40
SFR Dependency
Dependency
Satisfied
Rationale
FMT_MSA.1 
FMT_SMR.1 
FMT_MSA.3(1) FMT_MSA.1 
FMT_SMR.1 
FMT_MSA.3(2) FMT_MSA.1 
FMT_MSA.3 
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_STM.1 None N/A
Table 14 – Functional Requirement Dependencies
Security Assurance Requirements Rationale
6.4.4
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.
Dell EMC™ Avamar®
v18.1
Security Target
Doc No: 2095-000-D102 Version: 1.8 Date: 19 September 2019 Page 37 of 40
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 SECURITY AUDIT
Audit records are generated for the events specified with FAU_GEN.1. System
time is maintained and included in all audit records. The audit trail is maintained
on the Avamar Server.
Startup of the audit function is equivalent to a power on event. It is not possible
to shut down the audit function. The following information is included in all audit
records:
• Date and time of the event,
• Type of event,
• Subject identity (if applicable).
Users with the Root Administrator or Domain Administrator role may view the
audit records via the MCGUI application. Users with any other user roles are
denied access.
TOE Security Functional Requirements addressed: FAU_GEN.1, FAU_GEN.2,
FAU_SAR.1, FAU_SAR.2.
7.2 USER DATA PROTECTION
Administrators configure backup policies for applicable IT systems, and the TOE is
responsible for performing those configured backups. Administrators may
configure restore operations to be performed from backup files. Users may
perform restore operations to the system on which they are logged in.
Access control for the TOE differs depending on how a user accesses the TOE.
The users of the TOE fall into one of three categories: Administrators, Operators,
and Users. Operators and Administrators access the TOE via the MCGUI or
MCCLI. Their access permissions are defined by the Server Access Control SFP.
Users access the TOE only via a client system (using GUI and/or CLI interfaces
on the clients). Their access permissions are defined by the Client Access
Control SFP.
The Server Access Control SFP defines access to backup files through the MCGUI
and MCCLI. The server-side user assigned attributes Domain and Role
determine the accesses allowed.
Root Administrators have full access to all backup files. Users with any other
role are organized and segregated within the server through the use of client
domains. Avamar client domains are distinct zones to organize and segregate
clients in the Avamar server. The server provides enhanced security by enabling
you to define administrative user accounts on a domain-by-domain basis. The
domains are hierarchical so users added to a higher level domain have access
to the lower levels. Users can only perform functions on the backup files within
Dell EMC™ Avamar®
v18.1
Security Target
Doc No: 2095-000-D102 Version: 1.8 Date: 19 September 2019 Page 38 of 40
their assigned domains, involving clients in the domain, and according to the
functions allowed for their role.
The Client Access Control SFP defines access to backup files through local
interfaces on a client. Users can only perform functions on the backup files
within their assigned domains, involving the client they are executing on and
which also belongs to their Domain, and according to the functions allowed for
their role.
The Avamar VMware Universal Proxy acts as a proxy backup server and is installed
as a virtual machine on VMware vSphere ESXi platforms. It provides the interface to
virtual machines images via VADP to receive backup and restore instructions, send
images related to backup and restore operations, and respond to polls from the
Avamar server.
TOE Security Functional Requirements addressed: FDP_ACC.1(1),
FDP_ACC.1(2), FDP_ACF.1(1), FDP_ACF.1(2), FDP_BCK_EXT.1.
7.3 IDENTIFICATION AND AUTHENTICATION
When GUI or CLI users initiate sessions with the TOE, they must complete the
login process. Prior to successful completion, the only controlled data or function
they can access is viewing the configured banner. CLI and GUI users must
present a valid username and password before gaining access to the TOE.
During collection of the password, only dots are echoed for each character
supplied to the GUI and no characters are echoed by the CLI.
Upon successful login, the user’s username, domain and role are bound to the
session.
Avamar Agent users on client systems must also authenticate before being
granted access to any of the TOE functions. Users can access the Avamar Agent
through either a Web or client GUI application.
TOE Security Functional Requirements addressed: FIA_ATD.1, FIA_UAU.2,
FIA_UAU.7, FIA_UID.2.
7.4 SECURITY MANAGEMENT
Management of the TOE is performed by users with an Operator and/or
Administrator role via the MCGUI or MCCLI. Each user session is bound to a role
and domain upon login, and those attributes determine their access permissions.
Backup and restore operations may be scheduled by users with an Administrator
and/or Operator role. These operations may be performed once or according to
a defined schedule. Scheduled operations are performed autonomously by the
TOE.
Security attributes for users and clients can only be changed by Root
Administrators and Domain Administrators. Domain Administrators are limited to
user account management for users with Operator or User roles.
Dell EMC™ Avamar®
v18.1
Security Target
Doc No: 2095-000-D102 Version: 1.8 Date: 19 September 2019 Page 39 of 40
Default attribute settings are restrictive. When backup files are created, they
have the same Domain as the client providing the data. Root Administrators and
Domain Administrators may change the initial attributes for users and clients.
TOE Security Functional Requirements addressed: FMT_MSA.1(1),
FMT_MSA.1(2), FMT_MSA.3(1), FMT_MSA.3(2), FMT_SMF.1, FMT_SMR.1.
7.5 PROTECTION OF THE TSF
The TOE provides reliable time stamps for auditable events.
TOE Security Functional Requirements addressed: FPT_STM.1.
8 TERMINOLOGY AND ACRONYMS
8.1 TERMINOLOGY
The following terms are used in this ST:
Term Description
User Data User data is categorized as any data on a client machine that
can be backed up or restored by the TOE.
Table 15 - Terminology
8.2 ACRONYMS
The following acronyms are used in this ST:
Acronym Definition
API Application Program Interface
CC Common Criteria
CLI Command Line Interface
CM Configuration Management
EAL Evaluation Assurance Level
ESRS EMC Secure Remote Support
GUI Graphical User Interface
IT Information Technology
I&A Identification & Authentication
JRE Java Runtime Environment
LAN Local Area Network
Dell EMC™ Avamar®
v18.1
Security Target
Doc No: 2095-000-D102 Version: 1.8 Date: 19 September 2019 Page 40 of 40
Acronym Definition
LDAP Lightweight Directory Access Protocol
MB Megabyte
MCCLI Management Console CLI
MCGUI Management Console GUI
NDMP Network Data Management Protocol
OE Operational Environment
OS Operating System
OSP Organizational Security Policy
PP Protection Profile
REST Representational State Transfer
RHEL Red Hat Enterprise Linux
SFP Security Function Policy
SFR Security Functional Requirement
ST Security Target
SLES Suse Linux Enterprise Server
TOE Target of Evaluation
TSF TOE Security Functionality
VADP vStorage API for Data Protection
VM Virtual Machine
Table 16 – Acronyms