sap grc 10.1 - access control project lessons · pdf filesap grc components implemented 4 sap...
TRANSCRIPT
SAP GRC 10.1 - Access Control Project
Lessons Learned
January 2015
Big Picture: Identity Management and Access Control
2
Compliance Check
Remediation
Position
User
SRM
BOBJ
Non SAP
Systems
New Hire /
Change Position
SAP HCM (HR)
HR Master record
Position Based
Access
SAP NetWeaver
Identity Management
Calculates Entitlements
Based on Position
SAP GRC
Access Control
Compliance Check
& Remediation
Line Manager
Approve Assignments
Create Users
Assign Privileges
Create Users
Assign Roles
Big Picture: Solution
3
Compliance Check
Remediation
Position
User
SRM
BOBJ
Non SAP
Systems
New Hire /
Change Position
Web Front end
to access request
SAP HCM (HR)
HR Master record
Position Based
Access
SAP NetWeaver
Identity Management
Calculates Entitlements
Based on Position
SAP GRC 10
Access Control
AMR, DMR, CEA, PUA
Line Manager
Approve
Using Workflow
Create Users
Assign Privileges
Create Users
Assign Roles
= Not in Scope
SAP GRC Components Implemented
4
SAP User
Process Controls *
Provision & Manage Users (PMU)
Analyze & Manage
Access Risk (AMR)
Centralized Emergency
Access (CEA)
* Design & Manage
Role (DMR)
Redesigned Roles &
Provisioning Process
Phase II
How many Roles in Production?
A. > 2,000
B. > 1,000 and < 2,000
C. > 500 and < 1,000
D. < 500
5
SAP Security Design Considerations
Task Based Roles vs. Job Based Roles
6
Job Based Role Approach
Task Based Role Approach
• Security is built based on positions/jobs for
a group of users (e.g. Accounts Receivable
Manager)
• Smaller number of roles per user –
increased risk for granting functionality
more than once
• Transaction codes and authorizations
typically duplicated in many roles.
• Too many Job roles to choose from leading
to complexity in provisioning process
• Security is built based on small, definable tasks executed by a user (e.g. Process Cash Receipts)
• Larger number of roles per user – decreased risk of duplicate access
• Transaction codes in one role with very minimal exception
• Smaller number of roles to choose from
A/P Clerk
T-Code T-Code Description
F-43 Enter Vendor Invoice
MK01 Create Vendor
ME23 Display PO
Process Invoice
T-Code T-Code Description
F-43 Enter Vendor Invoice
Maintain Vendor Master
T-Code T-Code Description
MK01 Create Vendor
Decision:
Bite Size Inherent Conflict Free
Task Roles
Global Roles; Global Processes; Global Role Owners
User Access and SOD Management :
How it works?
7
Request Access List of Roles Manager Approve SOD Check (based on Rule-sets)
Role Owners Apply Mitigating
Controls
Approve Reject
1: Removed User
Access
2: Adjusted Roles
3: Adjusted SOD
Rule-set(s)
1: Removed User
Access
2: Adjusted Roles
3: Adjusted SOD
Rule-set(s)
Why Mitigate Segregation of Duty Conflicts?
8
Function:
ZPR01 - Vendor Master Maintenance
Roles:
ZE:PR_MAINT_VNDR_MSTER_BU_IT
ZE:PR_MAINT_VNDR_MSTER_HR
ZE:PR_MAINT_VNDR_MSTR_IC_BU_IT
ZE:PR_MAINT_VND_MSTR_BU_IT_RUS
XK01 XK02
Function: ZPR02 - Maintain Purchase Order
Roles:
ZE:PR_MAINT_PURCHASE_ORDER
ME21
ME21N
Mitigate
the users
with SOD
Risk:
ZP008 - Maintain a
fictitious vendor and
initiate purchase to
vendor
Mitigating Control: PRO.PROCR.EBAYI.
C01:
The Global Vendor
Manager reviews
monthly vendor adds
and change reports.
Risk Mitigation Strategy
9
Level Risk Definition Mitigation Strategy
Low Low inherent risk. Well controlled and consistent processes in place
Blanket Mitigation. Mitigation
does not need to be part of the control framework
Medium Medium inherent risk. Well controlled within the control
framework and well tested. Business processes and
controls which support the risk are consistent/centralized
across the organization.
Mitigated at User or Risk
Level. Mitigation needs to be part of the control framework
High High inherent risk. Processes may be
inconsistent/decentralized across the organization. Global
or local entity specific controls are in place to mitigate this risk.
Mitigated locally at the User
Level. Mitigating control needs
to be part of the control framework.
Critical High inherent risk and existing controls are not sufficient to mitigate this risk
No one shall have this risk
Access Controls Governance enabled by SAP GRC
10
Process Consideration
–Automated User Provisioning
–Role Management Process
–Fire Fighter Process
–User Access Review Process
–Critical / Sensitive Access Review
–SOD Rule-set Review
11
Lessons Learned
• Principle of Security Redesign
– Ensure that SAP Roles are clean and inherently conflict free
– Use transaction history as the basis of redesign
• Log transactions 6 months before start of the project
• Define stakeholders and engage. Leverage steering committee to manage changes.
• Engage with External Auditors early; They are a key stake holder.
• Define business SOD rule-sets early; SOD rule-sets are the basis of your SOD conflicts.
• Don’t believe all that your consultants promise. Think about sustaining the process and systems when
consultants are gone.
• Change management, Change management, Change management: Training is key.
• Articulate the Governance process.
12
Governance Model
•User Access Review
•Critical Access Review
•Firefighter Access Review
•SOD Rule-set and Reports Review
•ITGC Control
•Automated Provisioning
•Automated SOD and Access Review
•Fire Fighter
•User reports
•GRC Maintenance
•Role and Rule-Set Management
•Fire Fighter Access
•SOD Review
•Governance Team / Steering Committee
•Controllers/Process Owners
•Role Owners
•Information Technology
•SOX PMO/Internal Audit
People Process
Controls GRC
(System)
13
Disclaimer
SAP and other SAP products and services mentioned herein as well as their respective logos are
trademarks or registered trademarks of SAP SE (or an SAP affiliate company) in Germany and other
countries. All other product and service names mentioned are the trademarks of their respective companies.
15