Burton Whenprovision

8/19/2019 Burton Whenprovision

1/29

When Provisioning Isn't Enough: EnterpriseApplication Controls ManagementVersion: 1, May 17, 2007

AUTHOR(S):Lori Rowland([email protected])

TECHNOLOGY THREAD:

Identity Management

ConclusionThe enterprise application controls management (EACM) market is rapidly evolving andexpanding. This growth is, for the most part, due to regulatory pressures. Organizations arestruggling to maintain access controls over financial, private, and otherwise sensitive data.

EACM applications provide fine-grained access and separation of duties (SoD) controls for enterprise resource planning (ERP) applications. Integrated EACM and identity management(IdM) solutions allow organizations to enable a compliant provisioning process that includesSoD enforcement, ERP role lifecycle changes, workflow-based ERP role and access changeapprovals, and risk detection and remediation.

: 1

Identity and Privacy Strategies

In-Depth Research Report

40

http://%20%20%20%20%20%20%20%20%20%20%20mailto:[email protected]/


2/29

Publishing Information

Burton Group is a research and consulting firm specializing in network and applications infrastructure technologies.

Burton works to catalyze change and progress in the network computing industry through interaction with leadingvendors and users. Publication headquarters, marketing, and sales offices are located at:

Burton Group7090 Union Park Center, Suite 200Midvale, Utah USA 84047-4169Phone: +1.801.566.2880Fax: +1.801.566.3611Toll free in the USA: 800.824.9924Internet: [email protected]; www.burtongroup.com

Copyright 2007 Burton Group. ISSN 1048-4620. All rights reserved. All product, technology and service names aretrademarks or service marks of their respective owners.

Terms of Use: Burton customers can freely copy and print this document for their internal use. Customers can alsoexcerpt material from this document provided that they label the document as Proprietary and Confidential and addthe following notice in the document: Copyright © 2007 Burton Group. Used with the permission of the copyrightholder. Contains previously developed intellectual property and methodologies to which Burton Group retainsrights. For internal customer use only.

Requests from non-clients of Burton for permission to reprint or distribute should be addressed to the ClientServices Department at +1.801.304.8174.

Burton Group's Identity and Privacy Strategies service provides objective analysis of networking technology,market trends, vendor strategies, and related products. The information in Burton Group's Identity and PrivacyStrategies service is gathered from reliable sources and is prepared by experienced analysts, but it cannot be

considered infallible. The opinions expressed are based on judgments made at the time, and are subject to change.Burton offers no warranty, either expressed or implied, on the information in Burton Group's Identity and PrivacyStrategies service, and accepts no responsibility for errors resulting from its use.

If you do not have a license to Burton Group's Identity and Privacy Strategies service and are interested in receivinginformation about becoming a subscriber, please contact Burton Group.


3/29

Table Of Contents

Synopsis.......................................................................................................................................................................... 4Analysis...........................................................................................................................................................................5

IdM vs. EACM............................................................................................................................................................5Integration Methodology: How Do IdM and EACM Play Together?........................................................................ 6

Methodology 1........................................................................................................................................................6Methodology 2........................................................................................................................................................7

Integration Technologies.............................................................................................................................................7EACM Architecture....................................................................................................................................................9EACM Features.........................................................................................................................................................10

EACM Process Flow.............................................................................................................................................12Phase 1: Policy Definition.................................................................................................................................13Phase 2: Risk Detection and Remediation........................................................................................................13Phase 3: Continuous Controls Enforcement..................................................................................................... 13Phase 4: Audit and Reporting........................................................................................................................... 13

Market Impact........................................................................................................................................................... 13Market Segmentation............................................................................................................................................ 14Cooperative vs. Competitive.................................................................................................................................15

Recommendations.....................................................................................................................................................16The Details.................................................................................................................................................................... 17

The Regulatory Impact..............................................................................................................................................17United States: Sarbanes-Oxley Act of 2002......................................................................................................... 17

SOX Section 302: Corporate Responsibility for Financial Reports................................................................. 17SOX Section 404: Management Assessment of Internal Controls................................................................... 17

ERP Privilege Models...............................................................................................................................................18Oracle E-Business Suite........................................................................................................................................18PeopleSoft.............................................................................................................................................................19SAP....................................................................................................................................................................... 19

EACM Product Details............................................................................................................................................. 20Approva.................................................................................................................................................................20LogicalApps..........................................................................................................................................................23

SAP........................................................................................................................................................................... 25Oracle.................................................................................................................................................................... 27

Conclusion.................................................................................................................................................................... 28Author Bio ....................................................................................................................................................................29

3

BURTON GROUP 7090 Union Park Center Suite 200 Midvale · Utah 84047 · P 801.566.2880 · F 801.566.3611 · www.burtongroup.com


4/29

Synopsis

The enterprise application controls management (EACM) market has seen significant growth over the past threeyears. This growth is primarily due to increased organizational pressure to comply with regulatory, legal, andcorporate mandates. The Sarbanes-Oxley Act of 2002 (SOX) has had a significant impact on the EACM market,

because it requires organizations to implement, maintain, audit, and attest to controls over financial data.

Financial data is often stored in enterprise resource planning (ERP) applications, which have complex privilegemodels and embedded business processes. Identity management (IdM) vendors offer account management and

provisioning solutions for the ERP environment. However, IdM vendors do not provide the level of granularityneeded to enforce separation of duties (SoD) within an ERP application. Organizations are turning to integratedIdM and EACM solutions to enable effective controls for compliant provisioning and SoD within ERPapplications.

EACM systems provide fine-grained access control and SoD enforcement within ERP applications. EACMsystems comprise several features that help organizations achieve regulatory compliance, including:

• A predefined SoD policy library

• Risk analysis, detection, and remediation

• A workflow-based approval process for privilege and role changes

• “What if” simulations that detect risks before they are committed to the ERP environment

• ERP role definition tools

• Critical transaction monitoring and fraud detection

• Emergency or privileged user account management

Significant opportunity exists for cooperation between IdM and EACM technologies. A common integrationscenario is for the IdM system to send ERP provisioning events to the EACM simulation tool, which checks for SoD violations. This ensures that potential risks are detected and remediated before changes are provisioned to theERP application. EACM vendors such as Approva, LogicalApps, and SAP have partnered with IdM vendors tooffer an integrated IdM and EACM solution.

EACM systems augment IdM and enterprise role management (ERM) systems by providing an additional layer of control. Enterprises should take a hybrid approach to automated controls and compliance management byintegrating IdM, EACM, ERM, risk management, document management, and other audit and securitytechnologies.

4



5/29

Analysis

The Sarbanes-Oxley Act of 2002 (SOX) has had a significant impact on large, publicly traded organizations in theUnited States. Its ripple effect has also been felt by non-U.S., private, and smaller organizations. As a result,organizations have invested significant amounts of money on compliance-related technologies.

SOX and other regulatory mandates require organizations to implement internal controls over financial data, asdescribed in “The Regulatory Impact” section of this report. Maintaining appropriate controls over financial or sensitive data is nothing new. For years, employers have been concerned with how financial data is controlled andhow it is maintained. However, until recently, financial controls were dictated and managed at the departmentallevel. Executives were rarely, if ever, involved in the management or assurance of financial controls—they weretypically only concerned with the bottom line. New corporate regulations have changed this dynamic. Today,CxO-level executives are not only concerned about the accuracy of financial data and the effectiveness of financial controls, but accountable for it—their skin is in the game.

The seemingly simple SOX mandate to “maintain adequate controls over financial data” has caused a firestorm.Vendors have responded with a plethora of compliance-related technologies, while organizations scramble to

make heads or tails of it all. Most organizations utilize a combination of technologies to automate controls andmanage compliance processes.

