BeyondTrust PowerBroker UNIX + Linux Edition Version 9.1. Common Criteria Assurance Activities Report. Version 1.4 8/25/2016

Transcription

1 BeyondTrust PowerBroker UNIX + Linux Edition Version 9.1 Common Criteria Assurance Activities Report Version 1.4 8/25/2016 Prepared by: Leidos Inc. Common Criteria Testing Laboratory 6841 Benjamin Franklin Drive Columbia, MD 21046

2 Prepared for: National Information Assurance Partnership Common Criteria Evaluation and Validation Scheme The Developer of the TOE: BeyondTrust Software, Inc N. 40th Street Phoenix, AZ Phone: The TOE Evaluation was Sponsored by: BeyondTrust Software, Inc N. 40th Street Phoenix, AZ Phone: Evaluation Personnel: Gregory Beaver Cody Cummins Common Criteria Versions Common Criteria for Information Technology Security Evaluation Part 1: Introduction, Version 3.1, Revision 4, dated: September Common Criteria for Information Technology Security Evaluation Part 2: Security Functional Components, Revision 4, dated: September Common Criteria for Information Technology Security Evaluation Part 3: Security Assurance Components, Revision 4, dated: September Common Evaluation Methodology Versions Common Methodology for Information Technology Security Evaluation, Evaluation Methodology, Version 3.1, Revision 4, dated: September Protection Profiles Standard Protection Profile for Enterprise Security Management Policy Management, Version 2.1, October 24, 2013 ) and includes the additional optional SFRs: FAU_SEL.1, and FMT_MTD.1 Standard Protection Profile for Enterprise Security Management Access Control, Version 2.1, October 24,

3 2

4 Table of Contents 1 Introduction Evidence Security Functional Requirement Assurance Activities Security Audit (FAU) Audit Data Generation FAU_GEN.1 [ESM_PM] ESM_AC] Selective Audit FAU_SEL.1 [ESM_AC] External Selective Audit FAU_SEL_EXT.1 [ESM_PM] Protected Audit Trail Storage (Local Storage) FAU_STG.1 [ESM_AC] External Audit Trail Storage FAU_STG_EXT.1 [ESM_AC] ESM_PM] Communication (FC0) Enforced Proof of Receipt FCO_NRR.2 [ESM_AC] User Data Protection (FDP) Host-Based Access Control FDP_ACC.1(1), FDP_ACF.1(1) [ESM_AC] Access Control Policy (Self-Protection) FDP_ACC.1(2), Access Control Functions FDP_ACF.1(2) [ESM_AC] Identification and Authentication (FIA) User-Subject Binding FIA_USB.1 [ESM_PM] Security Management (FMT) Management of Functions Behavior FMT_MOF.1 [ESM_PM] Management of Functions Behavior FMT_MOF.1(1) [ESM_AC] Management of Functions Behavior FMT_MOF.1(2) [ESM_AC] External Management of Functions Behavior FMT_MOF_EXT.1 [ESM_PM] Management of Security Attributes FMT_MSA.1 [ESM_AC] Static Attribute Initialization FMT_MSA.3 [ESM_AC] Consistent Security Attributes FMT_MSA_EXT.5 [ESM_PM] Management of TSF Data FMT_MTD.1 [ESM_PM] Specification of Management Functions FMT_SMF.1 [ESM_PM]

5 Specification of Management Functions FMT_SMF.1 [ESM_AC] Security Management Roles FMT_SMR.1 [ESM_PM] [ESM_AC] Protection of the TSF (FPT) Protection of Stored Credentials FPT_APW_EXT.1 [ESM_PM] [ESM_AC] Protection of Secret Key Parameters FPT_SKP_EXT.1 [ESM_PM] [ESM_AC] Failure of Communications FPT_FLS_EXT.1 [ESM_AC] Replay Detection FPT_RPL.1 [ESM_AC] Resource Utilization (FRU) Degraded Fault Tolerance FRU_FLT.1 [ESM_AC] Trusted Path/Channels (FTP) Inter-TSF trusted channel FTP_ITC.1 [ESM_PM] ESM_AC] Trusted Path FTP_TRP.1 [ESM_PM] Enterprise Security Management (ESM) Access Control Policy Definition ESM_ACD.1 [ESM_PM] Access Control Policy Transmission ESM_ACT.1 [ESM_PM] Reliance on Enterprise Authentication ESM_EAU.2(1) ESM[ESM_PM] Reliance on Enterprise Authentication ESM_EAU.2(2) [ESM_PM] Reliance on Enterprise Identification ESM_EID.2(1) [ESM_PM] [ESM_AC] Reliance on Enterprise Identification ESM_EID.2(2) [ESM_PM] [ESM_AC] 65 3 Security Assurance Requirements Class ADV: Development ADV_FSP.1 Basic Functional Specification Class AGD: Guidance Documents AGD_OPE.1 Operational User Guidance AGD_PRE.1 Preparative Procedures ATE_IND.1 Independent Testing Conformance ATE_IND.1 Assurance Activity Class AVA: Vulnerability Assessment AVA_VAN.1 Assurance Activity Class ALC: Life-Cycle Support

