McAfee Change Controland Application Control

Security Target


Security Target

McAfee Change Control and Application Control 8.0.0

with

ePolicy Orchestrator 5.3.2

Document Version: 1.1

November 24, 2017

McAfee,LLC.
2821 Mission College Blvd.
Santa Clara, CA 95054

Abstract

This document provides the basis for an evaluation of a specific Target of Evaluation (TOE): McAfee Change Control and Application Control 8.0.0 with ePolicy Orchestrator 5.3.2. This Security Target (ST) defines a set of assumptions about the aspects of the environment, a list of threats that the product intends to counter, a set of security objectives, a set of security requirements, and a specification for the IT security functions provided by the TOE that meet the set of requirements.

Table of Contents

1Introduction

1.1Purpose

1.2Security Target and TOE References

1.3Product Overview

1.3.1Change Control Monitoring

1.3.2Change Control

1.3.3Application Control

1.3.4ePolicy Orchestrator

1.4TOE Overview

1.4.1Brief Description of the Components of the TOE

1.4.2TOE Environment

1.5TOE Description

1.5.1Physical Scope

1.5.2Logical Scope

1.5.3Product Physical/Logical Features and Functionality not included in the TOE

2Conformance Claims

3Security Problem Definition

3.1Threats to Security

3.2Organizational Security Policies

3.3Assumptions

4Security Objectives

4.1Security Objectives for the TOE

4.2Security Objectives for the Operational Environment

4.2.1IT Security Objectives

4.2.2Non-IT Security Objectives

5Extended Components

5.1Extended TOE Security Functional Components

5.1.1Class EXT_MAC: McAfee Application and Change Control

5.2Extended TOE Security Assurance Components

6Security Requirements

6.1Introduction

6.2Security Functional Requirements

6.2.1Class FAU: Security Audit

6.2.2Class FCS: Cryptographic Support

6.2.3Class FIA: Identification and Authentication

6.2.4Class FMT: Security Management

6.2.5Class FPT: Protection of the TSF

6.2.6Class EXT_MAC: McAfee Application and Change Control

6.3Security Assurance Requirements

7TOE Summary Specification

7.1TOE Security Functions

7.1.1Security Audit

7.1.2Cryptographic Support

7.1.3Identification and Authentication

7.1.4Security Management

7.1.5Protection of the TSF

7.1.6McAfee Application and Change Control

8Rationale

8.1Conformance Claims Rationale

8.2Security Objectives Rationale

8.2.1Security Objectives Rationale Relating to Threats

8.2.2Security Objectives Rationale Relating to Policies

8.2.3Security Objectives Rationale Relating to Assumptions

8.3Rationale for Extended Security Functional Requirements

8.4Rationale for Extended TOE Security Assurance Requirements

8.5Security Requirements Rationale

8.5.1Rationale for Security Functional Requirements of the TOE Objectives

8.5.2Security Assurance Requirements Rationale

8.5.3Dependency Rationale

9Acronyms

Table of Figures

Figure 1 – Software Components of the Product

Figure 2 – Deployment Configuration of the TOE

Figure 3 – Physical TOE Boundary

Figure 4 – EXT_MAC: McAfee Application and Change Control Class Decomposition

Figure 5 – Application and Change Control Data Collection family decomposition

Figure 6 – Application and Change Control React family decomposition

List of Tables

Table 1 – ST and TOE References

Table 2 – TOE Platform Minimum Requirements

Table 3 – CC and PP Conformance

Table 4 – Threats

Table 5 – Assumptions

Table 6 – Security Objectives for the TOE

Table 7 – IT Security Objectives

Table 8 – Non-IT Security Objectives

Table 9 – Extended TOE Security Functional Requirements

Table 10 – TOE Security Functional Requirements

Table 11 – Selectable audit review fields

Table 12 - Cryptographic Operations

Table 13 – TSF Data Access Permissions

Table 14 – Assurance Requirements

Table 15 – Mapping of TOE Security Functions to Security Functional Requirements

Table 16 – Threats: Security Objectives Mapping

Table 17 – Assumptions: Objectives Mapping

Table 18 – Objectives: SFRs Mapping

Table 19 – Functional Requirements Dependencies

Table 20 – Acronyms

1Introduction

