Burton Whenprovision

Identity and Privacy Strategies
In-Depth Research Report
When Provisioning Isn't Enough: Enterprise

Application Controls Management
Version: 1, May 17, 2007
AUTHOR(S):
Lori Rowland
(Lrowland@burtongroup.com)
TECHNOLOGY THREAD:
Identity Management
Conclusion
The enterprise application controls management (EACM) market is rapidly evolving and
expanding. This growth is, for the most part, due to regulatory pressures. Organizations are
struggling 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 includes
SoD enforcement, ERP role lifecycle changes, workflow-based ERP role and access change
approvals, and risk detection and remediation.
Page: 1
49440
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 leading
vendors and users. Publication headquarters, marketing, and sales offices are located at:
Burton Group
7090 Union Park Center, Suite 200
Midvale, Utah USA 84047-4169
Phone: +1.801.566.2880
Fax: +1.801.566.3611
Toll free in the USA: 800.824.9924
Internet: info@burtongroup.com; www.burtongroup.com
Copyright 2007 Burton Group. ISSN 1048-4620. All rights reserved. All product, technology and service names are
trademarks 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 also
excerpt material from this document provided that they label the document as Proprietary and Confidential and add
the following notice in the document: Copyright 2007 Burton Group. Used with the permission of the copyright
holder. Contains previously developed intellectual property and methodologies to which Burton Group retains
rights. For internal customer use only.
Requests from non-clients of Burton for permission to reprint or distribute should be addressed to the Client
Services 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 Privacy
Strategies 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 Privacy
Strategies 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 receiving
information about becoming a subscriber, please contact Burton Group.
Table Of Contents
Synopsis.......................................................................................................................................................................... 4
Analysis...........................................................................................................................................................................5
IdM vs. EACM............................................................................................................................................................5
Integration Methodology: How Do IdM and EACM Play Together?........................................................................ 6
Methodology 1........................................................................................................................................................ 6
Methodology 2........................................................................................................................................................ 7
Integration Technologies.............................................................................................................................................7
EACM Architecture.................................................................................................................................................... 9
EACM Features.........................................................................................................................................................10
EACM Process Flow.............................................................................................................................................12
Phase 1: Policy Definition.................................................................................................................................13
Phase 2: Risk Detection and Remediation........................................................................................................ 13
Phase 3: Continuous Controls Enforcement..................................................................................................... 13
Phase 4: Audit and Reporting........................................................................................................................... 13
Market Impact........................................................................................................................................................... 13
Market Segmentation............................................................................................................................................ 14
Cooperative vs. Competitive.................................................................................................................................15
Recommendations..................................................................................................................................................... 16
The Details.................................................................................................................................................................... 17
The Regulatory Impact..............................................................................................................................................17
United States: Sarbanes-Oxley Act of 2002......................................................................................................... 17
SOX Section 302: Corporate Responsibility for Financial Reports................................................................. 17
SOX Section 404: Management Assessment of Internal Controls................................................................... 17
ERP Privilege Models............................................................................................................................................... 18
Oracle E-Business Suite........................................................................................................................................18
PeopleSoft............................................................................................................................................................. 19
SAP....................................................................................................................................................................... 19
EACM Product Details............................................................................................................................................. 20
Approva.................................................................................................................................................................20
LogicalApps.......................................................................................................................................................... 23
SAP........................................................................................................................................................................... 25
Oracle.................................................................................................................................................................... 27
Conclusion.................................................................................................................................................................... 28
Author 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
Synopsis
The enterprise application controls management (EACM) market has seen significant growth over the past three
years. This growth is primarily due to increased organizational pressure to comply with regulatory, legal, and
corporate 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 privilege
models 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 granularity
needed to enforce separation of duties (SoD) within an ERP application. Organizations are turning to integrated
IdM and EACM solutions to enable effective controls for compliant provisioning and SoD within ERP
applications.
EACM systems provide fine-grained access control and SoD enforcement within ERP applications. EACM
systems 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 integration
scenario 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 the
ERP application. EACM vendors such as Approva, LogicalApps, and SAP have partnered with IdM vendors to
offer 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 by
integrating IdM, EACM, ERM, risk management, document management, and other audit and security
technologies.
4
Analysis
The Sarbanes-Oxley Act of 2002 (SOX) has had a significant impact on large, publicly traded organizations in the
United 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, as
described 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 and
how it is maintained. However, until recently, financial controls were dictated and managed at the departmental
level. Executives were rarely, if ever, involved in the management or assurance of financial controlsthey were
typically 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 ittheir 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 and
manage compliance processes.
Controlling access to financial or sensitive data is a high priority for regulated organizations. As a result, many
organizations have implemented identity management (IdM) technologies, including provisioning, password
management, and access management solutions. However, as organizations become more controls savvy, they
are 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 controls
automation, management, and transaction monitoring capabilities. These features enable fine-grained access and
separation of duties (SoD) controls for the ERP environment. Each EACM vendor covered in this report has
incorporated years of hands-on experience, ERP knowledge, and research to develop a comprehensive, predefined
SoD 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's
information technology (IT) infrastructure. However, IdM systems do not inherently understand the underlying
intricacies of application privilege models. This is particularly true of ERP applications that have extremely
complex 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 more
granular level than what is traditionally provided by an IdM system. EACM systems enable effective SoD
controls by integrating with ERP systems at the lowest level possible (e.g., transaction-level controls).
5
EACM systems include predefined SoD policies that are consistently applied across all ERP applications within
an 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 risksand most IT
administrators do not possess this knowledge. This is further complicated by the fact that ERP role data is
dynamic. IdM policies must be updated each time an ERP role changes. Maintaining SoD rules in an IdM system
is 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 event
introduces an SoD violation, it may be left undetectedor 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 no
technical safeguards to prevent ERP administrators from entering changes within the ERP application itself (the
exception being LogicalApps, which prevents Oracle SoD violations at the application level). Some EACM
systems 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-level
changes that are left undetected by the EACM system. In this case, IdM systems provide valuable user lifecycle
management and reconciliation capabilities. IdM systems have robust reconciliation features that may be run in
real time or nearreal time. Once detected, the IdM system provisions the change through the EACM system.
Integration Methodology: How Do IdM and EACM Play