6 3.5.1 ALC_CMC.1 Labeling of the TOE Assurance Activity ALC_CMS.1 TOE CM Coverage Assurance Activity

7 1 INTRODUCTION This document presents assurance activity evaluation results of the BeyondTrust PowerBroker UNIX + Linux Edition, Version 9 evaluation. There are three types of assurance activities and the following is provided for each: 1. TOE Summary Specification (TSS) an indication that the required information is in the TSS section of the Security Target 2. Guidance a specific reference to the location in the guidance is provided for the required information 3. Test a summary of the test procedure and result is provided for each required test activity. This Assurance Activities Report contains sections for each functional class and family and sub-sections addressing each of the SFRs specified in the Security Target. 1.1 Evidence [ST] BeyondTrust PowerBroker UNIX + Linux Edition Security Target, Version 1.0, August 3, 2016 [PB_Admin] PowerBroker Servers UNIX + Linux Edition System Administration Guide, Software Version: 9.1, Document Revision: 0, July 2015 [PB_DM] [PB_BIG] PowerBroker Servers UNIX + Linux Edition System Diagnostic Messages Guide, Software Version: 9.1, Document Revision: 0, July 2015 PowerBroker Servers UNIX + Linux Edition System, Browser Interface Guide, Software Version: 9.1, Document Revision: 0, July 2015 [PB_Install] PowerBroker Servers UNIX + Linux Edition Installation Guide, Software Version: 9.1, Document Revision: 0, July 2015 [PB_PLG] [PB_CC] [PB_Event] PowerBroker Servers UNIX + Linux Edition Policy Language Guide, Software Version: 9.1, Document Revision: 0, July 2015 PowerBroker for Unix & Linux Common Criteria Supplementary Information Document PBUL_EventLog_Fields 2 SECURITY FUNCTIONAL REQUIREMENT ASSURANCE ACTIVITIES This section describes the assurance activities associated with the SFRs defined in the ST and the results of those activities as performed by the evaluation team. The assurance activities are derived from and. 6

8 2.1 Security Audit (FAU) Audit Data Generation FAU_GEN.1 [ESM_PM] ESM_AC] TSS Assurance Activities The evaluator shall check the TSS and ensure that it summarizes the auditable events and describes the contents of the audit records. ST Section 6.2 summarizes the auditable events and describes the contents of the audit records. The logged audit records identify the date and time (obtained from the underlying operating system), the nature or type of the triggering event, an indication of whether the event succeeded or failed, the identity of the user responsible for the event (retrieved from the underlying operating system), as well as the completion status of the applicable function. The success or failure of an audited event is implied by the event type. The logged audit records also include event-specific content that includes at least all of the content as required from the protection profiles Guidance Assurance Activities The evaluator shall check the operational guidance and ensure that it lists all of the auditable events and provides description of the content of each type of audit record. Each audit record format type shall be covered, and shall include a brief description of each field. The evaluator shall check to make sure that every audit event type mandated by the PP is described and that the description of the fields contains the information required in FAU_GEN 1.2, and the additional information specified in Table 3. [PB_CC] Section Event Record Format section provides an example of a single audit record for a single Accept command. Each event has well over 100 different fields recorded each time a command is processed. In addition, custom data derived during the processing of the policy when a command is executed can also be added to the event log. [PB_CC] Section Audit Record Breakdown identifies the applicable information for each audit record as applied to each SFR audit requirement and to which database the audit record is recorded. This section identifies the audit information that is captured in the configuration management database. This section also identifies the audit information in the Event Audit Log as it pertains to each SFR. A single audit record from the Event Log is identified in [PB_CC] Section Event Record Format which illustrates the detail that is recorded in each event. [PB_CC] Section Audit Record Breakdown identifies the applicable information from the Event Record Log for each audit record as applied to each SFR audit requirement in order to simply and identifies the applicable content. 7

9 Every audit event type mandated by the PP is described and that the description of the fields contains the information required in FAU_GEN 1.2 which includes the date and time of the event, type of event, subject identity (if applicable), and the outcome (success or failure) of the event. [PB_CC] Appendix A: Event Log Fields identifies and describes the variables, the data type, and a description for the Event Log fields. [PB_CC] Appendix B: Change Management Event Log Fields identifies and describes the variables, the data type, and a description for the Change Management Event Log Fields. [PB_CC] Section Additional Audit Functions and Change Management, provides the guidance to create, configure and access the configuration database. The evaluator shall review the operational guidance, and any available interface documentation, in order to determine the administrative interfaces (including subcommands, scripts, and configuration files) that permit configuration (including enabling or disabling) of the mechanisms implemented in the TOE that are necessary to enforce the requirements specified in the PP. The evaluator shall document the methodology or approach taken to do this. The evaluator may perform this activity as part of the activities associated with ensuring the AGD_OPE guidance satisfies the requirements. Using this list, the evaluation shall confirm that each security relevant administrative interface has a corresponding audit event that records the information appropriate for the event. The evaluator examined the security target and identified the administrative functions as identified in FMT_SMF.1. These administrative functions were mapped to the operational guidance to determine the administrative interfaces. These interfaces consist of the Policy Language commands, functions and configuration files. [PB_CC] Section Additional Audit Functions and Change Management, provides the guidance to create, configure and access the configuration database. Change management is not enforced or enabled by default, but is required to meet the requirements outlined in the Common Criteria requirements document. When any file is added to the configuration database using the pbdbutil command, PowerBroker for Unix & Linux will automatically handle the creation of the database and appropriate configuration for version control and file tracking The table below identifies the administrative interfaces of the mechanisms implemented in the TOE that are necessary to enforce the requirements specified in the PP. The corresponding audit record generated from the relevant administrative actions and interfaces are identified in [PB_CC] Section Audit Record Breakdown. The table in in [PB_CC] Section Audit Record Breakdown identifies the SFR component and details of the audit record. Table 1 Security Relevant Administrative Interfaces Requirement ESM_ACD.1 Management Activities Creation of policies Interface [PB_CC] Section: Define Policy provides the guidance and sample policy files used during the CC evaluation. [PB_BIG] p. 61 8