Controlling access to financial or sensitive data is a high priority for regulated organizations. As a result, manyorganizations have implemented identity management (IdM) technologies, including provisioning, passwordmanagement, and access management solutions. However, as organizations become more “controls savvy,” theyare finding that IdM systems have limitations, particularly within the enterprise resource planning (ERP)environment. Organizations are looking to optimize access controls with enterprise role management (ERM),fine-grained authorization, identity audit, and enterprise application controls management (EACM) solutions.

EACM solutions such as Approva, LogicalApps, and SAP GRC Access Control (SAP GRC) offer controlsautomation, management, and transaction monitoring capabilities. These features enable fine-grained access andseparation of duties (SoD) controls for the ERP environment. Each EACM vendor covered in this report hasincorporated years of hands-on experience, ERP knowledge, and research to develop a comprehensive, predefinedSoD policy library.

An integrated EACM and IdM solution enables compliant provisioning to ERP applications. EACM systems provide low-level access controls that can be integrated into the IdM provisioning process.

IdM vs. EACM

IdM systems offer account management and provisioning features for multiple systems within an organization'sinformation technology (IT) infrastructure. However, IdM systems do not inherently understand the underlyingintricacies of application privilege models. This is particularly true of ERP applications that have extremelycomplex privilege models, as described in the “ERP Privilege Models” section of this report. EACM systems

provide a deeper level of access control within the ERP environment.

ERP systems contain highly sensitive information, such as financial, employee, customer, vendor, and partner data. Therefore, ERP systems are built on a strong (albeit application-specific) security foundation. ERP roles and

profiles are a nesting of low-level entitlements, such as fields, authorization objects, transactions, functions, pages, and menus. In order to effectively maintain SoD controls, ERP permissions must be managed at a moregranular level than what is traditionally provided by an IdM system. EACM systems enable effective SoDcontrols by integrating with ERP systems at the lowest level possible (e.g., transaction-level controls).

5



6/29

EACM systems include predefined SoD policies that are consistently applied across all ERP applications withinan organization. It is possible for organizations to define SoD policies within an IdM system. However, these

policies are typically written in Extensible Markup Language (XML) format (or another programming language)and maintained by IT administrators with programming knowledge. Additionally, defining effective ERP SoD

policies requires extensive knowledge of the ERP environment, business processes, and risks—and most ITadministrators do not possess this knowledge. This is further complicated by the fact that ERP role data isdynamic. IdM policies must be updated each time an ERP role changes. Maintaining SoD rules in an IdM systemis less than ideal for customers with complex ERP environments and stringent control policies.

In the IdM environment, provisioning events are written directly to the ERP system. If the provisioning eventintroduces an SoD violation, it may be left undetected—or it may be detected after the fact during an audit or reconciliation process. An integrated EACM and IdM solution gives the customer an additional layer of control

by testing the impact of a role or privilege change before it is committed to the ERP environment.

EACM interfaces are designed to front-end ERP user and role maintenance functions. However, there are notechnical safeguards to prevent ERP administrators from entering changes within the ERP application itself (theexception being LogicalApps, which prevents Oracle SoD violations at the application level). Some EACMsystems are capable of intercepting application-level changes. If the change is detected, it is rerouted to the

workflow system for approval. However, a reconciliation process must be in place for back-door or database-levelchanges that are left undetected by the EACM system. In this case, IdM systems provide valuable user lifecyclemanagement and reconciliation capabilities. IdM systems have robust reconciliation features that may be run inreal time or near–real time. Once detected, the IdM system provisions the change through the EACM system.

Integration Methodology: How Do IdM and EACM PlayTogether?

EACM can be thought of as an IdM access control “safetynet.” Various integration points exist between the twosystems. In a standard IdM environment, the provisioning system sends account create, modify, and delete eventsdirectly to the ERP application. However, in an integrated solution, the provisioning event is sent to the EACMsolution and thoroughly scrutinized for adherence to SoD and other access control policies.

There are two primary methodologies for integrating IdM and EACM technologies.

Methodology 1

The first methodology assumes that the IdM system owns the provisioning event throughout its lifecycle. ERP provisioning events are initiated in the IdM environment. If the event contains role or privilege changes, it is sentto the EACM system. The proposed change is run through a “what if” simulation to determine its impact on theERP environment. The simulation verifies adherence to access control policies and detects SoD policy violations.Once the simulation is complete, the EACM system returns notification of a success or failure status to the IdMsystem. If the event fails, the EACM system also returns supporting root-cause data. The IdM system continuesthe provisioning process by committing the event to the ERP system or generating a processing error.

6



7/29

Figure 1: EACM Integration Methodology 1

Methodology 2

In the second methodology, provisioning events are generated in the IdM environment and subsequently sent tothe EACM system for processing. The EACM system intercepts the provisioning event and generates an EACMapproval workflow. As with the first methodology, the proposed change is run through a “what if” simulation;however, the EACM system takes over the provisioning process. The EACM system commits the change to theERP environment or generates an error. One disadvantage of releasing the event to the EACM system is that theIdM system must continuously poll the EACM system for the processing status. Also, the user, manager, or administrator must interrupt the provisioning process and switch from the IdM environment to the EACMenvironment.

Figure 2: EACM Integration Methodology 2

The methodology an organization deploys is dependent on the capabilities of its respective IdM and EACMtechnologies, as described in the “Integration Technologies” section of this report. The true value-add of bothintegration methodologies is the ability to simulate changes and prevent SoD violations before committing thechange to the ERP environment.

Integration Technologies

7



8/29

Most EACM systems are built on an extensible, open architecture. These systems include open application programming interfaces (APIs), web services, or other integration technologies that allow customers to buildcustom connectors to legacy or external systems. IdM systems are, for the most part, open andextensible—customers can build or customize adapters using an adapter framework or software development kit(SDK).

An integrated IdM and EACM solution is a fairly new concept to the market. To date, the majority of organizations integrating the technologies have extended or built customized IdM adapters. Several IdM andEACM vendors are working together to build customized solutions for high-profile customers. To date, SunMicrosystems and IBM are currently the only vendors with a productized solution. These vendors haveestablished formal reseller or developer partnerships with both Approva and SAP. Other IdM vendors, includingCA, BMC, HP, Novell, and Oracle, do not have a productized offering, but rather offer an integrated solution as

part of a field services or consulting engagement.

Sun has an EACM integration offering for Approva, LogicalApps, and SAP. However, the integrationmethodology for the two systems is quite different. Sun extends the capabilities of its existing Sun Java SystemIdentity Manager SAP adapter to integrate with SAP GRC. The SAP adapter has a configuration option thatenables support for SAP GRC. Sun integrates with SAP GRC's workflow-based provisioning component