Together?
EACM can be thought of as an IdM access control safetynet. Various integration points exist between the two
systems. In a standard IdM environment, the provisioning system sends account create, modify, and delete events
directly to the ERP application. However, in an integrated solution, the provisioning event is sent to the EACM
solution 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 sent
to the EACM system. The proposed change is run through a what if simulation to determine its impact on the
ERP 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 IdM
system. If the event fails, the EACM system also returns supporting root-cause data. The IdM system continues
the provisioning process by committing the event to the ERP system or generating a processing error.
6
Figure 1: EACM Integration Methodology 1
Methodology 2
In the second methodology, provisioning events are generated in the IdM environment and subsequently sent to
the EACM system for processing. The EACM system intercepts the provisioning event and generates an EACM
approval 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 the
ERP environment or generates an error. One disadvantage of releasing the event to the EACM system is that the
IdM 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 EACM
environment.
Figure 2: EACM Integration Methodology 2

The methodology an organization deploys is dependent on the capabilities of its respective IdM and EACM
technologies, as described in the Integration Technologies section of this report. The true value-add of both
integration methodologies is the ability to simulate changes and prevent SoD violations before committing the
change to the ERP environment.
Integration Technologies
7
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 build
custom connectors to legacy or external systems. IdM systems are, for the most part, open and
extensiblecustomers 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 and
EACM vendors are working together to build customized solutions for high-profile customers. To date, Sun
Microsystems and IBM are currently the only vendors with a productized solution. These vendors have
established formal reseller or developer partnerships with both Approva and SAP. Other IdM vendors, including
CA, 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 integration
methodology for the two systems is quite different. Sun extends the capabilities of its existing Sun Java System
Identity Manager SAP adapter to integrate with SAP GRC. The SAP adapter has a configuration option that
enables 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 the
event and continues the provisioning process. Because Sun is communicating with SAP GRC via the SAP
adapter, the Sun/SAP GRC integration is limited to the SAP ERP environment. Sun's integration with SAP GRC
is analogous withintegration methodology 2, as described in the Integration Methodology: How Do IdM and
EACM Play Together? section of this report.
In contrast, Approva provides the adapter for integration with Sun Identity Manager. ERP workflows are
configured in Sun Identity Manager. As Identity Manager receives ERP provisioning events, it triggers a
workflow-based web service call to Approva's BizRights platform. Approva checks the request for SoD violations
and returns a processing status to Sun Identity Manager. This solution is customizable; Approva can intercept and
then integrate the event into its workflow-based provisioning process. Customers may also choose to take a hybrid
approach and combine the various optionsin this scenario, Approva would intercept only events that fail the
simulation. The Approva adapter for Sun Identity Manager provides SoD controls for SAP, Oracle, and
PeopleSoft. 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's
workflow 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 delivered
through 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 SAP
adapter handles self-service password resets, provisioning of extended account attributes not supported in SAP
GRC, and reconciliation of ERP account data for continuous compliance monitoring of actual permissions versus
approved permissions. However, all ERP provisioning events containing role or access changes are processed
through 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. Many
IdM vendors have included a productized EACM integration solution on their short-term roadmaps. As these
relationships 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 the
EACM vendor, while others are provided by the IdM vendor. As a result, the functionality and application
support varies from one integrated solution to another.
8
Another area for improvement is expanding integration support to include additional EACM systems. Most IdM
vendors 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 a
high 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 .Net
framework.
Most EACM technologies make a footprint on the ERP application, typically in the form of SAP Advanced
Business 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. The
EACM system is dependent on the functionality of the ERP application; therefore, most analysis and monitoring
are performed in batch mode rather than in real time. For example, ABAP programs that collect data are run in
scheduled 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 impact
on the performance of the underlying ERP system. Once the EACM system has gathered privilege data from the
ERP system, it is stored in the EACM repository.
9
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 that
supports 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 policy
model, 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 connectivity
information. These adapters are not necessarily intelligent. Policies are defined, stored, and executed on the
server rather than at the adapter level. The adapter acts as a transport and communication layer. SDKs for building
custom 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 allow
organizations to push the normally tedious process of defining, approving, managing, and auditing ERP access
controls 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 the
organization 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 ERP
environment. Each vendor covered in this report has incorporated years of hands-on ERP experience and research
into 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 comprehensive
library of predefined access control and SoD policies. These policies are a permutation of in-depth knowledge
of business risks (e.g., create vendor vs. pay vendor), ERP roles and privileges, and system-level transactions
and functions. Role definitions and policies in the library are presented in a human-readable format that is
meaningful 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 span
multiple ERP applications, as shown in Figure 4.
10
Figure 4: Cross-Functional, Cross-Application SoD Policies

