Previous | Table of Contents | Next |
Invalid Identification Code Rejected
If the security administrator sets the security software to reject an invalid end-user identification code, the rejection will probably require other settings to be established. These settings may include, but are not limited to, one or more of the following:
There is no discussion of the situation when the system would either accept or reject an invalid password in a two-level sign-on environment. The reason is that if the end-user identification code is accepted when invalid, the password is invalid by default and there is no issue. In addition, consider the situation in which the end-user identification code is verified against the security file but the password is not validated. That is effectively a single-level sign-on environment, which has been previously discussed.
Limit on Unsuccessful Attempts. The security software may have the capability to track unsuccessful log-in attempts. This feature is designed to detect potential attempts to gain unauthorized access in which the unauthorized access is based on password guessing. If the number of attempted sign-ons reaches the threshold value in the security software, the system will respond.
The system response in a two-level sign-on environment can be based on either the end-user identification code or the device identification, unlike the single-level sign-on environment, which can only be associated with the device. In the two-level environment, anyone attempting to gain unauthorized access to the system would be using the same end-user identification code with different passwords.
System Responses Associated with the Device. The system typically has two options for a device: locking it out temporarily or locking it out permanently.
Locking the device out temporarily has the effect of delaying the person or program attempting to access the system without completely blocking an authorized user who is only having trouble logging onto the system properly. The temporary response is more appropriate in situations in which personnel may be working on a second or third shift, or on the weekend, when no one may be present in operations. The end user can continue trying to sign on to the system without having to go to another area or take some other potentially inefficient alternative.
The security administrator may choose to establish a permanent lockout of the device for those situations in which security considerations require a more definitive response, or in which someone is present to reset a device for the end user who accidentally disabled the device through unsuccessful access attempts.
System Responses Associated with the End User. The security software will usually have two alternatives for the end user: temporarily or permanently blocking access to the indicated end-user identification code:
If the security software permits setting exception rules for a particular purpose, the IT auditor has to ensure that the exceptions established are reasonable and proper. This includes determining if the systems professionals have established settings for themselves that are less stringent than those for the general population. If that is the case, the auditor has to note this fact, although there is the ongoing risk that the less stringent rules will be reestablished at any time after the audit is completed.
The IT auditor, in this circumstance, has to determine the extent of managements concern. If management chooses not to be concerned about this situation, there is little the auditor can do, because it is not practical for the IT auditor to monitor the situation continuously. If management chooses to be interested, the auditor may be able to show them the procedures involved to monitor the situation themselves on at least a random basis.
Notification. The security software should include at least one feature that provides for the notification of the system operator, security administrator, security guard, third-party security service, or other party responsible for monitoring activity at the covered location. The notification could be as simple as an indicator that there had been a violation without specification. It could also be complex, providing detailed information about the violation, the location, time, and user identification code.
Multiple Sign-on Requirements
The continuing technology penetration into business methods has led to an increasing percentage of end users having to keep track of two, three, or more user identification codes and associated passwords. Each system has its own rules, potentially different password expiration periods, and password syntax. In these situations, it is common for end users to record all of their identification codes and passwords.
Writing down identification codes and passwords should be a violation of company security policy, although the risk exposure comes not from recording the information but from deciding where to keep that information. If the enterprise could be assured that the information would be with the end user at all times, the risk is considerably different than if the information is kept in the end users work area or desk, or taped to his or her monitor or terminal.
Single Sign-on
In response to this situation, there has been a new development in access technology referred to as single sign-on. Under single sign-on technology, the end user has only to remember one end-user identification code and password. Two types of single sign-on technology are available to most enterprises:
One common problem for this type of application arises when the actual access security routine asks for a new password from the end user. In this situation, the front-end program will present a screen to the end user that is identical in appearance to the screen that would normally be presented by the true access security software. The end user completes the screen; then the front-end program both passes the new password through to the underlying security software so that the new password is set and also records the new password so that it may accurately perform the sign-on process the next time the end user needs to access the system involved in the processing previously described.
Previous | Table of Contents | Next |