(formerly known as Virsa Systems' Access Enforcer). Sun sends IdM events to SAP GRC, which intercepts theevent and continues the provisioning process. Because Sun is communicating with SAP GRC via the SAPadapter, the Sun/SAP GRC integration is limited to the SAP ERP environment. Sun's integration with SAP GRCis analogous withintegration methodology 2, as described in the “Integration Methodology: How Do IdM andEACM Play Together?” section of this report.

In contrast, Approva provides the adapter for integration with Sun Identity Manager. ERP workflows areconfigured in Sun Identity Manager. As Identity Manager receives ERP provisioning events, it triggers aworkflow-based web service call to Approva's BizRights platform. Approva checks the request for SoD violationsand returns a processing status to Sun Identity Manager. This solution is customizable; Approva can intercept andthen integrate the event into its workflow-based provisioning process. Customers may also choose to take a hybridapproach and combine the various options—in this scenario, Approva would intercept only events that fail thesimulation. The Approva adapter for Sun Identity Manager provides SoD controls for SAP, Oracle, andPeopleSoft. Sun and Approva have recently entered into a reseller agreement. Under the terms of the agreement,Sun can resell Approva's products, including the Sun Identity Manager adapter.

In April, 2007, LogicalApps announced its integration solution for Sun Identity Manager. Sun Identity Manager'sworkflow can be extended to include SoD testing for Oracle and PeopleSoft through LogicalApps plug-ins.

IBM also has a comprehensive EACM strategy. The IBM Tivoli Identity Manager (TIM) adapter is deliveredthrough Approva. This integration is similar to the Sun/Approva solution. IBM maintains full control of the

provisioning process. It integrates with Approva's SoD simulation tool by making web services calls within TIM's provisioning workflow.

IBM is also developing an adapter for SAP GRC. This adapter sends provisioning events to SAP GRC for processing. IBM's SAP adapter and SAP GRC adapter work in concert, rather than replacing each other. The SAPadapter handles self-service password resets, provisioning of extended account attributes not supported in SAPGRC, and reconciliation of ERP account data for continuous compliance monitoring of actual permissions versusapproved permissions. However, all ERP provisioning events containing role or access changes are processedthrough SAP GRC.

IdM integration technologies for EACM are fairly immature, and they offer several opportunities for advancement. The most obvious area for improvement is the expansion of IdM and EACM partnerships. ManyIdM vendors have included a productized EACM integration solution on their short-term roadmaps. As theserelationships improve, the integration technologies must become more consistently applied across systems.Today, there is no clear indication as to who “owns” the integrated solution. Some solutions are provided by theEACM vendor, while others are provided by the IdM vendor. As a result, the functionality and applicationsupport varies from one integrated solution to another.

8



9/29

Another area for improvement is expanding integration support to include additional EACM systems. Most IdMvendors have focused integration efforts on Approva and SAP GRC. Depending on customer demand, this should

be expanded to include LogicalApps and Oracle (as Oracle expands its GRC strategy).

EACM Architecture

The architectural components of an EACM system are similar to those traditionally found in IdM systems. At ahigh level, the EACM architecture consists of a centralized repository, policy engine, graphical user interface,adapter framework, and workflow engine. EACM systems also include audit, reporting, and alerting tools.

Figure 3: EACM Architecture

Platform support varies among EACM vendors. For example, SAP GRC is a Java application built on the SAP NetWeaver Application Server, whereas the Approva BizRights platform is built on the Microsoft .Netframework.

Most EACM technologies make a footprint on the ERP application, typically in the form of SAP AdvancedBusiness Application Programming (ABAP) code that enables Business Application Programming Interfaces(BAPIs) or other direct queries. Equivalent footprints are made in the PeopleSoft and Oracle environments. TheEACM system is dependent on the functionality of the ERP application; therefore, most analysis and monitoringare performed in batch mode rather than in real time. For example, ABAP programs that collect data are run inscheduled intervals. The EACM system receives data according to the schedule of the underlying ERP process.Customers can configure these processes to be run in near real time; however, this may have a significant impacton the performance of the underlying ERP system. Once the EACM system has gathered privilege data from theERP system, it is stored in the EACM repository.

9



10/29

The EACM server is data laden and process heavy. EACM adapters collect privilege data from ERP applications.This data is stored and processed on the EACM server. Moreover, all EACM events are recorded to an audit log,which is typically stored in the repository. It is important to implement a robust EACM server environment thatsupports load balancing. Most customers find that the largest performance hit is on the EACM server(s) rather than the ERP environment.

The centralized repository is the “brain” of the application. All business process, risk, control, workflow,remediation, alerting, privilege, and configuration data is stored in the repository. By using a centralized policymodel, EACM applications consistently apply controls across multiple ERP applications. The policy engine

processes events according to policies stored in the repository.

EACM systems include predefined ERP application adapters, which provide ERP configuration and connectivityinformation. These adapters are not necessarily “intelligent.” Policies are defined, stored, and executed on theserver rather than at the adapter level. The adapter acts as a transport and communication layer. SDKs for buildingcustom connectors to legacy, external, or third-party applications are available with most EACM systems.

EACM systems also include collaboration, reporting, user, and administrative tools. These tools alloworganizations to push the normally tedious process of defining, approving, managing, and auditing ERP accesscontrols to line of business (LOB) owners and users. EACM systems provide web-based interfaces that support

delegated administration and workflow-based user provisioning. Dashboard, alerting, and reporting tools give theorganization an up-to-date compliance snapshot.

EACM Features

The primary function of an EACM system is to provide fine-grained access control and SoD within the ERPenvironment. Each vendor covered in this report has incorporated years of hands-on ERP experience and researchinto its SoD policy libraries.

The following EACM features enable fine-grained access control and SoD within an ERP environment:

• Predefined SoD policy library: ERP applications contain tens of thousands of roles and permissions.Establishing effective ERP access control and SoD policies requires a thorough understanding of each role,

business function, and permission within the ERP environment. EACM systems provide a comprehensivelibrary of predefined access control and SoD policies. These policies are a permutation of in-depth knowledgeof business risks (e.g., create vendor vs. pay vendor), ERP roles and privileges, and system-level transactionsand functions. Role definitions and policies in the library are presented in a human-readable format that ismeaningful to nontechnical business users.

The policy libraries contain SoD policies for predefined business processes such as finance, payroll, procure to pay, order to cash, hire to retire, and production to delivery. These process-centric SoD policies can spanmultiple ERP applications, as shown in Figure 4.

10



11/29

Figure 4: Cross-Functional, Cross-Application SoD Policies

EACM policy libraries contain thousands of SoD policy definitions. However, not every SoD policydefinition is relevant to every organization. This is largely due to the fact that organizations typically onlyutilize a portion of the default roles available within the ERP system. Most organizations customize andcreate new ERP roles. Therefore, EACM libraries provide customizable templates for creating access

control and policy definitions that reflect the customer's dynamic ERP role environment.• Risk analysis, detection, and remediation: After access control and SoD policies are defined, existing

violations must be identified and remediated. User entitlement data is gathered from the ERP application, either in real time or through batch processing. Access control and SoD policies are applied to the user entitlementdata and the resulting output is analyzed. The system detects existing violations and triggers a remediationworkflow.

• Request-driven, workflow-based user provisioning: EACM systems serve as the gatekeeper to the ERPenvironment. Administrators, managers, and users make ERP access requests through the EACM interface.Users can request a new account, role, or privilege or modify existing privileges. Once an access request ismade, the system triggers an approval workflow.

The approving manager can accept the access request or run a “what if” simulation to ensure that the accessrequest does not pose a potential risk. Some EACM systems automatically run the simulation and provide theresulting data in the approval workflow. Request-driven user provisioning does not prevent ERP administrators

from changing account privileges at the system or database level. The EACM must include controls to combatviolations introduced by back-door or database-level changes. For example, if access is changed at the systemor database level, some EACM systems intercept the request and run a “what if” simulation to ensure that therequest does not introduce a violation. If the system detects a potential violation, it rejects the request andcreates an approval workflow. However, if the “what if” simulation does not detect a violation, the accesschange is made and the event is recorded in the EACM audit log. If the EACM system does not interceptsystem-level changes, then it must continuously monitor the ERP environment for control violations.

• Cross-application SoD support: Access control and SoD policies are stored in a centralized repository. Risks, business functions, workflows, and other controls are also stored in the repository.

11



12/29

Access control and SoD policy definitions can span two or more ERP applications. For example, a vendor profile may be created in one application (e.g., SAP) while vendor payments and purchase orders are enteredand approved in another (e.g., Oracle). The SoD policy must be applied across multiple applications (SAP andOracle, in this example). EACM solutions utilize a centralized repository to aggregate roles and permissionsand consistently apply policy across multiple systems.

• Compensating controls for privileged accounts: In an ideal world, organizations are able to enforce SoD byappropriately dividing business functions among employees. However, in the real world, this is not always

possible. Organizations are often forced to make exceptions to control policies. Privileged accounts includeaccounts needed for emergency access and delegated administration, and all other accounts created with controlexceptions. Auditors require that organizations mitigate, document, audit, and manage these accounts.

Compensating controls are used to minimize the risks associated with privileged user accounts. Compensatingcontrols might include:Documenting, logging, and reporting exceptions

Expiring excessive privileges

Monitoring privileged user activity

Creating a check in/check out system for privileged accounts

Restricting access to data (e.g., hiding fields or permitting read vs. read/write access)

The extent to which EACM systems support compensating controls varies from system to system.• ERP role creation and maintenance: ERP role creation and maintenance is a daunting task for any

organization. Many organizations create new or customized roles within the ERP environment. To ensure thatERP role changes do not introduce new violations, EACM systems provide a role sandbox feature for designing, simulating, and creating roles. EACM systems synchronize valid role changes across systems.Because roles, associated permissions, and policies are presented in a human-readable format, role creation can

be pushed to nontechnical LOB owners.

• “What if” simulation: To ensure compliant provisioning and role creation, EACM systems provide simulationtools. These tools simulate access control changes and identify potential risks before committing changes to theERP environment. Users, administrators, managers, ERP systems, and third-party systems can interact withsimulation tools.

• Critical transaction monitoring: Defining and managing access controls is the primary function of EACMsystems. However, in order to achieve a deeper level of control, EACM systems also include transaction

monitoring features. Highly sensitive or at-risk transactions are flagged and monitored. This allows anorganization to monitor user activity by business function or transaction, rather than by user. For example, amanager can evaluate all users who are executing payroll transactions. Also, by flagging critical transactions,organizations can monitor and identify transactions that indicate inappropriate behavior. All criticaltransactions are tracked, logged, and audited. It is important to note that this is a detective control. Transactionreport data is typically monitored rather than reported in real time.

• Audit and reporting: EACM systems include audit and reporting tools. Events are recorded in an audit logthat is available for reporting purposes. Audit logs and reporting tools are valuable to management and auditorsduring the audit process. EACM reporting tools allow organizations to identify risks and remediate them. SomeEACM systems provide web-based reporting tools that walk the administrator through the remediation processwith contextual recommendations based on the audit trail and the violation itself.

EACM Process Flow

EACM processes and features often interrelate. Figure 5 demonstrates the coalescence of the above features into a phased approach to EACM.

Figure 5: EACM Process Flow Diagram

12



13/29

Phase 1: Policy Definition

Organizations must define business processes, risks, and access controls relative to their environment. From thisinformation, the predefined SoD and access controls library is customized and refined. As with IdM deployments,

defining business process and gathering requirements is often identified as the most difficult aspect of an EACMdeployment.

Phase 2: Risk Detection and Remediation

This is the clean-up phase of an EACM deployment. This phase can only be completed after a valid policy libraryis defined. Violations are detected, analyzed, and corrected by applying EACM policies to existing privilegeswithin the ERP environment. It is important that organizations remediate not only the individual user's privileges

but also the privileges of the underlying role or permission that provisioned the error.

Phase 3: Continuous Controls Enforcement

Once the ERP environment is clean, it must be maintained. EACM solutions accomplish this through both preventive and detective controls. Preventive controls include compliant user provisioning, role creation, privileged user account management (UAM), and “what if” simulations. Detective controls include user activityand critical transaction monitoring.

Phase 4: Audit and Reporting

The last phase of an EACM deployment is the audit and reporting phase. Organizations must audit user privileges,roles, control policies, and system data. Reporting tools allow organizations to demonstrate the effectiveness of the EACM controls environment. Audit and report tools are available to administrators, LOB managers, andauditors.

Market Impact

Companies are increasingly burdened with regulatory compliance initiatives and reporting requirements. Softwarevendors have responded to this need with various technologies. These technologies are collectively referred to as“governance, risk, and compliance (GRC) solutions.” Viewing this term as too generic, Burton Group does notuse it to describe the market. Rather, Burton Group divides the market into several categories, including risk management, document management, vulnerability management, controls management, transaction monitoring,database security, and spreadsheet analysis and reporting.

The EACM market encompasses vendors offering controls management and transaction monitoring features. Inthis report, the EACM market is further divided to include only those vendors that offer access and SoD controlsfor the ERP environment. Clearly, this market niche is very small and highly specialized. Vendors in this marketinclude Approva, Control Software International, D2C Solutions, LogicalApps, Oracle, and SAP.

The EACM market has seen significant growth since the introduction of SOX in 2002. Most of these technologiesare less than six years old, yet each has seen double-digit growth every year for the last three years. Approva,LogicalApps, and SAP (formerly Virsa Systems) have a stronghold on the overall market. These vendors arehighlighted in this report due to their market presence.

SOX has also had a momentous impact on the IdM market. Many organizations have deployed IdM systems as part of an overriding compliance initiative. Organizations have established a baseline identity management systemwith authentication, provisioning, password management, and auditing capabilities for multiple applicationsthroughout the IT infrastructure. However, organizations are now looking to optimize controls.

13



14/29

The underlying business driver for an integrated IdM and EACM solution is controls optimization. Organizationsare looking to take the existing controls provided by their IdM system to the next level. There is also an increasedneed for automated, repeatable, and sustainable processes. An integrated solution is ideal for organizationslooking to simplify SoD policy definition, role maintenance, and access control enforcement for the ERPenvironment.

Market Segmentation

The EACM market is mostly composed of large, enterprise-level customers, due to the fact that theseorganizations are beholden to SOX and other regulatory requirements. Moreover, EACM systems are specificallydesigned for ERP applications, which are typically deployed in large organizations.

The EACM market can be segmented by several technological factors. The primary differentiator is the vendor'sERP application support strategy. For example, LogicalApps has historically focused on Oracle applications,while SAP GRC (dating back to its Virsa origins) has specialized on SAP.

EACM vendors are moving toward cross-application support. This requires vendors to create a comprehensive,cross-application SoD policy library. Currently, Approva and SAP have the widest reaching and most detailedSoD libraries. These vendors provide SoD policies for SAP, PeopleSoft, Oracle, JD Edwards, and HyperionSolutions.

SAP acquired Virsa Systems in 2006. These technologies are now known as “SAP GRC Access Control” (SAPGRC). Since the acquisition, both SAP GRC and Approva have struggled with interoperability perception issues.SAP maintains its commitment to operate in a heterogeneous environment. However, the product has been re-engineered to run in Java on the SAP NetWeaver server platform. Non-SAP customers may be hesitant to use anEACM application dependent on or tightly linked to SAP NetWeaver—no matter how small the imprint.

On the flip side, Approva is challenged with establishing itself as a viable solution for customers committed to theSAP platform. However, SAP continues to work with Approva as a strategic partner. Currently, neither SAP nor Approva has technology-related interoperability issues. However, moving forward, Approva is better positionedto offer a cross-platform solution because of its vendor-neutral architecture.

Some market segmentation exists among EACM vendors based on the depth of functionality they provide. Table1 provides a high-level overview of the strengths and challenges for each vendor in this space.

Vendor Cross-applicationsupport

Strengths Challenges

Approva Hyperion, JDEdwards,Oracle,PeopleSoft,SAP

Comprehensive feature set, cross-application support, establish

partnerships with IdM and risk management vendors

BizRight's reliance on theMicrosoft .Net platform may bean issue with non-Microsoftmiddleware and infrastructure

LogicalA pps

Oracle,PeopleSoft, and JDEdwards

Strong Oracle integration, fine-grainedcompensating controls, SoD controlsenforced inside the Oracle applicationlevel rather than through a proprietaryEACM interface

Limited support for PeopleSoftand SAP environment;integration with IdM systems isunproven in the market

14



15/29

Oracle Oracle Strong internal controls for Oracle E-Business Suite customers, integratedIdM strategy, strong GRC vision

EACM features limited to OracleE-Business Suite; access controlsand SoD controls are disjointed

until the GRC application suite isreleased

SAP Hyperion, JDEdwards,Oracle,PeopleSoft,SAP

Comprehensive feature set, strong policylibrary for cross-application support,

backed by SAP

Reliance on the SAP NetWeaver platform; long-term cross-application support may be atrisk

Table 1: Notable Vendors in the EACM Market

The EACM market is further segmented by vendors offering access controls versus transaction monitoringtechnologies. Transaction monitoring vendors continuously monitor transactions in the ERP environment,

searching for SoD violations and fraudulent behavior. Although they are not covered in this report, transactionmonitoring technologies may also be integrated with IdM systems. Vendors offering transaction monitoringsolutions include ACL Services and Oversight Systems. The EACM access control vendors covered in this reportoffer some transaction monitoring features—however, not necessarily to the same extent.

The EACM market is composed of small vendors that are seeing rapid growth. Many large, high-profile vendorsare building robust risk and security portfolios. This makes vendors in the EACM market ripe for acquisitions thatcould have significant impact on the market. If Oracle were to acquire an EACM, it would change the EACMmarket dynamic significantly.

Oracle now owns Oracle E-Business Suite, PeopleSoft, JD Edwards, and has announced its intention to purchaseHyperion. If Oracle were to acquire an EACM vendor, the EACM market would likely be dominated by twomajor players: SAP GRC and Oracle. It is not unreasonable to assume that EACM technologies may at some

point be embedded in the ERP application itself or consumed by a larger risk management or security product.

One Burton Group customer is using SAP GRC for provisioning to external systems outside the ERPenvironment. This functionality was not intended for the product, and it is limited in its capabilities. The productmust be highly customized in order to accomplish this integration. However, this integration may be an indicator of SAP's intention to compete more directly in the IdM market. Oracle and SAP are both well positioned tochange the dynamics of the EACM market with their respective application controls and IdM strategies.

Cooperative vs. Competitive

There is some confusion in the market regarding the crossover between IdM, ERM, and EACM technologies.These products all offer access control, account management, workflow, and audit capabilities. However, thedepth and breadth of these capabilities varies significantly. These products should be thought of as cooperativerather than competitive technologies. Table 2 highlights the core functional strengths of each technology set.

Technology

Function

IdM UAM, provisioning, directory services, authentication, and identity audit capabilities

ERM Role mining, definition, and management

15



16/29

EACM Controls automation, management, and monitoring for ERP applications; low-level access controland SoD enforcement for ERP applications

Table 2: IdM, ERM, and EACM Functionality

EACM technologies provide a deeper level of control but are for the most part limited to the ERP environment(some EACM vendors also support legacy and custom applications). In contrast, IdM and ERM technologies

provide limited account or role-level controls but integrate with multiple applications throughout the ITinfrastructure. For more information on ERM functionality, refer to the Identity and Privacy Strategies report, “Understanding Role Management Applications: No Pain, No Gain.”

As described in the “Integration Technologies” section of this report, IdM and EACM technologies are segmented by the capabilities of the respective products. LogicalApps has only recently improved its APIs, which allow for integration with third-party systems such as IdM. SAP and Approva were both built on extensible platforms. Eachof these vendors has established formalized partnerships with both Sun and IBM. The partnerships betweenEACM and ERM vendors are still undefined. As of yet, no formal partnerships have been established, althoughthis type of integration seems highly plausible.

Recommendations

Because organizations are increasingly faced with regulatory, legal, or enterprise mandates, they must automatecontrols within the IT infrastructure wherever feasible. Many organizations have turned to IdM systems toautomate controls. However, these organizations have found that IdM systems have not adequately provided low-level controls for effective SoD enforcement within the ERP infrastructure. These organizations should consider integrating IdM and EACM technologies for a deeper level of control.

As organizations evaluate the necessity and viability of an EACM solution, planners should ask themselvesseveral questions, including:

• What are the organization's regulatory, legal, or enterprise controls and reporting requirements?

• Are the access controls provided by our IdM sufficient, or do we require low-level ERP controls for SoD?

• Do we want to maintain SoD policies in the IdM environment?

• Do we have the resources and knowledge base to define SoD policies for the ERP environment?

• How will ERP role changes be maintained? Who will update ERP roles? What tool will be used?

• What ERP systems are currently running in our environment? Do we require cross-application support?

• Do we have a corporate principle that limits us to a specific ERP vendor?

• What are the underlying access control capabilities of our existing ERP systems?

Organizations governed by a regulatory mandate or with a complex ERP environment should consider the benefits of an EACM system.

As with IdM, EACM deployments can be difficult. Vendors provide predefined SoD policies; however, these policies must be customized to reflect the organization's unique environment. This takes considerableinvolvement from ERP administrators, LOB managers, and IT. This task should not be underestimated. Many

organizations have involved system integrators (SIs) to help with EACM deployments. Approva, SAP, andLogicalApps have trained hundred of SIs to assist with these deployments. SIs provide both EACM and ERPexpertise.

IdM systems do not and should not provide document, risk, and controls management functionality. IdM systemswere designed to gather and aggregate data from disparate sources. When organizations build too muchintelligence into the IdM policy engine, that engine becomes impossible to maintain. It essentially becomes a siloof stale, inaccurate data that introduces (and potentially propagates) new risks into the IT infrastructure.Organizations should look to IdM vendors to build tighter integration with external security and risk managementsolutions such as EACM.

16


http://www.burtongroup.com/Client/Research/Document.aspx?cid=1114


17/29

The Details

The enterprise application controls management (EACM) market is evolving. The ever-growing burden to complywith regulations has accelerated the adoption of EACM technologies. In the subsequent sections Burton Groupdetails the regulatory mandates impacting organizations (specifically, the Sarbanes-Oxley Act [SOX]), thecomplexities of the enterprise resource planning (ERP) privilege model, and vendor-specific EACM offerings.

The Regulatory Impact

Due to highly publicized corporate scandals and fraudulent behavior, many countries have adopted regulationsdesigned to protect employees and investors. These regulations have caused public organizations to implementinternal procedures that ensure accurate financial disclosures.

Organizations often identify regulatory compliance as the primary business driver for implementing an EACMsolution. SOX is known throughout the world for its stringent reporting requirements, as detailed in the “UnitedStates: Sarbanes-Oxley Act of 2002” section of this report. However, a host of regulations throughout the world

dictate similar controls over financial data and reporting requirements, namely, Japan's Financial Instruments andExchange Law (J-SOX), the United Kingdom's Combined Code on Corporate Governance and the TurnbullReport, France's Loi de Sécurité Financière, and Canada's Bill 198/CSA 52-313.

United States: Sarbanes-Oxley Act of 2002

The passage of SOX and subsequent actions by the U.S. Securities and Exchange Commission (SEC) haveimposed significant requirements on organizations, management teams, and auditors. The organizational cost of SOX compliance has spiraled out of control. This is largely due to the complexities of complying with the internalcontrols and reporting mandates dictated in Section 302 and Section 404 of the act. Many organizations haveimplemented EACM solutions that automate controls over financial data.

SOX Section 302: Corporate Responsibility for Financial ReportsSection 302 requires executive and financial officer(s) to certify their quarterly and annual financial reports.Executives must also certify the effectiveness and validity of internal controls within their organization. Thefollowing is an excerpt taken from Section 302, line item 4:

The signing officers— A. are responsible for establishing and maintaining internal controls;

B. have designed such internal controls to ensure that material information relating to the issuer and itsconsolidated subsidiaries is made known to such officers by others within those entities, particularlyduring the period in which the periodic reports are being prepared;

C. have evaluated the effectiveness of the issuer's internal controls as of a date within 90 days prior to thereport; and

D. have presented in the report their conclusions about the effectiveness of their internal controls based

on their evaluation as of that date

The regulation further dictates the requirement to disclose information to auditors that might affect the accuracyof the organization's financial data. Organizations must report deficiencies in the design or operation of internalcontrols and any fraud, whether or not material, that involves management or employees who have a significantrole in the organization's internal controls.

SOX Section 404: Management Assessment of Internal Controls

17



18/29

Section 404 provides further guidance on assessing and certifying internal controls. As with Section 302, it callsfor both management oversight and auditor involvement. The regulation requires each annual report to include aninternal control report. As outlined in Section 404, the internal control report must:

1 State management's responsibility for establishing and maintaining an adequate internal control structure2 Contain an assessment of the effectiveness of the internal control structure and procedures for financial

reporting

Public accounting firms that prepare or issue an audit report for an organization must also attest to and report onthe organization's assessment of internal controls.

The Public Company Accounting Oversight Board (PCAOB) is a private sector, non-profit corporation created bySOX. The PCAOB oversees the auditors of public companies and sets guidelines for completing SOX audits. ThePCAOB guidelines and the SOX regulation itself have been criticized for being too generic—or broad-reaching.The regulation gives little guidance on how to gather data and to what extent companies must report on it. Thishas caused organizations to spend exuberant amounts of money on control mechanisms that span the entireenterprise rather than on key controls. In December 2006, the SEC and PCAOB proposed new guidelines that areintended to help auditors prioritize and narrow the scope of the audit. The PCAOB also recommended the use of

technology to automate controls, thus reducing time and costs.

ERP Privilege Models

Financial, and otherwise sensitive data, is typically stored within ERP systems. ERP systems are highly secureand built with complex privilege models that are designed to keep intruders out. Defining, managing, andmaintaining sufficient access controls within the ERP environment requires in-depth knowledge of the system's

privilege model. The following sections provide a high-level overview of the privilege models found in Oracle E-Business Suite, PeopleSoft, and SAP.

Oracle E-Business Suite

The Oracle E-Business Suite includes a User Account Management (UAM) feature for defining access controls.UAM is implemented in six successive layers that build upon each other. Table 3 provides an overview of eachlayer.

1 FunctionSecurity

Base layer of UAM. Restricts access to menus and menu options, but does not restrict accessto data within a menu.

2 DataSecurity

Restricts the data a user can access and the actions a user can perform.

3 Role BasedAccessControl

Access controls are defined by roles. Roles are assigned to users. Roles can consolidateresponsibilities, permissions, data security policies, and function security policies.

4 DelegatedAdministration

Allows local administrators to perform predefined administrative tasks and manage the usersfor which they are responsible.

5 ProvisioningServices

Defines the registration models that allow users to self-register for system access.

18



19/29

6 Self-Service Once provisioning services are defined, users can request new accounts or additional access.The self-service feature also includes approval routing capabilities.

Table 3: Oracle UAM Layers

Oracle's security model is supported by underlying components—namely, functions, menus, and responsibilities.A function is a registered name for an action in the system. There are executable and non-executable (e.g., radio

buttons) functions on a form. Once functions are created, they are assigned to menus. Functions and menus are, inturn, assigned to responsibilities. Responsibilities define the context for which the user can operate.Responsibilities can be thought of as a privilege or permission set. Oracle E-Business Suite includes predefinedresponsibilities that can be customized to meet the organization's needs.