EACM policy libraries contain thousands of SoD policy definitions. However, not every SoD policy
definition is relevant to every organization. This is largely due to the fact that organizations typically only
utilize a portion of the default roles available within the ERP system. Most organizations customize and
create 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 entitlement
data and the resulting output is analyzed. The system detects existing violations and triggers a remediation
workflow.
Request-driven, workflow-based user provisioning: EACM systems serve as the gatekeeper to the ERP
environment. 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 is
made, the system triggers an approval workflow.
The approving manager can accept the access request or run a what if simulation to ensure that the access
request does not pose a potential risk. Some EACM systems automatically run the simulation and provide the
resulting 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 combat
violations introduced by back-door or database-level changes. For example, if access is changed at the system
or database level, some EACM systems intercept the request and run a what if simulation to ensure that the
request does not introduce a violation. If the system detects a potential violation, it rejects the request and
creates an approval workflow. However, if the what if simulation does not detect a violation, the access
change is made and the event is recorded in the EACM audit log. If the EACM system does not intercept
system-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
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 entered
and approved in another (e.g., Oracle). The SoD policy must be applied across multiple applications (SAP and
Oracle, in this example). EACM solutions utilize a centralized repository to aggregate roles and permissions
and consistently apply policy across multiple systems.
Compensating controls for privileged accounts: In an ideal world, organizations are able to enforce SoD by
appropriately 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 include
accounts needed for emergency access and delegated administration, and all other accounts created with control
exceptions. Auditors require that organizations mitigate, document, audit, and manage these accounts.
Compensating controls are used to minimize the risks associated with privileged user accounts. Compensating
controls 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 that
ERP 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 simulation
tools. These tools simulate access control changes and identify potential risks before committing changes to the
ERP environment. Users, administrators, managers, ERP systems, and third-party systems can interact with
simulation tools.
Critical transaction monitoring: Defining and managing access controls is the primary function of EACM
systems. 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 an
organization to monitor user activity by business function or transaction, rather than by user. For example, a
manager 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 critical
transactions are tracked, logged, and audited. It is important to note that this is a detective control. Transaction
report 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 log
that is available for reporting purposes. Audit logs and reporting tools are valuable to management and auditors
during the audit process. EACM reporting tools allow organizations to identify risks and remediate them. Some
EACM systems provide web-based reporting tools that walk the administrator through the remediation process
with 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
Phase 1: Policy Definition