This section identifies the Security Target (ST), Target of Evaluation (TOE), and the ST organization. The Target of Evaluation is the McAfeeChange Controland Application Control 8.0.0 with ePolicy Orchestrator 5.3.2, and will hereafter be referred to as the TOE throughout this document. The TOE is a change control and application control software solution with robust management functionality.

1.1Purpose

This ST is divided into nine sections, as follows:

  • Introduction (Section 1) – Provides a brief summary of the ST contents and describes the organization of other sections within this document. It also provides an overview of the TOE security functions and describes the physical and logical scope for the TOE, as well as the ST and TOE references.
  • Conformance Claims (Section 2)– Provides the identification of any Common Criteria (CC), ST Protection Profile, and Evaluation Assurance Level (EAL) package claims. It also identifies whether the ST contains extended security requirements.
  • Security Problem (Section 3) – Describes the threats, organizational security policies, and assumptions that pertain to the TOE and its environment.
  • Security Objectives (Section 4) – Identifies the security objectives that are satisfied by the TOE and its environment.
  • Extended Components (Section 5) – Identifies new components (extended Security Functional Requirements (SFRs) and extended Security Assurance Requirements (SARs)) that are not included in CC Part 2 or CC Part 3.
  • Security Requirements (Section 6) – Presents the SFRs and SARs met by the TOE.
  • TOE Summary Specification (Section 7) – Describes the security functions provided by the TOE that satisfy the security functional requirements and objectives.
  • Rationale (Section 8) - Presents the rationale for the security objectives, requirements, and SFR dependencies as to their consistency, completeness, and suitability.
  • Acronyms (Section 9) – Defines the acronyms and terminology used within this ST.

1.2Security Target and TOE References

Table 1– ST and TOE References

ST Title / Security TargetMcAfeeChange Control and Application Control 8.0.0 with ePolicy Orchestrator 5.3.2
ST Version / Version 1.1
ST Author / McAfee, LLC
ST Publication Date / November 24, 2017
TOE Reference / McAfee Change Control and Application Control 8.0.0 with ePolicy Orchestrator 5.3.2
Keywords / Change Control, Application Control, McAfee, ePolicy Orchestrator, ePO, McAfee Agent, Change Prevention

1.3Product Overview

The Product Overview provides a high level description of the McAfeeChange Control and Application Control 8.0.0with ePolicy Orchestrator 5.3.2, which is the subject of the evaluation. The following section, TOE Overview, provides the introduction to the parts of the overall product offering that are being evaluated.

McAfeeChange Control and Application Control 8.0.0 withePolicy Orchestrator 5.3.2 provides change control and monitoring on servers and desktops. It also ensures that only authorized code can run on those managed systems. This functionality is managed through the ePolicy Orchestrator (ePO) management software.

The product consists of fourlogical components:

  • Change Control
  • Application Control
  • ePO (for management of Change Control and Application Control)
  • McAfee Agent

These fourlogical components are implemented via fourphysical software components:

  • Solidcore Service – Manages the policy for the Filesystem Driver and interfaces with the CLI and McAfee Agent.
  • Filesystem Driver (swin.sys) –The portion of the product implemented in the Operating System’s (OS) kernel space; the filesystem driver intercepts and analyzes all file system, registry, memory, and other critical reads and writes occurring in the OS and implements the core application control and change control and monitoring actions.
  • ePO – Used for remote management of the Solidcore Service.
  • McAfee Agent – A generic agent used by ePO for communication with a managed endpoint. The agentdistributes policies from and reports back to ePO.

In addition, the product interacts with a third-party databasein the TOE environment.

The database and thefive physical software components of the product are shown in Figure 1 below as they are configured in a typical implementation of the product.

Figure 1 –Software Components of the Product

The following sections describe each of the logical components of the product.

1.3.1Change Control Monitoring

The Solidcore Service contains Change Control functionality, which monitors change actions happening on the managed system. Change Control can monitor changes to the following:

  • Files and directories
  • Windows Registry entries
  • Process execution/termination
  • User activity (Logon/Logoff)

Change Control tracks all changes to the files and directories on the managed system. Types of changes monitored on files and directories include:

  • Creation
  • Modification of contents
  • Deletion
  • Renaming
  • File attribute modification
  • Access Control List (ACL) modification
  • Owner modification

