When performing a security review of an computer operating environment, auditors and security administrators are restricted in the methods available for establishing control processes based on how the operating system and security perform system processing.

The objective of ASSEC is to provide a method to evaluate the adequacy of security within a system. Assessing the security available within an environment is the basis for determining other mechanisms that must be established to provide an acceptable level of control desired by an installation.

Many computer security criterias have been introduced in the past, including the Department of Defense Trusted Computer System Evaluation Criteria which is published by the Department of Defense and is referred to as the "Orange Book". The Orange Book specifies the controls that are required to be provided by the security system and the controls that are required to be set by an installation (e.g., restrict read access to audits trails to the appropriate individuals). The Orange Book has not been totally embraced by the private sector because of its emphasis on

the confidentiality of data. The Orange Book also requires a great level of interpretation since the control requirements are written in generic terms. Within ASSEC, the evaluation criteria is presented at the lowest possible level, thereby eliminating the need for interpretation.

ASSEC can be used as a standard by operating system and security vendors to design security features within their systems/products. ASSEC can also be used by security professionals to assess the level of security provided by a system.

ASSEC consists of a set of security and processing functions that are typically found in most commercially available mainframe and minicomputer systems. It should be noted that ASSEC does not address application security or security features that are available in interconnected nodes.

Security Administration

The Security Administration category identifies the processes that are required to ensure that all security changes are made by the appropriate users and that facilities are available to establish secured signons.

System Access

The System Access category identifies the security controls that are required to prevent unauthorized access and processing from occurring.

Security System Integrity

The Security System Integrity category identifies the controls that are required to ensure that the security system cannot be circumvented.

Auditability

Audit Trail Integrity

The Audit Trail Integrity category identifies the processes that are required to maintain the integrity of the data used in the security review process.

In future articles of Audit Vision, specific operating environments and the level of security controls provided will be evaluated using ASSEC.

1) Access levels are available to distinguish between read, update, execute, and delete access to resources (e.g., data file, program library).

2) Userids can be established with a password change frequency.

This control could be a discretionary control that is enforceable by the installation.

This control could be a discretionary control that is enforceable by the installation.

Standard Protection

1) The administration of security entitlements is performed through front end process (i.e., screens).

Administering security entitlements through a front end process provides a mechanism for restricting the access to those individuals responsible for administering security changes and providing audit trails of the changes that are made. The alternate method which is used by systems that provide minimal security consists of a module which is directly edited and placed in a specific library called by the security system.

2) The security administration authority that is used to establish access entitlements and userids does not provide the security administrator the ability to access the resources.

The security administrator should be a separately assigned function which provides them with the ability to administer access entitlements on the system. However, since the security administrator is also the person responsible for coordinating the review of unauthorized access on the system, they themselves should be limited to the access that they have on the system.

3) Individual modules of a directory (i.e., dataset) can be restricted.

4) The ability to access resources can be restricted based on the execution of a specific program which resides in a specific library.

Providing the ability to restrict access to a resource through a specific program that resides in a specific library would prevent a user from performing unauthorized updates outside of the installation authorized program.

5) A password change frequency can be set on an individual userid level.

Sensitive userids should be required to change their password in more frequently then general users. If the same password change frequency is set at a global level for all users, then an installation may be apt to set a less stringent password change frequency in order not to inconvenience users with non-sensitive job functions.

6) Newly assigned passwords are automatically set to require the password to be changed when it is first used.

Passwords are assigned by security administrators when a userid is initially setup and when the security administrator changes the user’s password (i.e., typically after a user forgets their password).

When a user’s password is changed by the security administrator, the security administrator has knowledge of the password which enables them to use the userid without accountability for their actions. Therefore, the user should be required to change their password when the user logs onto the userid for the first time.

This control should be a mandatory requirement with no ability to disable this function. However, certain userids are assigned to functions that are not logged into by individual users. Although, passwords should not have to be assigned to these type of userids, if a password must be assigned, these userids should not be required to change their password.

7) Security administrators are restricted from viewing a users password.