Organizations must define business processes, risks, and access controls relative to their environment. From this
information, 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 EACM
deployment.
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 library
is defined. Violations are detected, analyzed, and corrected by applying EACM policies to existing privileges
within 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 activity
and 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, and
auditors.
Market Impact
Companies are increasingly burdened with regulatory compliance initiatives and reporting requirements. Software
vendors 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 not
use 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. In
this report, the EACM market is further divided to include only those vendors that offer access and SoD controls
for the ERP environment. Clearly, this market niche is very small and highly specialized. Vendors in this market
include 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 technologies
are 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 are
highlighted 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 system
with authentication, provisioning, password management, and auditing capabilities for multiple applications
throughout the IT infrastructure. However, organizations are now looking to optimize controls.
13
The underlying business driver for an integrated IdM and EACM solution is controls optimization. Organizations
are looking to take the existing controls provided by their IdM system to the next level. There is also an increased
need for automated, repeatable, and sustainable processes. An integrated solution is ideal for organizations
looking to simplify SoD policy definition, role maintenance, and access control enforcement for the ERP
environment.
Market Segmentation
The EACM market is mostly composed of large, enterprise-level customers, due to the fact that these
organizations are beholden to SOX and other regulatory requirements. Moreover, EACM systems are specifically
designed 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's
ERP 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 detailed
SoD libraries. These vendors provide SoD policies for SAP, PeopleSoft, Oracle, JD Edwards, and Hyperion
Solutions.
SAP acquired Virsa Systems in 2006. These technologies are now known as SAP GRC Access Control (SAP
GRC). 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 reengineered to run in Java on the SAP NetWeaver server platform. Non-SAP customers may be hesitant to use an
EACM application dependent on or tightly linked to SAP NetWeaverno matter how small the imprint.
On the flip side, Approva is challenged with establishing itself as a viable solution for customers committed to the
SAP 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 positioned
to 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. Table
1 provides a high-level overview of the strengths and challenges for each vendor in this space.
Vendor
Crossapplication
support
Strengths
Challenges
Approva
Hyperion, JD
Edwards,
Oracle,
PeopleSoft,
SAP
Comprehensive feature set, crossapplication support, establish

partnerships with IdM and risk
management vendors
BizRight's reliance on the

Microsoft .Net platform may be
an issue with non-Microsoft
middleware and infrastructure
LogicalA
pps
Oracle,PeopleS
oft, and JD
Edwards
Strong Oracle integration, fine-grained

compensating controls, SoD controls
enforced inside the Oracle application
level rather than through a proprietary
EACM interface
Limited support for PeopleSoft

and SAP environment;
integration with IdM systems is
unproven in the market
14
Oracle
Oracle
Strong internal controls for Oracle EBusiness Suite customers, integrated

IdM strategy, strong GRC vision
EACM features limited to Oracle

E-Business Suite; access controls
and SoD controls are disjointed
until the GRC application suite is
released
SAP
Hyperion, JD
Edwards,
Oracle,
PeopleSoft,
SAP
Comprehensive feature set, strong policy

library for cross-application support,
backed by SAP
Reliance on the SAP NetWeaver

platform; long-term crossapplication support may be at
risk
Table 1: Notable Vendors in the EACM Market

