Hardening access-control rules

Assuming you are using LDAP-based security with Enterprise Server through the External Security Facility (ESF) and the MLDAP ESM Module, or file-based security through the VSAM ESM Module, access to various resources — programs, data files, CICS queues, and so forth — from application programs running in Enterprise Server is controlled by resource rules stored in the LDAP repository. Similar rules restrict access to administration functions under ESCWA, system services invoked by command-line utilities such as casout, and so forth.

A set of sample rules is provided with Enterprise Server in the form of LDAP Data Interchange Format (LDIF) files such as es_default_ldap.ldf, and in YAML format as es_default_security.yaml, for use with the VSAM ESM Module. For LDAP, there are a number of LDIF files to accommodate variations in repository structure, LDAP object types, and syntax among LDAP servers and configurations. You can import these rules into your LDAP repositories or use them as a basis for creating your own security configuration. For file-based security, you can customize es_default_security.yaml to suit your needs.

Many of the rules are unnecessary, inappropriate, or too permissive for most production enterprise server instances. As discussed in Removing unnecessary configuration objects, Micro Focus recommends removing rules for sample applications and some unused features.

For the rules that remain, you should review and consider tightening the permissions. In some cases that might involve adding additional permissions to the rules for some resources so that a group of users can be granted access only to those resources, rather than membership in a generally privileged group such as SYSADM. For example, an organization might create a group with permission to use some CICS system transactions such as CINS, but not others such as CFLE; that could be achieved by adding an Access Control Entry (ACE) to the rule for CINS.

About access-control rules

With the MLDAP ESM Module and VSAM ESM Module, access to Enterprise Server resources is controlled by Access Control Lists (ACL) in determining rules. Rules are grouped into classes which correspond to particular types of resources: data files, programs, CICS transactions, administration commands, and so forth. Each rule has a name, which can contain wildcard characters.

When Enterprise Server needs to authorize a user for a particular operation (read, update, and so forth) on a particular resource, it queries ESF, passing the resource class and name, the user information, and the requested level of access. In ESF, the ESM Module will find all rules in the given class with names which match the resource name; because rule names can contain wildcards, there might be multiple matches. The module examines each of these rules from the closest match to the most general one, until it finds a rule with an ACL that applies to the user, explicitly or through group membership. That rule becomes the determining rule which grants or denies the action.

ACLs contain one or more Access Control Entries, or ACEs, each of which allows or denies a permission level or set of permissions to an actor, which is the name of a user or group, possibly specified with wildcards, so an ACE can apply to multiple users or groups. The interactions between user and group ACEs, and allow and deny ACEs, and the case where multiple ACEs apply to a given request, can be complex and are discussed at more length in the product documentation. Broadly speaking, more-specific ACEs override less-specific ones; user ACEs override group ACEs; and deny ACEs override allow ACEs. In most cases, the result of the ACE and ACL processing algorithm is what an administrator would expect, following the "principle of least surprise".

Access-control rules can be hardened by ensuring their ACLs do not grant excessive permission to any users. Sometimes this might involve changing the permissions granted by a part of the ACL; in other cases, it might be achieved by adding ACEs or changing them to refer to different actors (usually groups) created to give only certain users a type of access.

Group structure

For most organizations, few or no ACEs refer to individual users. Assigning permissions at the granularity of users does not scale and makes it difficult to reassign responsibilities. Aside from generic rules which refer to all users with a wildcard (for example, allow:*:none), most ACEs will refer to groups.

There are many ways to organize users into groups for the purpose of resource access control. Groups might represent user roles; projects, departments, or functional areas; or simply sets of resource-access assignments. Micro Focus does not recommend any particular interpretation of user groups. Keep in mind that a clear, well-documented group structure will make it easier to assign and audit permissions.

The MLDAP ESM Module has a number of options for group structure, including nested groups and features for using different types of group objects. The VSAM ESM Module also supports nested groups. See your product Help for more information.

Principle of least privilege

In security, the principle of least privilege states that actors, such as users, groups, and applications, should be given the minimum set of privileges they require. While this can be difficult to achieve completely, here are some guidelines to help administrators move toward this goal:

Use generic rules to deny access by default: A rule with the name ** and the ACL deny:*:all in a resource class will match all requests if there is not a more-specific rule, and deny access. This avoids any issues if an attacker is able to specify a resource name not covered by your specific rules.
Note: These rules will prevent the Allow unknown resources security option from taking effect, since no resources will be unknown. As a minimum, they will all be covered by the generic rule.
Organize resources in ways that make it easy to use wildcard rules: If your cataloged datasets follow a well-documented hierarchy of qualifiers, it is easier to create an accurate set of rules and validate them against your policies. For example, if everything below the top-level qualifier SYS. should only be writable by members of the SYSADM group, you can create a rule in the DATASET class named SYS.** with the ACL allow:SYSADM group:alter; deny:*:update and know that except where overridden by more-specific rules, that will implement the desired policy. In general, following naming conventions that are parallel to security policies where possible will reduce the number of rules that need to be created, maintained, and vetted.
Err on the side of restriction: It is better to make rules too restrictive and subsequently have to relax them, than to make them too permissive initially. Trying to remove permissions after users have adopted habits or applications have been deployed can cause many problems, and often excessive permissions never get revoked.
Strive for rules which are simple and clear: Another important concept in security is the principle of least surprise, this states that a system which is difficult to perceive, understand, and reason about is more likely to contain vulnerabilities. It is important that you are able to read the security rules and understand their intent. Try to avoid special-case rules and conflicting rules which require understanding how Security Managers prioritize and resolve conflicts.

As a rule of thumb, restrict access to resources and then grant it according to specific requirements. In addition to making the security configuration more secure, it will lead to documenting access requirements and their justifications.

General recommendations

Micro Focus recommends the following for hardening access-control rules:

Remove permissions for unused features, or restrict them to privileged users such as system administrators.
Note: The sample rules provided with Enterprise Server include many sample and demonstration resources which should be removed, particularly from production environments.
Ensure features for tracing, debugging, querying system information, and so on, are restricted to users with a legitimate need for it. Depending on the resource, system type (for example, production or development), and other factors, that might mean only system administrators, or also operators or developers.
Make rule names and ACLs as general as possible to achieve a given security requirement.
Apply ACEs to groups, not individual users. Create groups that represent something meaningful for your organization.
Consider using advanced features if they address a security requirement. For example, the username-substitution feature of the MLDAP ESM Module lets you easily give each user access to their own dataset "namespace". When this feature is enabled, you can create two rules in the DATASET class like this:

USERS.**

deny:*:all

USERS.${user}.**

allow:*:alter

Because the second rule only applies to a top-level dataset qualifier of USERS followed by the user's ID as a second qualifier, each user will only have access to their own datasets under the USERS area. For example, the user ALICE would have access to everything under USERS.ALICE.

Finally, Micro Focus recommends periodically reviewing access rules to determine whether any should be tightened or removed.