8) Userids may be restricted from being used only at a specific time period.

This control could be a discretionary control whereby the installation defines the period in which userids can be used.

9) Userids can be suspended at an installation specified date and time.

This feature is most commonly used to establish temporary userids (e.g., emergency userids or IDs for temporary employees).

10) Access entitlements can be granted on a temporary basis.

This feature is most commonly used when emergency access is required to resources in order to resolve a problem.

11) A decentralized security administration function can be defined so that decentralized security administrators can only access entitlements for resources that are defined as being within their scope of responsibility.

12) The scope of authority is clearly defined within a decentralized security administration environment whereby installation security options cannot be changed by decentralized security administrators.

13) Security administrators have the ability to suspend userids.

The control is necessary when a user leaves the company.

14) Userids are suspended after an installation specified period of non-use.

Userids which are not actively used may potentially allow unauthorized users to gain access to them. This control could be a discretionary control whereby the installation sets the number of days of non-usage before a userid is suspended.

15) Users are not allowed to assign their access entitlements to other users.

In many instances, users mistakenly perform actions which suspend their userids during non-business hours when the security administrator is not available to reactivate their userids. Since, there may be a business need for the suspended user to perform a specific function, the operations area should be provided with the ability to reactivate userids. However, the scope of this security administration function should be limited to only reactivating userids and not other functions that affect the security within the system.

2) Separate authorities are available to establish use-rids, assign access entitlements, and to set global security settings (e.g., audited events) in order to establish a segregation of duties within the security administration job function.

3) Users are required to change their own passwords.

1) A userid and password combination is used to identify the user. In this way the userid determines the user’s access entitlements and the password authenticates the identity of the user.

2) Passwords not displayed on terminal in clear text.

3) All userids are forced to be established with a password.

The suspension of a userid should can be a discretionary control so that attempted unauthorized access attempts can be logged instead of suspending the userid.

4) Userids are suspended after an installation specified number of unauthorized logon attempts. In addition, terminals on which users are accessing the system should also be disabled from use.

The suspension of a userid should be a mandatory control.

5) Passwords must be created with a minimum of 6 characters in length.

6) Users are prevented from using the last 3 passwords that they used.

7) Passwords that are easy to guess can be defined by an installation to prevent their use when a password is constructed.

8) All userids are forced to be established with a password.

This control should be a mandatory requirement with no ability to disable this function. However, userids are assigned to certain processes (e.g., application assigned userid for security validation purposes) that are not logged into by individual users. For these userids, passwords should not have to be assigned. However a mechanism should be in place to prevent other users from using these userids.

9) A user active session is disabled after a period of 5 minutes of terminal inactivity and either logs off the user or places a terminal lock on the terminal (i.e., requires the user to re-enter their password in order to continue with their session).

The execution time of a submitted job should not be counted towards the period of inactivity. Terminal locking is not the preferred method since a userid will be active indefinitely until a user enters their password.

10) The access authority associated with a batch job is based on the user that submitted the job.

11) Users are prevented from hard coding another user’s userid (i.e., without a password) in order to initiate a job that runs under their authority unless they have specifically been permitted access by the security administrator.

12) Users can be restricted from accessing the system through a particular point of entry (e.g., RJE, local access, remote, batch, dial-up).

This control requires that remote submissions be identified and authenticated.

13) Users are notified of their last logon when they log onto the system.

This information can be used by the owner of the userid to determine whether their userid was used by an unauthorized individual.

The traditional approach of using passwords as the method for authenticating a user’s identity is not an acceptable control for this security level since it is common for users to disclose their passwords to other users who require a more privileged userid.

Requiring the owner of the userids to be physically present when attempting to access the system through the use of smart cards and other approaches provides greater assurance that the owner of the userid is actually the person using the userid.

2) Userids are suspended after an installation specified number unauthorized access attempts to resources.

The suspension of a userid should be a mandatory control.

