what

job title, keywords

where

city, state, zip

Guidelines for Reviewing the Appropriateness of User Access

By Denise Silon Louie, Protiviti Associate Director

	Web AuditNet

  

Companies in today’s market fight a constant battle trying to protect data internal to the organization and data provided by their customers.  Unfortunately, there are times when they lose this fight to internal and external culprits. The media is full of high-profile stories publicizing organizations that have recently experienced a security breach, leaving important data in the hands of the perpetrators.  The possible negative results grow exponentially and are very difficult to control once this unfortunate event has occurred. 

 

However, it is important to remember that these situations are preventable, or at least can be minimized, if companies take on the responsibility to regularly review the security of their IT systems. There are many aspects to an overall IT security review.  One key component is to review the appropriateness of user access.  In other words, are the active user accounts valid and do they reflect the user’s current job responsibilities?

 

This article outlines general risks, control objectives and best practices to consider when evaluating the overall appropriateness of user access security privileges.  An organization may find this article useful when developing guidelines for its own periodic review of user access. However, it will not cover the methods used to evaluate user access for a segregation of duties (SOD) conflict, which is a means to evaluate the various user access functions for internal control incompatibility.

 

A Pre-SOX Best Practice

Reviewing the appropriateness of user access privileges to information systems has been a generally accepted control objective in the IT security world long before the passing of the Sarbanes-Oxley Act (SOX) of 2002 in the United States.  Control Objectives for IT (COBIT) 4.0 even has dedicated a section to this topic:  “Deliver and Support (DS) Section 5:  Ensure System Security.”  Sections DS.5.3 and DS.5.4 are of particular interest for user access reviews.

 

DS 5.3:  User access rights to systems and data should be in line with defined and documented business needs and job requirements.

 

Regarding DS 5.3, ideally a user is granted access to information systems with a level of privilege consistent with their job responsibilities.  In other words, accounts payable clerks should have access privileges that are consistent with their duties in the accounts payable department.  However, they should not also have access to accounts receivable transactions if it is not within the scope of their duties, even if the privileges provided for accounts receivable do not pose a segregation of duties conflict.

 

DS 5.4:  Perform regular management review of all accounts and related privileges.

 

COBIT does not offer specific guidelines in DS 5.4 regarding the frequency of the review.  If management is implementing a security risk program for the first time, it may consider a review of access privileges for all information systems on a quarterly basis.  Given resource constraints within the security administration department—not to mention the impact such a review may have on the business owners of the system—this frequency may not be a feasible approach.  Many organizations limit the scope of their user access reviews to the applications and system software used specifically for financial reporting, thereby

 

 

 

significantly reducing the number or scope of systems reviewed.  While this is a feasible and practical approach, management should also consider a regular review of systems that pose a high operational risk to the organization—for example, a plant scheduling system (production risk) or external website (reputation risk).

 

Factors that Raise the Inherent Risk of Inappropriate User Access

Several factors are commonly used to evaluate the inherent risk of information system security administration.  An organization should evaluate its own information systems using these criteria and others as it sees fit.  The ultimate goal is to develop a user access review plan that considers manageable, measurable and meaningful criteria for the purpose of ranking the systems and user accounts according to risk.  An example list of factors that raise inherent risk follows.  Please note this list is not comprehensive or absolute and should be customized to fit the makeup of your organization.

 

1. Large numbers of users (i.e., employees, contractors, third-parties with access to company resources such as customers, suppliers, brokers, etc.).
   • Large is a relative term to the organization, and should be evaluated in light of the total number of employees or number of employees with access to information systems (i.e., knowledge workers).
2. Large numbers of non-employee users.
   • Many organizations have a strong process of internal control for tracking the hiring and termination of employees in order to properly manage the salary/wages paid to those individuals (i.e., a centralized HR function, a structured hierarchy of supervisors and approvals, etc.). 
   • In contrast, contractors and other third-party users of information systems are commonly engaged and managed by different departments with varying degrees of structure and control. 
   • Oftentimes, information security administration relies upon controls within the employee-centric payroll/HR process and is ill-equipped to handle the anomalies introduced when contractors and other third parties are provided access to information assets.
3. Turnover rate among user population.
   • Turnover rate can be measured as a percentage of overall user base, individually or in groups (i.e., the closing of a plant).
4. Frequent internal job changes among existing users.
   • A job change is an inherent change in job responsibilities.  Some organizations do not have a formal mechanism to monitor job changes, although a change in title as defined by the HR/payroll process is one metric that can be monitored.
   • Job changes are often characterized by a transition period—whereby the employee continues in the old role while assuming new responsibilities.  The auditor should consider these transition periods when evaluating the appropriateness of user access, but also recognize that a breach of internal control or segregation of duties can often arise under the circumstances.
