Performing an audit of the application security access request handling and the recertification processes
Part 1 of 2
By: Mitchell H. Levine, CISA - Audit Serve, Inc.
When performing an audit of application security the primary focus is whether the security design provides sufficient granularity of security to support separation of duties.
At an application level, the security access controls to resources are typically at a menu screen or transaction level. These menu screens or transactions could be further restricted based on read-only or update functions. To provide additional granularity of security, field level security could be used. In addition, since individuals may not require access to use the menu screens which impacts all data records, additional limitation can be configured to restrict access to specific records based on criteria established using additional fields (e.g., restrict users which can impact data based on a specific region).
The review to determine whether application security provides a sufficient level of granularity of access needs to be performed as part of an integrated audit since an understanding of roles and responsibilities and the operation functions is necessary. This level of review is typically not possible when performing an IT general controls audit since an understanding of the business operation is necessary.
This two-part article will provided insights on the required controls within the application security request handling and security access recertification area. These two areas need to be reviewed together since the security components being requested are the same components which need to be re-evaluated.
Performing an Audit of Security Access Recertification
Security Access Recertification consists of determining whether (1) resource roles or profiles are assigned to the appropriate individuals based on the requirements of their job function (referred to user access recertification) and (2) determining whether the resource roles continue to be mapped to the individual access components which fosters the required separation of duties (referred to resource role recertification). The user access recertification is also used as a backup control to ensure that user access is removed when they are terminated and to ensure that user access is reassessed when they change job functions.
A case could be made that user access recertification is not required if there are strong controls in the security request handling process since it is assumed that the access should remain the same. However, most organizations do not have the controls necessary to ensure that access remains the same. Alternatively, many organizations do not have a mature security request handling process which ensures that the approver understands the exact system access which is being provided to an individual user. In this case, the security access recertification process is being relied upon to have a focused review of all user access.
The following controls and security access design approaches would be necessary in order for organizations to consider not requiring a security access recertification process:
1) Security Request handling process which ensures that resources access granted to individual users is based on the requirements of their job function
2) Audit Trails of the security changes which alters users access to resources which includes an independent review to ensure the changes are supported by an authorized security request
3) Effective processes to identify terminations and remove access in a timely basis
4) Effective processes to identify job transfers or overall changes within an individual’s job function
In addition, other factors could impact the need to perform a recertification which include:
- Overall complexity of the security design
- Frequency of the security changes
- Number of IDs which have application level access
When reviewing the security access recertification of user access one of the common design issues of this process is that all security access components which are available to be assigned to individual users are not included in the recertification process. Besides resource profiles, there could be privileges assigned which allow for additional levels of access. Assuming that there is security access listings available to identify these access levels assigned to individual users, the audit should assess whether they are presented in a simplistic manner which would allow individuals responsible for the review to perform an effective review.
Another common design issue with the recertification process is the assignment of the review function. The review could consist of the user’s manager performing the review but this would require an inventory maintained of the authorized reviewer for each individual user. Since a critical control is to obtain a positive acknowledgement of the review being performed by each assigned person, this distributed approach would require a massive tracking of access listings distributed to the appropriate reviewers and the collections of the results of their review. An alternative approach is to have assigned resource owners perform the review but a control process needs to be in place to ensure that these users understand the job requirements of these individuals although they do report to them. In addition, the control to ensure that job transfers are identified by these resource owners is a common inherent weakness when using this approach.
If a centralized approach is used whereby the reviewer authorizes the proper access, the question again is whether they have an understanding of the access requirements of all of the users. If the organization which utilizes the application is a central process with a limited number of users, a case could be made to use this approach.
This article will continue in the issue of Audit Vision which will cover resource role based recertification and security access request handling.
Copyright 2009, Audit Serve, Inc. All rights reserved. Reproduction, which includes links from other Web sites, is prohibited except by permission in writing.