System products (e.g., scheduling function) may perform privileged functions whereby they are provided privileged access. This can be used by individuals that are provided access to the process (e.g., product). It is important for the user of the product to be restricted to the access requirements of their job function which holds them accountable for all actions that they perform. This process would require the user to be uniquely identified within the system product to the security system. In addition, the functions performed by the system product on behalf of the user must be an identifiable unit of work which can be administered by the security system.

In order to achieve a high level of security, the system should not be available to users when the security system is not validating access to resources on the system. To implement such a control, the operating system would be required to detect the times when the security system is not active. An alternative approach is for the security system to monitor its active status without the security system being active on the system.

2) The tables used to specify a user’s access entitlements are not stored in a user’s address space that the user can alter.

In many environments, users who access the system for on-line editing services are provided their own address space to perform their tasks. Once they log onto the system, many environments build a table of information which identifies the user and the access entitlements that they have been assigned.

This should be a mandatory control which cannot be disabled by the installation.

3) All resources are protected by default whereby all users must be explicitly assigned access to a resource either individually or through a group that they have been assigned to.

There are many types of resources that require protection besides DASD volumes, data files, and program libraries. The resources that should require protection by default are tasks that invoke processing (e.g., commands issued, transactions initiated) but not methods of access (e.g., terminals printers) which should be protected based on the discretion of the installation.

4) Calls to the security system to perform security validation for a requested access to resources or return calls from the security system cannot be bypassed or changed by any user.

Most security systems are layered products which are not part of the direct code of the operating system. In such cases, an interface is constructed to process security calls which must be initiated by the operating system or a point of entry is provided for code to be executed to initiate a call for security validation.

In addition, after the security system has been called to initiate security validation, in many cases the security system itself provides an exit points prior and after security validation that enables an installation to insert code which bypasses security validation.

5) The operating system functional state which bypasses security validation does not provide an entry point (i.e., table) which allows installations to specify tasks which can bypass security, unless the table is controlled through an authority that is administered by the security administrator.

Many operating system environments have system programs which require complete access to all resources at the hardware and software level (i.e., open system log to write system events). Therefore, in order to perform its required functions it must be able to execute at a state which bypasses security validation. Since it is not practical to assign a userid to operating system tasks, its method of processing is at a level which would not be identified by the security system.

The concern of this security issue is the case which the operating system provides installations the ability to define tasks and programs which can also bypass security validation.

6)  Tape datasets and tape volumes are protected by default.

1) An audit trail (i.e., which can be viewed on-line or extracted via a report) is maintained of all accesses

(i.e., successful and unsuccessful attempts) to resources (e.g., dataset) which include the following types of information:

o all information mentioned in minimal and standard level protection

o resource being accessed (e.g., dataset)

o volume that resource being accessed resides on

o module being accessed (i.e., if module within library being accessed)

o user accessing the resource

o method used to access resource (e.g., program used)

o time and date of access type of access (e.g., read, update) device used to access resource (e.g., terminal ID used).

3) The following security definitions can be viewed online or extracted via a report without requiring security administration authority which provides for the administration of access entitlements:

o all information mentioned in minimal and standard level protection

o userids assigned with no passwords (i.e., if no preventive control available)

o userids that are not required to change their password (i.e., if no preventive control available)

o userids and/or terminals that are not subject to terminal timeout after a period of inactivity (i.e., if not set on a global level)

o terminals or devices that do not require a signon to initiate system processing-

1) Security audit trail files can be a protected resource and the system is able to update the audit trails automatically without requiring authorization or by being assigned a userid.

1) A notification is sent to an installation specifies individual or recorded on an alternate audit trail when the security audit trails are not active.

2) An audit trail is provided of the type of security events that are being suppressed (i.e., command issued to specify security events not to record).

1) The system is shut down when the security audit trail is not recording security events due to an individual specified shutdown or file corruption.

2) Mechanisms (i.e., commands) are not provided which suppress the recording of data.

3) Security audit trail data contained in buffers are automatically recovered during the recovery process when there is a system failure.

For a free proposal to perform an audit of your organization or provide SOX support & testing services, contact Mitchell Levine of Audit Serve at (203) 972-3567 or via e-mail at Levinemh@auditserve.com.