Most identity management (IdM) systems are capable of creating user accounts and assigning roles within theOracle application. However, fine-grained access privileges are actually maintained through Oracleresponsibilities, menus, and functions. To enforce separation of duties (SoD), EACM solutions interact withOracle functions—the lowest access control level within the application.

PeopleSoft

Security in the PeopleSoft application is controlled by security definitions. Security definitions are composed of three primary components, including permission lists, roles, and user account profiles.

To understand PeopleSoft's permission model, it is important to understand the building blocks of the PeopleSoftenvironment. Users access PeopleSoft through a web browser interface. Users are presented with a navigationalmenu from which they can progress to subsequent pages. Pages contain attributes, records, and executablefunctions that are defined through component interfaces within the PeopleTools development environment.

Permission lists are the building blocks of the PeopleSoft security model. Permission lists store privileges such as page access, PeopleTools access, and sign-on and sign-off times. Permission lists control what applications,development tools, and navigational panes a user will be allowed to access. Read, write, and read/write access todata elements on a page are also configured through permission lists.

Roles are a combination of permission lists. Roles link permission lists to user profiles. Multiple permission listscan be assigned to roles. Once roles are defined, they are linked to a user profile (the user object). Users can beassigned multiple roles.

The complexity of the PeopleSoft privilege model is due in part to thousands of role definitions in the application.Understanding the inherent permissions of each role within the PeopleSoft environment requires intimateknowledge of the system and its functionality. IdM vendors can typically assign user profiles and roles. However,EACM solutions provide an additional layer of control through in-depth knowledge of roles and the underlying