5. Organizational change such as downsizing, expansion or re-organization (i.e., centralization or decentralization of functions such as accounting, legal and HR).
   • Changes in the size of (i.e., number of employees) or business processes executed by an organization can increase inherent risk regardless of the direction of change.
   • Downsizing (i.e., plant closings, consolidation of divisional headquarters into a single corporate headquarters, etc.) may result in terminated users who continue to have inappropriate access to information systems.
   • Downsizing may also cause users to assume more job responsibilities, thereby increasing the risk of inadequate segregation of duties. 
   • Business expansion may result in users continuing to have access responsibilities that are too broad given a new, narrower focus in their job responsibilities.

 

 

 

 

 

6. Large numbers of information systems available to user group.
   • Again, large is a relative term and, in this case, should be evaluated in light of the total number of systems in use at the organization.  The larger the number of systems in use, the more difficult and cumbersome it may be for the organization to administer security with consistency and maturity.
7. Decentralization of IT operations and/or security administration.
   • Organizations with differences in geography or organizational structure may operate with disparate security administration processes and suffer from inconsistently applied internal controls.
8. Outsourcing of IT operations and/or security administration.
   • Some organizations outsource due to lack of knowledge regarding good security administration practices and rely solely on the outsourcing organization to provide this expertise. However, outsourcing does not relieve the buying organization of responsibility for security.  Buyers that fail to define strong security administration controls/expectations in their outsourcing Service Level Agreement may be subject to increased risk.
9. Maturity of the inherent security administration features of the information systems in question.
   • In-house developed systems and purchased, niche software may lack robust security administration features, thereby increasing inherent risk.
   • ERP and other, current, purchased software typically contain more robust security administration features and reporting capability, thereby decreasing inherent risk.
10. User-based access rights vs. role-based access.
    • User-based access rights are customized for each user, thereby increasing inherent risk.
    • Role-based access is pre-defined by the organization to include access required for a given job responsibility, thereby decreasing inherent risk.
11. Frequent changes to defined roles, if role-based access is deployed.
    • Role-based security is often deployed to simplify user security administration.  Presumably the suite of capabilities that define a security role is more static than the number of roles a given user may perform at the company over a period of time. 
    • However, roles may change frequently if an organization experiences significant organizational change such as high growth or downsizing; the organization may experience increased risk if the impact of role changes on users is not thoroughly considered.
    • In some companies, roles change frequently because of lack of understanding of or appreciation for the intricate design of roles to meet SOD or other needs, resulting in increased security risk to the organization. 
12. Large numbers of roles assigned to users.
    • This metric can be difficult to track and is dependent upon how roles are defined.  If access roles are defined to mirror standard job responsibilities, then the greater the number of roles assigned to a user, the greater the inherent risk of inappropriate access as well as the likelihood of a breach in segregation of duties.
13. Broadly defined or poorly designed roles.
    • Related to the item immediately above, broadly defined roles may provide users with inappropriate access.
    • The auditor should take care to evaluate user access based upon the lowest level of access capability defined (i.e., menus, forms, fields, etc.) and not on the name of the role, which is often defined by the implementation team of the noted information systems.
14. Use of the information systems for financial reporting or other critical business operations (i.e., plant scheduling and production, external websites and company reputation.)
    • Financial reporting systems receive higher scrutiny among public companies due to their impact on internal controls over financial reporting (e.g., SOX compliance).
    • Highly visible or critical systems with operational impact may deserve the same level of scrutiny despite the lack of regulatory pressure to evaluate internal controls over user security.

 

 

 

 

 

15. SOX operating effectiveness deficiencies within the security administration process.
    • Failures in the user security administration process and its primary controls are a symptom of process immaturity or instability and may signal the need for more frequent user access reviews.  
16. High failure rates of the user access review process.
    • Management may want to define an acceptable failure rate for key systems, if not all systems, such that any user access review with a failure rate greater than five percent should be reviewed more frequently than is currently the case (i.e., quarterly versus semi-annual, semi-annual versus annual).
17. Older/end-of-life-cycle, or home-grown information systems.
    • Older systems and home-grown systems are more likely to operate without the robust security administration features often required in this post-SOX era.  Vendors usually discontinue support on old software releases. Enhancements to home-grown systems may be difficult to make given a lack of documentation or resources to program and thoroughly test the necessary changes.
