Information, Articles, Tools, and Useful LinksCommittee Listings, Member Forums, and Find a CITPInformation on AICPA Tech. Conference, Seminars, Webcasts, and ConferencesIT Section Membership Information, CITP Credential Information, Members Only Tools and Communications, and MorePublications, CPE, Conferences, and Webcasts
 
Search

Printer Friendly View

Relevant and Practical Application to Access & Identity Management
By: Janis Wong, CPA.CITP, CISA

Many top 10 lists rank Identity and Access Management (IAM) as one of the key technologies most likely to affect today’s business marketplace. In fact, participants who voted in the 2008 Top Technology Initiatives ranked IAM the 6th most important initiative out of a possible 29.

 

According to the Ponemon Institute’s 2007 Annual Study: Cost of a Data Breach, data breach incidents cost companies $197 per compromised customer record in 2007, compared to $182 in 2006. Lost business opportunities, including losses associated with customer churn and acquisition, represented the most significant component of the cost increase, rising from $96 in 2006 to $128 in 2007 – a 30 percent increase.

 

With these numbers in mind, companies and organizations are increasingly investing in IAM products and procedures to enforce stronger controls and avoid potential data breach incidents. These tools serve multiple purposes and, in general, protect against possible external/internal security breaches and establish internal guidelines for data accessibility. While access management products and procedures are integrated with other core technology resources, the two primary access entries in which organizations are vulnerable to security risk are logical access and physical access.

 

With logical access, businesses typically spend more of their initial investments purchasing firewall software, installing VPNs and using intrusion detection tools to achieve network security. Other access control policies applicable through a business’ existing resources, including Windows Active Directory or Oracle applications, may be further enforced at the server/database and financial system/application level. When implementing access policies, the key element an organization should consider is all possible points of entry to its resources and assets.

 

With physical access, businesses may be exposed to risk of theft or asset damage when on-premise physical access is not monitored, from the office building itself to the specific IT server room(s) located in the office building. Monitoring capabilities may be preventive, detective or corrective in nature depending on the format and tools used to monitor access. Examples of preventive controls include electronic badge cards and biometric security; detective controls include video cameras and room entry audit logs. Conversely, corrective controls are designed to remedy problems soon after they arise.

 

While an organization may have the financial resources to invest in technology tools and the sense of urgency to secure its data and resources, security goals cannot be achieved without proper setup, policies and enforcement. IAM is generally a two-step process and applies to logical and physical access: 1) establishing user identity or authentication to establish user accountability, and 2) ensuring the appropriate level of access is granted.

 

Establishing User Identity or Authentication

When addressing a user’s identity and authentication, three techniques are frequently applied in combination or independently to establish user accountability:

·                     What you know: Passwords/pass phrases.

·                     What you have: Tokens, digital certificates, PKI (public key infrastructure).

·                     Who you are or what you do: Biometrics (finger, hand, retina, voice recognition).

 

While the first two techniques apply most often to logical access controls, biometrics are implemented more often for physical access controls – more frequently at businesses that host client servers and have multiple clients trafficking through the building/warehouse to access their own servers.

 

Logical controls can be achieved through single sign-ons, token-devices or multiple-factor authentications. Other authentication device examples may also include RSA (Rivest, Shamir, Adleman) tools that encrypt and decrypt messages, such as digital certifications and smartcards. Combining required password features, such as requiring expiration or syntax rules, along with the examples provided above, make up a large component of enforcing a strong access management policy.

 

Ensuring the Appropriate Level of Access

With logical access, system administrators grant system access to an employee so he or she may perform a job function. More importantly, however, the level of logical access is enforced to ensure that the system is allowing the appropriate user to enter a transaction into a financial system or application, and that an organization’s assets (intellectual or monetary) are safeguarded appropriately.

 

Some logical access management examples include:

·                     Financial application access, including entry access only to create a journal entry, restricted access to delete a journal entry or limited approval access to only post a journal entry.

·                     Database access, such as read-only access to a sales transaction table, or establishing Payment Card Industry Data Security Standards (PCI DSS) to protect customer payment information.

·                     Programmer access, including read-only access to the production environment of a financial system/application or restricted access to push program coding to a financial system/ application.

 

Oracle Financial Segregation of Duty Matrix

For a more specific example, review the Oracle Financial Segregation of Duty (SOD) matrix. These matrices are SOD guidelines that financial system vendors (such as Oracle) often offer and suggest to clients to reference and use during implementation. In the case of the circled example, the Accounts Payable Clerk should not have access to create an AP voucher and make the AP payment. However, what happens when the Accounting and Finance Department only consists of a staff of three? In this case, the Segregation of Duty concept is harder to implement in this reality. Organizations and policy setters may have to rely more on other manual policies and procedures that mitigate the risk of fraud if a particular logical access control cannot be enforced.

 

According to the Oracle Community of employees and users, managing and monitoring user identities, or the associated roles and system privileges across the whole organization, are critical to solving Segregation of Duty problems. For example, one consideration relates to how relevant an individual’s identity is to managing good corporate governance. Other typical problems include:

1.                Difficulty enforcing SODs across a heterogeneous environment and across multiple business applications.

2.                System roles and identities have conflicting privileges that leave organizations vulnerable to fraud.

3.                Managing access privileges across business applications and siloed identity repositories.

4.                Privileges are managed on a system-by-system basis, rather than across the whole organization. This makes conflicting roles difficult to spot and manage.

5.                Difficulty auditing and reporting access controls.

6.                Difficulty protecting information assets.

 

Small businesses are generally more vulnerable to risk when implementing access management controls, as identified in #2 and illustrated in the SOD example. In addition, businesses may be disinclined to invest in updated technology if a system in an older version still works. As a result, there may be limitations to enforcing access management policies due to the capability of the older/outdated financial system. An outdated system may not have the capability to define specific user groups and distinguish user access levels, or require various password syntax rules, to apply during login.

 

Security risk may not be significant for an application that only tracks 20 semiconductor machines (that are very visible and less likely to be stolen or lost from a warehouse). However, if a system has limited functionality and mitigating procedures are not implemented, there may be a greater risk exposure for an organization to monitor internal and external access, financial ledger activity, or customer/supplier activity in an application. Physically security is also at higher risk when companies may not have the funding available to provide high-quality facilities and store its servers. Organizations with branch offices may tend to follow this path and allocate less technology funding to the branch facilities. In this case, allocating funds to implement good access management policies also depend on the importance of the assets to an organization and the risks associated with the loss.

 

While companies should not create more unnecessary complexity into processing a transaction, appropriate access and identity management policies should be in place to secure an entity’s sensitive information. However, organizations also should consider whether implementing a process or software will reduce any associated specific costs – or if the benefits outweigh the costs.

 

Contact Janis Wong at jawong@aicpa.org.

Return to Table of Contents

Janis Wong has more than nine years’ experience in corporate finance, business process improvement, IT internal controls and compliance, and project management. Currently, she is a project manager at the AICPA, where she develops new benefits and manages existing benefits for the CITP Credential membership community. Previously, Wong worked at Grant Thornton, LLP as an Internal Controls manager within the firm’s Business Advisory Services group in the San Francisco/Bay Area.

Copyright © 2008 by the American Institute of Certified Public Accountants, Inc., New York, New York.