permission sets. EACM solutions include predefined SoD libraries that detect and prevent lethal rolecombinations within the PeopleSoft environment.

SAP

The SAP privilege model comprises several components, including object class, authorization objects,authorizations, profiles, roles, and user master records. Users log on to the SAP system with a user master record.A user master record must contain one or more roles, which determine the user's access privileges. This concept isfairly straightforward; however, the underlying components of the SAP privilege model are much more complex.

19



20/29

Users perform activities in the SAP system by executing transactions. Each time a transaction is started, the SAPsystem performs an authorization check to ensure that the user has appropriate rights to perform requested action.Authorization objects define the fields that are required to execute a transaction or function in the system. For example, the authorization object “G/L Account: Authorization for company codes” includes the fields “CompanyCode” and “Activity.” Authorization objects can be divided into object classes for clarity. Authorization objectclass names typically correspond to the underlying SAP application (e.g., Human Resources and FinancialAccounting).

Where authorization objects define the fields, authorizations define the permissible field values. Multipleauthorizations can exist for each authorization object. Continuing the example above, the authorizations datamight include the following:

Field Fieldvalue

Activity 1(create)

CompanyCode

200

Note: “Activity” defines the action the user can perform, such as create, modify, delete, or view.

Authorization profiles are collection of authorizations. Profiles are very similar to traditional permission sets inthat they are a collection of corresponding privileges. Authorization profiles are associated with user roles.Administrators can assign profiles or roles to user master records.