10 Requirement ESM_ACT.1 ESM_EAU.2 Management Activities Transmission of policy to Access Control products Management of authentication data for both interactive users and authorized IT entities (if managed by the TSF) Interface The Policy Editor (see Policy Editor Overview, page 61) can be used to create and modify policy files. It is intended to be a starting point from which administrators can create and modify simple policies based on a limited number of constraints. Creating policies with the Policy Editor requires the construction of a policy tree (see Policy Tree, page 64). The policy tree represents a policy file that is broken down into its individual components. The policy tree is built by inserting individual policy components. Each component handles a particular property of a policy and is configured with one of the Smart Editors (see Smart Editors, page 67). Note: The Policy Editor should not be expected to handle overly complex policies. Complex policies are best implemented with the PowerBroker Policy Language and a text editor. [PB_PLG] p. 19 Creating Policy Files A security policy file is a collection of instructions that define the system security rules that PowerBroker Servers applies during task verification processing. These instructions are written using PowerBroker Servers security policy scripting language. The default name of the primary PowerBroker Servers security policy file is pb.conf. This file is analogous to the main() function in a C program. It is possible to add security policy scripting language statements directly to pb.conf or to use security policy subfiles. Security policy subfiles are separate, individual security policy files invoked at runtime using the include statement (using the syntax include "subfilename";). [PB_CC] Section: 7 Start issuing commands provides the guidance to start issuing the pbrun commands. Note: The transmission of a policy is normally an administrative action. However, this product issuing a pbrun command is not necessarily an administrative action. Requests from the Submit Host (the Access control portion of the TOE) are transmitted to the Master Host (the Policy Management portion of the TOE). If the task is ACCECPTED by the policy, the Master Host transmits the secure task to the Run Host (the Access control portion of the TOE). [PB_CC] Section: Additional Authentication provides the guidance to set the policy to authenticate a user. [PB_Admin] p. 47 PAM to RADIUS Authentication Module Starting in V8.5, PBUL includes a PAM module (pam_radius_auth) to support authentication against a configured RADIUS server. The module allows PBUL to act as a RADIUS client for authentication and accounting requests. You must have a RADIUS server already installed and configured before using this module. Your RADIUS server must also have the PBUL host requesting authentication already 9

11 Requirement FAU_SEL.1 FAU_SEL_EXT.1 FAU_STG_EXT.1 FMT_MOF_EXT. 1 FTP_ITC.1 Management Activities Configuration of auditable events Configuration of auditable events for defined external entities Configuration of external audit storage location Configuration of the behavior of other ESM products Configuration of actions that require trusted defined as a RADIUS client. Interface [PB_PLG] Section LDAP Functions page 235, summarizes the PowerBroker for Unix & Linux LDAP functions. [PB_Admin] p. 171 Shared Libraries for LDAP The following setting is related to the shared libraries that are needed for LDAP use in PowerBroker Servers. The loadldaplibs setting determines whether the libraries that are listed in the sharedlibldapdependencies setting are loaded at runtime even if Policy LDAP functions are not used. This setting is useful in certain cases where the operating system is configured to use LDAP and we need to force PowerBroker Servers to load the LDAP libraries. sharedlibldapdependencies This setting should be used in either of the following circumstances: LDAP is used in the PowerBroker Servers policy The pam setting is set to yes and PAM is using LDAP [PB_CC] Section Audit Record Inclusion/Exclusion provides the guidance to configure the auditable events. [PB_CC] Section Audit Record Inclusion/Exclusion provides the guidance to configure the auditable events. [PB_CC] Section: PowerBroker for Unix & Linux Auditing provides the guidance to configure the audit generation and storage. [PB_CC] Section: Additional Audit Functions and Change Management, provides the guidance to configure the audit generation and storage for the records stored in the configuration database. [PB_Admin] page 93, Section Event Logging provides the guidance to configure the event log. [PB_CC] Section: Define Policy provides the steps to set up the policy. The TOE is both an access control and policy management product. The behavior of the TOE is control by creating and implementing policy files. [PB_CC] Section: Encryption Settings provides the guidance to use the enforcehighsecurity setting to set the encryption requirements. 10

