ST Vid10682-Agd PDF

IBM BigFix 9.
Common Criteria Guide V1.9
Table of Contents
Preface.........................................................................................................................................................7
Introduction and Common Criteria Orientation and Roadmap....................................................................7
What is Common Criteria?.......................................................................................................................7
What this guide describes........................................................................................................................8
Network Device Protection Profile...........................................................................................................8
Specifications and References for the CC-Evaluated System........................................................................9
About the evaluated version of IBM BigFix Endpoint Manager...............................................................9
How to obtain the CC-evaluated product..............................................................................................10
Component specifications for the CC-evaluated system........................................................................11
IBM BigFix Endpoint Manager technical documentation library...........................................................11
Evaluated and non-evaluated security functionality..............................................................................12
Evaluated security functionality.........................................................................................................12
Protected Communications........................................................................................................12
Verifiable Updates......................................................................................................................12
Audit of activities........................................................................................................................12
Display Banner............................................................................................................................12
Administration ...........................................................................................................................13
Access Control ...........................................................................................................................13
Clearing of Residual Information ...............................................................................................13
Session Lock ...............................................................................................................................13
Self-Tests.....................................................................................................................................13
Security functionality not evaluated...........................................................................................13
Description of the Target of Evaluation (TOE)........................................................................................14
TOE Hardware....................................................................................................................................14
TOE Software.....................................................................................................................................14
Installation and Environmental Configuration...........................................................................................15
Network description and assumptions..................................................................................................16
Installing rhel2 (DB2 /Audit Server Machine).........................................................................................16
RAID Controller Configuration...........................................................................................................16
Create RAID 0 virtual drive.................................................................................................................16
Initialize the Virtual Drive..................................................................................................................17
Restore the RHEL Image.....................................................................................................................17
Logging into rhel2..............................................................................................................................18
Configuring DB2 on rhel2...................................................................................................................18
Installing and configuring DB2....................................................................................................19
Configuring stunnel for secure networking between rhel1 and rhel2........................................20
Configuring stunnel server on rhel2...........................................................................................20
Install rhel1 (IBM BigFix Server and Client - TOE)..............................................................................21
RAID Controller Configuration...........................................................................................................21
2
Create RAID 0 virtual drive.................................................................................................................21

Restore the RHEL Image.............................................................................................................22
Logging into and out of rhel1 (The TOE).....................................................................................23
Change DB2 client password......................................................................................................23
Configure rsyslog........................................................................................................................23
Configure auditd to use rsyslog..................................................................................................23
Changing the rhel1 hostname............................................................................................................24
Configuring Stunnel on rhel1.............................................................................................................24
Configuring stunnel client on rhel1 to connect to rhel2.............................................................24
Edit /etc/hosts on both machines......................................................................................................25
Install/Configure the IBM BigFix Server.....................................................................................25
IBM BigFix License Key Install...............................................................................................25
Installing the IBM BigFix Server.........................................................................................................25
Installing the IBM BigFix Client..................................................................................................33
Installing the IBM BigFix Console on win7box...................................................................................33
Windows 7 machine .iso clone instructions to install Windows.................................................33
Logging in to win7box........................................................................................................................34
Proceed to log into win7box as administrator...................................................................................34
Installing the Console, Logging in and Logging Out............................................................................34
Manual Policy Gather Step for Air-Gap Networks .............................................................................35
Enhanced Security Configuration and References.....................................................................................39
IBM BigFix Endpoint Manager Warning banner .............................................................................39
Organizational security policies.............................................................................................................39
How to View Remote rsyslog Events......................................................................................................40
RHEL Audit Events..................................................................................................................................41
Configuring auditd for a Common Criteria.........................................................................................41
Starting the audit Service...................................................................................................................41
IBM BigFix Audit Events........................................................................................................................43
SERVICE - Triggered when the service is started or stopped..............................................................43
AUTH - Triggered when a user attempts to log in or unlock the session............................................43
NOTIFICATION - Triggered when a refresh notification is sent...........................................................44
APPROVAL - Triggered when an action approval takes place by an additional user...........................44
ACTION - Triggered when an operator attempts to create an action.................................................44
CERTIFICATE - Triggered for operator actions on computer certificates.............................................44
PERMISSION - Triggered when user permissions are modified..........................................................44
ROLE - Triggered when roles are modified.........................................................................................45
USER - Triggered when a user account is modified............................................................................45
CONNECTION - Triggered when an inbound trusted connection is accepted, closed or failed..........45
Audit Records.........................................................................................................................................50
Audit Records.....................................................................................................................................50
Audit Logging Behavior Under TLS Failure.........................................................................................50
Guidance for networking.......................................................................................................................51

Hardening IBM BigFix Endpoint Manager..............................................................................................52
Changing Privileges On Files, Certificates and Public Keys.....................................................................52
How to configure IBM BigFix password policies:...................................................................................52
Configuring IBM BigFix session termination:.........................................................................................53
IBM BigFix Endpoint Manager Warning banner.....................................................................................54
RHEL Hardening And Configuration.......................................................................................................54
SetUID Root.......................................................................................................................................54
........................................................................................................................................................54
Allow Use of USB Stick.......................................................................................................................54
Disabled Functionality on the TOE.........................................................................................................54
RHEL 6.6 Terminal lockout.....................................................................................................................55
RHEL 6.6 Account Settings.....................................................................................................................56
How to configure a RHEL warning banner (rhel1)..................................................................................57
TLS Ciphersuites.....................................................................................................................................57
Keys On the TOE.....................................................................................................................................58
Software Versions..................................................................................................................................58
IBM Endpoint Manager......................................................................................................................59
RHEL...................................................................................................................................................59
Logging Into and Out of the TOE (rhel1)................................................................................................59
Reliable time-stamps.............................................................................................................................60
Firewall configuration............................................................................................................................60
Processes that receive data from the network......................................................................................60
Power on self-test..................................................................................................................................61
Cryptography self-tests..........................................................................................................................61
RHEL Operating System/Open SSL..............................................................................................61
Stunnel.......................................................................................................................................62
IBM Endpoint Manager components..........................................................................................62
Administrator Access to TSF-data..........................................................................................................62
Prior to Disabling Root...................................................................................................................63
Disabling root Account...................................................................................................................63
Re-enabling root Account...............................................................................................................63
Hardware Hardening..............................................................................................................................64
Assumptions......................................................................................................................................64
Upgrade process................................................................................................................................65
Support......................................................................................................................................................67
Notices.......................................................................................................................................................68
Trademarks............................................................................................................................................70
Intentional blank page
Preface
This guidance document is broken down into 4 high level areas. The information contained in each is as
follows:
(I) Introduction and Common Criteria (CC) Orientation and Roadmap General introduction and
explanation of Common Criteria and the Protection Profile.
(II) Specifications And References for the IBM BigFix CC-Evaluated System Describes the TOE and
evaluated components as well as how to obtain the CC-Evaluated product
(III) Installation and Environmental Configuration Initial install procedure for the TOE and supporting
components.
(IV) Enhanced Security Configuration and References Outlines all required steps taken after install that
are necessary for bringing the TOE into compliance. Describes enhanced security features and how to
use them.
Introduction and Common Criteria

Orientation and Roadmap
What is Common Criteria?
What this guide describes
Network Device Protection Profile
What is Common Criteria?

In order to ensure the security of their computer environments, many governments and other
organizations rely on the development of and adherence to strict standards for software and other
products. One of the most important of these standards is the Common Criteria for Information
Technology Security Evaluation, an internationally recognized ISO standard (ISO 15408) that defines
general concepts and principles of information technology (IT) security evaluation and presents a general
model of evaluation.
Common Criteria presents constructs for expressing IT security objectives, for selecting and defining IT
security requirements, and for writing high-level specifications for products and systems. Common
Criteria is used by the United States federal government, international governments, and other
organizations to assess the security and assurance of technology products. The Common Criteria
provides a standardized method of expressing security requirements and defines rigorous criteria by
which products are evaluated.
7
A product that passes a Common Criteria evaluation receives officially recognized certification. Common
Criteria certification is widely recognized among IT professionals, government agencies, and customers
as a seal-of-approval for mission-critical software. Common Criteria evaluation can take place in any
certificate issuing member country. The Common Criteria Mutual Recognition Arrangement (CCMRA)
ensures that certified products are accepted globally. New members are regularly and frequently added
to the list of countries. You can find the information about Common Criteria at the following Web site:
http://www.commoncriteriaportal.org
What this guide describes

The document flows as follows:
Information on Common Criteria and Network Device Protection Profile
Basic structure of the IBM BigFix Endpoint Manager environment for Common Criteria
Security Configuration of software and operating systems for Common Criteria
The system configuration that meets these conditions is referred to as a CC-evaluated system in this
guide. The TOE is only a subset of the system. Other components of the system were not
officially evaluated.
A CC-evaluated implementation of IBM BigFix Endpoint Manager makes specific assumptions about
installation, configuration, and security that distinguishes it from most production versions of the
product. A CC-evaluated version of the product includes certain restrictions on the way product
components are employed and draws specific boundaries around functionality and performance. The
purpose of this guide is to describe the assumptions, conditions, and boundaries required to reproduce
the implementation of IBM BigFix Endpoint Manager used for the Common Criteria evaluation.
This Common Criteria evaluation is based on the English version of IBM BigFix Endpoint Manager and its
documentation. You must use only the English-version IBM BigFix Endpoint Manager GUI and refer only
to the English-version technical documentation when implementing the CC-evaluated version of IBM
BigFix Endpoint Manager.
Network Device Protection Profile