IdM systems typically provision and manage SAP user master records, including role and profile information.However, like PeopleSoft applications, SAP applications include thousands of roles, profiles, and authorizations.EACM solutions are better able to manage fine-grained access control and SoD within the SAP environment.

EACM Product Details

The EACM market is specialized, with only a handful of vendors in this space, including Approva, ControlSoftware International Distribution, D2C Solutions, LogicalApps, Oracle, and SAP. This report highlightsApprova, LogicalApps, and SAP due to their large presence in the market. Oracle is also highlighted in thisreport. However, Oracle does not deliver a stand-alone EACM solution. Nevertheless, when selecting an EACMsolution, it is important to understand the company's access control, SoD, and security strategy.

Approva

Founded in Reston, Virginia in 2001, Approva is a privately held company with over 200 employees based in theUnited States, Europe, Asia, and India. Its over 130 customers represent various industries, including consumer

products, retail, energy, pharmaceutical, biotech, telecom, media, technology, manufacturing, transportation, andthe public sector.

Approva is closely aligned with the major audit firms Deloitte, Ernst & Young, KPMG, PricewaterhouseCoopers,Grant Thornton, and Protiviti. There are over 800 Approva Certified Professionals across these major audit firms.The company has also formed strategic partnerships with platform vendors, including Oracle (including Hyperionand PeopleSoft), SAP, and Microsoft.

20



21/29