12 Requirement FTP_TRP.1 Management Activities channel (if applicable) Configuration of actions that require trusted path (if applicable) Interface [PB_CC] Section: Encryption Settings provides the guidance to use the enforcehighsecurity setting to set the encryption requirements Test Activities The evaluator shall test the TOE s audit function by having the TOE generate audit records for all events that are defined in the ST and/or have been identified in the previous two activities. The evaluator shall then check the audit repository defined by the ST, operational guidance, or developmental evidence (if available) in order to determine that the audit records were written to the repository and contain the attributes as defined by the ST. This testing may be done in conjunction with the exercise of other functionality. For example, if the ST specifies that an audit record will be generated when an incorrect authentication secret is entered, then audit records will be expected to be generated as a result of testing identification and authentication. The evaluator shall also check to ensure that the content of the logs are consistent with the activity performed on the TOE. For example, if a test is performed such that a policy is defined, the corresponding audit record should correctly identify the policy that was defined. The majority of necessary audits are captured by default in the pb.eventlog. The evaluator enabled the change management database to enable the capturing of the remaining audits. The evaluator collected the necessary audits throughout the course of the evaluation. The pb.eventlog and change management database were reviewed and it was found that the audit records written do contain the attributes as defined in the ST. Table 2 Audit Record Verification Requirement Auditable Events Test Case ESM_ACD.1 ESM_ACT.1 ESM_EAU.2 FAU_GEN.1 Creation or modification of policy Transmission of policy to Access Control products All use of the authentication mechanism Start-up of the audit functions; 6.1 ESM_ACD ESM_ACT ESM_EAU.2 (1) 6.5 FAU_GEN.1 11

13 Requirement Auditable Events Test Case FAU_GEN.1 FAU_SEL.1 FAU_SEL_EXT.1 FAU_STG_EXT.1 FCO_NRR.2 FDP_ACC.1(1), (2) FDP_ACF.1(1), (2) FMT_MOF.1 FMT_SMF.1 Shut-down of the audit functions All modifications to audit configuration All modifications to audit configuration Establishment and disestablishment of communications with audit server The invocation of the non-repudiation service Any changes to the enforced policy or policies All requests to perform an operation on an object covered by the SFP All modifications to TSF behavior Use of the management functions 6.5 FAU_GEN FAU_SEL.1 - FAU_SEL_EXT FAU_SEL.1 - FAU_SEL_EXT FAU_STG_EXT.1 Note: The evaluated configuration did not use an external audit server. The audit record captures the establishment of communication with the pblogd audit server. 6.9 FCO_NRR.2 Note: Policies are not transmitted, instead policies are stored centrally and requests are made against the central policy. Requests from the Submit Host (the Access control portion of the TOE) are transmitted to the Master Host (the Policy Management portion of the TOE). If the task is ACCECPTED by the policy, the Master Host transmits the secure task to the Run Host (the Access control portion of the TOE). The event log captures the entire process in the Event Log Accept record. The ACCECPT Event Log record captures the identification of the requesting user and each TOE component is identified FDP_ACC.1 (1) & FDP_ACF.1 (1) 6.1 ESM_ACD FDP_ACC.1 (2) & FDP_ACF.1 (2) 6.13 FMT_MOF ESM_ACD FAU_SEL.1 - FAU_SEL_EXT FMT_MOF_EXT FMT_SMF ESM_ACD ESM_EAU.2 (1) 6.6 FAU_SEL.1 - FAU_SEL_EXT FMT_MOF_EXT FTP_ITC.1 12

14 Requirement Auditable Events Test Case 6.28 FTP_TRP.1 FMT_SMR.1 FPT_FLS_EXT.1 FTP_ITC.1 FTP_TRP.1 Modifications to the members of the management roles Failure of communication between the TOE and Policy Management product All use of trusted channel functions All attempted uses of the trusted path functions 6.22 FMT_SMR ESM_ACD.1 Note: This is an audit record from importing the policy file, thus applying the policy. The policy file is what controls who can perform the management functions FPT_FLS_EXT FRU_FLT FTP_ITC FPT_RPL.1 Note: The ACCEPT Event Log entry captures the use of the trusted channel functions. Two fields are in the Event Log entry identifies the initiator and target of the trusted channel FTP_TRP.1 Note: The audit records generated for the use of the trusted path are recorded in the ACCEPT Event Log entry and the REJECT Event Log entries. The Event Log entry records the identification of the user associated with the trusted path function Selective Audit FAU_SEL.1 [ESM_AC] TSS Assurance Activities The evaluator shall check the TSS in order to determine that it discusses the TSF s ability to have selective auditing and that it summarizes the mechanism(s) by which auditable events are selected for auditing. ST Section 6.2 identifies the selective auditing capabilities of the TOE. The Administrator can define variables inside the policy. The value of the policy variables are recorded in the event log by default immediately after the policy is saved and enforced. The selective auditing is performed by including the logomit command inside the policy. The logomit function disables values of specified variables from being recorded in the event log. Add the eventlog = "/dev/null"; statement. 13