IBM BigFix Endpoint Manager is certified under the Network Device Protection Profile. This Protection
Profile (PP), describing security requirements for a Network Device (defined to be an infrastructure
device that can be connected to a network), is intended to provide a minimal, baseline set of
requirements that are targeted at mitigating well defined and described threats. It represents an
evolution of "traditional" Protection Profiles and the associated evaluation of the requirements
contained within the document. This introduction will describe the features of a compliant TOE, and will
also discuss the evolutionary aspects of the PP as a guide to readers of the document.
This is a Protection Profile (PP) for a network device. A network device in the context of this PP is a
device composed of hardware and software that is connected to the network and has an infrastructure
role in the overall enterprise. Examples of a "network device" that should claim compliance to this PP
8
include routers, firewalls, IDSs, audit servers, and switches that have Layer 3 functionality. Examples of
devices that connect to a network but are not suitable for evaluation against this PP include mobile
devices ("smart phones"), end-user workstations, SQL servers, web servers, application servers, and
database servers.
Compliant TOEs will provide security functionality that addresses threats to the TOE and implements
policies that are imposed by law or regulation. Compliant TOEs must protect communications to and
between elements of a distributed TOE (e.g., between a network IDS sensor and the centralized IDS
manager) or instantiations of the TOE in a single enterprise (e.g., between routers). The TOE must offer
identification and authentication services that support the composition of moderate complex passwords
or passphrases, and make these services available locally (that is, a local logon) as well as remotely
(remote login). The TOE must also offer auditing of a set of events that are associated with securityrelevant activity on the TOE, although these events will be stored on a device that is distinct from the
TOE. The TOE must offer some protection for common network denial of service attacks and must also
provide the ability to verify the source of updates to the TOE.
While the protocols required by this PP make use of certificates, this version of the PP does not levy
requirements on the certificate infrastructure (for example, using OCSP to verify a certificate's validity).
Such requirements will be included in future versions of this document.
It is intended that the set of requirements in this PP is limited in scope in order to promote quicker, less
costly evaluations that provide some value to end users. STs that include a large amount of additional
functionality (and requirements) are discouraged. Future modules will be used to specify sets of
additional functionality (e.g., Firewalls, VPNs), which can then be used by ST writers looking to specify
additional functionality.
Specifications and References for the CCEvaluated System
About the evaluated version of IBM BigFix Endpoint Manager

How to obtain the CC-evaluated product
Component specifications for the CC-evaluated system
IBM BigFix Endpoint Manager technical documentation library
Evaluated and non-evaluated security functionality
Environmental Description: Target of Evaluation (TOE)
About the evaluated version of IBM BigFix Endpoint

Manager
The version of IBM BigFix Endpoint Manager that has been certified under Common Criteria is 9.2. The
system configuration that meets these requirements is referred to as a CC-evaluated system in this
guide. The Common Criteria evaluation for IBM BigFix Endpoint Manager was performed on the specific
configuration described in this guide. Any deviation from this configuration may result in a nonevaluated system, but does not necessarily mean that the security of the system is reduced.
The TOE and supporting environment comprises 3 ISO images to be installed according to the steps
contained in this guide. Once installed and configured these will provide the complete platform
necessary to operate the IBM BigFix BigFix Endpoint Manager in compliance with this evaluation. In
this guide we will refer to that set of ISO images as The CC-Evaluated Product.
How to obtain the CC-evaluated product

Software:
IBM BigFix Endpoint Manager is a distributed system comprising the IBM BigFix Endpoint Manager
Server, IBM BigFix Client, database, and Console. Only the IBM BigFix Endpoint Manager Server and IBM
BigFix Client have been assessed as the part of the evaluation, while other components are considered
to provide supplementary functions in the IT environment. In this guide the term when the CCevaluated System is referred to, please note this includes the TOE and supporting operational
environment as described below.
The CC-evaluated IBM BigFix Endpoint Manager Version can be obtained by contacting your IBM U.S.
Federal Sales representative through the following link:
https://www.ibm.com/connect/federal/us/en/home .
This link notifies IBM Federal Sales of your request to receive all CC Evaluated materials and guides and
you will be directly contacted by a Sales representative to provide the DVD set.
Please request the IBM BigFix Common Criteria TOE and Operational Environment Release 9.2. It will be
provided on DVDs in the form of (for a discussion of the contents of the distribution media see
Installation and Environmental Configuration):
ISO image comprising the TOE rhel1. This contains the IBM BigFix server, IBM BigFix client and
BESAdmin Tool - IBM BigFix 9.2 Common Criteria Release: DVD
**Note that the IBM BigFIx server on the ISO image will be patched during installation
with the server overlay image listed below
ISO images for the operational environment rhel2 and win7box. These contain the IBM BigFix
DB2 data store, audit server and the IBM BigFix Windows Console. IBM BigFix 9.2 Common
Criteria release: DVD (2 ISO images).
**Note that the IBM BigFIx Console on the ISO image will be patched during installation
with the console overlay image listed below
The BES Authorization file to create licenses (the license.crt file):
LicenseAuthorization.BESLicenseAuthorization
IBM BigFix Console patch overlay File (BESConsole.exe)
IBM BigFix Server patch overlay file (ServerInstaller_9.2.3.101-rhel6.x86_64.tgz)
The CC Guidance Documentation: BigFix Common Criteria Configuration Guide_<version>.odt
Upgrade fixlet: BES Support QA.efxm
10
RedHat security patch: RHEL OpenSSL RPM (openssl-1.0.1e-42.el6_7.2.x86_64.rpm)
Software Acceptance:
The CC Evaluated DVD set will include a printed serial number/hash key code on each DVD.
After you receive the DVDs you will contact the sending representative and the matching hash code will
be separately provided to you by via email in a password protected file. You will then verify that the
codes on your DVD packages matches that which was sent.
Hardware:
The customer can purchase the hardware components matching those used in the TOE evaluation that
host the software components from IBM/Lenovo. Please see the specifications in section TOE Hardware
below. Please contact your IBM U.S. Federal Sales Representative to acquire matching hardware.
IBM uses a known courier to ship the boxes containing the TOE hardware to ensure their integrity during
shipping. This courier supports the ability to track the packages against a tracking number. Upon receipt
of the packages, please check that the boxes are factory sealed and have not been opened and check the
contents against the packing slip.
Please note that shipments are sent requiring signature for delivery to ensure they are not handed off in
an insecure fashion.
Please also check the serial numbers on each machine with those on record with your Sales
Representative to ensure they match.
If the serial numbers do not match or is any box appears to have been tampered with please contact
your sales representative immediately and do not proceed with the install.
Component specifications for the CC-evaluated system

The CC-evaluated implementation of IBM BigFix Endpoint Manager is a single-node deployment only.
The list of CC-evaluated IBM Endpoint Manager components is:
IBEM 9.2.3.101 Server software component (Linux only)
IBEM 9.2.3.101 Client software component (Linux only)
Red Hat Enterprise Linux (RHEL) 6.6 Server (x86-64)
IBM BigFix Endpoint Manager technical documentation

library
This Common Criteria evaluation is based on the English version of IBM BigFix Endpoint Manager and its
documentation. The following technical documents provide standard information and procedures for
installing and configuring the IBM BigFix Endpoint Manager. These documents were updated and
11
revised for version 9.2. Any deviation from these manuals for Common Criteria certification will be
specified in this Common Criteria Guide: http://www01.ibm.com/support/knowledgecenter/SS63NW_9.2.0/com.ibm.tem.life.doc_9.2/platform.html
Evaluated and non-evaluated security functionality

Evaluated security functionality
Security functionality not evaluated
Evaluated security functionality

This section describes the security functionality that was evaluated for the 9.2 version of IBM BigFix
Endpoint Manager. Note that provisioning & client state data have not been evaluated. The list of
evaluated functionality is:
Protected Communications
Verifiable Updates
Audit of activities
Display Banner
Administration
Access Control
Clearing of Residual Information
Session Lock
Self Test
Protected Communications
The IBM BigFix Endpoint Manager provides uses encryption and digital signatures to guarantee the
communications between all components.
Verifiable Updates
The IBM BigFix Endpoint Manager provides the capability to ensure that any updates to the TOE can be
verified by the administrator to be unaltered and from a trusted source.
Audit of activities
The IBM BigFix Endpoint Manager is capable of auditing internal events (such as the modification of
policies or the creation of new users) by generating audit information for all transactions and storing this
information remotely in the system log. The local logs are created in the cache during normal operation
and rsyslogs is used to store them remotely. The local logs are equivalent to the local 1GB cache.
Display Banner
12
The IBM BigFix Endpoint Manager displays a warning banner advisory on its console which is viewed
prior to logging in.
Administration
IBM BigFix Endpoint Manager identifies users (including administrators) by user name and authenticates
them by password. IBM BigFix Endpoint Manager users are persons having an account on the IBM BigFix
Endpoint Manager system. Users can be organized by membership in BigFix Admin groups. Only hashes
of the passwords are stored in the IBM BigFix Endpoint Manager system. Password policies can be
applied to enforce requirements on the quality of the password that a user chooses. Lockout
mechanisms prevent password guessing attacks.
Access Control
IBM BigFix Endpoint Manager performs authorization for user actions, commonly referred to as
requests, based on access control . Functionality and data in an IBM BigFix deployment can be restricted
to certain users or groups . Users and user groups can be granted administrator privileges over specific
data or functionality.
Creation of users
Assigning privileges to users
Enforcing access restrictions on users
Clearing of Residual Information

IBM BigFix Endpoint Manager ensures that any data contained in a protected resource is cleared when
no longer in use and not available when the resource is reallocated.
Session Lock
The IBM BigFix Endpoint Manager provides mechanisms that mitigate the risk of unattended sessions
being hijacked via timeouts for locking and subsequently terminating idle sessions.
Self-Tests
The IBM BigFix Endpoint Manager provides the capability to test some subset of its security
functionality to ensure it is operating properly.
Security functionality not evaluated

This section lists the security functionality that was determined to be out of scope and therefore not
evaluated for the 9.2 version of IBM BigFix Endpoint Manager. You can use the functionality listed in this
section; however, the current Common Criteria evaluation for IBM BigFix Endpoint Manager Version 9.2
does not provide any level of assurance for the use of these items.
Encrypted reports
13
Client authentication
Use of the BESAdmin tool to change client authentication settings
Key rotation
Description of the Target of Evaluation (TOE)

Assumptions
Intended usage of the TOE
NO_GENERAL_PURPOSE It is assumed that there are no general-purpose computing

capabilities (e.g., compilers or user applications) available on the TOE, other than those services
necessary for the operation, administration and support of the TOE.
PHYSICAL Physical security, commensurate with the value of the TOE and the data it contains,
is assumed to be provided by the environment.
TRUSTED_ADMIN TOE Administrators are trusted to follow and apply all administrator
guidance in a trusted manner.
TOE Hardware
TOE Software
TOE Hardware
The physical TOE hardware consists of
IBM System x3500 M5

Dual Intel Xeon Processor E5-2637 v3 3.5GHz 15MB 130W Kit
Intel Xeon Processor E5-2637 v3 3.5GHz 15MB Cache 1866MHz
8GB (1x4GB- 2Rx8- 1.5V) PC3-14900 CL13 ECC DDR3 1866MHz LP R
ServeRAID M5210 SAS/SATA Controller for IBM System
IBM DVD-ROM
IBM ServeRAID M5210 SCSI Disk 1.09TB
Monitor
Keyboard
Mouse
TOE Software
The TOE software consists of
Standard Red Hat Linux Version 6.6
IBM BigFix Endpoint Manager 9.2 Server
14
IBM BigFix Endpoint Manager 9.2 Client

Note that the versions of stunnel and openssl packages that reside in the ISO images have had their
security modules updated in order to meet the Security Target cryptography requirements.
Software Entity Names
Note that the IBM BigFix Endpoint Manager 9.2 server is a collection of processes consisting of
BESGatherDB, BESFillDB, BESRootServer
The IBM BigFix client (agent) is running as the BESClient process.
Installation and Environmental

Configuration
The CC Evaluated IBM BigFix component placement is as follows on 3 physical computers that make up
the TOE and supporting Operational Environment:
3 Physical machines contain:
I. IBM BigFix Console on Windows 7 machine (w7box)
II. IBM BigFix Server, Client and and BESAdmin Tool on the TOE, a RHEL 6.6 machine (rhel1)
III. DB2 and audit server on a separate RHEL Linux machine (rhel2)
There are 9 items that make up the installation package and are included in the distribution media:
3 ISO images corresponding to w7box,rhel1 and rhel2 (DVDs)
1 IBM BigFix Endpoint Manager Console install package (BESConsole.exe)
1 IBM BigFix Endpoint Manager Server install package (ServerInstaller_9.2.3.101rhel6.x86_64.tgz)
1 BES Support Site Masthead (BES Support QA.efxm)
1 file from which licenses are generated (LicenseAuthorization.BESLicenseAuthorization)
1 RHEL RPM containing necessary security patches ( RHEL OpenSSL RPM (openssl-1.0.1e42.el6_7.2.x86_64.rpm)
As previously mentioned, the CC-Evaluated product is contained in three ISO images corresponding to
the above three components. The installation process involves copying those software (ISO) images to
the appropriate hardware components using Clonezilla.
Clonezilla is a system imaging package. Use of this tool facilitates installation of system image, including
operating system and database, on the required hardware that is almost completely configured to meet
the Common Criteria evaluated configuration. This removes the added complexity of needing to
configure generic RHEL 6.6 and DB2 installations to meet the Common Criteria Security Target.
15
Network description and assumptions

The machines w7box, rhel1 and rhel2 are connected to a closed local area network. This is known to IBM
BigFix users as the Air-Gap Network Configuration.
Installing rhel2 (DB2 /Audit Server Machine)
RAID Controller Configuration

Initialize the virtual driver
Restore the RHEL Image
Logging in to rhel2
Configuring DB2 on rhel2

Before any hard drive images can be restored, The RAID controller in the servers needs additional
configuration in order to use the installed disk drive. A virtual disk must be created in order to
set the RAID level, which in our case is RAID 0 because there is only one disk.
Create RAID 0 virtual drive

Power on the computer. After the POST, at the Lenovo splash screen, press F1 to enter the UEFI server firmware
setup program.
Select "System Settings" and then select "Storage".

Select "LSI MegaRAID <ServeRAID M5210> Configuration Utility".
Select "Configure"
Select "Create Virtual Drive"
For "Select RAID Level", select "RAID0"
Next, go to "Select Drives From" and select "Unconfigured Capacity"
Select "Select Drives". This brings a new menu screen.
Go to Drive Port xxx and press Spacebar to select the physical drive. The drive port may vary but there
will only be one drive to select.
Select "Apply Changes". This should bring a new screen with the message "The operation has been
performed successfully". Select "OK" to return to the "Create Virtual Drive" screen.
Go to "Virtual Drive Name" and enter a name for the virtual drive.
16
Select "Save Configuration"

A new screen "Warning" appears warning that creating a new virtual drive will delete any data on the
physical drive
that the virtual drive was created from. For new hard drives this is not an issues.
Move to "Confirm" and press spacebar to select that the consequences are understood.
A new menu item "Yes" appears. Select "Yes" to create the virtual drive. If creation is successful, a new
screen appears "Success". Select "OK".
This returns you to the screen "Main Menu". Press Esc to exit. At the "Success" screen, press Esc. This
brings up the screen "Create Virtual Drive" and message informing of the successful creation of a virtual
drive.
Press Esc again. This brings back the "Configuration Management" screen.
Press Esc to exit to the "Dashboard View" screen. For "Virtual Drives" there should be 1. Press Esc again
to exit. This bring back the "Storage" screen.
Press Esc to exit this screen. This brings back "System Settings" press Esc to return to "System
Configuration and Management".
Now set the system time. Select "Date and time" and set appropriately. Exit this, and then exit "System
Configuration and Boot Management". Press Y to Save and Exit the Utility. This reboots the computer.
Initialize the Virtual Drive

From the Main Menu select Virtual Drive Management
Specify Virtual Drive 0: [name], RAID 0,...
Select Operation then Fast Initialization
Select Go
Press space bar
Confirm [x]
Select OK on the Success popup

Clone the RHEL image onto your rhel2 machine from the corresponding IBM BigFix CC DVD for rhel2.
The ISO image DVDs obtained as part of the Common Criteria package are bootable. B oot from the
17
DVD, and answer the Clonezilla prompts to restore the image. wRestoring the image will
permanently overwrite any existing data". Keep answering yes, and the image will self
install. Please refer to the following link for instructions on cloning a RHEL Linux image:
https://www.linux.com/learn/tutorials/783416-how-to-image-and-clone-hard-drives-withclonezilla
1. Place the IBM BigFix CC Evaluated installation DVD into the DVD device on rhel2 (DB2 machine)
2. Boot the machine from the DVD and follow the directions under the heading Restoring a
Clonezilla Image using the DVD device from step 2 as the source.
3. When Clonezilla is finished, select Reboot
Logging into rhel2

Proceed to log into rhel2 as user db2inst1
I. Access the rhel2 console
ii. Type in db2inst1 for user name
iii. Type password db2inst1
Set the rhel2 system date and time

The current date and time should be set on rhel2 before making any other configuration changes. This
ensures that correct dates and times are issued in log messages and put into file time stamps. With root
privileges to set the date, issue the command
date +%D -s YYYY-MM-DD
Where YYYY is the year, MM is two digits for the month, and DD is the day within that month. To set the
system time, with root privileges issue the command
date +%T -s HH:MM:SS
Where HH is the hour, MM is the minute, and SS is the second.
Official Red Hat guidance on how to change the RHEL 6 operating system time can be found in Section
2.2 of the RHEL 6 Deployment Guide: https://access.redhat.com/documentation/enUS/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/index.html
Configuring DB2 on rhel2

Installing and configuring DB2
Configuring Stunnel Client on rhel2 for rsyslog & Audit Event Viewing
18
Installing and configuring DB2

DB2 V10.5 Enterprise Server Edition:
1. The IBM BigFix Endpoint Manager CC DVD for rhel2 is pre-installed with DB2 V10.5 Enterprise
for RHEL installed.
2. The IBM BigFix Endpoint Manager CC DVD for rhel1, which contains the IBM BigFix Server
(which is updated during the install) and Client, has an embedded DB2 10.5 client included for
local access. It will communicate with the DB2 10.5 server installed on the remote workstation.
No additional DB2 configurations (such as the catalog of the remote database) are required.
3. On the remote DB2, ensure that the DB2 administrative server db2admin is started to enable
remote administration. To start db2admin, run the following commands note that the dasusr1
password will default to dasusr1. This will be the case for all the default accounts.
# su dasusr1
$ db2admin start
Changing the rhel2 Server Host Name

The DB2 version supplied with the IBM BigFix Server for Linux tarball has no licensing constraints. DB2
v10.5 can gracefully handle changes to the hostname if the hostname is changed before the Platform is
installed. If done in this manner no configuration changes are necessary for DB2.
If so desired, the hostname of the rhel2 machine can be changed from its pre-configured value by doing
the following as the root user. First, use the editor vim to edit the file /etc/sysconfig/network. Change
the line 'HOSTNAME=rhel2' so that 'rhel2' is replaced with the desired hostname. Next, use vim to edit
the file /etc/hosts, replacing both entries of 'rhel2' with the desired hostname.
Now restart the network interfaces by issuing the command
/etc/init.d/network restart
Finally, issue the command
hostname new_hostname
where new_hostname is the desired hostname for the rhel2 machine. The bash RHEL console prompt
will retain the old hostname until the current bash session is terminated. New bash sessions will have
the new hostname in the prompt.
Changing the DB2 account passwords
On the rhel2 machine, the following RHEL system accounts used by DB2 need to have their passwords
changed: dasusr1, db2fenc1, db2inst1. This can be done as root using the command passwd account,
where account is one of the accounts previously listed. Note that by default, the above DB2 accounts
19
will have their passwords set to the same text as the user name (e.g. dasusr1/dasusr1). These should be
changed prior to production deployment.
Applying OpenSSL, RHEL Patches
We have provided a RHEL rpm for applying the latest security patches prior to deploying the
environment.
0. you must be root
1. copy openssl-1.0.1e-42.el6_7.2.x86_64.rpm from the CC media to /tmp
2. apply the patch with the following command:
rpm -Uvh /tmp/openssl-1.0.1e-42.el6_7.2.x86_64.rpm
Configuring stunnel for secure networking between rhel1 and rhel2.

Stunnel is used to provide secure connections for DB2 and rsyslog between rhel1 and rhel2 by creating a
TLS tunnel for both services. Rhel2 is configured to be the stunnel server, while rhel1 will be the stunnel
client. After installing the Clonezilla images on rhel1 and rhel2 the stunnel configuration is almost
complete only requiring the creation of a new secure certificate/private key pair on rhel2, along with
updating rhel2's hostname if it has been changed from default.
WARNING: The RHEL operating system, stunnel, and as well as both the BES server and client all use the
same shared OpenSSL 1.0.1e-based library, but the use of other cryptographic engines was not evaluated
nor tested during the CC evaluation of the TOE.
Configuring stunnel server on rhel2

The first step is to generate a new certificate/private key pair for use in stunnel's TLS connection
between rhel1 and rhel2. The same certificate will be used for both DB2 and rsyslog connections
between the machines.
On the rhel2 machine, login as root and change to root's home directory. To generate the
certificate/private key pair, enter the command
openssl req -new -x509 -days 1095 -nodes -out
/etc/pki/tls/certs/stunnel.crt -keyout
/etc/pki/tls/private/stunnel.pvk -sha256 -newkey rsa:2048
The openssl will require input for the computer locality, common name, and admin email address. For
the common name, enter the chosen host name of rhel2. This will generate a self signed certificate valid
for 3 years from the date of creation with a 2048-bit RSA key and SHA-256 message digest.
This private key file contains very sensitive secret information which must be protected from viewing by
unauthorized users. As such, only root should be able to read this file. Adjust the file permissions so that
only root can read this file by entering the command
20
chmod a-r /etc/pki/tls/private/stunnel.pvk

Copy the public certificate file located at /etc/pki/tls/certs/stunnel.crt to a USB stick. This file will be
installed as a trusted certificate on rhel1 to authenticate the rhel2 machine.
To complete the rhel2 stunnel configuration, the stunnel daemon mbust be restarted. To do this, as root
enter the command
/etc/init.d/stunnel restart
Install rhel1 (IBM BigFix Server and Client - TOE)

Logging into rhel1
Installing the IBM BigFix Server
Installing the IBM BigFix Client
Manual Policy Gather Step for Air-Gap Networks
Configuring Stunnel on rhel1 for ryslogs & Audit Events

Before any hard drive images can be restored, The RAID controller in the servers needs additional configuration in
order to use the installed disk drive. A virtual disk must be created in order to set the RAID level, which in our case
is RAID 0 because there is only one disk.
Create RAID 0 virtual drive.

Power on the computer. After the POST, at the Lenovo splash screen, press F1 to enter the UEFI server firmware
setup program.
Select "System Settings" and then select "Storage".
Select "LSI MegaRAID <ServeRAID M5210> Configuration Utility".
Select "Configure"
Select "Create Virtual Drive"
For "Select RAID Level", select "RAID0"
Next, go to "Select Drives From" and select "Unconfigured Capacity"
Select "Select Drives". This brings a new menu screen.
Go to Drive Port xxx and press Spacebar to select the physical drive. The drive port may vary but there will only be
one drive to select.
Select "Apply Changes". This should bring a new screen with the message "The operation has been performed
successfully". Select "OK" to return to the "Create Virtual Drive" screen.
Go to "Virtual Drive Name" and enter a name for the virtual drive.
21
Select "Save Configuration"

A new screen "Warning" appears warning that creating a new virtual drive will delete any data on the physical drive
that the virtual drive was created from. For new hard drives this is not an issues.
Move to "Confirm" and press spacebar to select that the consequences are understood.
A new menu item "Yes" appears. Select "Yes" to create the virtual drive. If creation is successful, a new screen
appears "Success". Select "OK".
This returns you to the screen "Main Menu". Press Esc to exit. At the "Success" screen, press Esc. This brings up the
screen "Create Virtual Drive" and message informing of the successful creation of a virtual drive.
Press Esc again. This brings back the "Configuration Management" screen.
Press Esc to exit to the "Dashboard View" screen. For "Virtual Drives" there should be 1. Press Esc again to exit. This
bring back the "Storage" screen.
Press Esc to exit this screen. This brings back "System Settings" press Esc to return to "System Configuration and
Management".
Now set the system time. Select "Date and time" and set appropriately. Exit this, and then exit "System
Configuration and Boot Management". Press Y to Save and Exit the Utility. This reboots the computer.
Initialize the Virtual Drive

From the Main Menu select Virtual Drive Management
Specify Virtual Drive 0: [name], RAID 0,...
Select Operation then Fast Initialization
Select Go
Press space bar
Confirm [x]
Select OK on the Success popup

Restore the IBM BigFix CC Evaluated RHEL image for the IBM BigFix server machine onto your rhel1
machine from the IBM BigFix CC Evaluated DVD corresponding to rhel1.
Clone the RHEL image onto your rhel1 machine from the corresponding IBM BigFix CC DVD for rhel1.
The ISO image DVDs obtained as part of the Common Criteria package are bootable. B oot from the
DVD, and answer the Clonezilla prompts to restore the image. wRestoring the image will
permanently overwrite any existing data". Keep answering yes, and the image will self
install. Please refer to the following link for instructions on cloning a RHEL Linux image:
https://www.linux.com/learn/tutorials/783416-how-to-image-and-clone-hard-drives-withclonezilla
1. Place the IBM BigFix CC Evaluated installation DVD into the DVD device on rhel1 (IBM BigFix
Server machine)
22
2. Boot the machine from the DVD and follow the directions under the heading Restoring a
Clonezilla Image using the DVD device from step 2 as the source.
3. When Clonezilla is finished, select Reboot
Logging into and out of rhel1 (The TOE)

Proceed to log into rhel1 as user root
Access the rhel1 console
Type in root for user name
Type password root
Note: to log out, type the command logout at the command line.
Note: remote log in is disabled.
After the installation please change this password to a strong secure password known to the machine
administrators
Set the rhel1 system date and time

The current date and time should be set on rhel1before making any other configuration changes. This
ensures that correct dates and times are issued in log messages and put into file time stamps. 'Please see
the section Set the rhel2 system date and time' for details on how to set the system data and time for
rhel1.
Change DB2 client password

On the rhel1 machine, the RHEL system account db2inst1 used by the DB2 remote client needs to have
its password changed. This can be done by logging in as the user db2inst1 and then issuing the
command
passwd
Changing the password in this way, rather than as the root user, will enforce the password policies set for
rhel1.
Configure rsyslog
On rhel1, syslog will be pre-configured to send logging messages to the rhel2 machine via secure stunnel
TLS forwarding. All that needs to be done is modify the stunnel configuration if the hostname for the
rhel2 machine has been changed from its pre-configured value. This is detailed below.
Configure auditd to use rsyslog

The rhel1 image is pre-configured to have the Linux Auditing System daemon auditd log all audit events
via rsyslog to the rhel2 remote rsyslog server. No additional configuration is required.
23
Changing the rhel1 hostname

The rhel1 machine comes pre-configured with the hostname rhel1. If so desired, this hostname can be
changed. The procedure for changing the hostname on rhel1 is identical to the procedure for rhel2. This
must be done before creating the license certificate with the IBM BigFix installer as the IBM BigFix
server hostname is tied to the license and masthead.
Applying OpenSSL, RHEL Patches

We have provided a RHEL rpm for applying the latest security patches prior to deploying the
environment.
0. you must be root
1. copy openssl-1.0.1e-42.el6_7.2.x86_64.rpm from the CC media to /tmp
2. apply the patch with the following command:
rpm -Uvh /tmp/openssl-1.0.1e-42.el6_7.2.x86_64.rpm
Configuring Stunnel on rhel1

Configuring stunnel client on rhel1 to connect to rhel2
Connect the USB stick with the stunnel public certificate to rhel1. Transfer the stunnel.crt file into the
location /etc/pki/tls/certs/stunnel.crt on rhel1, overwriting the existing certificate. If the hostname for
the rhel2 machine has been changed from the default setting, the stunnel configuration file on rhel1
must be updated to use the new hostname. To do this, as root use the vim text editor to replace 'rhel2'
with hostname on the lines beginning with connect = in the file /etc/stunnel/stunnel.conf. This can be
done as single command by entering as root
sed -i "s/rhel2:/hostname:/" /etc/stunnel/stunnel.conf
Where hostname is the new hostname for rhel2. The next time rhel1 is booted into multi-user mode the
stunnel daemon will start using the new certificate and hostname for the connection to rhel2. The
changes can be made to take effect immediately by restarting the stunnel daemon; as root this can be
done with the command /etc/init.d/stunnel restart
After restarting the stunnel daemon on rhel2 and rebooting rhel1 into multiuser mode, both rsyslog and
DB2 will be using the new secure stunnel connection between the two machines.
Please be sure to reboot rhel1.
24
Edit /etc/hosts on both machines

If the hostnames are unchanged, then these files do not need to be modified.
If the hostname for rhel2 has been changed, then the file /etc/hosts on rhel1 needs to be updated to
reflect this. As root, edit this file with vim and replace 'rhel2' with the new hostname for rhel2.
Similarly, if the hostname for rhel1 has been changed, then the file /etc/hosts on rhel2 must be edited as
above with 'rhel1' replaced with the new hostname for rhel1.
Install/Configure the IBM BigFix Server

IBM BigFix License Key Install
IBM BigFix License Key Install
Following the Airgap network approach, handling the license authorization file needs to be copied from
an external machine for installation.
The key material is copied over to the rhel1 server manually per the steps below.
Installing the IBM BigFix Server

To install the Endpoint Manager Server in your production environment, perform the following steps. If
any steps are unclear or if the order of the questions is slightly different and you do not know how to
proceed, please contact your IBM Federal Sales representative and we will arrange to walk you through
the process. Note that if you install multiple times some of the prompts will differ.
1. You will have received a license file called LicenseAuthorization.BESLicenseAuthorization as part
of your CC Package from your Sales representative. Please place this file on a thumb drive
2. Copy this authorization token file to the RHEL1 server manually. They need to be saved to any
location in a place that will be referenced later in the installation steps.
3. The IEM Server software is found in the compressed tar file ServerInstaller_9.2.3.101rhel6.x86_64.tgz in the distribution media. The tar file may be copied and extracted to any
location (according to your administrative customs e.g. /usr/programs). The directory
containing those files becomes the installation directory.
$ zcat ServerInstaller_9.2.3.101-rhel6.x86_64.tgz | tar xf $ cd ServerInstaller_9.2.3.101-rhel6.x86_64
4. The database will be remote on rhel2, but the connection point to it is the local stunnel endpoint
on the TOE (rhel1). We must initially tell the install program that the database is remote so the
TOE will use the network interface to communicate with the database, but the installation
program won't accept a local hostname or IP address during configuration since normally you
should have selected local database for that. We have to force the TOE to use stunnel.
25
- Create a unique hostname for the database host

(we will use db2host here, but you can use any name you choose)
- Edit /etc/hosts and add the hostname from the above step to the line with rhel2
During the installation, when prompted for the remote database, provide this hostname
(db2host in our example). The install script will connect directly to the database (unencrypted)
to complete its configuration.
After the installation is complete, you will edit /etc/hosts again and remove db2host from the
rhel2 line and add it to the localhost line (127.0.0.1). After rhel1 is rebooted, the TOE will still
communicate with the database using the hostname db2host, but it will now connect to the
local stunnel endpoint and be forwarded to rhel2 over an encrypted connection.
5. From the root login shell cd to the server installation directory,
ServerInstaller_9.2.0.101-rhe6.x86_64 and enter the following command:
./install.sh
6. After reading the License Agreement, enter <1> to accept it and continue.
7. For the installation type, enter <2> for Production:
Select the type of installation
[1] Evaluation: Request a free evaluation license from IBM Corp.
This license allows you to install a fully functional copy of the
IBM Endpoint Manager on up to 30 clients, for a period of 30 days.
[2] Production: Install using a production license or an authorization
for a production license.
8. For the IBM Endpoint Manager features, enter <2> to install Server and Client only:
Select the IBM Endpoint Manager features that you want to install:
[1]
[2]
[3]
All components (server, client, and WebReports)

Server and client only
WebReports only
9. You will see the following display regarding database replication configuration, enter <1> to
create a single/master database (no replication):
Select the database replication:
[1]
[2]
26
Single or master database

Replicated database
10.For the database server configuration, enter <2> to use the remote rhel2 database:
Select the database:
[1]
[2]
Use a local database

Use a remote database
11.To configure IBM Endpoint Manager for use of the rhel2 DB2 instance, perform the following
steps:
a. Install the DB2 server on the remote workstation. <already done>
b. Install a DB2 client on the workstation from where you run the Endpoint Manager Server
installation <already done>
c. Stunnel for the DB must be configured beforehand. At this point the inbound port for the
stunnel would be used to configure the DB2 connection
d. Connect the DB2 server to the DB2 client installed on the workstation from where you
run the installation, that is, the port of the DB2 database (default 50000) must be
reachable by the workstation where the installation is running.
e. Provide the following information in the installation procedure:
e.i.
the remote DB2 node **
e.ii.
the DB2 port number
e.iii.
the user name of the local DB2 instance owner
Note: ** This will NOT be the remote DB2 node (rhel2). Please be aware this is NOT the final
configuration. The remote DB2 connection is equivalent to the local stunnel. The name of the
DB2 node should be the special db2-specific hostname currently associated with rhel2 db2host
in our installation example - but that will be changed to point to rhel1 later
12.For configuration of the Root Server's root folder (called web server in the install message)
message)configuration, press <Enter> to accept the default location:
Choose the web server's root folder:
Specify the location for the web server's root folder or
press <Enter> to accept the default: /var/opt/BESServer
13.Enter <db2inst1> for the user name for the local DB2 Administrative user
14.Enter <db2inst1> for the DB2 Local Administrative user password, if prompted.
15.Enter the DB2 instance configuration. Please note it is a DB2 requirement for having a remote
installation that there are 3 accounts.
27
DB2 server name: db2host (or name you chose if different)

DB2 instance owner: db2inst1
DB2 fenced user: db2fenc1

DB2 administration server user: dasusr1
DB2 communication port: 50000
16.Enter the user ID and the password to define the IBM Endpoint Manager administrative user. The
default user name is: IEMAdmin.
17.For the firewall configuration, enter <2> as the firewall is pre-configured:
Firewall configuration
The firewall of the operating system is active on the local
server. To enable the communication using the specified ports you
can:
[1] Configure the firewall now
[2] Configure the firewall later
18.For the setup type, enter <1> to install with a BES license authorization file:
Choose
[1] I
[2] I
[3] I
the setup type that best suits your needs:

want to install with a BES license authorization file
want to install with a production license that I already have
want to install with an existing masthead
Note that if you are re-installing using an existing license the steps will differ. You will instead be
prompted to Specify a folder for your site masthead
(masthead.afxm) or pres <Enter> to accept the default value."
This is followed by a prompt to "Specify the hostname of the remote DB2 system,"
followed by prompt for port, username, and password.
19.For the proxy usage, enter <2> as in the Airgap architecture, RHEL1 will not be leveraging a proxy
to access the Internet.
Proxy usage
[1]
Use the proxy to access the internet
[2]
Do not use the proxy
20.For the License authorization location, point the installer to the token file that was manually
copied to the RHEL1 server in step 2 above.
License Authorization Location
Enter the location of the license authorization file that you received
from IBM or press <Enter> to accept the default
21.For the Server DNS name, enter the DNS name of the RHEL1 server:
28
Server DNS name

This name is recorded into your license and will be used by
Clients to identify the IBM Endpoint Manager Server. It cannot be
changed after a license is created. Enter the DNS name of your
IBM Endpoint Manager server or press <Enter> to accept the
default value
22.Specify (and note) the related site admin private key password
23.For the key size level, enter <2> to select Max level (4096 bits)
Key Size Level
Provide the key size that you want to use:
[1] 'Min' Level (2048 bits)
[2] 'Max' Level (4096 bits)
24.For the license folder, specify a folder to maintain the site-admin credentials
Choose the license folder:
Specify a folder for your private key (license.pvk), the license
certificate (license.crt), and the site masthead (masthead.afxm)
or press <Enter> to accept the default value
25.The license request file will be generated. Enter <2> to save the request file
Request license
Your request is now ready for submission to IBM.
[1] Submit the request from this machine over the Internet. The
request is redeemed for a license certificate (license.crt) and
then saved in your credential folder.
[2] Save request to a file and send it to IBM at the URL:
'http://support.bigfix.com/bes/forms/BESLicenseRequestHandler.html'. This method might be necessary if your
deployment is isolated from the public Internet.
26.At this point, the BESLicenseRequest file (whose location on RHEL1 will be specified in an Info
message of the installation) must be manually copied to a machine with Internet access, and
sent to IBM via the following URL in order to obtain the license.crt to continue the installation:
a. http://support.bigfix.com/bes/forms/BESLicenseRequestHandler.html
29

a.i.Click Choose File and browse to the copied license request from RHEL1, then
click Submit
a.ii.Save the resulting license.crt and manually copy it to RHEL1
27.Once the license.crt file has been copied to RHEL1 per step 24, continue with the installation by
entering <1> to import the license certificate
Import the license certificate
[1] Continue with the installation by importing the certificate
(license.crt).
[2] Exit from the installation, I will import the certificate at
a later time.
28.Enter the License certificate location on RHEL1 per step 24 ii.
License certificate location
Enter the location of the license certificate file or press
<Enter> to accept the default value
29.For the advanced masthead parameters, enter <1> to use the defaults, which are suitable for
most deployments.
Advanced masthead parameters
The masthead will be created using the following defaults:
Server port number: 52311
Use of FIPS 140-2 compliant cryptography: Disabled
30
Gather interval: One Day

Initial action lock: Unlocked
Action lock controller: Console
Action lock exemptions: Disabled
Unicode filenames in archives: Enabled
The above default values are suitable for most of IBM Endpoint
Manager deployments. Select ,<1> for defaults and we will enable
FIPS 140-2 in a later step.
[1]
Use default values
[2]
Use custom values
30.For the Server port number, press <Enter> to accept the default value of 52311:
####################
Server port number
Specify the server port or press <Enter> to accept the default: 52311
31.For FIPS mode, enter <1> to enable

Note: ***although the generic install script mentions FIPS 140-2 compliance, the TOE does
not contain a FIPS 140-2 approved module.
####################
The use of FIPS 140-2 compliant cryptography must be enabled; select [1]
[1] Use of FIPS enabled
[2] Use of FIPS disabled
Choose one of the options above or press <Enter> to accept the default
value
32. For the gathering interval, press <enter> to accept the default value (One day)
####################
Gathering interval
Specify the time interval that you want to use. The default value is
suitable for most of the IBM Endpoint Manager deployments.
[1] Fifteen minutes
[2] Half an hour
[3] One hour
[4] Eight hours
[5] Half day
[6] One day
[7] Two days
[8] One week
[9] Two weeks
[10] One month
[11] Two months
value
31
33. For the initial action lock, press <enter> to accept the default value (unlocked):
####################
Initial action lock
[1] Locked
[2] Lock duration
[3] Unlocked
value [3]
34. For the action lock controller, press <enter> to accept the default value (Console):
####################
Action lock controller
[1] Console
[2] Client
[3] Nobody
value
35. For lock exemptions, press <enter> to accept the default value (disabled):
####################
Enable lock exemptions
[1] Lock exemption enabled (fairly unusual)
[2] Lock exemption disabled
value
36. For Unicode filenames in archives, press <enter> to accept the default value (enabled):
####################
Enable the use of Unicode filenames in archives
[1] The use of Unicode filenames in archives is enabled.
[2] The use of Unicode filenames in archives is disabled.
value
37. The system will proceed with the installation:
Info: The license masthead was successfully generated.
Info: Creating the database for the server component, please wait ...
Info: The database for the server component was created successfully.
Info: Configuring the database for the server component, please wait ...
32
Info: The database for the server component was configured successfully.
Info: The service 'BESRootServer' started successfully.
Info: The service 'BESFillDB' started successfully.
Info: The service 'BESGatherDB' started successfully.
Info: The service 'BESClient' started successfully.
The installation of 'IBM Endpoint Manager' completed successfully.
38.
Now complete the editing discussed in step 10

- Edit /etc/hosts again and remove db2host (the host name you specified
in step 10) from the line with rhel2
- Add db2host to the line with 127.0.0.1
- Reboot
Installing the IBM BigFix Client

The IBM BigFix client is installed as part of the installation process for the IBM BigFix server.
The IBM Endpoint Manager Server installation is now complete. You can now install the IBM Endpoint
Manager Console on a win7box and log on with the account you created during the above installation.
Installing the IBM BigFix Console on win7box

You can now proceed to install the IBM Endpoint Manager console on win7box
Installing Windows 7 on win7box
Logging in to win7box
Installing the IBM BigFix Console, Logging In and Logging Out
Windows 7 machine .iso clone instructions to install Windows
33
1. Boot the Win7 ISO

2. Install Windows from the ISO
Logging in to win7box
Proceed to log into win7box as administrator
Installing the Console, Logging in and Logging Out

The win7box Windows computer will make a network connection via HTTPS port 52311 to the
Server. Using the IBM Endpoint Manager console you can monitor and fix problems on all
managed computers across the network.
To install the console, follow these steps:
1. Obtain the IBM BigFix Console installer package from the DVDs provided by IBM with
the Common Criteria package. (BigFix-BES-Console-9.2.3.68.exe) and copy this to the
Windows work station to a convenient location such as the desktop.

.
2. Run the installer and follow the instructions displayed on the screen during the install.
3. When you have your credentials, you are ready to operate the console:
i. Start the console by double-clicking its desktop icon or select it from the Programs
menu: Start / Programs / IBM Endpoint Manager / IBM Endpoint Manager Console.
ii. The warning banner will be displayed and by proceeding with login the user agrees to
the conditions therein.
Iii. Log in to the console using one of the following notations for the username:
username
username@domain
domain\user
iv. For further operation details on using the IBM BigFix Console see the "IBM Endpoint
Manager Version 9.2 Console Operators Guide" to cover general usage and navigation in
the Console.
Note: To allow the Console to connect to the IBM Endpoint Manager Server, ensure that the
firewall is configured to allow tcp communications through the Server port (default 52311).
Note: There is no remote login to the Console
Note: To log out go to the tool bar: File->Exit
Update Windows 7 hosts file (if necessary)

34
If the hostname for rhel1 has been changed, then the hosts file on win7box must be changed to reflect
this. Run Notepad as administrator, and open the file C:\Windows\System32\drivers\etc\hosts. Replace
the text "rhel1" with the new hostname for the rhel1 machine. Save the changes
Subscribing to BES Support QA

1. Transfer the supplied BES Support QA.efxm file (masthead) to the filesystem on the Windows machine
running the Console - place in a temporary folder such as C:\windows\temp
2. Launch and login to the Console as a Master Operator
3. Within the Console, select the 'Tools' menu, then click 'Add/Update External Site Masthead...'
4. Browse to the temporary folder where the BES Support QA.efxm file was transferred in step 1 (ex:
C:\windows\temp), select the BES SUpport QA.efxm file, then click Open
5. Click 'Yes' to subscribe to the site
For further information see "Subscribing with a masthead" for external documentation reference:
http://www01.ibm.com/support/knowledgecenter/SS6MCG_9.2.0/com.ibm.tivoli.tem.doc_9.2/Platform/Adm/c_sub
scribing_to_fixlet_sites.html
Manual Policy Gather Step for Air-Gap Networks

Air-Gap: Conceptual Steps
The idea here is that the BigFix system (in this case the TOE and supporting environment) is on a
network that is isolated from external network access. In order to transfer the BigFix content and
licenses (something that happens automatically in environments connected to the Internet),
manual steps must be taken to gather the content and licenses and manually copy them to the
air-gapped installation. So you will need to use a machine that is connected to the Internet (not
a part of the TOE & supporting environment) to carry out the following steps.
1. On a Windows machine connected to the Internet ( call it Win1), download and extract the
Airgap tool available from the Utilities page
(https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/Tivoli
%20Endpoint%20Manager/page/Utilities)
2. On rhel1 (the TOE; Linux BigFix Server), run the Air-Gap script
(/opt/BESServer/bin/airgap.sh). This generates an airgap.tar file on the Linux server.
35
3. On Linux BigFix Server, extract the tar file created and copy the 'AirgapRequest.xml' to Win1 (the
Windows machine connected to the internet) in the same folder as the extracted airgap tool
utility
4. On Win1, run the BESAirgaptool.exe (which will leverage the request xml from the Linux server,
and create an AirgapResponse file, which is just a BigFix archive)
5. Copy the AirgapResponse file from the Windows machine to the Linux Server (where the tar file
was extracted) using a removable device such as a USB key.
6. Run the airgap.sh Air-Gap script on Linux Server to process AirgapResponse
Detailed Instructions
In an air-gapped environment where a secure network is physically isolated from insecure
networks, such as the public Internet or an insecure local area network, and the computers on
opposite sides of the air gap cannot communicate, to download and transfer files to the main
Endpoint Manager server running on a Linux system, you can use the Airgap utility.
This utility can also help download patch contents in a Fixlet site or single file downloads from a
url.
Note: The AirGap utility does not support a configuration where the clients are air-gapped
separately from the main Endpoint Manager server. The clients must be air-gapped together
with the main Endpoint Manager server to be able to gather across the network from the main
Endpoint Manager server.
In addition to the Endpoint Manager server which is being configured on the isolated network,
you need a Windows computer that has access to the public Internet, to download Fixlet site
content using the BESAirgapTool.exe utility. The downloaded site content and files are
transferred to the Endpoint Manager server on the Linux computer.
To run the Airgap utility on Linux servers, you must have a Windows computer with the following
environment:
It must be connected to the Internet to download contents from the Fixlet sites. For additional
information, see the Administration Tool documentation.
The BESAirgapTool.exe tool must be installed. You can download the Windows Endpoint
Manager Airgap utility (BESAirgapTool.exe), from the Utilities page.
The following libraries must be copied to the Windows computer, in the same directory as
BESAirgapTool.exe:
libBEScrypto.dll
libBEScryptoFIPS.dll
In addition, Microsoft C/C++ Runtime Libraries might be needed.
36
You can copy these libraries from the folder where you installed the Endpoint Manager console.
The default folder is %PROGRAM FILES%\Bigfix Enterprise\BES Console.
Perform these steps to run the Airgap utility on the Linux Endpoint Manager server:
1. Ensure that on the Linux computer, the Airgap utility is in the path where you installed
the Endpoint Manager server. The default path is /opt/BESServer/bin.
2. Open the Linux Terminal, and type these commands to create a tar file named
airgap.tar, containing the AirgapRequest.xml based on the information about
the Endpoint Manager database:
# cd /opt/BESServer/bin
# ./Airgap.sh -run
Note: The complete syntax of Airgap.sh is the following:

Airgap { -run | -remotedir directory | -proxy
[user:password@]host[:port] | -help }
where:
-run
Runs Airgap to generate the tar file with the request in the local folder.
-remotedir directory
Runs Airgap to generate the tar file with the request in the specified folder.
-proxy [user:password@]host[:port]
Specifies the proxy information as follows:
Authenticating_proxy:
-proxy user:password@ipaddress:port
Non-authenticating proxy:
-proxy ipaddress:port
-help
Lists the Airgap usage.
On the Linux computer, extract the airgap.tar file with the following command under the
airgap sub-folder::
# tar -xf airgap.tar
3. Copy the file AirgapRequest.xml, created in the airgap folder, to the folder containing
the BESAirgapTool.exe file of the Windows computer.
4. On the Windows computer, run BESAirgapTool.exe to download the data related to the
AirgapRequest.xml request into the AirgapResponse file.
5. Copy the AirgapResponse file, generated by BESAirgapTool.exe, from the Windows
computer to the airgap folder of the Linux workstation.
37
6. On the Linux computer, from the airgap folder, run the Airgap tool to load the data on the
database:
# cd /opt/BESServer/bin
# ./Airgap.sh -run
38
Enhanced Security Configuration and

References
Containing Informational References, How-To Items and Required Actions
Organizational security policies

How to View Remote ryslog Events
Configuring RHEL Audit Events
IBM BigFix Audit Events
Audit Records
Guidance for networking
Hardening IBM BigFix Endpoint Manager
Changing Privileges On Files, Certificates and Keys
How to configure IBM BigFix password policies
Configuring IBM BigFix Session Termination
IBM BigFix Endpoint Manager Warning banner
RHEL Hardening
Disabled Functionality On The TOE
RHEL 6.6 Terminal lockout
RHEL 6.6 Account Settings
How to configure a RHEL warning banner
TLS Ciphersuites
Keys On The TOE
Software Versions
Logging In and Logging Out of the TOE
Reliable Timestamps
Firewall Configuration
Processes that Receive Data from the Network
Power On Self Test
Cryptography Self Tests
Administrator Access to TSF Data Disabling and Re-Enabling root
Hardware Hardening
Upgrade Process
How to Contact Support
Organizational security policies

Role Description
39
The IBM BigFix Site Administrator operator is responsible for installing and maintaining the IBM
Endpoint Manager components, as well as advanced deployment-wide configurations. This role
is used primarily during initial installation and configuration of the TOE.
The IBM BigFix Console Master Operators will be used for all run time operations and
corresponds to the Authorized Administrator described in the NDPP. The security functionality
available to this user are:
Setting passwords and password restriction policies
Configuring lockout settings
Configuring warning banners
The IBM BigFix Site Administrator authenticates with both a password and private key. IBM
BigFix Console Master Operators authenticate via password.
Other roles and operators described in the general IBM BigFix documentation should not be
used in the evaluated configuration.
Access Banner
The TOE displays an initial banner describing restrictions of use, legal agreements, or any other
appropriate information to which users consent by accessing the TOE.
Authentication Verification: The TOE only uses the local RHEL user account and password
mechanism for the RHEL console and that IBM BigFix only uses its local mechanism for the IBM
BigFix console. Remote authentication mechanisms, such as LDAP, are not part of the evaluated
configuration.
How to View Remote rsyslog Events

To view the log information, Log into rhel2 and execute the following command:
# cat /var/log/messages | grep BESRootServer
May 14 22:06:51 localbuild BESRootServer: BES Root Server version
9.2.3.69,
built for RedHat 6 x86_64, starting
May 14 22:09:47 localbuild BESRootServer: user "bigfix" (1):
Successful log in. (Data Connection)
May 14 22:10:03 localbuild BESRootServer: Audit Message -user "bigfix" (1): Console closing. Logging out user.
May 14 22:10:29 localbuild BESRootServer: BES Root Server received stop
request
May 14 22:10:29 localbuild BESRootServer: BES Root Server shutting down
All the messages have the process name identifier, so IBM Endpoint Manager audit events can
be seen using the filter BESRootServer.
40
RHEL Audit Events

Configuring auditd for a Common Criteria
The default auditd configuration is suitable for use in the CC Evaluated environment. The directory
that holds the Audit log files is /var/log/audit/.
Configure auditd to start at boot time using the following command as
the root user:
# chkconfig auditd on
Starting the audit Service

Once auditd is properly configured, start the service to collect Audit information and store it in the log
files. Execute the following command as the root user to start auditd:
# service auditd start
You must configure auditd to start at boot time using the following command as the root user:
# chkconfig auditd on
A number of other actions can be performed on auditd using the service auditd action
command, where action can be one of the following:
stop stops auditd.
restart restarts auditd.
reload or force-reload reloads the configuration of auditd from the
/etc/audit/auditd.conf file.
rotate rotates the log files in the /var/log/audit/ directory.
resume resumes logging of Audit events after it has been previously suspended, for
example, when there is not enough free space on the disk partition that holds the Audit log files.
condrestart or try-restart restarts auditd only if it is already running.
status displays the running status of auditd.
Note that the above list of actions will not work once root has been disabled (see Administrator
Access to TSF Data.
Rules Configuration:
The following commands must be carried out on rhel1 adding the following to
/etc/audit/audit.rules
-a always,exit -F arch=b64 -S adjtimex -S settimeofday -k time-change
41
-a always,exit -F arch=b32 -S adjtimex -S settimeofday -S stime -k time-change

-a always,exit -F arch=b64 -S clock_settime -k time-change
-a always,exit -F arch=b32 -S clock_settime -k time-change
-w /etc/localtime -p wa -k time-change
RHEL Event Records

1A - FIA_UIA_EXT.1:
Fields:
<record type> <msg> <user pid> <uid> <auid> <ses> <subj> <msg> <id> <exe> <hostname> <addr>
<terminal> <res>
Example (initiate):
type=USER_START msg=audit(1444407283.629:1058): user pid=24195 uid=0 auid=501 ses=85
msg='op=PAM:session_open acct="vagrant" exe="/bin/login" hostname=? addr=? terminal=tty1
res=success'
Example (establish):
type=USER_LOGIN msg=audit(1444407283.629:1060): user pid=24195 uid=0 auid=501 ses=85
msg='op=login id=501 exe="/bin/login" hostname=? addr=? terminal=tty1 res=success'
Example (terminate):
type=USER_END msg=audit(1444407283.629:1062): user pid=24195 uid=0 auid=501 ses=85
msg='op=login id=501 exe="/bin/login" hostname=? addr=? terminal=tty1 res=success'
1B - FPT_STM.1:
Fields:
<record type> <msg> <arch> <syscall> <success> <exit> <a0> <a1> <a2> <a3> <items> <ppid> <pid>
<auid> <uid> <gid> <euid> <suid> <fsuid> <egid> <sgid> <fsgid> <tty> <ses> <comm> <exe> <subj> <key>
Example:
type=SYSCALL msg=audit(1442963033.635:7247): arch=c000003e syscall=227 success=yes exit=0 a0=0
a1=7fffb47efd30 a2=0 a3=112e0be826d694b3 items=0 ppid=3078 pid=3278 auid=0 uid=0 gid=0 euid=0
suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1198 comm="date" exe="/bin/date"
subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key="time-change"
1C - FTA_SSL_EXT.1
Fields:
<record type> <msg> <user pid> <uid> <auid> <ses> <subj> <msg> <op> <kind> <fp> <direction>
<spid> <suid> <exe> <hostname> <addr> <terminal> <res>
Example:
42
type=USER_AUTH msg=audit(1446756078.113:736): user pid=13852 uid=501 auid=501 ses=55

msg='op=PAM:unix_chkpwd acct="vagrant" exe="/sbin/unix_chkpwd" hostname=? addr=? terminal=? res=success'
Please see the following link for further reading on RHEL events.
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Security_Guide/appAudit_Reference.html#sec-Audit_Events_Fields
IBM BigFix Audit Events

Audit Event Log Fields
user : the user login name initiating the action being logged
origin : the IP address of the user carrying out the event being logged
version : IBM BigFix software version number
platform : operating system platform for which the IBM BigFix package was built
computerid : ID number within a deployment for an endpoint being acted on in the

event being logged. This ID identifies the endpoint within the IBM BigFix deployment.
number : number of endpoints being acted on in the command being logged
privilege list : list of IBM BigFix privileges being manipulated (changed, added, removed) for the
user in the given command event being logged
role : list of IBM BigFix operator roles being manipulated (modification, user assignment) in the
command event being logged
site name : IBM BigFix application content site name
ldap_group : LDAP group name
ldap_user : LDAP user name
Note: the failure reasons for audit entries corresponding with failed actions
such as connection failure are contained in the syslog log record (see the
Audit Records section below). The diagnostic message from that subsystem
(e.g. OpenSSL) is captured and passed along in the audit record.
SERVICE - Triggered when the service is started or stopped

BES Root Server version <version> built for <platform>, starting
BES Root Server shutting down
BES Root Server received stop request
AUTH - Triggered when a user attempts to log in or unlock the session

43
<user>
<user>
<user>
<user>
<user>
<user>
<user>
<user>
<user>
at
at
at
at
at
at
at
at
at
<origin>:
<origin>:
<origin>:
<origin>:
<origin>:
<origin>:
<origin>:
<origin>:
<origin>:
Too many log in attempts

Session has expired.
Failed log in.
Successful log in.
Displaying Warning Banner
Locking user due to inactivity
User has reauthenticated. Unlocking screen.
Console closing. Logging out user.
Warning Banner Text Cancelled. User has logged out.
NOTIFICATION - Triggered when a refresh notification is sent

Unknown user sent a refresh to 1 computer
Unknown user sent a refresh to all computers
<user> tried to send a refresh to all computers
<user> sent a refresh to <number> computers.
<user> tried to send a refresh to <number> computers without permission
APPROVAL - Triggered when an action approval takes place by an additional

user
"<user>" approved an activity performed by "<user>"
ACTION - Triggered when an operator attempts to create an action

<user> tried to create an action without permission
<user> tried to create an action that shuts down computers as PostAction Behavior without permission
<user> tried to create an action with Action Script Commands that
shutdown computers without permission
<user> tried to create an action that restarts computers as Post-Action
Behavior without permission
<user> tried to create an action with Action Script Commands that
restart computers without permission
<user> tried to create an action that lock or unlock computers without
permission
CERTIFICATE - Triggered for operator actions on computer certificates

Certificate for computer with id <computerid> revoked by <user>
PERMISSION - Triggered when user permissions are modified

<user> was made a reader for custom site "<site name>" by <user>
<user> was removed as a reader from custom site "<site name>" by <user>
<user> was made a writer for custom site "<site name>" by <user>
<user> was removed as a writer from custom site "<site name>" by <user>
<user> privileges updated by <user> from Console. Changed privileges
for the operator are: <privilege list>
<user> was modified by <user> from REST API. Changed privileges for
operator are: <privilege list>
<user> management rights updated by <user>
44
ROLE - Triggered when roles are modified

<role> was created by <user> from Console with the following
privileges: <privilege list>
<role> was created by <user> from REST API with the following
<role> was modified by <user> from REST API. Changed privileges for the
role are: <privilege list>
<role> was modified by <user> from Console. Changed privileges for the
role are: <privilege list>
<role> has been given write privileges on <site name> by <user>
<role> has been given read privileges on <site name> by <user>
<role> has been given ownership privileges on <site name> by <user>
<role> was deleted by <user>
<ldap_group> has been added to <role>
<site name> added to <role> by <user>
<site name> removed from <role> by <user>
<user> has been added to <role> by <user>
<user> added to <role> by <user>
<user> was assigned to <role> by <user>
<user> removed from <role> by <user>
<user> was removed from <role> by <user>
USER - Triggered when a user account is modified.

<user> created by <user> from Console with the following privileges:
<privilege list>
<user> created by <user> from REST API with the following privileges:
<privilege list>
<ldap_user> created based on membership of role(s): <roles>
<ldap_user> created by <user> from Console with the following
<ldap_user> created by <user>
<user> password changed by <user>
<user> changed their own password
<user> was converted to ldap user <ldap_user> by <user>
<user> was removed by <user>
CONNECTION - Triggered when an inbound trusted connection is accepted,

closed or failed
Accepted:
CONNECTION - Accepted connection from <origin>
CONNECTION - Accepted connection from <origin> to REST API
Closed:
CONECTION - Closed connection from <origin>
Failed (syslog message):
CONNECTION - Failed connection from <ipaddress>: <Failure reason>
45
OUTBOUNDCONNECTION - Triggered when an outbound trusted connection is

accepted, closed or failed
Outgoing trusted connection events logged to rsyslog have the formats below
The two outbound trusted connections are to DB2 and rsyslog. These are forwarded
by stunnel, so we have to use the logging events that stunnel sends to rsyslog.
Connection:
<date> <time> <TOE hostname> stunnel: LOG<severity>[<PID>:<thread
number>]: rsyslog connected remote server from <IP address>:<port>
Where LOG<severity> is one of
0 - emerg
1 - alert
2 - crit
3 - error
4 - warning
5 - notice
6 - info
7 - debug
This is syslog convention
Example:
Aug 3 21:25:45 localbuild stunnel: LOG5[2090:140223453169408]: rsyslog
connected remote server from 10.1.1.3:52431
Connection closed:
<date> <time> <TOE hostname> stunnel: LOG5[<PID>:<xxx>]: Connection
closed: <yyy> bytes sent to SSL, <zzz> bytes sent to socket
Example:
Aug 3 21:32:26 localbuild stunnel: LOG5[2090:140223453308672]: Connection
closed: 6717 bytes sent to SSL, 168904 bytes sent to socket
Connection Failure
The IBM BigFix Sver (BESRootServer) will generate only untrusted outbound UDP
messages.
Since all trusted outbound connections are via stunnel, stunnel logs those failures.
<date>time> <TOE Hostname><stunnel: LOG<severity>[<PID>:<thread
number>]: <reason for failure>
46
Examples:
Different errors may be issued by OpenSSL, depending on the timing of the error.
Example 1:
Oct 7 11:48:58 localbuild stunnel: LOG5[1391:140117046093568]: rsyslog
accepted connection from 127.0.0.1:58547
Oct 7 11:48:58 localbuild stunnel: LOG3[1391:140117046093568]:
connect_blocking: getsockopt 10.1.1.4:50001: No route to host (113)
Oct 7 11:48:58 localbuild stunnel: LOG5[1391:140117046093568]: Connection
reset: 0 bytes sent to SSL, 0 bytes sent to socket
Oct 7 11:55:53 localbuild stunnel: LOG3[1391:140117046232832]: SSL_read:
Connection reset by peer (104)
Example 2:
Oct 7 11:48:58 localbuild stunnel: LOG5[1391:140117046093568]: rsyslog
accepted connection from 127.0.0.1:58547
connect_blocking: connect_blocking: s_poll_wait 10.10.10.3:50001: timeout (111)
LOG3 severity corresponds to error. In both rhel1(TOE) and rhel2, stunnel is configured to send
every event LOG5 (notice) and below to rsyslog. So the TOE stunnel will have rsyslog entries for
emerg, alert, crit, error, warning, and notice.
DB2 events will involve an outgoing connection to port 50001, while rsyslog errors will have
outgoing port 61515.
Outgoing trusted connection to DB2 have the format
Connection opened:
<date> <time> <TOE hostname> stunnel: LOG<severity>[<PID>:<thread
number>]: db2 connected remote server from <IP address>:<port>
Where LOG<severity> is one of
0 - emerg
1 - alert
2 - crit
3 - error
4 - warning
5 - notice
6 - info
7 - debug
This is syslog convention
47
Example:
Aug 3 21:31:31 localbuild stunnel: LOG5[2090:140223453308672]: db2 connected
remote server from 10.1.1.3:47910
Connection closed:
<date> <time> <TOE hostname> stunnel: LOG5[<PID>:<xxx>]: Connection
closed: <yyy> bytes sent to SSL, <zzz> bytes sent to socket
Example:
Aug 3 21:32:43 localbuild stunnel: LOG5[2090:140223453308672]: Connection
closed: 3965 bytes sent to SSL, 164365 bytes sent to socket
Connection Failure
The IBM BigFix Sver (BESRootServer) will generate only untrusted outbound UDP
messages.
Since all trusted outbound connections are via stunnel, stunnel logs those failures.
<date>time> <TOE Hostname><stunnel: LOG<severity>[<PID>:<thread
number>]: <reason for failure>
Examples.
Oct 7 11:48:58 localbuild stunnel: LOG5[1391:140117046093568]: db2 accepted
connection from 127.0.0.1:58547
connect_blocking: getsockopt 10.1.1.4:50001: No route to host (113)
Oct 7 11:55:53 localbuild stunnel: LOG3[1391:140117046232832]: SSL_read:
Connection reset by peer (104)
LOG3 severity corresponds to error. In both rhel1(TOE) and rhel2, stunnel is configured to send
every event LOG5 (notice) and below to rsyslog. So the TOE stunnel will have rsyslog entries for
emerg, alert, crit, error, warning, and notice.
DB2 events will involve an outgoing connection to port 50001, while rsyslog errors will have
outgoing port 61515.
48
SYSTEM UPDATE
Version numbers are logged when the server process starts. When the server
process shuts down and restarts with a higher version number is an implicit log of an
upgrade.
A filter script (fixlet) is provided that can be run from the IBM BigFix Console to
display these events.
Additionally, in the CC evaluated system, upgrade fixlets have been modified to use
the logger command (http://linux.die.net/man/1/logger)
<date> <time> <user> at <origin>: System update initiated

<date> <time> <user> at <origin>: System update completed
<date> <time> <user> at <origin>: System update failed
TERMINATION OF REMOTE SESSION

When a user is logged out of the Console due to inactivity, a pair of audit log messages will be
generated. The first one will be of the form:
<date><time><TOE Hostname>: <type><user> at <origin>: Shutting down Console due to
inactivity
Example:
Sep 22 22:24:59 localbuild BESRootServer: Audit Message -- AUTH - user "IEMAdmin" (1) at
10.0.2.2: Shutting down Console due to inactivity
This is followed by the regular logout message:
Sep 22 22:24:59 localbuild BESRootServer: Audit Message -- AUTH - user "IEMAdmin" (1) at
10.0.2.2: Console closing. Logging out user.
49
Audit Records
Audit Records
Audit and rsyslog events are logged as generic rsyslog messages using LOG_USER and LOG_INFO
as the rsyslog flags.
Entries into rsyslog have the following format:
<type> <date> <time> <TOE hostname> BESRootServer[<PID>]: <audit event entry>
Example:
Aug 3 21:25:45 localbuild BESRootServer[14271]: CONNECTION - Accepted connection from
127.0.0.1
<type> : The type of notification. Values can be Informational, warning, critical
<date> : Date of the record entry
<time> : Time the record is logged
<TOE hostname> : Hostname of the computer logging the entry
BESRootServer : The component issuing the event is always the BESRootServer. This is one of the
processes that make up the IBM BigFix Server.
<PID> : Process ID of the BESRootServer
<audit event entry> : Audit event log message (see Audit Events).
-Note: NDPP does not specify which types we are required to use. So we define all of our audit
events to be of the type "notice", and we omit the type field in the log entry since there are no
different audit events types to distinguish.
Audit Logging Behavior Under TLS Failure

-Note: Audit log records generated during downtime of TLS connection to the audit server are
not resent to the audit server.
Audit records are not sent to the remote syslog server when the network connection is broken
and will not be resent when the connection is restored.
There is no buffering that occurs. Records are sent via syslogs immediately when a given event
occurs so only those records generated during loss of TLS connection will not be resent.
-Note: The audit records during TLS downtime do exist in the local log files on the TOE platform
but are not reflected in log of remote audit log server. If the administrator wishes to archive
these records they may be accessed there.
50
rsyslog delivers the message through a TCP connection connected to a local port managed by
stunnel. rsyslog attempts to keep a permanent connection to this TCP local port. This port is
managed by stunnel. When stunnel receives a new connection in the local port in the TOE from
rsyslog, it establishes a permanent connection to the remote system to set up the encrypted
tunnel.
When the system determines the TCP connection managed by stunnel between the TOE and the
remote syslog server has failed, the stunnel connection will be closed and stunnel will send a TCP
reset to the rsyslog connection, which will cause rsyslog to close this connection too. If there was
a syslog message in-flight when the connection failed either between rsyslog and stunnel or in
the encrypted tunnel connection, the message will not be written to the remote syslog, just to
the local syslog.
The local port managed by stunnel will remain open. The next time rsyslog receives a message,
since the TCP connection was lost, rsyslog will try to create a new TCP connection to the local
stunnel port. When stunnel receives this connection attempt, it will try to create a new tunnel
connection. If this succeeds the message will be sent correctly to the remote server and the
permanent TCP connections will remain in place for successive messages. If it doesn't succeed
because the network problem is not yet resolved, the message would be just written to the local
syslog in the TOE.
This means that the audit records during the connection downtime do exist in the local log files
on the TOE platform, but they are not in the log of the remote audit log server. So if the
administrator wishes to archive these records, they can be accessed in the audit logs of the local
server.
We recommend that when there is a connection loss to the remote audit server that the
administrator examine the local logs on the TOE for audit records to see if any events occurred
during the connection loss. As part of best practices, the administrator should manually copy the
segment of the local log file representing the connection downtime to the audit server machine
and name it in a meaningful way in support of any future audit tracing that might arise.
Guidance for networking

stunnel relies on TLS X509 certificates for authentication, and so will automatically recover in the
case of an unintentionally broken network connection as long as the certificate/private key pairs
have not become corrupted. Since the BES root server will automatically recover the DB2
connection, and rsyslogd will automatically recover its connection, nothing manual needs to be
done in the case of an unintentional network disconnect/reconnect.
The IBM BigFix Server will automatically recover the database connection and log error
messages to the log file.
51
Hardening IBM BigFix Endpoint Manager
In order to disable certain open HTTP functionality you will need to make come client settings to
disable the diagnostics interface (it can be enabled as needed for trouble shooting) and make
the server and authenticating server. This will prevent remote access to any of the web
interfaces (admin or otherwise) without authentication, and for local access to the same
web interfaces, it will require authentication as well as HTTPS.
Please refer to the following link on how to configure client settings:

https://www.ibm.com/developerworks/community/wikis/home?lang=en#/wiki/Tivoli
Endpoint Manager/page/Configuration Settings#TEMClient
(1)
_BESRelay_Diagnostics_Enable = 0
Default: 1
Requires Restart: Yes
Change the _BESRelay_Diagnostics_Enable entry from 1 to 0.
(2) Set the following to 1.

_BESRelay_Comm_Authenticating = 1
Changing Privileges On Files, Certificates and Public Keys

Be sure to run chmod a-r on all certificates and public keys created during installation so no
user can read them after root user is disabled.
chmod a-r /etc/pki/tls/certs/*.crt
Also make the following file readable by users
chmod a+r /var/log/messages
How to configure IBM BigFix password policies:

52
Please refer to the following link for setting password policies:

https://www.ibm.com/developerworks/community/wikis/home?
lang=en#!/wiki/Tivoli+Endpoint+Manager/page/Console+User+Password+Policies
Note; in the below specifications [[:punct:]] denotes [-!"#$%&'()*+,./:;<=>?
@[\\\]^_`{|}~]as per standard perl documentation. This list constitutes the allowed non-alphanumeric characters in passwords.
How to configure IBM BigFix password policies
* Password complexity:
Login as the administrative user of the system and run the following commands:
# /opt/BESServer/bin/BesAdmin.sh -setadvancedoptions -sitePvkLocation=/path/to/license.pvk -update
"passwordComplexityRegex=(?=.*[[:lower:]])(?=.*[[:digit:]])(?=.*[[:upper:]])(?=.*[[:punct:]]).{15,}"
"passwordComplexityDescription=15 or more characters with any combination of upper and lower case,
numbers and special characters"
* Session lock timeout in seconds:
"loginTimeoutSeconds=n"
Where n is the number of seconds before the session automatically locks out.
Note that the BES Admin Tool password is dependent on the private key password (license.pvk
password). If the appropriate password policies were not specified at install you will need to manually
change the password to comply with password policies with the following command:
# /opt/BESServer/bin/BesAdmin.sh -changeprivatekeypassword -sitePvkLocation=/path/to/license.pvk
Configuring IBM BigFix session termination:

The Console will close itself after an adminstrator-specified time interval. This time interval is set by the
BESAdmin advanced option timeoutLogoutMinutes by issuing the command:
'./BESAdmin.sh -setadvancedoptions
-sitePvkLocation=/path/to/license.pvk -update
"timeoutLogoutMinutes=n"'
from the directory /opt/BESServer/bin on the TOE/rhel1. This option is analogous to the
"timeoutLockMinutes" advanced options used to set the Console lock time.
Note: There is no maximum value allowed other than the maximum unsigned int for RHEL Linux. A larger
value will be truncated. Non positive integer values are disallowed on input. However, in practice
consult the security rules for your company and set the time out accordingly.
53
IBM BigFix Endpoint Manager Warning banner

Please refer to the following link in configuring a warning banner. That will display after user
login.
http://www01.ibm.com/support/knowledgecenter/SS63NW_9.2.0/com.ibm.tem.doc_9.2/Platform/Adm/c_r
unning_the_tivoli_endpoint_ma_onlinux.html
To configure a login banner issues the following commands from the command prompt on rhel1
./BESAdmin.sh -setadvancedoptions -sitePvkLocation=<path+license.pvk>
[-sitePvkPassword=<password>]
{ -list | -display
| [ -f ] -delete option_name
| [ -f ] -update option_name=option_value }
For example:
./BESAdmin.sh -setadvancedoptions
-sitePvkLocation=/root/backup/license.pvk
-sitePvkPassword=mypa55w0rd -update loginWarningBanner='new message'
Important: In order to display a console warning banner prior to user
login please log into the IBM BigFix Console (see Installing and
Logging In to the IBM BigFix Console) after setting or changing the
text in order to initialize the pre-login warning banner.
RHEL Hardening And Configuration

SetUID Root
You must set certain utilities to be executed as root:
chmod
chmod
chmod
chmod
4755
4755
4755
4755
/bin/date
/sbin/shutdown
/sbin/halt
/sbin/reboot
Allow Use of USB Stick

Add a line in /etc/fstab so a regular user can mount USB stick:
/dev/sda
/mnt
vfat
users 0
Disabled Functionality on the TOE

54
Note that FTP is not pre-installed on rhel1 and should not be installed later
SSH has been removed on rhel1 and should not be installed.
BigFix WebReports is disabled on rhel1 and should remain so.
IBM Feature on Demand functionality is not activated and should not be activated
RHEL 6.6 Terminal lockout

The screen application is used to provide a locking mechanism of the current terminal for
every user. The screen locking is invoked by the following means:
The locking is executed automatically after a period of inactivity on the terminal defined by a
timeout in either /etc/screenrc or ~/.screenrc using the lockscreen configuration value.
Every user can lock his/her screen by executing the C-a C-x screen key binding combination.
You MAY change the timeout value for locking the session in /etc/screenrc with the value for
lockscreen.
Please note that users can modify the timeout by providing their own ~/.screenrc. You can
disable the support for per-user configuration files by invoking screen with the option of
-c /dev/null.
To invoke screen automatically upon log in, you MAY enter the following line to either
/etc/bash_profile for system-wide enforcement or ~/.bash_profile for a per-user
enforcement. Note that a user can change ~/.bash_profile.
exec screen
Sytem-wide configuration changes require root access.
Detailed Settings for Terminal Lockout:
When the user is logged in as an administrator, an unattended login session may pose a
significant security risk. To reduce this risk, you can configure the system to
automatically log out idle users after a fixed period of time:
As root, add the following line at the beginning of the /etc/profile file to make sure the
processing of this file cannot be interrupted:
trap "" 1 2 3 15
Add the following lines at the end of the /etc/profile file to start a screen session each
time a user logs in to a virtual console or remotely:
SCREENEXEC="screen"
55
if [ -w $(tty) ]; then
trap "exec $SCREENEXEC" 1 2 3 15
echo -n 'Starting session in 10 seconds'
sleep 10
exec $SCREENEXEC
fi
Note that each time a new session starts, a message will be displayed and the user will
have to wait ten seconds. To adjust the time to wait before starting a session, change the
value after the sleep command.
Add the following lines to the /etc/screenrc configuration file to lock the session after a
given period of inactivity:
This will set the time limit to 120 seconds. To adjust this limit, change the value after the
idle directive.
idle 120 lockscreen
autodetach off
This way, a password will be required to unlock the session.
The changes take effect the next time a user logs in to the system.
RHEL 6.6 Account Settings

The allowable RHEL password characters consist of the 95 printable ASCII characters. The official
Red Hat guidance for creating and configuring RHEL 6.6 user accounts can be found in the RHEL 6
Deployment Guide: https://access.redhat.com/documentation/enUS/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/index.html
Specifically, sections 3.4, and 3.5 cover user and group management using command line tools.
The password for the RHEL 6.6 console login can be any secure combination of the following list
of characters
'0123456789abcdefghIjklmnopqrstuvwxyzABCDEFGHIJKLMNOPQ
R S T U V W X Y Z ! # $ % & \ ( ) * + , - . / : ; ? @ [ ] ^ _ ` { } | = < > ~ and the space characer
Usage of any other characters fall outside the scope of the CC evaluated configuration.
In order to configure the default minimum password length of 15 characters or greater please
carry out these steps:
(i) Use the text editor vim (prior to disabling root) to edit the file
/etc/pam.d/system-auth
56
(ii) Locate the line containing "cracklib", it currently looks like this (all on a single line):
password requisite
retry=3 type=
pam_cracklib.so
try_first_pass
(iii) Add the following parameters to the end of the line

minlen=15 ucredit=0 dcredit=0 lcredit=0 ocredit=0
This yields the following line (Note the display is wrapped. This is a single line with two
spaces after type=) :
password requisite pam_cracklib.so try_first_pass retry=3 type=
minlen=15 ucredit=0 dcredit=0 lcredit=0 ocredit=0
Note that the option minlen= is set to 15 in our example which yields the desired
minimum password length of 15. A number greater than 15 is acceptable, depending on
the customer's password security requirements (for example minlen=19) . However,
changing the setting to less than 15 falls outside the scope of the evaluated
configuration.
In addition to enforcing minimum password length, RHEL 6.6 login passwords are also enforced
to have a minimum complexity so that passwords that meet minimum the length requirements
but are too simple to be secure are rejected when users change passwords.
How to configure a RHEL warning banner (rhel1)

RHEL warning banner instructions
The warning banner displayed at the RHEL console login can be modified to meet customer
needs by editing the file /etc/issue by using the vim text editor. Modifying this file requires root
permissions.
Use vi commands to edit file and replace with your banner text. Enter ESC:x! when finished to
save file.
vi /etc/issue
ssh has been disabled so there is no need to add it to the sshd_config file.
TLS Ciphersuites
57
The IBM Endpoint manager provided on the CC Evaluated ISO image DVDs has been preconfigured to support TLS 1.0 or greater. TLS 1.2 is used for communication from the TOE to the
Console (1.0/1.1/1.2 is allowable). TLS 1.0 is used over stunnel to syslogs and DB2.
There are no steps to enable Enhanced Security mode to meet the requirements for TLS versions
and cipher suites. The CC Evaluated IBM BigFix package has been built to disable some cipher
suites that aren't allowed by the NDPP/Security Target.
The following cipher suites are allowed by the BES root server:
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS v1.0, v1.1 and v1.2 are allowed. No configuration is required to enable these cipher suites
and protocols. None of the cipher suites can be disabled.
The stunnel uses TLS v1.0 to securely forward DB2 and rsyslog connections between rhel1 and
rhel2, and uses the following cipher suites:
No configuration is required for stunnel to use these cipher suites.
Keys On the TOE

There are several signature keys/certificates on the TOE:
The server signing key is in /var/opt/BESServer/ServerSigningKey and is generated at install time
and can be rotated using besadmin and the site level credentials.
The ClientCAKey is used to generate certificates/keys on each client to support mailboxing, and
client authentication. It is and is generated at install time and can be rotated using besadmin and
the site level credentials: /var/opt/BESServer/ ClientCAKey
The license.crt and license.pvk (site credentials) are generated during server install and placed in
a specified folder (step 22 in the install process).
ClientKey.pvk is generated at install (/var/opt/BESClient/KeyStorage/__ClientKey.pvk) and is used
for client authentication and report encryption.
Software Versions
58
IBM Endpoint Manager

The version of the IBM Enpoint Manager server that is installed on rhel1 can be determined by
issuing from the RHEL console the command
rpm -q --queryformat '%{VERSION}\n' BESRootServer
The version of the IBM Endpoint Manager agent that is installed on rhel1 can be determined by
rpm -q --queryformat '%{VERSION}\n' BESAgent
RHEL
The version of Red Hat Enterprise Linux server that is installed on rhel1 can be determined by
rpm -q --queryformat '%{RELEASE}\n' redhat-release-server
The version of the Linux kernel installed through the official Redhat mechanism can be
determined by issuing from the RHEL console the command
rpm -q --queryformat '%{VERSION}-%{RELEASE}.%{ARCH}\n' kernel
To determine if this is the version of the kernel that is actually running, form the RHEL console
issue the command
uname -r
The kernel version from uname should match the kernel version from rpm.
Logging Into and Out of the TOE (rhel1)
59
Logging into the TOE RHEL machine is done via the physical console connected to that machine.
The warning banner is displayed and by proceeding with login the user agrees to the conditions
therein.
After completion of the Common Criteria set-up steps contained in this guide, the root login will
be disabled, so the administrator must create another user account during installation in order
to log in.
To log out, issue the command logout at the command line.
Note: remote login is disabled on the TOE.
Reliable time-stamps
The RHEL operating system maintains the system time that is used for all time-stamps issued,
including such sensitive events as audit record generation, certificate validation, session locking,
and timeouts for remote sessions. As such, changing the system time requires root access.
Official Red Hat guidance on how to change the RHEL 6 operating system time can be found in
Section 2.2 of the RHEL 6 Deployment Guide: https://access.redhat.com/documentation/enUS/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/index.html
Firewall configuration
Note that port number 52311 (the default) must be accepted during installation to correspond to the
pre-configured firewall settings.
And be aware that the firewall on the rhel1 is pre-configured to block all ICMP packets.
After installation of the Clonezilla image on rhel1, the firewall will be on and configured to have only the
following ports open on the external network interfaces:
TCP Port 52311
UDP Port 52311 outbound only
TCP port 50001
TCP port 61515
Changing the firewall settings falls outside the scope of the Common Criteria evaluated configuration.
There will be additional ports open for DB2 and rsyslog on the internal loopback device to allow stunnel
to securely forward those connections to rhel2 using TLS.
Processes that receive data from the network

The firewall will only allow the following processes to process data received over an external
facing network interface: BESRootServer, and stunnel.
BESRootServer runs at hardware privilege level ring 3, and RHEL system privilege level root. This
is main process providing the central server functionality for the IBM Endpoint Manager. This
process accepts inbound connections on port 52311.
60
stunnel runs at hardware privilege level ring 3 , and at a low user RHEL system privilege level
through the account 'nobody'.It provides secure forwarding of DB2 and rsyslog connections
using TLS to the rhel2 machine. This process only has outbound connections, on port 50001 to
forward the DB2 connection, and on port 61515 to forward the rsyslog connection.
Power on self-test
The TOE, specifically the RHEL OpenSSL package, performs a series of power-up self-tests when invoked.
First, the TOE performs an integrity test on the cryptographic module using HMAC-SHA-256. If the integrity
test passes, then the TOE performs a set of Known Answer Tests (KATs) on individual algorithms. If the KAT
tests pass, then the cryptographic module enters FIPS mode. The following cryptographic algorithms are
tested during the KAT tests: AES, RSA, HMAC-SHA1, HMAC-SHA-224, HMAC-SHA-256, HMAC-SHA-384,
HMAC-SHA-512, SHA-1, SHA-224, SHA-256, SHA-384, SHA-512 and CTR_DRBG.
The IBM BigFix Server additionally calls FIPS_mode_set() upon start up, which in turn calls
FIPS_self_test(). If this test fails an error message is displayed (Cryptographic module failed to
initialize required FIPS mode: FIPS selftest failed ) and openSSL fails to load. The sever will then
throw an exception and will exit. The following message is written to the log : "Failed FIPS setup!
Exiting"
Cryptography self-tests
The RHEL operating system, stunnel, and the BES server all use the same shared OpenSSL 1.0.1ebased library provided by the RHEL operating system, and all components are operating with
OpenSSL cryptography in FIPS mode. In FIPS mode, the OpenSSL library performs a series power
on self-tests to ensure the reliable operation of cryptography algorithms. The RHEL operating
system performs the self-test at boot time, while stunnel and the BES server components
perform the self-test as part of process initialization anytime the executable are run. If any of the
cryptography self-tests fail, the following will happen:
RHEL Operating System/Open SSL

Self test failure results for the OpenSSL module vary depending on which test failed. The powerup self test (algorithm-specific Pairwise Consistency and Known Answer Tests) is performed.
Non-fatal errors result in transition to one of the following error states. To recover, the
application must be restarted.
FIPS_R_FINGERPRINT_DOES_NOT_MATCH
- Failure of integrity verification check
FIPS_R_FIPS_SELFTEST_FAILED
- Failure of a known answer test
FIPS_R_FIPS_MODE_ALREADY_SET
- Application tried to initialize FIPS mode though already initialized
61
RAND_R_PRNG_STUCK
-two matching 128 bit values were consecutively generated by the random number
generator.
The above errors are flagged through the normal ERR interface of the OpenSSL library. For
details please see the OpenSSL manual page.
Fatal Errors: These occur if the crypto module is in an error state due to having failed a self test
and a crypto function form the module is called by the application that cannot return an error
message (void return value) . The error message: 'FATAL FIPS SELFTEST FAILURE' is sent to stderr
and the application is terminated via the abort() call.
Recovery: application must be restarted. If failures reoccurs, the module must be reinstalled.
In downloading the software, remember to verify the package hash to ensure the correct
download. If the problem persists, contact IBM Technical Support.
Stunnel
The self-tests are done when the executable is launched as a part of process initialization. If the
self-tests fail, stunnel will terminate itself and not allow forwarding of DB2 or rsyslog
connections outside the TOE. The stunnel logs will state that it could not enter FIPS mode and
contain further information on why the self-tests failed.
Recovery: To recover from this error, check error logs and consult the Stunnel documentation.
Verify that the correct version of Open SSL is installed. If the problem persists, contact IBM
Technical Support.
IBM Endpoint Manager components

The self-tests are done when each executable is launched as a part of process initialization. If the
self-tests fail for a particular component, that component will terminate itself, logging an error
message that it was unable to enter FIPS mode. The specific error message that will be logged is
class BES_FIPS_mode_set_Failed:
Where the ellipses () indicate that error strings from OpenSSL itself will follow, further
detailing the specific reason for the failure of the self-tests.
Administrator Access to TSF-data

The RHEL root account login must be disabled on rhel1 in multi-user mode to protect TSF-data.
Disabling the root account prevents unauthorized access of the private keys stored on the
machine. If an administrator needs authorized access to the private keys, the machine must be
taken offline and rebooted in single user mode. Disabling root also prevents unauthorized
changes to the TOE firewall settings.
62
Only root can read the three main BES private keys locate at:
/var/opt/BESClient/KeyStorage/__ClientKey.pvk, /var/opt/BESServer/ClientCAKey, and
/var/opt/BESServer/ServerSigningKey
Prior to Disabling Root

Be sure to wait until you are completely finished with install and configuration to disable root
because once that is done commands requiring root privileges won't run.
Note: For later steps in carrying out upgrades you will need to create a user account on the TOE
to enable file transfer. To allow this account carry out the necessary file transfer during upgrade,
execute the following chmod command on the downloa file cache.
> chmod 755 /var/opt/BESServer/wwwrootbes/bfmirror/downloads/sha1
Run the following so a regular user can create and untar airgap.tar to perform an update.
>chmod +w /opt/BESServer/bin
After root is disabled the following actions will require renabling root.
Configuring warning and consent banners
Configuring session lock and termination timeouts
Trusted update
Changing password policies
Disabling root Account

The final step configuration step for Common Criteria is to disable the root account on the rhel 1
machine. This should be done ONLY AFTER the rhel1 machine is in the desired state with
Common Criteria guidelines. To disable root, as root enter the command
passwd -l root
You will not be able to login as root again.
To re-enable the root account, the machine must be taken offline and booted into single user
mode from the GRUB boot screen. In single-user mode, use the vim editor to edit the file
/etc/shadow. From the line that begins with root:!! delete both exclamation points. This will
re-enable the root login in multi-user mode.
Using rhel1 in multi-user mode with root account enabled falls outside the scope of a CC
evaluated system.
63
Re-enabling root Account

Offical Red Hat guidance on how to boot RHEL 6.6 into single-user mode can be found in Section
31.2 of the Deployment Guide: https://access.redhat.com/documentation/enUS/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide
Note: For later steps in carrying out upgrades you will need to enable root to carry out the file
transfers and run the upgrade steps.
To accomplish this the TOE will need to be taken offline, and booted into single user mode.
i.
Have the trusted admin with physical access to the machine take the TOE offline and
boot into single-user mode from the local RHEL console.
When the TOE begins its boot process, a screen showing the Linux kernel name will
appear with a message saying it will boot in a few seconds.When you see this
screen, hit the ESCAPE to interrupt the boot sequence.The GRUB boot loader screen
will be presented, allowing you to modify the boot process. Type a to append to
the current boot command. Then type single to append the word single to the
end of the boot command. Then hit RETURN. The system will boot into single-user
mode. Then reactivate (unlock) the root account and exit single-user mode.
# passwd u root
# exit
When you exit single-user mode, the machine will reboot normally with
the root account enabled.
ii. In single user mode, re-enable the root account

iii. Reboot the TOE.
iv. The trusted admin with root login access and physical machine access runs the airgap
upgrade steps from the local RHEL console.
v.
Disable the root account.
vi. Reboot the machine into multi-user mode.
Hardware Hardening
64
Assumptions
The TOE is assumed to exist in a locked, secure data center with physical access limited to
authorized personnel.
The TOE (rhel1) is connected to win7box and rhel2 on a closed or air-gap network that has no
physical or virtual connection to any outside network.
No further hardening of the hardware is required.
Upgrade process
The upgrade process for the CC-Evaluated IBM Endpoint Manager follows the normal upgrade
process for upgrades in air-gap networks. Please refer back to the section Manual Policy Gather
Step fpr Air-Gap Networks to review the process for manual gather. Upgrade actions are
implemented as policies to be gathered in the IBM BigFix environment.
After performing the manual step to gather new content using the airgap tool from the IBM
Corporate fixlet hosting site, an upgrade fixlet will appear in the IBM BigFix Console in the
BESSupport QA site which can be launched by an Administrator user to perform the in-place
upgrade.
The following link describes the generic upgrade process. From the air gap perspective, the only
difference is in copying the installation image/package to the TOE .
http://support.bigfix.com/index/Upgrading.html
The general process for downloading files and patches for the Air-Gap scenario is described at
this link. The rest of this section describes the upgrading process for the TOE specifically.
http://www01.ibm.com/support/knowledgecenter/SS6MER_9.2.0/com.ibm.tivoli.tem.doc_9.2/Platform/
Config/c_airgap_tool_overview.html?lang=en
Note that all fixlets are digitally signed with RSA 2048 and SHA1 which provides protection when
downloading the fixlet and when uploading to the TOE. The existing certificate present in the
IBM BigFix installation will be used to validate the signature on the upgrade fixlet used during
upgrade, this license file is named license.crt.
Note: It is advisable to make a DB2 database backup prior to carrying out the upgrade. If there is
an error during this process, the database can be restored to reset the state to the known good
one. Please see DB2 documentation for more detail on taking database backups. See the note
below for steps to take in case of failure.
65
As the TOE is in an air-gapped network, it is necessary to use the BigFix standard manual process
for caching the payload (the binaries constituting the upgrade) in air-gap network environments.
In order to modify the protected files, root will be re-enabled prior to the upgrade steps.
Re-Enabling Root Access:
There are various files and directories encountered during upgrade process that require root
privileges to modify. Prior to carrying out the upgrade process, the trusted administrator with
physical access to the TOE must temporarily enable root.
Follow the instructions in this section to re-enable root to allow updating protected files:
Re-Enabling Root
After root is re-enabled, proceed with the upgrade steps below.
Upgrade Steps
Caching the Files for later use by the Upgrade Fixlet
Prior to running the upgrade fixlet, the binaries must be cached on the server (TOE). Caching
files on the IEM Server is a simple process:
i. Obtain the file you wish to cache on the BES Server *
ii. Calculate the sha1 checksum of the file.**
iii. Rename the file to its sha1 checksum value. (Remove file extension if it exists)
iv. Place the renamed file in the IEM Server download cache folder.***
Once the file is cached on the IEM Server, any action deployed that checks for the same sha1 will
use the file in the cache instead of downloading it from the Internet.
For more details on how the IEM Server/Relay caches work, see: http://www01.ibm.com/support/docview.wss?uid=swg21505905
*In this case the file to be cached is the new binary/binaries to upgrade the IBM BigFix software
on the TOE. The binary will be accessible via hashed link, which will be sent to you via signed
email. The public key for validating the email signature will be provided to you by your IBM
Federal Sales representative.
**You can calculate the sha1 checksum of a file by using the sha1.exe tool available
here: https://www.ibm.com/developerworks/mydeveloperworks/wikis/home?
lang=en#/wiki/Tivoli%20Endpoint%20Manager/page/SHA1%20Tool
*** the Server download cache directory on a Linux system is located at
/var/opt/BESServer/wwwrootbes/bfmirror/downloads/sha1
66
Recall that this directory is writable only by root and root has been re-enabled/
Assuming the binary file had been previously copied to /tmp:
cp /tmp/serverinstaller.tgz /var/opt/BESServer/wwwrootbes/bfmirror/downloads/sha1/<sha1>
Once the binary has been manually cached and previously the fixlet has been transferred to the
server (the air-gap gather step) you then proceed to the Console, navigate to the BES Support
QA site and run the upgrade fixlet (example: for a given patch 200, you would run the fixlet
titled IBM Endpoint Manager - Updated Platform Server Components version 9.2.3.200 Now
Available).
For further operation details on using the IBM BigFix Console see the "IBM Endpoint Manager
Version 9.2 Console Operators Guide" to cover general usage and navigation in the Console.
If the upgrade completed successfully, a message is displayed 'Upgrade successful' and the
product version number will be changed (normally to a higher number).
Once the upgrade is finished, disable root by following the instructions here:
Set Root back To Disabled
Failure During the Upgrade Process
If the upgrade did not complete successfully an error message will be displayed, with an error
number (such as 'error 94').
If the upgrade process fails, restore the DB2 database on rhel2. If all cables are in place and the
IBM BigFix processes are running, contact technical support.
In addition to being displayed, the error message will be saved in the error log file please see the
following information on which logs to check (http://www01.ibm.com/support/knowledgecenter/SS6MER_9.2.0/com.ibm.tivoli.tem.doc_9.2/Platform/Adm/c
_upgrade_the_tem_server_linux.html).
Appendix A. Support information

Appendix B. Process List
The operational guidance shall at a minimum list the processes running (or that could run) on
the TOE in its evaluated configuration during its operation that are capable of processing data
received on the network interfaces (there are likely more than one of these, and this is not
limited to the process that "listens" on the network interface)
Searching knowledge bases
Searching the documentation
Search the information center on your local system or network
Contacting IBM Software Support
67
Support
For support with your IBM BigFix Common Criteria deployment, please contact your federal Sales
representative to arrange for a technician to contact you. For general information on IBM Federal Sales,
please see:
IBM Federal Sales
For more general information about this product, see the following resources:
IBM BigFix Support site
Notices
This information was developed for products and services offered in the U.S.A.
IBM may not offer the products, services, or features discussed in this document in other countries.
Consult your local IBM representative for information on the products and services currently available in
your area. Any reference to an IBM product, program, or service is not intended to state or imply that
only that IBM product, program, or service may be used. Any functionally equivalent product, program,
or service that does not infringe any IBM intellectual property right may be used instead. However, it is
the user's responsibility to evaluate and verify the operation of any non-IBM product, program, or
service.
IBM may have patents or pending patent applications covering subject matter described in this
document. The furnishing of this document does not grant you any license to these patents. You can
send license inquiries, in writing, to:
IBM Director of Licensing
IBM Corporation
North Castle Drive
Armonk, NY 10504-1785
U.S.A.
For license inquiries regarding double-byte character set (DBCS) information, contact the IBM Intellectual
Property Department in your country or send inquiries, in writing, to:
Intellectual Property Licensing
Legal and Intellectual Property Law
IBM Japan Ltd.
19-21, Nihonbashi-Hakozakicho, Chuo-ku
Tokyo 103-8510, Japan
The following paragraph does not apply to the United Kingdom or any other country where such
provisions are inconsistent with local law:
68
INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS PUBLICATION "AS IS" WITHOUT
WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Some states do not allow disclaimer of express or implied warranties in certain transactions, therefore,
this statement may not apply to you.
This information could include technical inaccuracies or typographical errors. Changes are periodically
made to the information herein; these changes will be incorporated in new editions of the publication.
IBM may make improvements and/or changes in the product(s) and/or the program(s) described in this
publication at any time without notice.
Any references in this information to non-IBM Web sites are provided for convenience only and do not in
any manner serve as an endorsement of those Web sites. The materials at those Web sites are not part
of the materials for this IBM product and use of those Web sites is at your own risk.
IBM may use or distribute any of the information you supply in any way it believes appropriate without
incurring any obligation to you.
Licensees of this program who wish to have information about it for the purpose of enabling: (i) the
exchange of information between independently created programs and other programs (including this
one) and (ii) the mutual use of the information which has been exchanged, should contact:
IBM Corporation
2Z4A/101
11400 Burnet Road
Austin, TX 78758 U.S.A.
Such information may be available, subject to appropriate terms and conditions, including in some cases,
payment of a fee.
The licensed program described in this document and all licensed material available for it are provided
by IBM under terms of the IBM Customer Agreement, IBM International Program License Agreement or
any equivalent agreement between us.
Any performance data contained herein was determined in a controlled environment. Therefore, the
results obtained in other operating environments may vary significantly. Some measurements may have
been made on development-level systems and there is no guarantee that these measurements will be
the same on generally available systems. Furthermore, some measurements may have been estimated
through extrapolation. Actual results may vary. Users of this document should verify the applicable data
for their specific environment.
Information concerning non-IBM products was obtained from the suppliers of those products, their
published announcements or other publicly available sources. IBM has not tested those products and
cannot confirm the accuracy of performance, compatibility or any other claims related to non-IBM
products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of
those products.
69
All statements regarding IBM's future direction or intent are subject to change or withdrawal without
notice, and represent goals and objectives only.
All IBM prices shown are IBM's suggested retail prices, are current and are subject to change without
notice. Dealer prices may vary.
This information is for planning purposes only. The information herein is subject to change before the
products described become available.
This information contains examples of data and reports used in daily business operations. To illustrate
them as completely as possible, the examples include the names of individuals, companies, brands, and
products. All of these names are fictitious and any similarity to the names and addresses used by an
actual business enterprise is entirely coincidental.
COPYRIGHT LICENSE:
This information contains sample application programs in source language, which illustrate programming
techniques on various operating platforms. You may copy, modify, and distribute these sample programs
in any form without payment to IBM, for the purposes of developing, using, marketing or distributing
application programs conforming to the application programming interface for the operating platform
for which the sample programs are written. These examples have not been thoroughly tested under all
conditions. IBM, therefore, cannot guarantee or imply reliability, serviceability, or function of these
programs. The sample programs are provided "AS IS", without warranty of any kind. IBM shall not be
liable for any damages arising out of your use of the sample programs.
If you are viewing this information softcopy, the photographs and color illustrations may not appear.
Trademarks
IBM, the IBM logo, and ibm.com are trademarks or registered trademarks of International Business
Machines Corp., registered in many jurisdictions worldwide. Other product and service names might be
trademarks of IBM or other companies. A current list of IBM trademarks is available on the "Web at
Copyright and trademark information" at www.ibm.com/legal/copytrade.shtml.
Adobe, Acrobat, PostScript and all Adobe-based trademarks are either registered trademarks or
trademarks of Adobe Systems Incorporated in the United States, other countries, or both.
IT Infrastructure Library is a registered trademark of the Central Computer and Telecommunications
Agency which is now part of the Office of Government Commerce.
Intel, Intel logo, Intel Inside, Intel Inside logo, Intel Centrino, Intel Centrino logo, Celeron, Intel Xeon, Intel
SpeedStep, Itanium, and Pentium are trademarks or registered trademarks of Intel Corporation or its
subsidiaries in the United States and other countries.
Linux is a trademark of Linus Torvalds in the United States, other countries, or both.
Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in
the United States, other countries, or both.
ITIL is a registered trademark, and a registered community trademark of the Office of Government
Commerce, and is registered in the U.S. Patent and Trademark Office.
70
UNIX is a registered trademark of The Open Group in the United States and other countries.
Java and all Java-based trademarks and logos are trademarks or registered trademarks of Oracle and/or
its affiliates.
Cell Broadband Engine is a trademark of Sony Computer Entertainment, Inc. in the United States, other
countries, or both and is used under license therefrom.
Linear Tape-Open, LTO, the LTO Logo, Ultrium, and the Ultrium logo are trademarks of HP, IBM Corp. and
Quantum in the U.S. and other countries.
71

ST Vid10682-Agd PDF

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

ST Vid10682-Agd PDF

Încărcat de

Drepturi de autor:

Formate disponibile

IBM BigFix 9.

Common Criteria Guide V1.9

Create RAID 0 virtual drive.................................................................................................................21

Guidance for networking.......................................................................................................................51

Intentional blank page

Introduction and Common Criteria

What is Common Criteria?

What this guide describes

Network Device Protection Profile

Specifications and References for the CCEvaluated System

About the evaluated version of IBM BigFix Endpoint Manager

About the evaluated version of IBM BigFix Endpoint

How to obtain the CC-evaluated product

RedHat security patch: RHEL OpenSSL RPM (openssl-1.0.1e-42.el6_7.2.x86_64.rpm)

Component specifications for the CC-evaluated system

IBEM 9.2.3.101 Server software component (Linux only)

IBEM 9.2.3.101 Client software component (Linux only)

Red Hat Enterprise Linux (RHEL) 6.6 Server (x86-64)

IBM BigFix Endpoint Manager technical documentation

Evaluated and non-evaluated security functionality

Evaluated security functionality

Assigning privileges to users

Enforcing access restrictions on users

Clearing of Residual Information

Security functionality not evaluated

Description of the Target of Evaluation (TOE)

NO_GENERAL_PURPOSE It is assumed that there are no general-purpose computing

IBM System x3500 M5

IBM BigFix Endpoint Manager 9.2 Client

The IBM BigFix client (agent) is running as the BESClient process.

Installation and Environmental

3 ISO images corresponding to w7box,rhel1 and rhel2 (DVDs)

1 IBM BigFix Endpoint Manager Console install package (BESConsole.exe)

1 IBM BigFix Endpoint Manager Server install package (ServerInstaller_9.2.3.101rhel6.x86_64.tgz)

1 BES Support Site Masthead (BES Support QA.efxm)

1 file from which licenses are generated (LicenseAuthorization.BESLicenseAuthorization)

Network description and assumptions

Installing rhel2 (DB2 /Audit Server Machine)

RAID Controller Configuration

RAID Controller Configuration

Create RAID 0 virtual drive

Select "System Settings" and then select "Storage".

Select "Save Configuration"

Initialize the Virtual Drive

Restore the RHEL Image

Logging into rhel2

Set the rhel2 system date and time

Configuring DB2 on rhel2

Installing and configuring DB2

Changing the rhel2 Server Host Name

Configuring stunnel for secure networking between rhel1 and rhel2.

Configuring stunnel server on rhel2

chmod a-r /etc/pki/tls/private/stunnel.pvk

Install rhel1 (IBM BigFix Server and Client - TOE)

RAID Controller Configuration

RAID Controller Configuration

Create RAID 0 virtual drive.

Select "Save Configuration"

Initialize the Virtual Drive

Restore the RHEL Image

Logging into and out of rhel1 (The TOE)

Set the rhel1 system date and time

Change DB2 client password