The EACM market is further segmented by vendors offering access controls versus transaction monitoring
technologies. 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, transaction
monitoring technologies may also be integrated with IdM systems. Vendors offering transaction monitoring
solutions include ACL Services and Oversight Systems. The EACM access control vendors covered in this report
offer some transaction monitoring featureshowever, not necessarily to the same extent.
The EACM market is composed of small vendors that are seeing rapid growth. Many large, high-profile vendors
are building robust risk and security portfolios. This makes vendors in the EACM market ripe for acquisitions that
could have significant impact on the market. If Oracle were to acquire an EACM, it would change the EACM
market dynamic significantly.
Oracle now owns Oracle E-Business Suite, PeopleSoft, JD Edwards, and has announced its intention to purchase
Hyperion. If Oracle were to acquire an EACM vendor, the EACM market would likely be dominated by two
major 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 ERP
environment. This functionality was not intended for the product, and it is limited in its capabilities. The product
must 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 to
change 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, the
depth and breadth of these capabilities varies significantly. These products should be thought of as cooperative
rather than competitive technologies. Table 2 highlights the core functional strengths of each technology set.
Technolo
gy
Function
IdM
UAM, provisioning, directory services, authentication, and identity audit capabilities
ERM
Role mining, definition, and management
15
EACM
Controls automation, management, and monitoring for ERP applications; low-level access control
and 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 IT
infrastructure. 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. Each
of these vendors has established formalized partnerships with both Sun and IBM. The partnerships between
EACM and ERM vendors are still undefined. As of yet, no formal partnerships have been established, although
this type of integration seems highly plausible.
Recommendations
Because organizations are increasingly faced with regulatory, legal, or enterprise mandates, they must automate
controls within the IT infrastructure wherever feasible. Many organizations have turned to IdM systems to
automate controls. However, these organizations have found that IdM systems have not adequately provided lowlevel 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 themselves
several 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 considerable
involvement 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, and
LogicalApps have trained hundred of SIs to assist with these deployments. SIs provide both EACM and ERP
expertise.
IdM systems do not and should not provide document, risk, and controls management functionality. IdM systems
were designed to gather and aggregate data from disparate sources. When organizations build too much
intelligence into the IdM policy engine, that engine becomes impossible to maintain. It essentially becomes a silo
of 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 management
solutions such as EACM.
16
The Details
The enterprise application controls management (EACM) market is evolving. The ever-growing burden to comply
with regulations has accelerated the adoption of EACM technologies. In the subsequent sections Burton Group
details the regulatory mandates impacting organizations (specifically, the Sarbanes-Oxley Act [SOX]), the
complexities 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 regulations
designed to protect employees and investors. These regulations have caused public organizations to implement
internal procedures that ensure accurate financial disclosures.
Organizations often identify regulatory compliance as the primary business driver for implementing an EACM
solution. SOX is known throughout the world for its stringent reporting requirements, as detailed in the United
States: 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 and
Exchange Law (J-SOX), the United Kingdom's Combined Code on Corporate Governance and the Turnbull
Report, France's Loi de Scurit Financire, 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) have
imposed 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 internal
controls and reporting mandates dictated in Section 302 and Section 404 of the act. Many organizations have
implemented EACM solutions that automate controls over financial data.
SOX Section 302: Corporate Responsibility for Financial Reports

Section 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. The
following 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 its
consolidated subsidiaries is made known to such officers by others within those entities, particularly
during 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 the
report; 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 accuracy
of the organization's financial data. Organizations must report deficiencies in the design or operation of internal
controls and any fraud, whether or not material, that involves management or employees who have a significant
role in the organization's internal controls.
SOX Section 404: Management Assessment of Internal Controls