15 The TOE can also perform selective auditing on the following object types: Processes, Files, Host Configuration, and Authentication Function by using the eventlog = /dev/null ; based upon the statements inside the policy file Guidance Assurance Activities The evaluator shall check the operational guidance in order to determine the selections that are capable of being made to the set of auditable events, and shall confirm that it contains all of the selections identified in the Security Target. [PB_CC] Section Audit Record Inclusion/Exclusion states that the administrator may implement selective auditing, i.e. to disable variables from being entered into the event log, anywhere within the policy file by the use the logomit function. The auditable event log fields are identified in Appendix A: Event Log Fields. The guidance also identifies the eventlog = "/dev/null"; statement which can be included in the policy to permit selective auditing based on statements inside the policy. The guidance contains all of the selections identified in the Security Target Test Activities The evaluator shall test this capability by using all allowable vectors that are defined in FMT_MOF.1 to configure the TOE in the following manners: - All selectable auditable events enabled - All selectable auditable events disabled - Some selectable auditable events enabled For each of these configurations, the evaluator shall perform all selectable auditable events and determine by review of the audit data that in each configuration, only the enabled events are recorded. The TOE automatically adds all administrator defined variables in the policy to the eventlog. The evaluator verified that that defined variables were in fact included in the eventlog after a request was sent to the policy server. The evaluator successfully demonstrated that these defined variables could also be omitted from the event log. The TOE automatically adds all administrator defined variables in the policy to the eventlog. The evaluator verified the selective auditing by including and then excluding two defined variables. 1. The evaluator identified two variables defined in the pbul_functions.conf file, one for the LDAP server address and another for the LDAP username. The evaluator submitted a pbrun request to the MasterHost and viewed that the variables and their values were found in the eventlog upon completion. 2. The evaluator used the logomit function to disable the LDAP server variable from being stored in the event log. The logomit function is passed a list of variables to be excluded. The format to omit just the LDAP server variable is : logomit={ LDAPServer }; 3. The evaluator submitted a pbrun request to the MasterHost and viewed that the LDAP server variable was not found in the eventlog upon completion. 14

16 4. The evaluator used the logomit function to disable the LDAP user variable from being stored in the event log. The format to omit just the LDAP server variable is : logomit={ LDAPUser }; 5. The evaluator submitted a pbrun request to the MasterHost and viewed that the LDAP user variable was not found in the eventlog upon completion. Selective auditing was performed on the four object types: processes, files, host configuration and authentication function using the eventlog = /dev/null ; command External Selective Audit FAU_SEL_EXT.1 [ESM_PM] TSS Assurance Activities The evaluator shall check the TSS in order to determine that it discusses the TSF s ability to configure selective auditing for an Access Control product and that it summarizes the mechanism(s) by which auditable events are selected for auditing. ST Section 6.6 states that the Protection Profile AC components are spread across the three TOE components. Management functions occur locally on each device with the Master Host providing both Policy Management and Access Control functionality. Configuration of each node is done locally on that node, through the use of locally defined configuration files. See AAR Section Selective Audit FAU_SEL.1 TSS Assurance Activities for a description of how the TOE implements selective auditing Guidance Assurance Activities The evaluator shall check the operational guidance in order to determine the selections that are capable of being made to the set of auditable events, and shall confirm that it contains all of the selections identified in the Security Target. ST Section 6.6 states that the Protection Profile AC components are spread across the three TOE components. Management functions occur locally on each device with the Master Host providing both Policy Management and Access Control functionality. Configuration of each node is done locally on that node, through the use of locally defined configuration files. See AAR Section Selective Audit FAU_SEL.1 Guidance Assurance Activities for a description of how the TOE implements selective auditing Test Activities The evaluator shall test this capability by configuring a compatible Access Control product to have: - All selectable auditable events enabled - All selectable auditable events disabled - Some selectable auditable events enabled 15