Change Controlalso monitors changes to network file shares, such as Network File Server (NFS) and Client for NFS Services (NFS Client), as well as Common Internet File System (CIFS)/Server Message Block (SMB) for Windows systems. Change Control also monitors changes to file attributes on Windows systems, such as ‘FILE_ATTRIBUTE_ENCRYPTED’, and ‘FILE_ATTRIBUTE_HIDDEN’, etc. Change Control monitors the start and stop events for process execution, as well. In addition, it monitors the success or failure of user logon and logoff attempts, and other account changes.

For each change made to an object, Change Control generates a change event. It uses event filters to tailor which change events appear in the event viewer. These filters can be customized by the administrator. Filters can be set on files, directories, registries, process names, file extensions, and user names. Filters match criteria based on file extension, path name, process name, user name, or registry name for change events. Filters can be configured in two different ways:

  • Include filters cause events matching the filtering criteria to be reported to the user
  • Exclude filters cause events matching the condition to be suppressed and not reported to the user.

The filtering of change events for the purpose of reporting them ensures that only change events the administrator is interested in are recorded. Many change events are program-generated, and may not be of interest to the administrator. Filtering helps reduce the volume of change events being recorded, and thereby reduces the ‘noise’ on the system. Filter rules are implemented in a predefined order of precedence. For example, filters based on user name will have the highest precedence over all other filter rules.

1.3.2Change Control

The Solidcore Service also contains Change Policy Enforcement functionality, which prevents specified reads or writes to files and directories on the managed systems. Any addition, removal, or modification of software on the managed system is allowed only when the product is in Update Mode, which also tracks every change action made.

1.3.2.1Write Protection

Critical files, directories, and volumes can be write-protected using the ‘deny-write’ feature of SolidcoreServices. This renders the specified files as read only. The following operations are controlled by this feature:

  • Deletion
  • Renaming
  • Creation of hard links
  • Modifying contents
  • Appending
  • Truncating
  • Changing owner
  • Creation of Alternate Data Stream[1] (ADS)

When a directory or volume is specified for write-protection, all files in that directory or volume are added to the write-protected list. These specifications are inherited by sub-directories, as well. In addition to the operations listed above, creation of new files is also denied for directories or volumes listed as write-protected. If any file or directory within a parent directory is write-protected, renaming of the parent directory is also denied. All operations listed above on a write-protected file, directory, or volume are considered unauthorized, and are therefore stopped and an event is generated in the Event Log.

Critical registry keys can also be protected against change using the ‘deny-write’ feature. All enforcement rules to control modifications to registry keys can be applied using this feature. Any unauthorized attempts to modify a write-protected registry key will be stopped, and a change event will be generated.

1.3.2.2Read Protection

Critical files, directories, and volumes can also be read-protected using the ‘deny-read’ feature of Solidcore Services. This enforces read-protection on specified files, directories, and volumes, and also denies the execution of script files. When a directory or volume is specified for read-protection, all files in that directory or volume are added to the read-protected list. The rules are inherited by sub-directories, as well. All unauthorized attempts to read a read-protected file, directory, or volume are stopped, and an event is generated in the Event Log.

1.3.3Application Control

The Solidcore Service also contains Application Control functionality, which prevents the execution of unauthorized program code on a managed system. Upon initial configuration, Application Control takes an initial snapshot of the software implemented on a managed system, and creates a whitelist inventory of the program code that exists at that time on the system. The listed program code includes binary executables such as ‘.exe’ and ‘.dll’ files, as well as scripts, such as ‘.bat’, ‘.cmd’, and ‘.vbs’ files. This becomes the list of code that will be allowed to run on the managed system.

The following types of control are enforced on the program code that is resident on the managed system’s disk, or executed on the managed system:

  • Execution control
  • Memory control
  • Tamper-proofing
1.3.3.1Execution Control

Execution control prevents all programs not in the inventory from executing on the managed system. All programs not in the inventory are considered unauthorized, their execution is prevented, and their failure to execute is logged. This enforcement prevents unauthorized programs such as worms, viruses, and spyware, which install themselves, from executing; and also provides protection against fileless malware and script-based attacks.

1.3.3.2Memory Control