17
Section 404 provides further guidance on assessing and certifying internal controls. As with Section 302, it calls
for both management oversight and auditor involvement. The regulation requires each annual report to include an
internal control report. As outlined in Section 404, the internal control report must:
1
2
State management's responsibility for establishing and maintaining an adequate internal control structure
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 on
the organization's assessment of internal controls.
The Public Company Accounting Oversight Board (PCAOB) is a private sector, non-profit corporation created by
SOX. The PCAOB oversees the auditors of public companies and sets guidelines for completing SOX audits. The
PCAOB guidelines and the SOX regulation itself have been criticized for being too genericor broad-reaching.
The regulation gives little guidance on how to gather data and to what extent companies must report on it. This
has caused organizations to spend exuberant amounts of money on control mechanisms that span the entire
enterprise rather than on key controls. In December 2006, the SEC and PCAOB proposed new guidelines that are
intended 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 secure
and built with complex privilege models that are designed to keep intruders out. Defining, managing, and
maintaining 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 EBusiness 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 each
layer.
1 Function
Security
Base layer of UAM. Restricts access to menus and menu options, but does not restrict access
to data within a menu.
2 Data
Security
Restricts the data a user can access and the actions a user can perform.
3 Role Based
Access
Control
Access controls are defined by roles. Roles are assigned to users. Roles can consolidate
responsibilities, permissions, data security policies, and function security policies.
4 Delegated
Administrati
on
Allows local administrators to perform predefined administrative tasks and manage the users
for which they are responsible.
5 Provisioning
Services
Defines the registration models that allow users to self-register for system access.
18
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 componentsnamely, 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, in
turn, 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 predefined
responsibilities 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 the
Oracle application. However, fine-grained access privileges are actually maintained through Oracle
responsibilities, menus, and functions. To enforce separation of duties (SoD), EACM solutions interact with
Oracle functionsthe 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 PeopleSoft
environment. Users access PeopleSoft through a web browser interface. Users are presented with a navigational
menu from which they can progress to subsequent pages. Pages contain attributes, records, and executable
functions 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 to
data 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 lists
can be assigned to roles. Once roles are defined, they are linked to a user profile (the user object). Users can be
assigned 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 intimate
knowledge 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 role
combinations 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 is
fairly straightforward; however, the underlying components of the SAP privilege model are much more complex.
19
Users perform activities in the SAP system by executing transactions. Each time a transaction is started, the SAP
system 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 Company
Code and Activity. Authorization objects can be divided into object classes for clarity. Authorization object
class names typically correspond to the underlying SAP application (e.g., Human Resources and Financial
Accounting).
Where authorization objects define the fields, authorizations define the permissible field values. Multiple
authorizations can exist for each authorization object. Continuing the example above, the authorizations data
might include the following:
Field
Field
value
Activity
1
(create)
Company
Code
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 in
that 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, Control
Software International Distribution, D2C Solutions, LogicalApps, Oracle, and SAP. This report highlights
Approva, LogicalApps, and SAP due to their large presence in the market. Oracle is also highlighted in this
report. However, Oracle does not deliver a stand-alone EACM solution. Nevertheless, when selecting an EACM
solution, 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 the
United States, Europe, Asia, and India. Its over 130 customers represent various industries, including consumer
products, retail, energy, pharmaceutical, biotech, telecom, media, technology, manufacturing, transportation, and
the 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 Hyperion
and PeopleSoft), SAP, and Microsoft.
20
Approva has focused development efforts on controls management, continuous monitoring, and audit
technologies. 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 transactionlevel 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, manage
emergency 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 on
Approva'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 the
Insights that address their particular business needs. Insights contain rules (or corporate policies) and reports that
are presented in a business-friendly, human-readable format so that nontechnical, cross-functional groups can
manage 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 technology
required 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 extract
data from the participating ERP application. Approva's Integration Studio, Adapter Studio, and Insight Studio are
wizard-driven tools used to extend the functionality of BizRights CCM by integrating with custom and legacy
applications as well as with related compliance applications such as IDM solutions and controls documentation
systems.
21
Approva's Insights are commonly integrated with an organization's identity management solutions. The
Authorizations Insight component monitors and enforces SoD and sensitive access policies. It continuously
monitors 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 rules
for SoD violations map to the lowest level of ERP authorizations (e.g., SAP transaction codes, authorization
objects, and field values).
Authorizations Insight also prevents new issues by simulating changes before they are committed. The simulation
utility provides a what if analysis that can detect potential violations and prevent the change from provisioning
to 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 runs
a what if simulation on the requested change. The simulation ensures that the event does not introduce a
controls 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 handles
the 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 is
approved, the change is automatically executed in the ERP application. Access Management Insight works with
Authorizations Insight to simulate all proposed changes and provisioning activities to determine what impact the
requested 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 preapproved 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, so
that if an SoD risk is identified, the appropriate manager is notified and given options to allow the access and
assign a compensating control, disallow the access, or request a change in the role design. All this is managed
through workflow. When a control violation is detected, it triggers remediation activities by alerting the
designated approver with an e-mail that contains a reportor a link to an online reportwhich provide details on
the 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 ERP
applications. 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 evaluate
any proposed changes to role design or provisioning against actual user activity. This allows organizations to
define more appropriate privileges and roles without introducing any SoD or sensitive user access risks into the
organization. Role Designer also synchronizes role changes across systems and documents signoffs and approvals
as a source of record for the audit.
Approva offers other Insights that address the controls monitoring across enterprise applications. User Activity
Insight provides a history of executed transactions, which can be used as compensating controls for users with
sensitive access and for audit and reporting purposes. General Computing Controls Insight baselines global bestpractice 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-focused
Insights 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 activity
of 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 customers
that have integrated BizRights with an IDM solution. Approva has prebuilt connectors to integrate with Sun Java
System Identity Manager and IBM Tivoli Identity Manager. Approva works closely with both Sun Microsystems
and IBM and has joint marketing and cooperative sales arrangements in place. In addition, because BizRights is
an open, extensible platform, the Integration Studio allows organizations to connect to any other IdM solution,
including home-grown applications.
22
LogicalApps
LogicalApps, headquartered in Irvine, California, is a privately held company founded in 2000. The company
recently acquired the Integra product line from Applimation. This added to its already growing employee and
customer base. LogicalApps now has over 140 employees throughout the United States, and over 300 customers
representing the aerospace, defense, communications, consumer products, education, technology, and financial
industries.
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 firms
such as Deloitte, KPMG, PricewaterhouseCoopers, and Protiviti. It has also partnered with system integrators
such as IBM Global Services, BearingPoint, DLT Solutions, and Fulcrum Information Technology.
LogicalApps' EACM solution, ACTIVE Governance, supports Oracle ERP solutions, including Oracle EBusiness Suite and PeopleSoft. It is composed of the three primary ACTIVE components described in Table 4.
Compon
ent
Functionality
Access
Governor
Provides workflow-based access approval. Monitors and enforces access policies such as SoD and
manages temporary or privileged user access.
Data
Governor
Implements controls over data, including master data, configuration data, and transaction data.
Tracks all changes in an audit log.
Policy
Governor
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 also
includes a workbench utility that is shared across components. The Workbench provides a risk and control
framework library, administrative and security tools, and a dashboard.
23
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 SoD
controls 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 in
remediating existing SoD or other access policy violations within the enterprise application. Detective policies
can 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 ability
to monitor specific users' activities within the enterprise application to ensure that privileged access remains in
compliance 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 activity
and 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 predefined
authorization process prior to the submission of the event to the ERP application. Other policies prevent certain
users 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 has
also recently released APIs that will simplify IdM and other third-party integration efforts.
24
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 deployed
to over 500 cross-industry customers world-wide.
SAP has established strategic partnerships with several audit firms and deployment partners, including
PricewaterhouseCoopers, Deloitte, Protiviti, and SecureIntegration. SAP is committed to cross-application, crossplatform 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 has
its 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; role
management; 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. The
architecture 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 extraction
to 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 the
adapters to access user and authorization data.
25
SAP GRC Access Control is comprised of four functional components as outlined in table 5. Note: Although used
in this document for clarity, SAP has recently eliminated the Virsa naming convention and identifies each
component according to its capabilities as reflected in the SAP GRC Access Control Capability column.
Virsa Component
SAP GRC Access Control