17 For each of these configurations, the evaluator shall perform all selectable auditable events and determine by review of the audit data that in each configuration, only the enabled events are recorded by the Access Control product. If this SFR is iterated, the evaluator shall repeat these activities for each iteration of the SFR, substituting the appropriate external entity for Access Control product where appropriate. ST Section 6.6 states that the Protection Profile AC components are spread across the three TOE components. Management functions occur locally on each device with the Master Host providing both Policy Management and Access Control functionality. Configuration of each node is done locally on that node, through the use of locally defined configuration files. See AAR Section Selective Audit FAU_SEL.1 Test Activities for a description of how the TOE implements selective auditing and the test results Protected Audit Trail Storage (Local Storage) FAU_STG.1 [ESM_AC] TSS Assurance Activity The evaluator shall examine the TSS to ensure it describes the amount of audit data that are stored locally, what happens when the local audit data store is full, and how these records are protected against unauthorized access. The TOE auditing capabilities are identified in the ST Section 6.2. Physical storage for log records (internal and external) is provided by the operational environment. The amount of audit data which can be stored is dependent upon on the amount of disk space available on the server hosting pblogd. The same applies for logs exported to external log servers. The TOE includes options for log file management, i.e. log file rotation and archiving based on time and/or size. Additionally, to help prevent loss of space on the file system for audit logs; space on the log host can be controlled and the system can be configured to fail over to the next log server with the logreservedfilesystems and logreservedblocks settings. The logreservedfilesystems and logreservedblocks settings enable the administrator to control free space on the logreservedfilesystems file systems, and cause an immediate failover if the log host s free space falls below logreservedblocks. If the number of free 1-KB blocks falls below logreservedblocks on any of the file systems that are specified in any of the logreservedfilesystems on the log host, then the log daemon immediately refuses any new requests, causing an immediate failover. If the free space in any of the file systems containing /var/log or /usr/log falls below 10,000 blocks, then new requests are rejected. Requests that are already in progress are allowed to continue. If there are no Log Servers (including the Master Host) capable of recording an event (e.g., no disk space is available), the TOE itself would fail and therefore stop. The audit records are protected against unauthorized access since the TOE does not provide any interfaces to modify or delete the log files Guidance Assurance Activities 16

18 The evaluator shall examine the operational guidance to determine that it describes the relationship between the local audit data and the audit data that are sent to the audit log server. For example, when an audit event is generated, is it simultaneously sent to the external server and the local store, or is the local store used as a buffer and cleared periodically by sending the data to the audit server. Physical storage for log records is provided by the operational environment. The amount of audit data which can be stored is dependent upon on the amount of disk space available on the server hosting pblogd. [PB_CC] Section: Event Audit Records provides the guidance for log file management such as log file rotation and archiving logs based on time and/or size Test Activities The evaluator shall test this capability by attempting to access locally-stored audit data without authorization and observe that the attempts fail. They shall also observe that the space allocated for audit storage is consistent with the TSF s capabilities. The evaluator attempted to access the audit data stored on the Master Host as a non-admin user and observed that access was denied as expected. The evaluator demonstrated in FMT_MOF_EXT.1 that the space allocated for audit storage is defined in /etc/pb.settings. The evaluator verified that the defined space received the audits successfully External Audit Trail Storage FAU_STG_EXT.1 [ESM_AC] ESM_PM] TSS Assurance Activity The evaluator shall check the TSS in order to determine that it describes the location where the TOE stores its audit data, and if this location is remote, the trusted channel that is used to protect the data in transit. The TOE auditing capabilities are identified in the ST Section 6.2. The generated records are sent to an internal Log Server for storage (note that if no Log Server (i.e., pblogd) is configured, the Master Host (i.e., pbmasterd) will serve as the Log Server). If there are no Log Servers (including the Master Host) capable of recording an event (e.g., no disk space is available), the TOE itself would fail and therefore stop. If the Log Server storage location is not the Master Host, the audit records are sent to the Log Server using TLS. 17

19 Guidance Assurance Activities The evaluator shall check the operational guidance in order to determine that it lists any configuration steps required to set up audit storage. If audit data is stored in a remote repository, the evaluator shall also check the operational guidance in order to determine that a discussion on the interface to this repository is provided, including how the connection to it is established, how data is passed to it, and what happens when a connection to the repository is lost and subsequently reestablished. The generated records are sent to an internal Log Server for storage (note that if no Log Server (i.e., pblogd) is configured, the Master Host (i.e., pbmasterd) will serve as the Log Server). The Log Host is the machine on which the PowerBroker for Unix & Linux log server runs. The daemon pblogd is used for writing the event logs and I/O logs. [PB_CC] Section Configure Desired Auditing provides the instructions required to set up audit storage. [PB_Install] Section PowerBroker for Unix & Linux pbinstall Installation Menu, page 40 identifies the installation menu options and configuration options to set up the audit storage. [PB_Admin] Section pblogd, page 284 identifies the pblogd as the PowerBroker for Unix & Linux log server daemon that records event and I/O logs as directed by other PowerBroker for Unix & Linux programs. A socket-listener process (typically inetd, xinetd, or pblogd d) starts pblogd Test Activities The evaluator shall test this function in conjunction with testing of FAU_GEN.1 by confirming that the same set of audit records are received by each of the configured audit destinations. The evaluator shall also make the connection to the external audit storage unavailable, perform audited events on the TOE, re-establish the connection, and observe that the external audit trail storage is synchronized with the local storage. Similar to the testing for FAU_GEN.1, this testing can be done in conjunction with the exercise of other functionality. Finally, since the requirement specifically calls for the audit records to be transmitted over the trusted channel established by FTP_ITC.1, verification of that requirement is sufficient to demonstrate this part of this one. The evaluator successfully captured all necessary audit records which are demonstrated in FAU_GEN.1. The use of an external syslog server was not used in the evaluated configuration. 2.2 Communication (FC0) Enforced Proof of Receipt FCO_NRR.2 [ESM_AC] 18

