Previous | Table of Contents | Next |
Controls over logical access security should ensure that all programs and data stored on computer systems are protected from unauthorized access and execution. It is a business decision as to the level of security implemented and to what extent that security will either compensate for or eliminate in terms of logical access risks. The two most fundamental logical access control objectives are that:
Subsequent to adopting these two fundamental objectives, the enterprise should determine which levels of access should be controlled. Logical access controls may be able to control access at one or more of the following levels:
The access to system resources can also be managed based on the type of access. Depending on the situation, this may supplement or replace other techniques. Access types include:
The majority of systems begin the sign-on process by requesting an identification code. The system will read the code and attempt to match that code against the security master files. Most systems will be configured to refuse access if that code cannot be matched against these files. The IT auditor should be aware that many systems have an operating condition where an unmatched code does not prevent access, and another where the unmatched code is added to the master file.
If a password requirement has been established, the matched user code acts as the link from the entered password to the stored password. The password would then be entered and matched just as the code had been. The same configuration issues discussed for the user code would also apply to the user password.
The IT auditor should assess the reliability of user identification codes in terms of meeting the appropriate control objectives. The IT auditors ability to assess this will partially rely on his or her understanding of the differences between a single-level sign-on process and a two-level sign-on process. The single-level sign-on process only requires a user identification code for both identification and authentication. A two-level sign-on process uses the end-user identification code, sometimes referred to as a user ID, for identification and the password to authenticate the identification.
Single-Level Sign-on Environment
In a single-level sign-on environment, it is critical that the user identification code not have any correlation to other information about the user. If the user identification code is the end users initials, or last name and first initial, it is extremely likely that one end user or a third party could guess the identification code of another end user, and successfully sign on to the system by using that other identification code.
The companys application software may provide logging capabilities that include capturing the user identification code with each transaction entered into the system. This logging is important if the enterprise values the ability to investigate application transactions and to know which end user is responsible for a particular transaction. The problem created by logging the user identification code in a single-level sign-on environment is that the logged code values must be accessible to be useful. If it is accessible, anyone having access to the logged codes has the ability to sign on using any of those other values.
Another drawback is associated with the usefulness of the logged code values. If the values are randomly or otherwise generated such that there is no association with the actual end user, anyone expected to review the transaction logs will have to have some access to information concerning which end user is associated with each code value. If this information is not available, it should not be possible for anyone reviewing transaction logs to ascertain which end user is identified by the logged code value.
Another issue in the single-level sign-on environment concerns the idea of period code value changes. If the user identification code values change periodically, the control objectives related to logging transactions and the associated end-user code are partially or fully compromised. If the codes never change, there is a significant risk that over time end users will accidentally or intentionally let their identification code become known to someone else, which effectively fully compromises the related control objectives.
The IT auditor will often be faced with situations in which the potential harm related to accidental or intentional events must be considered. The auditors problem is often determining whether something was done accidentally or intentionally. A well-designed system should reduce the risk of errors and, thus, facilitate the determination just described. Poorly designed systems will do just the opposite.
Two-Level Sign-on Environment
The two-level sign-on environment often employs a user identification code that is associated with end users, such as their initials, for the first level. The second level is the password, which should not be associated with the end user and should be kept private at all times. This approach supports transaction logging activities because the end-user identification code for a particular end user should not change, and anyone reviewing a transaction log should be able to identify the logged identification codes and quickly determine which end user to contact with questions.
The enterprises (and the auditors) ability to rely on the concept that a logged end-user identification code actually identifies the person responsible for a particular transaction or other event is critical, particularly in online environments in which end users may be responsible for entering some or all of their own transactions. The security features related to passwords in many systems are in place just to support the reliability of the user authentication process in a two-level sign-on environment.
Previous | Table of Contents | Next |