McAfee Policy Auditor 5.2 is an agent-based, purpose-built IT policy audit application that leverages the XCCDF and OVAL security standards to automate the processes required for internal and external IT audits. McAfee Policy Auditor evaluates the status of managed systems relative to audits that contain benchmarks. Benchmarks contain rules that describe the desired state of a managed system. Benchmarks are distributed with the TOE or imported into McAfee Benchmark Editor and, once activated, can be used by Policy Auditor. Benchmarks are written in the open-source XML standard formats Extensible Configuration Checklist Description Format (XCCDF) and the Open Vulnerability Assessment Language (OVAL). XCCDF describes what to check while OVAL specifies how to perform the check.
\r\nePO provides the user interface for the TOE via a GUI accessed from remote systems using web browsers. The ePO web dashboard represents policy compliance by benchmark. Custom reports can be fully automated, scheduled, or exported. ePO requires users to identify and authenticate themselves before access is granted to any data or management functions. Audit records are generated to record configuration changes made by users. The audit records may be reviewed via the GUI.
\r\nBased upon per-user permissions, users may configure the systems to be audited for policy compliance (the “managed systems”) along with the benchmarks to be checked. The Policy Auditor Agent Plug-In executing on the managed systems performs the policy audit and returns the results to Policy Auditor. Policy Auditor allows you to conduct policy audits on various releases of the following operating systems:
\r\nA) Microsoft Windows
\r\nB) Macintosh OS X
\r\nC) HP-UX
\r\nD) Solaris
\r\nE) Red Hat Linux
\r\nF) AIX
\r\nUsers can review the results of the policy audits via ePO. Access to this information is again limited by per-user permissions.
\r\nCommunication between the distributed components of the TOE is protected from disclosure and modification by cryptographic functionality provided by the operational environment.
","evaluation_configuration":null,"security_evaluation_summary":"The evaluation was carried out in accordance to the Common Criteria Evaluation and Validation Scheme (CCEVS) process and scheme. The evaluation demonstrated that McAfee Corporation’s McAfee Policy Auditor 5.2 and ePolicy Orchestrator 4.5 products meet the security requirements contained in the Security Target, version 2.0.2, dated February 2, 2011.
\r\nThe criteria against which McAfee Corporation’s McAfee Policy Auditor 5.2 and ePolicy Orchestrator 4.5 products were judged is described in the Common Criteria for Information Technology Security Evaluation, Version 3.1. The evaluation methodology used by the evaluation team to conduct the evaluation is the Common Methodology for Information Technology Security Evaluation, Version 3.1. The COACT, Inc. CAFE Lab determined that the evaluation assurance level (EAL) for McAfee Corporation’s McAfee Policy Auditor 5.2 and ePolicy Orchestrator 4.5 products are EAL 2 + ALC_FLR.2. The TOE, configured as specified in the installation guide, satisfies all of the security functional requirements stated in the Security Target, version 2.0.2, dated February 2, 2011.
\r\nA Validator on behalf of the CCEVS Validation Body monitored the evaluation carried out by the COACT, Inc. CAFE Lab. The evaluation was completed in December 2010. Results of the evaluation and associated validation can be found in the Common Criteria Evaluation and Validation Scheme Validation Report.
","environmental_strengths":"The TOE’s Security Functions are:
\r\nPolicy Audits
\r\nThe TOE evaluates the status of managed systems relative to audits that contain benchmarks. Benchmarks contain rules that describe the desired state of a managed system. Benchmarks are received through or imported into McAfee Benchmark Editor and, once activated, can be used by Policy Auditor. Benchmarks are written in the open-source XML standard formats Extensible Configuration Checklist Description Format (XCCDF) and the Open Vulnerability Assessment Language (OVAL). XCCDF describes what to check while OVAL specifies how to perform the check.
\r\nIdentification and Authentication (I&A)
\r\nUsers must log in to ePO with a valid user name and password supplied via a GUI before any access is granted by the TOE to TOE functions or data. When the credentials are presented by the user, ePO determines if the user name is defined and enabled. If not, the login process is terminated and the login GUI is redisplayed.
\r\nThe supplied password is passed to Windows for validation. If it is successful, the TOE grants access to additional TOE functionality. If the validation is not successful, the login GUI is redisplayed. Note that all the Windows I&A protection mechanisms (e.g., account lock after multiple consecutive login failures) that may be configured still apply since Windows applies those constraints when performing the validation.
\r\nUpon successful login, the Global Administrator status and the union of all the permissions from the permission sets from the user account configuration are bound to the session. Those attributes remain fixed for the duration of the session (until the user logs off). If the attributes for a logged in user are changed, those changes will not be bound to a session until the next login by the user.
\r\nManagement
\r\nThe TOE’s Management Security Function provides administrator support functionality that enables a user to configure and manage TOE components. Management of the TOE may be performed via the ePO GUI. Management permissions are defined per-user.
\r\nThe TOE provides functionality to manage the following:
\r\nA) ePO User Accounts,
\r\nB) Permission Sets,
\r\nC) Audit Log,
\r\nD) Event Log,
\r\nE) Notifications,
\r\nF) Event Filtering,
\r\nG) System Tree,
\r\nH) Tags,
\r\nI) Product Policies,
\r\nJ) Queries,
\r\nK) Dashboards,
\r\nL) Benchmarks,
\r\nM) Policy Auditor,
\r\nN) Policy Audits, and
\r\nO) Waivers
\r\nAudit
\r\nThe Audit Log maintains a record of ePO user actions. The auditable events are specified in the Audit Events and Details table in the FAU_GEN.1 section of the Security Target.
\r\nThe Audit Log entries display in a sortable table. For added flexibility, you can also filter the log so that it only displays failed actions, or only entries that are within a certain age. The Audit Log displays seven columns:
\r\nA) Action — The name of the action the ePO user attempted.
\r\nB) Completion Time — The time the action finished.
\r\nC) Details — More information about the action.
\r\nD) Priority — Importance of the action.
\r\nE) Start Time — The time the action was initiated.
\r\nF) Success — Specifies whether the action was successfully completed.
\r\nG) User Name — User name of the logged-on user account that was used to take the action.
\r\nAudit Log entries can be queried by a Global Administrator or users with the “View Audit Log” permission. The Audit Log entries are automatically purged based upon a Global Administrator-configured age. Other than automatic purging, no mechanisms are provided for users to modify or delete entries. The audit log entries are stored in the database; if space is exhausted, new entries are discarded.
\r\nSystem Information Import
\r\nePO offers integration with both Active Directory and NT domains as a source for systems, and even (in the case of Active Directory) as a source for the structure of the System Tree.
\r\nIf your network runs Active Directory, you can use Active Directory synchronization to create, populate, and maintain part or all of the System Tree with Active Directory synchronization. Once defined, the System Tree is updated with any new systems (and subcontainers) in your Active Directory.
\r\nThere are two types of Active Directory synchronization (systems only and systems and structure). Which one you use depends on the level of integration you want with Active Directory.
\r\nWith each type, you control the synchronization by selecting whether to:
\r\nA) Deploy agents automatically to systems new to ePolicy Orchestrator.
\r\nB) Delete systems from ePolicy Orchestrator (and remove their agents) when they are deleted from Active Directory.
\r\nC) Prevent adding systems to the group if they exist elsewhere in the System Tree.
\r\nD) Exclude certain Active Directory containers from the synchronization. These containers and their systems are ignored during synchronization.
\r\nePO may also use your NT domains as a source for populating your System Tree. When you synchronize a group to an NT domain, all systems from the domain are put in the group as a flat list. You can manage those systems in a single group, or you can create subgroups for more granular organizational needs.
\r\nWhen systems are imported, their placement in the System Tree may be automatically determined by criteria-based sorting of two forms; a) IP address sorting may be used if IP address organization coincides with your management needs for the System Tree, or b) Tag based sorting may be used to sort systems based on tags associated with them.
\r\nThe server has three modes for criteria-based sorting:
\r\nA) Disable System Tree sorting
\r\nB) Sort systems on each agent-server communication — Systems are sorted again at each agent-server communication. When you change sorting criteria on groups, systems move to the new group at their next agent-server communication.
\r\nC) Sort systems once — Systems are sorted at the next agent-server communication and marked to never be sorted again.
\r\n","features":[]}