20 TSS Assurance Activity The evaluator shall check the TSS in order to determine that the assignments were completed in a manner that is consistent with the guidance provided by the application note(s). The evaluator checked the TSS and determined that the assignments were completed in a manner that is consistent with the guidance provided by the application note(s). [ST] Section 6.3 states that the TOE is both a Policy Management and Access Control product where policies are centralized and never transmitted. Policies are defined on a Master Host and available immediately as soon as it is saved. Once defined, the policy files never leave this location or otherwise traverse across the TOE or outside the TOE. Policies are defined by administrators using secured task requests sent to the Master Controller. The Submit Host identifies where to submit the Secured Task using Master host name. The TOE identifies the submitter of a Secured Task using Submit Host Name, and uid. The administrator who has defined the policy or any authorized administrator can immediately verify the existence of the policy by performing a policy lookup using the policy file name. The administrator can also verify the location (Master Host) of the policy by viewing the Master Host field/attribute which contains the name of the Master Host the policy file is located on. The evaluator shall also check the TSS to see that it discusses how the TOE identifies itself to the Policy Management product and how it provides evidence of the policy s consumption to the Policy Management product. An application note is included in the security target section and further discussed in the TSS section 6.3 the states that The TOE is both a Policy Management and Access Control product where policies are centralized and never transmitted. The Submit Host identifies where to submit the Secured Task using Master host name. The TOE identifies the submitter of a Secured Task using Submit Host Name, and uid. The administrator who has defined the policy or any authorized administrator can immediately verify the existence of the policy by performing a policy lookup using the policy file name. The administrator can also verify the location (Master Host) of the policy by viewing the Master Host field/attribute which contains the name of the Master Host the policy file is located on Guidance Assurance Activities The evaluator shall check the operational guidance in order to determine how the TOE confirms evidence of received policy data back to the Policy Management product that originally sent it that policy data. This should include the contents and formatting of the receipt such that the data that it contains is verifiable. [PB_CC] Section Audit Record Breakdown, SFR Component FCO_NRR.2, confirms the evidence of received policy back to the Policy Management portion of the TOE (Master Host). The Event Log record identifies the submitter of a secured task by the user and Submit Host identification. The content 19

21 and formatting of the receipt (event log record) is verifiable by the Name of the Policy in Effect, Type of Command requested, Name of User Requesting the Privileged Command, Submit Host Identification, Master Host Identification, Run Host Identification, and the Successful Execution of the Command. If a user request to access a privileged command is denied, the Master Host returns a rejection notice to the Submit Host notifying the user request was denied. The notification also serves as a receipt the policy is in effect. If a user request to access a privileged command is accepted, the Submit Host displays the successful execution and results of the privileged command from the Run Host. The successful execution of the command also serves as a receipt the policy is in effect Test Activities The evaluator shall test this capability by configuring an environment such that the TOE is allowed to accept a policy from a certain source, sending it a policy from that source, observing that the policy is subsequently consumed, and that an accurate receipt is transmitted back to the Policy Management product within the time interval specified in the ST. The evaluator confirms accuracy by using the Policy Management product to view the receipt and ensure that its contents are consistent with known data. Policies are managed and stored on the Master Host component. Policies are not transmitted. The relevant information that is transmitted is the secured task that is accepted by the Master Host, based on the configured policy, and transmitted to the Run Host. In terms of the TOE, the Run Host (specifically, the pblocald daemon) provides positive access control enforcement by executing the command requested from the Submit Host and accepted by the Master Host. When the Run Host executes the submitted command, a log record to this effect is generated and written to the Log Host this provides proof of receipt by the Run Host of the positive access control decision made by the Master Host. The evaluator verified that such a log record was generated when a submit request is processed by the MasterHost. 2.3 User Data Protection (FDP) Host-Based Access Control FDP_ACC.1(1), FDP_ACF.1(1) [ESM_AC] TSS Assurance Activity Subject Object Operation Processes Execute Delete Terminate Change Permissions User Files Create Read Modify Delete Change Permissions Host Configuration Read Modify Delete Authentication Function Login 20

22 The evaluator shall check the TSS in order to verify that the TOE is capable of mediating the activities that are defined in Table above and that the access control policy enforcement mechanism is described. Section 6.4 of the Security Target states that the TOE s Access Control Policy function located on the Master Host enforces defined policies that allow users access to protected commands and functions. Policies can be configured and enforced for the following object types: programs, files, host configuration, and authentication function. The critical instructions in the policy file are accept and reject. Access to the Processes, Files, Host Configuration, Authentication Function objects on a target host is permitted or denied by these commands. The operations requiring privilege access are defined and controlled on individual user or group basis. The ability to create, read, modify, execute, delete, terminate, or change permissions of these objects, and ability to use authentication function is configurable in the policy by the accept and reject commands. In order to invoke a controlled command, the user uses one of the clients provided with the TOE: pbrun; pbsh; or pbksh. The client submits the command and its parameters, along with the user identity, user group, and the hostname of the computer from which the command was invoked, to pbmasterd, which evaluates the request against a policy file to determine whether the request will be accepted and executed, or rejected. The policy file is a collection of instructions that define the security rules the TOE applies during task verification processing. The instructions are written using PowerBroker s security policy scripting language, a C-like interpreted language. The evaluator shall also check the TSS to determine that the method by which access control rules are applied is sufficiently detailed to allow for the creation of scenarios that allow for thorough positive and negative testing of the policy enforcement mechanism based on the types of policy rules and their contents. ST Section 6.4 The critical instructions in the policy file are accept and reject. As soon as processing of the policy file reaches an accept statement, policy file processing ceases and the TOE attempts to execute the requested command. As soon as processing of the policy file reaches a reject statement, policy file processing ceases and the TOE notifies the user that the requested command has been rejected. If policy processing reaches the end of the file without encountering an accept or reject statement, the TOE will reject the request. The TOE can be configured to create a scenario for positive and negative testing of the policy enforcement mechanism. A policy can be configured to accept all commands from a user, where verification of the access is permitted. The policy can then be modified to reject all commands from the user, where verification that access was denied was observed Guidance Assurance Activities Subject Object Operation 21