18. High-risk data classification of information systems.
    • Systems containing data that are classified as intellectual property, confidential or restricted are subject to greater inherent risk.
19. Maturity of the user access administration (i.e., request) process.
    • Purely manual processes have a greater inherent risk than do processes with sophisticated, systematic and/or preventive controls such as automatic provisioning and de-provisioning.

 

Common Types of User Accounts

Questions often arise regarding which user accounts should be reviewed and how these user accounts differ.  Simply stated, two main types of information system access accounts exist:  administrator and user (sometimes referred to as end-user).  Because of the different roles these accounts fulfill, they should have different levels of access to properly segregate duties and restrict the number of people who hold administrator rights.

 

Administrator

Most packaged information systems come equipped with an administrator account—a user account that provides all system privileges and is necessary to install the system for the first time and perform subsequent maintenance.  This account is sometimes referred to as a service account and is used only for the purpose of installation and maintenance.

 

As the administrator account provides all access, it is often used to execute other high-access privileges such as administer access security; configure how the system works (including whether or not key internal controls will function); make programmatic changes; and override the transactions and functions performed by an end-user.  Oftentimes, the administrator account has access to modify or delete the log of user transactions on the system (i.e., the audit trail that tracks the transactions executed by a given user with a date/time stamp).  That said, the administrator may be able to modify transactions executed on the system and erase evidence of the account that performed these transactions.  The administrator account is often subject to frequent auditing and access reviews because administrator access privileges are so great.

 

Depending on the sophistication of security administration within and the size of the organization, the person within an organization who typically has access to this account is either a UNIX administrator, programmer/analyst in the IT department, security administrator, or a trusted, high-level business process manager.  Sometimes the many functions of an administrator account are unbundled into separate user accounts (i.e., programmer, security administrator, etc.). 

 

 

 

 

 

Super-user is a term often used interchangeably with administrator.  However, with the advent of Enterprise Resource Planning (ERP) systems, super-users can also describe an account that provides the user with menu-based configuration capability.  Configuration in ERPs such as SAP and Oracle is achieved via a user-friendly interface (i.e., application menus, screens and/or forms) to enable a variety of options in how the system will process transactions.  Oftentimes, these options provide a means of internal control from a SOX perspective.  That said, if an explicit super-user account has been defined for the information system in question, it should be reviewed routinely for appropriateness.

 

User

The user or end-user account is a lower privilege account assigned to an employee or contractor, for the purpose of granting that user access to a defined set of functionality or information.  Access typically should be provided to users on a least-privilege basis; in other words, the user should be granted only the bare minimum of access privileges necessary to do their job within the organization.

 

Generally Accepted User Access Review Practices - What, Who, Why, When, Where, and How

What should be reviewed?

This question can be answered at two levels:  Which software and what associated accounts should be audited? 

 

Regarding what software, an organization should inventory all information systems and track certain access metrics such as the: number of unique users; number of accounts; number of roles; and implementation date of the system.   Next, rank the inventory according to risk by using some or all of the inherent risk factors described earlier in this document.  For example, an organization may require a user-access review on a quarterly or semi-annual basis for all financial reporting systems but once every two years, if at all, for other systems.  An organization may strive to conduct a user assessment on every system to establish a baseline and then periodically revisit the assessment given the inherent risk.

 

When deciding what accounts to review, an organization can take one of several approaches:

 

1. Establish a baseline by reviewing 100 percent of the accounts created in the system at a single point in time.
2. Review certain types of accounts during every review (i.e., administrator and/or super-user), while selecting a sample of user accounts to review.
3. Review a subset of accounts on a cyclical basis, with the intent of reviewing all accounts within a stated period to establish a baseline.
4. Evaluate only a random sample of accounts.

 

Who has appropriate access?

In any audit, an organization should produce a list of every account and identify it by type (administrator or user).  From this listing, select a sample of accounts to evaluate who has been provided access to the system and whether it is appropriate.  Consider the following questions:

1. Is the account assigned to one, authorized individual or is it a documented system account?
2. If the account is assigned to a person, is that individual a valid employee, contractor or third-party who still requires access to the system?
3. Does authorization and documentation exist for all user-access privileges?
4. Is the access privilege generally appropriate given the user’s role within the organization?
   1. Obtain a list of employees and titles from payroll.
   2. Obtain a similar list of contractors and third-parties.  Note: This may be difficult to compile and manage, and will likely require advanced coordination with the managers of individual departments.

 

 

 

 

