{"product_id":10416,"v_id":10416,"product_name":"CA ACF2 r14 SP1 for z/OS","certification_status":"Not Certified","certification_date":"2011-04-04T00:04:00Z","tech_type":"Enterprise Security Management","vendor_id":{"name":"CA Technologies","website":"www.ca.com"},"vendor_poc":"William Clark","vendor_phone":"703-708-3501","vendor_email":"william.clark@ca.com","assigned_lab":{"cctl_name":"Booz Allen Hamilton Common Criteria Testing Laboratory"},"product_description":"<p>The Security Target (ST) defines the Information Technology (IT) security requirements for CA ACF2&trade; for z/OS (CA ACF2). CA ACF2 delivers access control capabilities for z/OS systems and includes interfaces for CICS, TSO, and IMS. CA ACF2 allows administrators to control user access to protected mainframe resources such as datasets and volumes. CA ACF2 controls access to the system and its own data through the use of policies and privileges that limit how and when a user or administrator can access the system and what they can do once they are authenticated. Administrators can be given authority over various segments of the system through the use of scope records.</p>","evaluation_configuration":"<p>Several different models were used in the evaluated configuration. All contained the same security functionality and the only differences were in throughput. They are enumerated as follows:</p>\r\n<p>The following requirements are defined for the evaluated configuration:</p>\r\n<ul>\r\n<li>CA ACF2 running in ABORT mode</li>\r\n<li>z/OS 1.11</li>\r\n<li>CICS CTS 3.2</li>\r\n<li>IMS 10</li>\r\n<li>CA LDAP Server r14</li>\r\n</ul>\r\n<p>The following system characteristics represent the tested configuration:</p>\r\n<ul>\r\n<li>IBM Model 2097</li>\r\n<li>384MB virtual memory</li>\r\n<li>~15,000 cylinders of Direct Access Storage Devices (DASD)</li>\r\n</ul>","security_evaluation_summary":"<p>The evaluation was carried out in accordance with the Common Criteria Evaluation and Validation Scheme (CCEVS) processes and procedures. CA ACF2 r14 SP1 for z/OS 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 EAL4 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 March 2011.</p>","environmental_strengths":"<p><strong><em>User Data Protection</em></strong></p>\r\n<p>CA ACF2 determines whether an individual user or administrator can be permitted access to a resource. Users and administrators cannot perform any action on a CA ACF2 controlled system unless they can first be identified and are then authorized access by CA ACF2. Therefore, CA ACF2 is protecting the resources of the computer system.</p>\r\n<p>&nbsp;</p>\r\n<p>CA ACF2 performs two main methods of access control, one being mandatory access control (MAC) and the other being discretionary access control (DAC).</p>\r\n<p>&nbsp;</p>\r\n<p>MAC imposes a security policy based on security labels. Security labels classify users, data, and resources.&nbsp; Standard access rules of z/OS and permissions still apply as well as those configured by CA ACF2 regarding passwords and other authentication methods, but only after MAC label dominance checks determine that a user can access data and resources based on their security label and the security label of the data or resources the user wants to access.</p>\r\n<p>&nbsp;</p>\r\n<p>DAC security policy manages the controlled sharing of data and resources using rules. Depending on an implementation option, a Security Administrator, Scoped Security Administrator, or the user which is the rule owner can write rules to permit operations on that resource. If a user or administrator tries to access data without permission, the system creates a violation audit record and denies access.</p>\r\n<p>&nbsp;</p>\r\n<p>When CA ACF2 locates the rule set, it interprets the rules to locate one that matches the environment that currently exists. If no rule matches the environment, CA ACF2 denies access to the resource.&nbsp; On the other hand, after CA ACF2 locates a rule that matches the current environment, it compares the access request against privileges, User ID (and UID or role) and scope of the user/administrator as specified in that rule. In accordance with what the rule specified for these permissions, CA ACF2:</p>\r\n<ul>\r\n<li>Grants the access and does not audit the event</li>\r\n<li>Grants the access and writes an informational audit entry</li>\r\n<li>Prevents the access and writes a &ldquo;violation attempt&rdquo; audit entry</li>\r\n</ul>\r\n<p><strong><em>Security Audit</em></strong><strong><em></em></strong></p>\r\n<p>CA ACF2 creates and maintains audit records for all security-relevant events on objects which it protects, such as system entry, data access, and resource access. CA ACF2 writes information in the audit records depending on the event that generated that audit record.&nbsp; Some of the information that is included in the audit record is the user&rsquo;s identifier and the object identifier that the user attempted to access.</p>\r\n<p>&nbsp;</p>\r\n<p>CA ACF2 uses the System Management Facility (SMF) to record all security-relevant events. These records are secured from accidental disclosure or destruction by CA ACF2&rsquo;s access control (DAC and MAC policies) protection mechanisms. CA ACF2 provides authorized users and administrators with the ability to produce reports on a wide range of events. For example, the ACFRPTPW report provides an audit trail of system entry events. A variety of parameters can be set to customize the reports to display the violations by a particular type or by a group of users.&nbsp;</p>\r\n<p><strong><em>Identification and Authentication</em></strong><strong><em></em></strong></p>\r\n<p>CA ACF2 controls how, when, and which resources a user or administrator can access.&nbsp; CA ACF2 requires that each user and administrator have a valid User ID and authenticate utilizing the necessary mechanism (i.e. password verification, passphrase verification, digital certificate verification, passticket verification, Kerberos authentication) before entering the system.&nbsp; CA ACF2 also tracks failed authentication attempts. If the threshold for failed authentication attempts is exceeded, CA ACF2 will suspend the user or administrator account from being able to authenticate.</p>\r\n<p>&nbsp;</p>\r\n<p>By default, CA ACF2 requires that all User IDs are password protected. The security administrator which created the user or administrator assigns the first password. The user or administrator associated with the User ID will then change the password immediately or later when it expires.&nbsp; CA ACF2 will also enforce the requirement that the user or administrator create a password which is consistent with a password policy (e.g., minimum length, complexity).&nbsp; The additional authentication mechanisms are set to none by default and require an administrator to configure the authentication applications to utilize these mechanisms.&nbsp; CA ACF2 will enforce the use of these authentication mechanisms when a user or administrator has been configured to use one of the additional mechanisms.&nbsp; In addition to the enforcement of a password policy, when passphrases are used, the CA ACF2 requires a user or administrator to create a passphrase which meets a passphrase policy.</p>\r\n<p><strong><em>Security Management</em></strong><strong><em></em></strong></p>\r\n<p>CA ACF2 maintains three roles: security administrators, scoped security administrator, and users.&nbsp; Administrators manage CA ACF2 and its users/administrators; whereas a user&rsquo;s primary ability is to manage their own password and resources as well as those that are scoped to them.&nbsp; These users/administrators can access CA ACF2 locally through the Console Address Space or remotely through the Application Process.&nbsp; Along with the roles, privileges exist that affect what functions a user or administrator may perform or what a user or administrator can access.&nbsp; These privileges include AUDIT, SECURITY, LEADER, CONSULT, and ACCOUNT.</p>\r\n<p>&nbsp;</p>\r\n<p>The SECURITY, ACCOUNT, and AUDIT privileges are the most commonly used in reference to being assigned to the users and administrators.&nbsp; An administrator has the SECURITY privilege assigned to their User ID record.&nbsp; This privilege will allow the administrator to perform management actions and view audit records within their scope.&nbsp; Any administrator with ACCOUNT administrative authority can create users/administrators.&nbsp; On the other hand, either a user or administrator can have the AUDIT privilege defined in their User ID record.&nbsp; This allows the user or administrator to display any audit record, and and thus be considered to be an auditor.</p>\r\n<p><strong><em>TOE Access</em></strong><strong><em></em></strong></p>\r\n<p>CA ACF2 is capable of denying access to users and administrators based on the following conditions:</p>\r\n<ol>\r\n<li>They have been suspended</li>\r\n<li>They fail to enter a correct User ID/authentication credential</li>\r\n<li>They request to authenticate when a policy denies their access. Policies can be based on time/date of entry, source or entry, and/or APPLID used for entry.</li>\r\n</ol>","features":[]}