Approva has focused development efforts on controls management, continuous monitoring, and audittechnologies. Approva is a cross-application system with support for Oracle, SAP, PeopleSoft, JD Edwards,Hyperion, legacy, and custom applications. The company provides services across five major control areas:general computing controls, user access controls, configurable controls, master data controls, and transaction-level controls. Organizations can use Approva's solution to manage SoD, design and maintain ERP roles, monitor user activity, enable compliant user provisioning, simulate changes with “what if” scenario testing, manageemergency or privileged access, monitor sensitive transactions, and support new ERP deployments.

Approva's product suite consists of Insights, which address various aspects of these controls. All Insights run onApprova's BizRights Continuous Controls Monitoring (CCM) platform and can be integrated with one another.Figure 6 illustrates Approva's product suite. Organizations purchase the BizRights platform and then select theInsights that address their particular business needs. Insights contain rules (or corporate policies) and reports thatare presented in a business-friendly, human-readable format so that nontechnical, cross-functional groups canmanage controls, even if they don't have deep ERP expertise.

Figure 6: Approva BizRights Platform Architecture (Source: Approva)

The BizRights CCM Platform is an open, services-oriented platform. It provides the underlying technologyrequired to analyze and continuously monitor controls. BizRights CCM can analyze information from all major ERP and financial systems.

Approva provides prebuilt adapters to SAP, Oracle, PeopleSoft, JD Edwards, and Hyperion. The adapters extractdata from the participating ERP application. Approva's Integration Studio, Adapter Studio, and Insight Studio arewizard-driven tools used to extend the functionality of BizRights CCM by integrating with custom and legacyapplications as well as with related compliance applications such as IDM solutions and controls documentationsystems.

21



22/29

Approva's Insights are commonly integrated with an organization's identity management solutions. TheAuthorizations Insight component monitors and enforces SoD and sensitive access policies. It continuouslymonitors access rights across an organization's financial, ERP, and legacy systems, looking for risks based on

predefined rules. It ensures that combinations of access rights across multiple applications do not cause security or compliance violations. It includes a library of customizable predefined rules, reports, and alerts. Predefined rulesfor SoD violations map to the lowest level of ERP authorizations (e.g., SAP transaction codes, authorizationobjects, and field values).

Authorizations Insight also prevents new issues by simulating changes before they are committed. The simulationutility provides a “what if” analysis that can detect potential violations and prevent the change from provisioningto the ERP system. The Authorizations Insight is a common integration point for IdM systems. For example, a

provisioning event that includes an ERP user change request can be sent to the Authorizations Insight, which runsa “what if” simulation on the requested change. The simulation ensures that the event does not introduce acontrols violation such as a SoD risk. The Authorizations Insight returns notification of a pass or fail status to the

provisioning system, which either continues provisioning the event to the ERP system or appropriately handlesthe issue.

Access Management Insight provides workflow-based approval templates for managing change requests,

including user creation, role assignment, role modification, and privileged user access. Once a workflow isapproved, the change is automatically executed in the ERP application. Access Management Insight works withAuthorizations Insight to simulate all proposed changes and provisioning activities to determine what impact therequested change will have on the application. Access Management Insight enables self-service ERP account

password resets. It also manages emergency access requests by temporarily assigning roles directly to pre-approved users and monitoring their activity. It provides a complete audit trail of all activity of superusers for reporting purposes.

Together, Access Management Insight and Authorizations Insight support a closed-loop remediation process, sothat if an SoD risk is identified, the appropriate manager is notified and given options to allow the access andassign a compensating control, disallow the access, or request a change in the role design. All this is managedthrough workflow. When a control violation is detected, it triggers remediation activities by alerting thedesignated approver with an e-mail that contains a report—or a link to an online report—which provide details onthe cause of the violation and recommendations on how to address the issue.

Approva's Role Designer provides information on existing role definitions and security models within ERPapplications. It provides a sandbox for correlating, comparing, designing, and simulating roles and user access

privileges across multiple systems. Role Designer allows administrators to view transaction history and evaluateany proposed changes to role design or provisioning against actual user activity. This allows organizations todefine more appropriate privileges and roles without introducing any SoD or sensitive user access risks into theorganization. Role Designer also synchronizes role changes across systems and documents signoffs and approvalsas a source of record for the audit.

Approva offers other Insights that address the controls monitoring across enterprise applications. User ActivityInsight provides a history of executed transactions, which can be used as compensating controls for users withsensitive access and for audit and reporting purposes. General Computing Controls Insight baselines global best-

practice system configurations and proactively notifies users if a setting changes, such as password policies, or custom programs introduced that could affect user privileges. Approva also offers business process-focusedInsights that monitor process configuration settings, master data, and transactions. These Insights cover the

procure-to-pay, order-to-cash, payroll, and financial close processes. They are useful for monitoring the activityof superusers and users with sensitive access and for identifying any business exceptions, including mistakes, potential fraud or high-risk events that could affect financial statements.

Approva has been a forward-thinking vendor in IdM and EACM integration. The company has several customersthat have integrated BizRights with an IDM solution. Approva has prebuilt connectors to integrate with Sun JavaSystem Identity Manager and IBM Tivoli Identity Manager. Approva works closely with both Sun Microsystemsand IBM and has joint marketing and cooperative sales arrangements in place. In addition, because BizRights isan open, extensible platform, the Integration Studio allows organizations to connect to any other IdM solution,including home-grown applications.

22



23/29

LogicalApps

LogicalApps, headquartered in Irvine, California, is a privately held company founded in 2000. The companyrecently acquired the Integra product line from Applimation. This added to its already growing employee andcustomer base. LogicalApps now has over 140 employees throughout the United States, and over 300 customersrepresenting the aerospace, defense, communications, consumer products, education, technology, and financialindustries.

LogicalApps is an Oracle Certified Partner. The company has also aligned itself with other technology partners,including Sun and Business Objects. LogicalApps has also formed strategic partnerships with leading audit firmssuch as Deloitte, KPMG, PricewaterhouseCoopers, and Protiviti. It has also partnered with system integratorssuch as IBM Global Services, BearingPoint, DLT Solutions, and Fulcrum Information Technology.

LogicalApps' EACM solution, ACTIVE Governance, supports Oracle ERP solutions, including Oracle E-Business Suite and PeopleSoft. It is composed of the three primary ACTIVE components described in Table 4.

Component

Functionality

AccessGovernor

Provides workflow-based access approval. Monitors and enforces access policies such as SoD andmanages temporary or privileged user access.

DataGovernor

Implements controls over data, including master data, configuration data, and transaction data.Tracks all changes in an audit log.

PolicyGovernor

Provides packaged detective analysis of critical transactions with ad hoc authoring capabilities.

Table 4: LogicalApps ACTIVE Governance Modules

The ACTIVE Governance Foundation provides the underlying infrastructure for each of these components,including policy engines, ERP agents, and open application programming interfaces (APIs). The solution alsoincludes a workbench utility that is shared across components. The Workbench provides a risk and controlframework library, administrative and security tools, and a dashboard.

23



24/29

Figure 7: LogicalApps Architectural Diagram (Source: LogicalApps)

Access Governor embeds user access controls within the enterprise application. Access Governor provides preventive, detective, and corrective controls. Its processing lifecycle includes:

• SoD controls management: SoD conflict rules definition, including a library of predefined best-practice SoDcontrols with ad hoc authoring capabilities

• Conflict analysis: SoD analysis engine that evaluates access controls at the lowest application access level,

such as function-level• Simulation/remediation (clean-up): Conflict impact of ERP cleanup simulation (“what if” scenario testing)and prepackaged reports

• Preventive provisioning: Workflow-based enforcement of SoD during access provisioning process

• Compensating controls: Granular forms controls, exception handling, and activity monitoring for sensitive or emergency access

LogicalApps utilizes a preventive and detective policy methodology. Detective policies identify and assist inremediating existing SoD or other access policy violations within the enterprise application. Detective policiescan either be used as controls themselves or as validation of the effectiveness of upstream controls.