Capability
Virsa Compliance
Calibrator
Access-risk analysis and

remediation
Virsa Access Enforcer
Compliant user provisioning
Virsa Role Expert
Enterprise role management
Virsa FireFighter for SAP
Privileged-user account
management
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, JD
Edwards, 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 existing
violations according to the pre-defined rule set. The solution monitors user privileges for SoD violations. It also
monitors critical transactions and sensitive data to look for abnormal or fraudulent behavior patterns. Risks are
remediated or mitigated according to policy. For example, if SAP GRC Access Control detects a risk, it can
remove access or trigger a remediation workflow. Only pre-approved mitigating controls can be assigned to
ensure 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 an
approval workflow. Managers are presented with a risk analysis (what if simulation). The manager must
remediate or mitigate any outstanding risks before approving access and physically provisioning the access for the
user.
If an administrative user of the ERP system changes a user's access directly in the ERP system, SAP intercepts the
request and runs a simulation to ensure that the access request does not introduce a violation. If the application
detects 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 between
SAP 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 can
define roles. Once roles have been simulated to ensure that the role creation or change does not introduce a
violation, 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 the
system needs privileged access (e.g. temporarily assigned super-user access) the application assigns a temporary
ID 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
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, and
emergency access. SAP provides audit and reporting tools, including a dashboard with views that are
customizable according to the role of the user (e.g. administrator, manager, auditor, CxO, etc.). All events are
logged in an audit log and available for reporting. Auditors can validate proper management oversight to ensure
compliance with all policies. This is accomplished by ensuring that all access is properly authorized and that SoD
risks are appropriately mitigated.
Oracle
In March 2007, Oracle announced its GRC application suite, highlighting the company's long-term strategy in this
space. The GRC application suite is a combination of Oracle's legacy application controls and the content and
controls 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 enable
organizations 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 initiates
corrective actions.
Oracle Application Access Controls provides the ability to detect and prevent access control violations at the
application 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. It
monitors the application for changes in application configuration controls and allows organizations to set
auditable 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-Business
Suite as well as other ERP applications. These technologies include Oracle E-Business Suite's Application Access
Controls (AAC), Oracle Identity Manager, and Oracle Database Vault.
The Oracle E-Business Suite AAC allows organizations to define SoD policies based on role, responsibility, and
function. AAC enables detective and preventive controls. It allows organizations to define granular detective
controls that identify which users are currently in violation of policy, where that violation occurs within the EBusiness Suite, who granted the role or responsibility, and when it was granted.
AAC also provides preventive controls that enforce SoD controls during a user creation event or when the users'
roles change. The Oracle E-Business Suite user management function calls AAC to check adherence to SoD
policies. If it detects a risk, it prevents the creation or change event. These features are limited to Oracle EBusiness Suite; AAC does not currently support PeopleSoft or JD Edwards.
The Oracle Database Vault also provides access control and security features. This relatively new product allows
organizations to lock down key subsets of data within the database so that authorized individuals can view or
copy only information pertinent to their job role.
Oracle Identity Manager provides access control and SoD functionality for Oracle and non-Oracle systems. Refer
to the Identity and Privacy Strategies Product Profile document, Oracle Identity Manager, for further details on
Oracle's IdM capabilities. Oracle Identity Manager can be extended to integrate with third-party EACM systems.
27
Conclusion
The enterprise application controls management (EACM) market is rapidly evolving and expanding. This growth
is, for the most part, due to regulatory pressures. Organizations are struggling 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 includes SoD
enforcement, ERP role lifecycle changes, workflow-based ERP role and access change approvals, and risk
detection and remediation.
28
Author Bio
Lori Rowland
Analyst
Emphasis: Identity management, provisioning, directories
Background: Over 10 years of experience in the Information Technology field with expertise in ERP applications,
business process design, directory services, identity management and provisioning. Previously part of Novell's
Secure Identity Management development team as DirXML Deployment Manager. Experience deploying identity
driven solutions for national and international enterprise organizations.
Primary Distinctions: Frequent speaker at industry events including BrainShare and PeopleSoft's end-user
conference.
29