23 User Processes Files Host Configuration Authentication Function Execute Delete Terminate Change Permissions Create Read Modify Delete Change Permissions Read Modify Delete Login The evaluator shall check the operational guidance in order to verify that it provides instructions on how it receives access control policy data. For example, if the TOE receives policy rules in some defined language, the operational guidance shall indicate the statements in this language that correspond with the activities that are defined in Table 15 above. The TOE receives policy rules from the security policy file programming language for the BeyondTrust PowerBroker for Unix & Linux software. [PB_CC] Section Controlling Commands states that standard functionally in PowerBroker for Unix & Linux allows for commands to be whitelisted (run with higher privileges) and blacklisted (denied from running). This also allows new commands to be created to control everything on a system, including management of PowerBroker for Unix & Linux itself. This customizable control applies to processes, files, host configuration, authentication functions, and the operations to act upon each object. [PB_CC] Section Conditional Command Processing states that the TOE can perform an almost endless list of additional checks before allowing a command to be processed. Conditional processing statements such as IF and CASE can be used to leverage hundreds of variables as part of the decision making process before a command is allowed to run, elevated and in what way, or rejected. [PB_CC] Section Configuration Files provides samples of the configuration files that were used by the CCTL to functionally test the TOE. These files were used during the testing of PowerBroker for Unix & Linux to ensure that all the requirements laid out in the common criteria template were met by the solution. These files are environment specific and should be used as examples only. The evaluator shall also check the operational guidance to verify that it provides information about how the TOE s rule processing engine. This allows administrators to design access control policies with appropriate expectations for how they will be enforced. [PB_CC] Section Controlling Commands states that standard functionally in PowerBroker for Unix & Linux allows for commands to be whitelisted (run with higher privileges) and blacklisted (denied from running). This also allows new commands to be created to control everything on a system, including management of PowerBroker for Unix & Linux itself. This customizable control applies to processes, files, host configuration, authentication functions, and the operations to act upon each object. [PB_CC] Section Conditional Command Processing states that the TOE can perform an almost endless list of additional checks before allowing a command to be processed. Conditional processing statements such as IF and CASE can be used to leverage hundreds of variables as part of the decision making process before a command is allowed to run, elevated and in what way, or rejected. 22

24 [PB_PLG] Section Security Policy File Processing pbmasterd, states that During security verification processing, the first accept or reject condition that is encountered causes security policy file processing to terminate immediately. No further security verification processing is performed. [PB_PLG] Section accept Statement, pages accept - When an accept statement is encountered, security policy file processing terminates immediately, pblocald starts, and the secured task is executed by pblocald. [PB_PLG] Section reject Statement, pages The reject statement immediately terminates security policy file checking and cancels the current job request without allowing it to execute. Depending on the parameters that are selected, the user sees a default message, custom reject message, or no message Test Activities Subject Object Operation Processes Execute Delete Terminate Change Permissions User Files Create Read Modify Delete Change Permissions Host Configuration Read Modify Delete Authentication Function Login The evaluator shall test this capability by using an authorized and compatible Policy Management product to define policies that contain rules for mediating the activities defined in Table 15. (Note: This table is incorrectly referenced as Table 6 in the PP.) For each subject/object/operation/attribute combination, the evaluator shall execute at least one positive and one negative test in order to show that the TSF is capable of appropriately mediating these activities. For example, the policy may define a rule that allows one user to execute a certain process and another that forbids a different user from executing the same process. Once this policy is implemented, the evaluator will access a system as each of these users and observe that the ability to execute the specified process is appropriately allowed or denied. Additionally, for each conditional attribute that is supported (such as time of day restrictions), the evaluator will devise a positive and negative test that proves that the conditional attribute affects whether or not the requested operation is allowed. This activity is then repeated for each other subject/object/operation/attribute tuple. If the TOE enforces any additional access control policy rules, the evaluator shall devise positive and negative tests that cause these to be invoked and observe that appropriate behavior is performed. This testing was completed while testing ESM_ACD.1. policy rules. Both positive and negative testing verified the The evaluator created policy files to test the subjects, objects, operations, and attributes inside the PowerBroker policy files pbul_functions.conf and pbul_policy.conf. 23