DNSVault Intelligent Threat
Protection Security Target
DOCUMENT VERSION 1.0
DOCUMENT DATE 15-FEB-2018
DOCUMENT ID: DNSVault_EAL2_ST
2 of 30
Document management
Document identification
Document ID DNSVault_EAL2_ST
Document title DNSVault Intelligent Threat Protection Security Target
Document Version/Date Version 1.0 (15-FEB-2018)
Document history
Version Date Description
0.1 31-JULY-2017 Released for internal review.
0.2 04-NOV-2017 Added Section 7 – TOE Summary Specification
1.0 15-FEB-2018 Final Released
3 of 30
Table of Contents
1 Security Target Introduction (ASE_INT.1)................................................................................5
1.1 ST Reference ............................................................................................................................5
1.2 TOE Reference .........................................................................................................................5
1.3 Document Organization...........................................................................................................5
1.4 TOE Overview ..........................................................................................................................6
1.5 TOE Description .......................................................................................................................8
2 Conformance Claim (ASE_CCL.1) ..........................................................................................10
3 Security Problem Definition (ASE_SPD.1)..............................................................................11
3.1 Overview................................................................................................................................11
3.2 Threats ...................................................................................................................................11
3.3 Organisational Security Policies.............................................................................................11
3.4 Assumptions ..........................................................................................................................12
4 Security Objectives (ASE_OBJ.2)...........................................................................................13
4.1 Overview................................................................................................................................13
4.2 Security Objectives for the TOE.............................................................................................13
4.3 Security Objectives for the Environment ..............................................................................13
4.4 TOE Security Objectives Rationale.........................................................................................14
4.5 Environment Security Objectives Rationale ..........................................................................16
5 Security Requirements (ASE_REQ.2).....................................................................................17
5.1 Overview................................................................................................................................17
5.2 Security Functional Requirements.........................................................................................18
5.3 Security Requirements Rationale ..........................................................................................24
6 TOE Security Assurance Requirements (ASE_REQ.2) .............................................................27
6.1 Overview................................................................................................................................27
6.2 Justification for SAR selection................................................................................................28
7 TOE summary specification (ASE_TSS.1) ...............................................................................29
7.1 Overview................................................................................................................................29
7.2 Security Audit.........................................................................................................................29
7.3 Identification and Authentication .........................................................................................29
7.4 Security Management............................................................................................................30
4 of 30
7.5 Secure Communication..........................................................................................................30
5 of 30
1 Security Target Introduction (ASE_INT.1)
1.1 ST Reference
ST Title DNSVault Intelligent Threat Protection Security Target
ST Identifier DNSVault_EAL2_ST
ST Version/Date Version 1.0 (15-FEB-2018)
1.2 TOE Reference
TOE Title DNSVault Intelligent Threat Protection
TOE Version 5.0
1.3 Document Organization
This document is organized into the following major sections:
• Section 1 provides the introductory material for the ST as well as the TOE description
(ASE_INT.1).
• Section 2 provides the conformance claims for the evaluation (ASE_CCL.1).
• Section 3 provides the definition of the security problem that the TOE has been designed to
address (ASE_SPD.1).
• Section 4 defines the security objectives for the TOE and the environment (ASE_OBJ.2).
• Section 5 contains the security functional and assurance requirements derived from the
Common Criteria Part 2 and 3 respectively, which are in turn satisfied by the TOE and the
development lifecycle (ASE_REQ.2).
• Section 6 contains the security assurance requirements derived from the Common Criteria,
Part 3 (ASE_REQ.2).
6 of 30
1.4 TOE Overview
1.4.1 TOE Usage and Major Security Functions
The Target of Evaluation (TOE) is DNSVault Intelligent Threat Protection version 5.0. The TOE is a web
application that has the ability to perform DNSVault Node management, DNS management, DNS
Statistics and logs monitoring. By integrating DNSVault Analytic into the platform, the TOE able to
revolutionize the way Admin view the raw data of the DNS statistics and logs providing advanced
threat Intelligent protections such as malware detection and web filtering. It’s also automatically
monitor DNS and related service health and status and can predictively adjust capacity based on
needs. Refer to Section 1.5.1 for more detail explanations.
With DNSVault Intelligent Threat Protection, Administrators have a holistic and unified platform that
empowers admins to control, secure and analyse every aspect of the DNS performance, security,
agility and availability whether it is on premises, in data centres, or even in the cloud. Thus, by
automating essential processes, eradicating solution silos and integrating into your existing
ecosystem, mitigating risk proactively, every aspect of DNS are in context and leveraging DNS data for
a truly intelligent threat protection.
The following table highlights the range of security functions implemented by the TOE.
Security functions Descriptions
Security Audit The TOE generates audit records for security events. Only Admin has the
ability to view/export the audit logs
Identification and
Authentication
The TOE requires that each user is successfully identified (user IDs) and
authenticated (password) before any interaction with protected resources
is permitted.
Security Management The TOE provides functions that allow management of the TOE and its
security functions. The TOE restricts access to the management functions
based on the role of the user.
Secure
Communication
The TOE can protect the user data from disclosure and modification by
using Secure Socket Layer (SSL) as a secure communication
1.4.2 TOE Type
The TOE is DNSVault Intelligent Threat Protection and provides security functionality such as Security
Audit, Identification and Authentication, Security Management and Secure Communication. The TOE
can be categorised as Other Devices and Systems in accordance with the categories identified on the
Common Criteria Portal (www.commoncriteriaportal.org) that lists all the certified products.
1.4.3 Supporting hardware, software and/or firmware
Minimum System Requirements
Web Browser Modern HTML 5 browser which include:
• Microsoft Internet Explorer 11
• Mozilla Firefox 54
• Google Chrome 56
• Apple Safari 10.1.2
Operating System FreeBSD 10.3
Memory 8 GB RAM
Processor Intel Core i3-3220 @ 3.30GHz
Storage 1 TB Internal Hard Drive
Database PostgreSQL 9.5
1.5 TOE Description
1.5.1 Physical scope of the TOE
A physical boundaries of the TOE can be found in Figure 1 below, which identifies the various
components of the TOE architecture.
Figure 1 – TOE Physical Boundaries
Below are the descriptions of the components stated in Figure 1 above.
Component Descriptions
TOE The Target of Evaluation (TOE) is DNSVault Intelligent Threat Protection
version 5.0. The TOE is a web application that has the ability to perform
DNSVault Node management, DNS management, DNS Statistics and logs
monitoring
TOE Users There are two types of TOE users; Admin and Normal User. Refer to
Section 5.2.4, Table 1 for detail explanations on user’s operation
Web Browser A web browser is a software program that allows a user to locate,
access, and display web pages. TOE Users (Admin and Normal User)
interact with the TOE via a supported web browser stated in Section
1.4.3
Database A database is an electronic system that allows data to be easily
accessed, manipulated and updated. a database is used as a method of
storing, managing and retrieving data
Operating System Operating System is a software program that enables the computer
hardware to communicate and operate with the computer software.
The TOE requires an operating system to function. Refer to Section 1.4.3
for minimum system requirement for operating system.
1.5.2 Logical scope of the TOE
The logical boundary consists of the security functionality of TOE is summarized below.
a) Security Audit. The TOE generates audit records for security events. The Admin has the
ability to view/export the audit logs. Types of audit logs are:
• User/Admin login
• User/Admin logout
• Data modification by User/Admin
Only Admin has the capability to review these audit records via the web interface
b) Identification & Authentication. All users are required to be identified and authenticated
before any information flows are permitted. The TOE checks the credentials presented by
the user at the login page against the authentication information stored in the database.
c) Security Management. The TOE contains various management functions to ensure efficient
and secure management of the TOE. The TOE maintains role-based access control
mechanisms to ensure that functions are restricted to those who have the privilege to
access them. The system admin has the ability to create users’ roles, who have privileged
access to specific functions. The functions above are restricted based on this role.
d) Secure communications. The TOE provides a secure SSL channel between the end-user and
the TOE.
10 of 30
2 Conformance Claim (ASE_CCL.1)
The ST and TOE are conformant to version 3.1 (REV 4) of the Common Criteria for Information
Technology Security Evaluation.
The following conformance claims are made for the TOE and ST:
• Part 2 conformant. Conformant with Common Criteria for Information Technology Security
Evaluation Part 2: Security functional requirements, version 3.1 (REV 4), September 2012
• Part 3 conformant, EAL2. Conformant with Common Criteria for Information Technology
Security Evaluation Part 3: Security assurance requirements, version 3.1 (REV 4). Evaluation
is EAL2, September 2012.
11 of 30
3 Security Problem Definition (ASE_SPD.1)
3.1 Overview
This section describes the nature of the security problem that the TOE is designed to address. The
security problem is described through:
a) a series of threats that the TOE has been designed to mitigate,
b) specific assumptions about the security aspects of the environment (both IT related and
non-IT related elements) in which the TOE will operate, and
c) any relevant organisational security policies are any statements made in terms of rules or
guidelines that must be followed by the TOE and/or the operational environment.
3.2 Threats
Identifier Threat statement
T.MANAGEMENT An unauthorized user modifies management data that they are not
authorised to access resulting in a loss of integrity of the data that the TOE
uses to enforce the security functions.
T.UNAUTHORISED_A
CCESS
A user may gain unauthorized access to the TOE and residing data by
sending impermissible information through the TOE (such as Brute Force
Attacks) resulting the exploitation of protected resources
T.CONFIG An unauthorized person may read, modify, or destroy TOE configuration
data.
T.TOECOM An unauthorized person or unauthorized external IT entity may be able to
view, modify, and/or delete security related information or information
properties sent between distributed components of the TOE.
3.3 Organisational Security Policies
No organisational security policies have been defined regarding the use of the TOE.
12 of 30
3.4 Assumptions
Identifier Assumption statement
A.PLATFORM The TOE relies upon a trustworthy platform and local network from which it
provides administrative capabilities. The TOE relies on this platform to provide
logon services via a local or network directory service, and to provide basic
audit log management functions. The platform is expected to be configured
specifically to provide TOE services, employing features such as a host-based
firewall which limits its network role to providing TOE functionality.
A.ADMIN One or more competent, trusted personnel who are not careless, wilfully
negligent, or hostile, are assigned and authorized as the Admin, and do so using
and abiding by guidance documentation.
A.USER TOE users are not wilfully negligent or hostile, and use the application within
compliance of a reasonable enterprise security policy.
A.TIMESTAMP The platforms on which the TOE operate shall be able to provide reliable time
stamps.
A.PHYSICAL It is assumed that the appliance hosting the operating system and database are
in a secure operating facility with restricted physical access and non-shared
hardware.
13 of 30
4 Security Objectives (ASE_OBJ.2)
4.1 Overview
The security objectives are a concise statement of the intended response to the security problem
defined in Section 3. There are security objectives for the TOE to address and additional objectives
that provide specific direction for the intended in environment in which the TOE is to operate.
4.2 Security Objectives for the TOE
Identifier Objective statements
O.ACCESS The TOE must ensure that only authorised users are able to access
protected resources or functions and to explicitly deny access to specific
users when appropriate
O.CONFIG TOE shall prevent unauthorized person to access TOE functions and
configuration data. Only Admin shall have access to TOE management
interface.
O.MANAGE The TOE must allow Admin to effectively manage the TOE, while ensuring
that appropriate controls are maintained over those functions.
O.USER The TOE must ensure that all users are identified and authenticated
before accessing protected resources or functions.
O.NOAUTH The TOE shall protect itself against attempts by unauthorized users to
bypass, deactivate, or tamper with TOE security functionality.
O.TOECOM The TOE must protect the confidentiality of its dialogue between
distributed components.
4.3 Security Objectives for the Environment
Identifier Objective statements
OE.PLATFORM The TOE relies upon the trustworthy platform and hardware
to provide policy enforcement as well as cryptographic
services and data protection.
OE.ADMIN The owners of the TOE must ensure that the Admin who
manages the TOE is not hostile, competent and apply all
Admin guidance in a trusted manner.
OE.USER Users of the systems are trained to securely use the systems
and apply all guidance in a trusted manner.
14 of 30
Identifier Objective statements
OE.TIMESTAMP Reliable timestamp is provided by the operational
environment for the TOE.
OE.PHYSICAL Those responsible for the TOE must ensure that the
appliance hosting the operating system and database are in a
secure operating facility with restricted physical access and
non-shared hardware.
4.4 TOE Security Objectives Rationale
This section provides the summary that all security objectives are traced back to aspects of the
addressed assumptions, threats and OSPs.
THREATS/
ASSUMPTIONS/OSPs
OBJECTIVES
T.MANAGEMENT
T.UNAUTHORISED_ACCESS
T.CONFIG
T.TOECOM
A.PLATFORM
A.ADMIN
A.USER
A.TIMESTAMP
A.PHYSICAL
O.ACCESS  
O.CONFIG 
O.MANAGE 
O.USER  
O.TOECOM 
O.NOAUTH 
OE.PLATFORM 
OE.ADMIN 
OE.USER 
OE. TIMESTAMP 
OE. PHYSICAL 
15 of 30
The following table demonstrates that all security objectives for the TOE trace back to the threats
and OSPs in the security problem definition.
Threats/OSPs Objectives Rationale
T.CONFIG O.CONFIG The objective ensures that the TOE only allowed
authorized person such as Admin to access TOE
functions and configuration data.
T.MANAGEMENT O.USER The objective ensures that the TOE identifies and
authenticates all users before they access a
protected resources or functions.
O.MANAGE This objective ensures that the TOE provides the
tools necessary for the authorized system admin
to manage the security-related functions and that
those tools are usable only by users with
appropriate authorizations.
O.ACCESS The objective ensures that the TOE restricts access
to the TOE objects to the authorized users and
deny access to specific users when appropriate
T.UNAUTHORISED_AC
CESS
O.ACCESS The objective ensures that the TOE restricts access
to the TOE objects to the authorized users and
deny access to specific users when appropriate
O.USER The objective ensures that the TOE identifies and
authenticates all users before they access a
protected resources or functions.
O.NOAUTH The objective ensures that the TOE protect itself
against attempts by unauthorized users to bypass,
deactivate, or tamper with TOE security
functionality.
T.TOECOM O.TOECOM The objective ensures that the TOE protect the
confidentiality of its dialogue between distributed
components.
16 of 30
4.5 Environment Security Objectives Rationale
The following table demonstrates that all security objectives for the operational environment all
trace back to assumptions or OSPs in the security problem definition.
Assumptions Objective Rationale
A.PLATFORM OE.PLATFORM This objective ensures that the underlying
platforms are trustworthy and hardened to
protect against known vulnerabilities and security
configuration issues.
A.ADMIN OE.ADMIN This objective ensures that those responsible for
the TOE are competent and trustworthy
individuals, capable of managing the TOE and the
security of the information it contains.
A.USER OE.USER This objective ensures that those responsible for
the TOE are competent and trustworthy
individuals, capable of operating the TOE and the
security of the information it contains in a secure
manner.
A.TIMESTAMP OE.TIMESTAMP This objective ensures that reliable timestamps
are provided by the operational environment for
the TOE.
A.PHYSICAL OE.PHYSICAL This objective ensures that the appliance that
hosts the operating system and database are
hosted in a secure operating facility with
restricted physical access with non-shared
hardware.
17 of 30
5 Security Requirements (ASE_REQ.2)
5.1 Overview
This section defines the security requirements satisfied by the TOE. Each requirement has been
extracted from version 3.1 (REV 4) of the Common Criteria, part 2 providing functional requirements
and part 3 providing assurance requirements.
Part 2 of the Common Criteria defines an approved set of operations that may be applied to security
functional requirements. Following are the approved operations and the document conventions
that are used within this ST to depict their application:
• Assignment. The assignment operation provides the ability to specify an identified
parameter within a requirement. Assignments are depicted using bolded text and are
surrounded by square brackets as follows [assignment].
• Selection. The selection operation allows the specification of one or more items from a list.
Selections are depicted using bold italics text and are surrounded by square brackets as
follows [selection].
• Refinement. The refinement operation allows the addition of extra detail to a requirement.
Refinements are indicated using bolded text, for additions, and strike-through, for deletions.
• Iteration. The iteration operation allows a component to be used more than once with
varying operations. Iterations are depicted by placing a letter at the end of the component
identifier as follows FDP_IFF.1a and FDP_IFF.1b.
18 of 30
5.2 Security Functional Requirements
5.2.1 Overview
The security functional requirements are expressed using the notation stated in Section 5.1 above
and itemised in the table below.
Identifier Title
FAU_GEN.1 Audit data generation
FAU_SAR.1 Audit review
FDP_ACC.1 Subset access control
FDP_ACF.1 Security attribute based access control
FIA_ATD.1 User attribute definition
FIA_UID.2 User identification before any action
FIA_UAU.2 User authentication before any action
FMT_MSA.1 Management of security attributes
FMT_MSA.3 Static attribute initialisation
FMT_MTD.1 Management of TSF data
FMT_MOF.1 Management of security functions behaviour
FMT_SMF.1 Specification of Management Functions
FMT_SMR.1 Security Roles
FTP_TRP.1 Trusted Path
19 of 30
5.2.2 FAU_GEN.1 Audit data generation
Hierarchical to: No other components.
FAU_GEN.1.1 The TSF shall be able to generate an audit report 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; and
c) [Specifically defined auditable events listed in the Notes section below].
FAU_GEN1.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, [none].
Dependencies: FPT.STM.1 Reliable time stamps
Notes: Auditable events within the TOE:
o Event date
o Event associated with the user
o Activity type
o Existing data and;
o Change data
5.2.3 FAU_SAR.1 Audit Review
Hierarchical to: No other components.
FAU_SAR.1.1 The TSF shall provide [admin] with the capability to read [all audit information]
from the audit records.
FAU_SAR.1.2 The TSF shall provide the audit records in a manner suitable for the user to
interpret the information.
Dependencies: FAU_GEN.1 Audit data generation
Notes: None.
5.2.4 FDP_ACC.1 Subset access control
Hierarchical to: No other components.
FDP_ACC.1.1 The TSF shall enforce the [access control SFP] on [objects listed in the table 1
below].
20 of 30
Dependencies: FDP_ACF.1 Security attribute based access control
Notes: Table 1 - Subject, Object and Operations for FDP_ACC.1
Subject Object Operation
Admin DNSVault Node View/Add/Edit/Delete
Views View/Add/Edit/Delete
User Account View/Add/Edit/Delete
Audit Log View/Export
Normal User Account Update own account
Views View/Add/Edit/Delete
5.2.5 FDP_ACF.1 Security attribute based access control
Hierarchical to: No other components.
FDP_ACF.1.1 The TSF shall enforce the [access control SFP] to objects based on the following:
[as listed in the Table 1].
FDP_ACF.1.2 The TSF shall enforce the following rules to determine if an operation among
controlled subjects and controlled objects is allowed: [
a) If the Admin and Normal User are successfully authenticated
accordingly, then access is granted based on privilege allocated;
b) If the Admin and Normal User are not authenticated successfully,
therefore, access permission is denied
]
FDP_ACF.1.3 The TSF shall explicitly authorise access of subjects to objects based on the
following additional rules: [none].
FDP_ACF.1.4 The TSF shall explicitly deny access of subjects to objects based on the following
additional rules: [none].
Dependencies: FDP_ACC.1 Subset access control
FMT_MSA.3 Static attribute initialisation
Notes: None.
5.2.6 FIA_ATD.1 User attribute definition
Hierarchical to: No other components.
21 of 30
FIA_ATD.1.1 The TSF shall maintain the following list of security attributes belonging to
individual users: [Username, Password, User role, User Account]
Dependencies: No dependencies.
Notes: None.
5.2.7 FIA_UAU.2 User authentication before any action
Hierarchical to: FIA_UAU.1 Timing of authentication
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.
Dependencies: FIA_UID.1 Timing of identification
Notes: None.
5.2.8 FIA_UID.2 User identification before any action
Hierarchical to: FIA_UID.1 Timing of identification
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.
Dependencies: No dependencies
Notes: None.
5.2.9 FMT_MSA.1 Management of security attributes
Hierarchical to: No other components.
FMT_MSA.1.1 The TSF shall enforce the [access control SFP] to restrict the ability to
[change_default, modify, delete] the security attributes [Admin Account, TOE
Configuration, Users Account] to [Admin].
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
Notes: None.
22 of 30
5.2.10 FMT_MSA.3 Static attribute initialisation
Hierarchical to: No other components.
FMT_MSA.3.1 The TSF shall enforce the [access 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 [none] to specify alternative initial values to override the
default values when an object or information is created.
Dependencies: FMT_MSA.1 Management of security attributes
FMT_SMR.1 Security roles
Notes: None.
5.2.11 FMT_MTD.1 Management of TSF data
Hierarchical to: No other components.
FMT_MTD.1.1 The TSF shall restrict the ability to [modify] the [User Accounts] to [Admin]
Dependencies: FMT_SMR.1 Security roles
FMT_SMF.1 Specification of Management Functions
Notes: None.
5.2.12 FMT_MOF.1 Management of security functions behaviour
Hierarchical to: No other components.
FMT_MOF.1.1 The TSF shall restrict the ability to [disable, enable and modify the behaviour of]
the functions [TOE Configurations] to [Admin].
Dependencies: FMT_SMR.1 Security roles
FMT_SMF.1 Specification of Management Functions
Notes: None.
5.2.13 FMT_SMF.1 Specification of Management Functions
Hierarchical to: No other components.
FMT_SMF.1.1 The TSF shall be capable of performing the following management functions: [
• View/Add/Edit/Delete DNSVault Node
• View/Add/Edit/Delete Views
• View/Add/Edit/Delete User Accounts
23 of 30
• View/Export Audit Log
].
Dependencies: No dependencies.
Notes: None.
5.2.14 FMT_SMR.1 Security Roles
Hierarchical to: No other components.
FMT_SMR.1.1 The TSF shall maintain the roles [Admin, Normal User].
FMT_SMR.1.2 The TSF shall be able to associate users with roles.
Dependencies: FIA_UID.1 Timing of identification
Notes: None.
5.2.15 FTP_TRP.1 Trusted Path
Hierarchical to: No other components.
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 or 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 [initial user authentication,
[and all further communication after authentication]].
Dependencies: No dependencies
Notes: None.
24 of 30
5.3 Security Requirements Rationale
5.3.1 Dependency rationale
Below demonstrates the mutual supportiveness of the SFR’s for the TOE by demonstrating how the
SFR dependencies are fulfilled by the TOE, and by justifying those dependencies that are not fulfilled.
The SARs relevant to the TOE constitute an evaluation assurance level EAL2 as defined in Common
Criteria and include no extensions or augmentations. Therefore, as a complete evaluation assurance
level, they are a mutually supportive set and require no further justification.
SFR Dependency Inclusion
FAU_GEN.1 FPT.STM.1 Reliable time stamps FPT_STM.1 has not been
included as the TOE obtains
all audit timestamps from the
underlying platform. This has
been addressed in Section
3.4 by A.TIMESTAMP.
FAU.SAR.1 FAU.GEN.1 Audit data generation FAU.GEN.1
FDP_ACC.1 FDP_ACF.1 Security attribute based access
control
FDP_ACF.1
FDP_ACF.1 FDP_ACC.1 Subset access control
FMT_MSA.3 Static attribute initialisation
FDP_ACC.1
FMT_MSA.3
FIA_ATD.1 No dependencies NA
FIA_UAU.2 FIA_UID.1 Timing of identification FIA_UID.2
FIA_UID.2 No dependencies N/A
FMT_MSA.1 [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
FDP_ACC.1
FMT_SMR.1
FMT_SMF.1
FMT_MSA.3 FMT_MSA.1 Management of security attributes
FMT_SMR.1 Security roles
FMT_SMR.1
FMT_MSA.1
25 of 30
SFR Dependency Inclusion
FMT_MTD.1 FMT_SMR.1 Security roles
FMT_SMF.1 Specification of Management
Functions
FMT_SMR.1
FMT_SMF.1
FMT_MOF.1 FMT_SMR.1 Security roles
FMT_SMF.1 Specification of Management
Functions
FMT_SMR.1
FMT_SMF.1
FMT_SMF.1 No dependencies N/A
FMT_SMR.1 FIA_UID.1 Timing of identification FIA_UID.2
FTP_TRP.1 No dependencies N/A
5.3.2 Mapping of SFRs to security objectives for the TOE
Security objective Mapped SFRs Rationale
O.USER FIA_UAU.2 The requirement helps meet the objective by
authenticating user before any TSF mediated actions.
FIA_UID.2 The requirement helps meet the objective by identifying
user before any TSF mediated actions
O.ACCESS FAU_GEN.1 This SFR specifies security events that are being audited
and recorded in log file. Each security event will be
recorded along with date and time of event, user who
execute the event, filename and other event details. It
traces back to this objective.
FAU_SAR.1 This SFR specifies that admin will have the capability to
view the audit trail data in log form. It traces back to this
objective.
FIA_ATD.1 The requirement helps meet the objective by ensuring
user security attributes are maintained.
FMT_SMF.1 The requirement helps meet the objective by providing
management functions of the TOE for authenticated user.
FMT_SMR.1 This SFR identifies the roles exist in TOE, which is Admin
and Normal User. Each user account created must be
associated to the roles. It traces back to this objective.
O.MANAGE FMT_MTD.1 This SFR restricts the ability to modify the user accounts
to Admin. It traces back to this objective.
26 of 30
Security objective Mapped SFRs Rationale
FMT_MSA.1 The requirement helps to meet the objective by
restricting the ability to modify the security attributes for
the Admin.
O.CONFIG FMT_MTD.1 The requirement helps meet the objective by restricting
user access to management functions.
FMT_MSA.1 The requirement helps meet the objective by restricting
user access to security attributes.
FMT_MSA.3
The requirement helps meet the objective by restricting
access to provide default values for security attributes
that are used to enforce the SFP.
FMT_SMR.1 The requirement helps meet the objective by defining the
security roles used within the TOE.
FDP_ACC.1 The requirement provides access control functionality to
ensure that access to security functionality is controlled.
FDP_ACF.1 The requirement provides access control functionality to
ensure that access to security functionality is controlled.
FMT_MOF.1 This requirement helps meet the objective by restricting
the modification of the TOE behaviour to Admin
O.TOECOM FTP_TRP.1 The requirement ensures that data sent by users is
protected from modification or disclosure.
O.NOAUTH FIA_UAU.2 The requirement helps meet the objective by
authenticating user before any TSF mediated actions.
FIA_UID.2 The requirement helps meet the objective by identifying
user before any TSF mediated actions
27 of 30
6 TOE Security Assurance Requirements (ASE_REQ.2)
6.1 Overview
EAL2 requires evidence relating to the design information and test results, but does not demand more
effort on the part of the developer than is consistent with good commercial practice.
EAL2 provides assurance by a full security target and an analysis of the SFRs in that ST, using a
functional and interface specification, guidance documentation and a basic description of the
architecture of the TOE, to understand the security behaviour.
The analysis is supported by independent testing of the TSF, evidence of developer testing based on
the functional specification, selective independent confirmation of the developer test results, and a
vulnerability analysis (based upon the functional specification, TOE design, security architecture
description and guidance evidence provided) demonstrating resistance to penetration attackers with
a basic attack potential.
EAL2 also provides assurance through use of a configuration management system and evidence of
secure delivery procedures.
Assurance class Assurance components
ADV: Development ADV_ARC.1 Security architecture description
ADV_FSP.2 Security-enforcing functional specification
ADV_TDS.1 Basic design
AGD: Guidance documents AGD_OPE.1 Operational user guidance
AGD_PRE.1 Preparative procedures
ALC: Life cycle support ALC_CMS.2 Parts of the TOE CM coverage
ALC_CMC.2 Use of a CM system
ALC_DEL.1 Delivery procedures
ASE: Security Target evaluation 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
28 of 30
Assurance class Assurance components
ASE_SPD.1 Security Problem Definition
ASE_TSS.1 TOE summary specification
ATE: Tests ATE_IND.2 Independent testing - sample
ATE_FUN.1 Functional testing
ATE_COV.1 Evidence of coverage
AVA: Vulnerability assessment AVA_VAN.2 Vulnerability analysis
6.2 Justification for SAR selection
The assurance package for the evaluation of the TOE is Evaluation Assurance Level 2 (EAL2).
TOE has a low to moderate level of assurance in enforcing its security functions when instantiated in
its intended environment, which imposes no restrictions on assumed activity on applicable
networks. EAL2 is sufficient to demonstrate that the TOE is resistant to attackers with a Basic attack
potential.
29 of 30
7 TOE summary specification (ASE_TSS.1)
7.1 Overview
This section provides the TOE summary specification, a high-level description of how the TOE
actually implements the claimed security functional requirements.
The TOE security functions include the following:
• Security Audit
• Identification and Authentication
• Security Management
• Secure Communication
7.2 Security Audit
The TOE will create audit records (which contain the date and time of the event, type of event, subject
identity and outcome of the event) when the following events occur (FAU_GEN.1):
• Normal User/Admin login
• Normal User/Admin logout
• Data modification by Normal User/Admin
Only Admin has the capability to review these audit records via the web interface (FAU_SAR.1).
Timestamps are generated for audit logs by utilising the underlying operating system. The TOE does
not generate its own timestamps for use in audit records; these are supplied by the underlying
operating system.
7.3 Identification and Authentication
When a user issues a request to the TOE to access a protected resource (method), the TOE requires
that the user (Normal User and Admin) identify and authenticate themselves before performing any
TSF mediated action (FIA_UID.2, FIA_UAU.2). At the TOE’s login page, Admin and Normal User need
to key in their credentials (username and password) in order to operate the TOE (FIA_ATD.1). The TOE
compares the credentials by checking the information presented by the user at the login page against
the authentication information stored in the database.
30 of 30
7.4 Security Management
The TOE contains various management functions to ensure efficient and secure management of the
TOE to Admin and User (FMT_SMF.1). These functions allow for the configuration of the TOE to suit
the organization in which it is deployed. Additionally, management roles may perform the following
tasks (FDP_ACC.1, FMT_MSA.1, FIA_ATD.1, FMT_MOF.1, FMT_SMR.1, FMT_MTD.1, FDP_ACF.1 and
FMT_MSA.3):
• View/Add/Edit/Delete DNSVault Node
• View/Add/Edit/Delete Views
• View/Add/Edit/Delete User Accounts
• View/Export Audit Log
7.5 Secure Communication
When a user accesses the TOE on their browser, by typing in the website address, the TOE will
initiate a SSL secure channel establishment with the user’s browser (FTP_TRP.1). The TOE
implements the Secure Sockets Layer (SSL v2/v3) and Transport Layer Security (TLS v1) protocols.