Burton Whenprovision

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Burton Whenprovision

Încărcat de

Drepturi de autor:

Formate disponibile

Identity and Privacy Strategies

In-Depth Research Report

When Provisioning Isn't Enough: Enterprise

A predefined SoD policy library

IdM vs. EACM

Integration Methodology: How Do IdM and EACM Play

Figure 1: EACM Integration Methodology 1

Figure 2: EACM Integration Methodology 2

Figure 3: EACM Architecture

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

EACM Process Flow

Figure 5: EACM Process Flow Diagram

Phase 1: Policy Definition

Phase 2: Risk Detection and Remediation

Phase 3: Continuous Controls Enforcement

Phase 4: Audit and Reporting

Comprehensive feature set, crossapplication support, establish

BizRight's reliance on the

Strong Oracle integration, fine-grained

Limited support for PeopleSoft

Strong internal controls for Oracle EBusiness Suite customers, integrated

EACM features limited to Oracle

Comprehensive feature set, strong policy

Reliance on the SAP NetWeaver

Table 1: Notable Vendors in the EACM Market

Cooperative vs. Competitive

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

Role mining, definition, and management

Table 2: IdM, ERM, and EACM Functionality

The Regulatory Impact

United States: Sarbanes-Oxley Act of 2002

SOX Section 302: Corporate Responsibility for Financial Reports

SOX Section 404: Management Assessment of Internal Controls

ERP Privilege Models

Oracle E-Business Suite

Table 3: Oracle UAM Layers

EACM Product Details

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

Table 4: LogicalApps ACTIVE Governance Modules

Figure 7: LogicalApps Architectural Diagram (Source: LogicalApps)

SAP GRC Access Control

Access-risk analysis and

Virsa Access Enforcer

Compliant user provisioning

Virsa Role Expert

Enterprise role management

Virsa FireFighter for SAP

Table 5: SAP GRC Access Control components and capabilities

S-ar putea să vă placă și