Memory control protects running processes from malicious attempts to hijack them. Unauthorized code injected into a running process is trapped, halted, and logged. In this fashion, attempts to gain control of a system through buffer overflow and similar exploits are rendered ineffective, and logged.

1.3.3.3Tamper-proofing

Tamper-proofing prevents intentional and unintentional changes to files that are in the inventory by users or programs.

The Solidcore Service can be put into “Update Mode” in order for software maintenance to be performed. This allows all update actions to be bracketed within an update window. Update actions include addition, removal, or modification of software on the system. It will track every update action and automatically updates the whitelist inventory. This enables new or modified software to run when the managed system returns to normal operation (“Enable Mode”).

In addition to real-time prevention of execution of unauthorized code, Application Control also performs reviews of the Event Log and other internal logs of changes to the managed system to identify applications that are attempting to perform updates, or fail to run when they execute. At times these applications should be allowed to update or run, and this information is brought to the attention of the administrator. The administrator can then take the recommended action.

1.3.4ePolicy Orchestrator

The ePolicy Orchestrator, or ePO, provides a platform for centralized policy management and enforcement of the Application Control and Change Control product on the managed systems. It uses the System Tree to organize managed systems into units for monitoring, assigning policies, scheduling tasks, and taking actions. The System Tree is a hierarchical structure that allows administrators to combine managed systems into groups. Policies can then be applied to groups of managed systems, rather than individually.

ePO allows administrators to manage the targeted systems from a single location through the combination of product policies and client tasks. Policies ensure that the application control and change controlfeatures are configured correctly. Client tasks are the scheduled actions that run on the managed systems hosting the Solidcore Services. Client tasks are commonly used for product deployment, product functionality, upgrades, and updates.

The ePO software is comprised of several components:

  • ePO server
  • Database
  • Master repository
  • McAfee Agent

Each of these is described in the following sections.

1.3.4.1ePO Server

This is the center of the managed environment. The ePO server delivers application control and change controlpolicies, controls updates, and processes the events for all the managed systems. It includes the following subcomponents:

  • Application server – includes the Automatic Response[2] functionality, Registered Servers (see below), and the user interface
  • Agent handler – distributes network traffic generated by agent-to-server communications; responsible for communicating policies, tasks, and properties
  • Event parser – parses events received from Solidcore Services
1.3.4.2Database

The database is the central storage component for all data created and used by ePO. The database can be housed on the ePO server, or on a separate server, depending on the specific needs of the organization.

1.3.4.3Master Repository

The Master Repository is the central location for all McAfee updates and signatures, and it resides on the ePO server. The Master Repository retrieves user-specified updates and signatures from McAfee or from user-defined source sites.

1.3.4.4McAfee Agent

The McAfee Agent is a vehicle of information and enforcement between the ePO server and each managed system. The McAfee Agent retrieves updates, ensures task implementation, enforces policies, and forwards events for each managed system. It uses a separate secure channel to transfer data to the ePO server. The McAfee Agent can also be configured as a SuperAgent with the addition of a repository.

1.4TOE Overview

The TOE Overview summarizes the usage and major security features of the TOE. The TOE Overview provides a context for the TOE evaluation by identifying the TOE type, describing the product, and defining the specific evaluated configuration.

The TOE is an application and change control software-only TOE. The TOE includes all the functionality described above in Section 1.3, except where indicated. Those features and functionality excluded from the scope of the TOE are listed below in Section 1.5.3. The TOE runs on the platforms described below in Section 1.4.2.

Figure 2 shows the details of the deployment configuration of the TOE.

Figure 2– Deployment Configuration of the TOE

1.4.1Brief Description of the Components of the TOE

The TOE consists of the following software components:

  • Solidcore Service – manages the policy for the Filesystem Driver and interfaces with the CLI and McAfee Agent;
  • Filesystem Driver (swin.sys) – the portion of the product implemented in the Operating System’s (OS) kernel space; the filesystem driver intercepts and analyzes all file system, registry, memory, and other critical reads and writes occurring in the OS and implements the core application control and change control actions;
  • ePO – for remote management of the Solidcore Service;
  • McAfee Agent – a plug-in to the Solidcore Service used by ePO.

The software packages that comprise the TOE are as follows: