Bit9, Inc. Parity™ Version 6.0.1 is a policy-driven whitelisting solution for restricting the execution of applications and devices that runs on Windows PCs. Whitelisting technology allows end-users to install and run legitimate software and devices while providing IT groups with a way to prohibit anything unauthorized or known to be malicious from executing. The end result is granular control of Windows computers, dramatically improving security, preventing software drift, and managing the flow of information to portable storage devices.
\r\nParity’s management capabilities track portable executable (PE) and script files and monitor their prevalence and execution. Unidentified files that have just appeared on the network receive a pending status. A file keeps its pending status until it becomes approved or banned. A pending file also can be acknowledged, which removes it from the list of new pending files but does not change its underlying pending status. Once a file is approved, it is allowed to execute on all systems but continues to be tracked.
\r\nAfter a network is under Parity control, Administrators approve new applications or patches using the approval methods that best suit their organization’s software rollout procedures. Parity features several automatic approval methods (trusted directory, trusted publisher, trusted user, and trusted updaters) that make it easy to approve new software without having to do it file-by-file.
","evaluation_configuration":"The TOE was evaluated on the following platforms:
\r\nParity Application Server v6.0.1
\r\nThe items below are to address the recommendations for the differences in Parity Client Loads. Items with a (1) are for less than 300 Parity Clients, items with a (2) are for 300 to 50000 Parity Clients, and items without a number apply to both.
\r\n(1) Dual Core Server Class
\r\n(2) Dual Core or Dual Processor Server Class
\r\n(1) 40 GB
\r\n(2) 2 drives: 40GB for Parity, 72GB for SQL
\r\n(1) 2-4 GB
\r\n(2) 4 GB
\r\n(1) 1 GB NIC
\r\n(2) 1 GB NIC
\r\n\r\n
Parity Application v6.0.1 Server Virtualization
\r\nTo run VMware ESX Server v.4.0+ to create a virtualized environment for Parity:
\r\nThe hardware requirements for the machine hosting the virtual environment should allow the virtual environment to be capable of the same level of performance as a hardware based installation.
\r\n\r\n
Parity Client v6.0.1
\r\nThe items below are to address the recommendations for all Parity Clients.
\r\nNote: The ‘Evaluated Configuration for Bit9 Parity 6.0.1’ document must be referenced to place the product within the CC evaluated configuration.
","security_evaluation_summary":"The evaluation was carried out in accordance with the Common Criteria Evaluation and Validation Scheme (CCEVS) processes and procedures. Bit9 Parity was evaluated against the criteria contained in the Common Criteria for Information Technology Security Evaluation, Version 3.1 Revision 3. The evaluation methodology used by the evaluation team to conduct the evaluation is the Common Methodology for Information Technology Security Evaluation, Version 3.1 Revision 3. It has been determined that the product meets the security criteria in the Security Target, which specifies an assurance level of EAL2 augmented with ALC_FLR.1 and ASE_TSS.2. Validators, on behalf of the CCEVS Validation Body, monitored the evaluation. The evaluation was completed in February 2011.
","environmental_strengths":"User Data Protection
\r\nThe primary purpose of the TOE is to enforce access control policies against distributed Windows PCs. Subjects who access these PCs are known as Client Users. These access control policies are centrally defined on the Parity Server and distributed to systems in an enterprise. The policies are subsequently enforced by an instance of the Parity Client which resides on each system. The effect of applying these access control policies is known as “enterprise whitelisting”. Whitelisting marks various specific files, processes, registry values, and removable media devices as authorized to be modified. The specific notion of enterprise whitelisting refers to the fact that individual users and computers in an enterprise can have different policies enforced upon them based on organizationally maintained Active Directory information.
\r\nPolicies also contain a value called a SecCon, which is short for “security condition”. The SecCon value of a policy determines what actions to take when an operation is performed on a system which is not whitelisted. For example, under the most restrictive setting, actions which are not whitelisted are forbidden outright. Another setting warns the subject that they are performing an action which has not been approved and gives them an option to proceed or abort using a dialog box.
\r\nThe Parity Server, which is where policies are defined and distributed, maintains its own role-based access control policy. Subjects which can access the Parity Server are called Console Users and can be assigned one of three specific roles: Administrator, PowerUser, and ReadOnly. Each of these roles confers a fixed set of privileges on the subject. This ensures that only trusted subjects are able to configure the TOE’s behavior.
\r\nSecurity Management
\r\nThere are four default roles for the TOE: Administrators, PowerUsers, ReadOnly, and Client Users. Administrators, PowerUsers, and ReadOnly are all types of Console Users. The role given to a user determines what operations or management functions they can perform on the TOE. Restrictions can be set on Client Users based on policy; permissions for Console Users are static.
\r\nThe major security management functions of the TOE are the ability to review audit data and the ability to configure how the client access control policy is enforced. Policy data is propagated to clients and stored internally. The Parity Console, as a web-based application, requires the use of an environmental DNS server if it is to be identified by a qualified domain or host name as opposed to an IP address.
\r\nIdentification and Authentication
\r\nThe TOE supports two types of users: Console Users and Client Users.
\r\nConsole Users manage the TOE remotely through a Web Browser. They are identified and authenticated with username and password. This authentication data can be maintained within the TSF, or Active Directory integration can be used to allow an existing organizational user to access the TOE using credentials maintained by the Operational Environment. If the Operational Environment is used, username/password validation will be done with LDAP.
\r\nClient Users access the TOE indirectly by using their own local machines upon which the Parity Client has been installed. Modifications to their machines are mediated by the TOE, but the TOE is invisible except for pop-up messages when an operation has been blocked. In the evaluated configuration, Client Users are identified by the user account they use to log in to their system, which is derived from Active Directory.
\r\nSecurity Audit
\r\nThe TOE collects, aggregates, and reports on IT activity and generates alerts when file/device information changes. “IT activity” refers the content and behavior of systems that reside in the operational environment. Auditing functions are performed by the TOE by collecting the logs via agents and servers, using a database in the operational environment to store the logs over an established timeframe, and presenting the logs via reports and queries. In addition, the TOE generates audit reports for its own startup and shutdown and all user actions on the TOE. Authorized users are able to select the notification mechanism for all auditable events. The TOE monitors these for events and notifies (alerts) users when a predefined condition is met. Alerts can be sent via email, which requires mediation by an environmental SMTP server. The TOE relies on the host operating system to provide reliable timestamps for audit records.
\r\nEncrypted Communications
\r\nRemote users establish a session with the Parity Server using a web-based GUI that is secured via HTTPS. Cryptography for this is provided by the environmental web server and Operating System. This secured path is used for user authentication and management of the TOE by authorized users. The Operational Environment generates cryptographic keys during communication with remote users, the ODBC client, and Active Directory. This is accomplished by the TOE requesting that these environmental components use their native cryptographic facilities. All communications between the Parity Server and Parity Clients and between the Parity Server and the GSR are protected using imported certificates.
\r\nThe only cryptographic function provided by the TSF is the ability to hash files for the purpose of access control checking.
\r\nThe cryptography used in this product has not been FIPS-certified, nor has it been analyzed or tested to conform to cryptographic standards during this evaluation. All cryptography has only been asserted as tested by the vendor.
\r\nTOE Access
\r\nBefore a session begins, a warning will be displayed alerting the Console User that unauthorized access to the TOE is prohibited.
","features":[]}