Examples of detective policies are Access Governor's Access Monitoring functionality, which provides the abilityto monitor specific users' activities within the enterprise application to ensure that privileged access remains incompliance with policy. Additionally, Policy Governor monitors and tracks critical transaction events in the

application based on defined criteria. Detective policies provide an additional level of control over user activityand functions in the enterprise application.

Access Governor's preventive policies prohibit the provisioning of incorrect access rights. A configuration change(Data Governor) or access provisioning event (Access Governor) can be routed through a predefinedauthorization process prior to the submission of the event to the ERP application. Other policies prevent certainusers from seeing and/or modifying data by hiding fields and values within the forms themselves.

LogicalApps has a formalized integration solution for Sun Identity Manager and Oracle ICM. The company hasalso recently released APIs that will simplify IdM and other third-party integration efforts.

24



25/29

SAP

SAP AG acquired Virsa Systems, Inc in May, 2006. Prior to the acquisition, the two companies had a formal

partnership that included joint sales, marketing, and development projects. SAP GRC Access Control is deployedto over 500 cross-industry customers world-wide.

SAP has established strategic partnerships with several audit firms and deployment partners, includingPricewaterhouseCoopers, Deloitte, Protiviti, and SecureIntegration. SAP is committed to cross-application, cross-

platform solutions for Oracle, PeopleSoft, JD Edwards, Hyperion, as well as legacy and custom applications.

SAP GRC Access Control comprises cross-application access risk analysis, remediation and prevention services,compliant user provisioning, enterprise role management and superuser privilege management. The product hasits roots in the Virsa acquisition.

SAP GRC Access Control enables SoD enforcement; fraud detection through critical transaction, permission,roles, and data monitoring; compliant user provisioning using workflows and “what if” simulations; rolemanagement; and mitigating controls for privileged users. SAP delivers a process methodology that includes three

phases: get clean, stay clean, and stay in control as described in Figure 8.

Figure 8: SAP GRC Access Control – Sustainable Prevention of Separation of Duties Violations (Source: SAP)

The latest release of SAP GRC Access Control is a Java application built on the SAP NetWeaver Platform. Thearchitecture consists of the following components:

• Core Java platform that allows for real-time connectivity to SAP.

• Common GRC repository for rule, risk, control, role, and business process definition. It also stores workflow,remediation, violation, and alert data and an audit log.

• Adapter framework providing connectivity options for both real-time agents (RTAs) and offline file extractionto ERP, legacy, and custom applications.

• Web Dynpro User Interface that supports collaboration, alerting, dashboard, and reporting tools.

SAP GRC Access Control differentiates itself through real-time risk analysis. It delivers pre-built RTAs, which provide real-time connectivity to SAP. RTAs to external enterprise applications such as Oracle, PeopleSoft,Hyperion or JD Edwards are developed by SAP GRC partners. Custom connectors can be built using stored

procedures or web services, or the database can be accessed directly through custom queries.

Application data can also be extracted and accessed offline. SAP provides a file adapter that uploads flat files.SAP's adapter framework establishes connectivity to the enterprise application. The Java application executes theadapters to access user and authorization data.

25



26/29

SAP GRC Access Control is comprised of four functional components as outlined in table 5. Note: Although usedin this document for clarity, SAP has recently eliminated the Virsa naming convention and identifies eachcomponent according to its capabilities as reflected in the SAP GRC Access Control Capability column.

Virsa Component SAP GRC Access ControlCapability

Virsa ComplianceCalibrator

Access-risk analysis andremediation

Virsa Access Enforcer Compliant user provisioning

Virsa Role Expert Enterprise role management

Virsa FireFighter for SAP Privileged-user accountmanagement

Table 5: SAP GRC Access Control components and capabilities

SAP GRC Access Control provides a rules library with pre-defined SoD rules for SAP, PeopleSoft, Oracle, JDEdwards, and Hyperion. These rules are customizable to meet an organizations individual control requirements.SAP GRC Access Control provides detective controls which monitor enterprise applications for existingviolations according to the pre-defined rule set. The solution monitors user privileges for SoD violations. It alsomonitors critical transactions and sensitive data to look for abnormal or fraudulent behavior patterns. Risks areremediated or mitigated according to policy. For example, if SAP GRC Access Control detects a risk, it canremove access or trigger a remediation workflow. Only pre-approved mitigating controls can be assigned toensure that they meet organizational or auditor's standards.

SAP GRC Access Control prevents future risks by automating the access approval process through workflows.Workflow-based user provisioning is provided through what was formerly known as Virsa Access Enforcer.Users request access (new access, changes, password resets, etc.) through a portal application that triggers anapproval workflow. Managers are presented with a risk analysis (“what if” simulation). The manager mustremediate or mitigate any outstanding risks before approving access and physically provisioning the access for theuser.

If an administrative user of the ERP system changes a user's access directly in the ERP system, SAP intercepts therequest and runs a simulation to ensure that the access request does not introduce a violation. If the applicationdetects a risk, the action is blocked and approval workflow is triggered.

The compliant user provisioning component, or Virsa Access Enforcer, is typically the integration point betweenSAP GRC Access Controls and IdM solutions. SAP intercepts the provisioning event from the IdM system,triggers a workflow, and reports a user status back to the IdM system.

SAP GRC Access Control provides an ERP role management application that centralizes role creation and performs risk assessments. It describes roles using common language so that technical and business owners candefine roles. Once roles have been simulated to ensure that the role creation or change does not introduce aviolation, SAP GRC Access Control automatically creates the role in the ERP application.

SAP manages privileged users using what was formerly known as Virsa FireFighter for SAP. When a user in thesystem needs privileged access (e.g. temporarily assigned super-user access) the application assigns a temporaryID that grants regulated access. Every action the user takes is tracked, monitored, and logged. The appropriate

business and technical owners are notified of these actions.

26



27/29

SAP GRC Access Control ensures that managers have control over user access attestation, user access risk reviews, SoD rules, mitigating controls, roles and audit trails for role provisioning, user provisioning, andemergency access. SAP provides audit and reporting tools, including a dashboard with views that arecustomizable according to the role of the user (e.g. administrator, manager, auditor, CxO, etc.). All events arelogged in an audit log and available for reporting. Auditors can validate proper management oversight to ensurecompliance with all policies. This is accomplished by ensuring that all access is properly authorized and that SoDrisks are appropriately mitigated.

Oracle

In March 2007, Oracle announced its GRC application suite, highlighting the company's long-term strategy in thisspace. The GRC application suite is a combination of Oracle's legacy application controls and the content andcontrols management features inherited with its acquisition of Stellent. The suite comprises several components,including:

• Oracle Fusion GRC Intelligence, which provides preconfigured dashboard and reporting tools that enableorganizations to manage performance, identify and remediate potential risks, monitor adherence to regulatory

mandates, and provide detailed compliance reports. These features are available through a dashboard that can be deployed to line of business (LOB) managers.

• Oracle Governance, Risk, and Compliance Manager, which analyzes, monitors, and detects business process risk and controls performance across the enterprise. It identifies control weaknesses and initiatescorrective actions.

• Oracle Application Access Controls provides the ability to detect and prevent access control violations at theapplication level. It delivers a SoD policy library with more than 200 rules for the Oracle E-Business Suite. The

policy library will be expanded in future releases.

• Oracle Application Configuration Controls monitors internal controls for the Oracle E-Business Suite. Itmonitors the application for changes in application configuration controls and allows organizations to setauditable tolerance thresholds across multiple Oracle instances.

These four products are now available as stand-alone products.

Today, Oracle utilizes a combination of technologies to enable access controls and SoD within the E-Busine

Burton Whenprovision

Documents

Transcript of Burton Whenprovision