5. If the user is invalid (i.e., a terminated employee, etc.), determine the last date the account was accessed. 
   1. Was it subsequent to the termination date?
   2. What transactions were executed?
   3. What is the root cause for this issue?

 

Why is access reviewed for appropriateness?

Errors often arise during the security administration process, especially if the organization’s process is manual and/or decentralized in nature.  Given the importance of the security administration process as a foundation of IT security and SOX control, a periodic review of user access for appropriateness is virtually mandated by the Big Four auditors as a strong, effective detective control.  For that matter, the steps undertaken to review user access for appropriateness are based on conventional auditing techniques. 

 

However, access administration is only one facet of information security.  Not only is it important to carefully control who is provided access to what information assets, but it is also important to monitor the proper usage of that access.  If an organization has not yet deployed, or finds difficulty in deploying, a meaningful user monitoring process, a periodic review of user accounts provides yet another means of internal control to minimize the exposure of user accounts with inappropriate access.  

 

When should access be reviewed?

The frequency of the review is subject to management’s discretion given the failure rate of the user review.  In the early days of SOX, the Big Four strongly encouraged quarterly reviews.  Many organizations continue this practice today. 

 

However, if an organization can demonstrate through regular, periodic reviews that its failure rate is low, or within management’s defined tolerance for risk, it can build a case for reducing the frequency from quarterly to semi-annual or perhaps annual.  For example, management reviews user access for key SOX applications on a quarterly basis and consistently lowers its failure rate to five percent for a period of a year.  This test result, along with maturation of the primary security administration process, could allow management to build a business case that the primary security administration process is operating effectively such that the frequency of user reviews can be reduced.  Likewise, if the error rate for an annual review remains at five percent year-after-year, the organization can continue to review access annually.  If the error rate increases, management may review access and take subsequent, corrective action on a semi-annual or even quarterly basis. 

 

Regardless of the sample size, an organization can define an acceptable failure/error rate for key, if not all, information systems and use this metric to drive what reviews are performed and how often. 

 

Where is access reviewed?

The source data for any audit is key to the success of that audit; user access reviews are no different.  A review of user access should begin with a system-generated list of accounts at a single point in time.  If possible, the reviewer should systematically display other attributes about the account, such as ID, user name, created date, last used date, last date of update, effective date, and associated access privileges.

 

Many vendor-provided information systems have security administration reports to facilitate such a review.  Report-writing tools may be deployed to supplement the information provided by the system in question and may prove helpful if the reviewer wishes to merge security data with employee name and title information sourced from the organization’s human resources system.

 

How is access reviewed?

Any given user account selected for review purposes should be forwarded to the business process owner who is in the best position to evaluate the appropriateness of the access.  If corrective action is necessary, the business process owner can communicate the required changes to a security administrator for immediate correction.

 

 

 

While this process is somewhat straightforward, it becomes considerably more complex when multiple accounts and applications are involved on a frequent basis, and even more so if a high failure rate is discovered and considerable corrective action is necessary.

 

Some organizations strive to automate the review process, but find it difficult to do so when their primary means of security administration is manual in nature.  Those organizations that go so far as to implement identity management systems may find that their primary controls over security administration are operating so effectively that they can easily implement an annual, manual review process. 

 

Regardless of the method by which a review is performed—manual or systematic—an organization should always strive to uncover the root cause of its user security administration failures and work quickly to minimize or correct the exposures they may cause. 

 

Conclusion

The periodic review of user access is both an insightful mechanism to evaluate the effectiveness of the user security administration process and a means to minimize risk and exposures due to breakdowns in the primary controls of that process.  The frequency, methods deployed and degree to which an organization conducts this analysis is highly dependent upon its velocity of change, organizational structure and the sensitivity of information assets accessible by its users.  The periodic user review process also could and should vary widely among organizations depending on the relative maturity of the security management processes, but the factors outlined in this article will provide a solid basis for starting this analysis.

---

  

Article from Protiviti KnowledgeLeader – www.knowledgleader.com.

 

KnowledgeLeader is a subscription-based website that provides audit programs, checklists, tools, resources and best practices to help internal auditors and risk management professionals save time, manage risk, and add value. Free 30-day trials available.

 

 

Protiviti is a leading provider of truly independent internal audit and business and technology risk consulting services. We help clients identify, measure and manage operational and technology-related risks they face within their industries and throughout their systems and processes. And we offer a full spectrum of audit services, technologies and skills for business risk management and the continual transformation of internal audit functions.   Protiviti is not licensed or registered as a public accounting firm and does not issue opinions on financial statements or offer attestation services.