This document discusses building a governance, risk, and compliance (GRC) system for SAP. It outlines how to build mechanisms to control access, detect segregation of duties violations, and detect fraud. It describes analyzing critical business processes and roles in SAP, developing a separation of duties matrix, and using reports to check for violations. It provides examples of how to monitor roles and detect fraudulent purchasing patterns like improper one-time vendor payments. The conclusion recommends automating controls and identifying business actions that produce risks if not properly separated.

1. Building a GRC System for SAP
Alexey Yudin
The Head of DBs and Business Applications Security Department
Positive Technologies
PHDays III

2. Plan
― Another three-letter acronym: GRC
― GRC market
― Access Control
― Fraud Management
― SAP authorization concept
― How to build access control mechanism in SAP
― How to build SOD check mechanism in SAP
― Fraud schemes in SAP MM
― Conclusions: to buy, to build or …?

3. GRC intro

4. GRC
Governance
Top
management
sets the
company’s goals
and wants to
control them
Risk
Management
A company
identifies risks
for business and
wants to avoid
them
Compliance
Inner and outer
controls,
regulations,
laws, that a
company must
obey
An integrated approach used by corporations to act in accordance with the
guidelines set for each category. Governance, risk management and
compliance (GRC) is not a single activity, but rather a firm-wide approach
to achieving high standards in all three overlapping categories.

5. What does business really want?
Governance
To make money
Risk management
To save money
Compliance
To save money

6. ― Detecting an unauthorized access to critical business
actions
― Detecting segregation of duties violations
― Detecting fraudulent actions
― IdM integration and automated access control
Russian companies are interested in

7. GRC market leaders

8. GRC market leaders
― ERP vendors solutions
• SAP
• Oracle
― GRC vendors solutions
• EMC-RSA
• Protivity
• MetricStream
• SAS
• Software AG
• …..

9. SAP GRC components
Risk Management
Access Control
Process Control
FraudManagementThe most demanded part of SAP GRC
Access Control

10. Possible approaches
1. Deployment one of the existing solutions (SAP GRC for SAP
ERP)
• High price
• Long term implementation
• High IT operations cost
• Too complicated
• Need much customization
2. Building own solution
• Need development from scratch

11. GRC implementation process
― Analyze critical business process
― Assess business actions
― Develop SoD matrix with possible violations
― Create and redesign roles (remove unnecessary roles)
― Map business actions to roles
― Check current usage of roles
― Find users with SoD violations
― Minimize number of SoD violations
― Control role modifications
― Develop and automate user access process

12. SAP terminology
― SAP Transaction is the execution of a program. The normal
way of executing ABAP code in the SAP system is by
entering a transaction code (for instance, PA30 is the
transaction code for "Maintain HR Master Data").
― Authorization objects are composed of a groups of fields
that are related to AND. These fields’ values are used in
authorization check. For example, authorization object
S_TCODE has one field TCD (transaction code).
― Authorization is a definition of an authorization object, that
is a combination of permissible values in each authorization
field of an authorization object. For example, authorization
S_TCODE: TCD=SE16.

13. Business Processes in SAP
Authorization 2Authorization 1
Business
Action 1
Business
Action 2
Business Process

14. SOD in SAP
Business
Action 1
Business
Action 2
Authorization 2
Authorization 1
Authorization 4
Authorization 3
SOD

15. Where to find SoD matrix
― ISACA - Security, Audit and Control Features SAP ERP, 3rd
Edition
― Australian National Office - SAP ECC 6.0 Security and Control
― http://scn.sap.com
― Google :)

16. SAP MM
― purchasing,
― goods receiving,
― material storage,
― consumption-based planning,
― inventory.

17. Procurement cycle overview

18. Purchasing activities

19. Critical actions in purchasing
― MM01 – Create Material
― MK01 – Create Vendor
― ME01 – Maintain Source List
― MD11 – Create Planned Order
― ME51N – Create Purchase Requisition
― ME41 – Create RFQ
― ME21N – Create PO
― MIRO – Enter Invoice

20. How to build a control mechanism
Module Action Transaction Role 1/Profile
1/User 1
Role N/Profile
N/User 1
MM Create
Purchase
Order
ME21
ME21N
Z_Role_1 Z_Role_N
― Create XL table with critical actions
― Run check on regular basis
• Report RSUSR070
• Transaction SUIM
― Compare results in XL

21. XL example

22. SOD in purchasing
Create SOD matrix based on particular business processes
Purchasing Document
Creator
Purchasing Document
Approver
Purchasing Document
Creator
X
Purchasing Document
Approver
X

23. How to build a SOD check mechanism
― Create XL table based on SOD matrix
SOD Name Action 1 Transaction
(Action 1)
Action 2 Transaction
(Action 2)
Role/Profile/
User
CREATE
PURCHASE
ORDER &
CREATE
VENDOR
MASTER
RECORD
Create
Purchase
Order
ME21
ME21N
ME25
ME27
ME31
Create
Vendor
Master
Record
FK01
MK01
XK01

24. How to build a SOD check mechanism
― Run roles check on regular basis
• Report RSUSR070
• Transaction SUIM
― Compare results in XL

25. How to build a SOD check mechanism
― Run users check on regular basis
• Report RSUSR002
• Transaction SUIM
― Compare results in XL

26. Max Patrol
Now
― Helps to analyze roles and authorization profiles
― Monitors users with critical administrative privileges
― Regular control of roles assigned to users
― Regular control of roles modifications (creating, updating
and role removal)

27. Max Patrol
Near futures
― Create customer business actions
― Map roles to business actions
― Automatically find matches of roles and business action
rules
― Automation in creating and control users and roles that
violate SoD matrix
― Check usage of roles and transactions

28. MaxPatrol – Role Control

29. MaxPatrol – Authorization profile control

30. MaxPatrol –Control administrative
privileges

31. Fraudulent activity in purchasing
― Purchasing without purchase requisition
― Abuse of one-time vendor accounts

32. How to build a fraud check mechanism
― Build a possible fraud scheme
― Divide a scheme into separate actions
― Describe each action in SAP terms
― Go to logs and get all users who perform actions
― Analyze users, performed sequence of actions which suits to
a fraud scheme

33. One-time vendor (OTV) payments
― SAP provides one-time vendor functionality to reduce
administration over the vendor master file by paying
infrequent vendors through a one-time vendor account.
― The use of the one-time vendor function overcomes typical
vendor master file authorization and review controls and
may be used to process unauthorized payments.

34. How to control OTV payments?
― Periodically review one-time vendor payments.
• The vendor line item report RFKEPL00, transaction code
S_ALR_87012103, is the best report to view one-time vendor
payments.
• Payments are also be viewed through the Purchasing
Overview by Vendor Report.

35. Best Practices
― Focus on prevention
― Automate as many controls as possible
― Automate the flow of manual controls
― Identify business actions that produce risks when executed
by one person
― Perform risk analysis before committing and approving
changes to access controls
― SoD risk identification and remediation should be
performed automatically across multiple ERP environments
and instances
― Automate user provisioning and changes
― Control real transaction and role usage

36. Conclusions
― GRC is an information security trend
― The most demanded GRC-features:
• Critical actions control
• SOD violation control
• Fraud control
― It’s possible to build a GRC system that satisfies top
management without large-scale deployments.

37. Thank you for your attention!
Q&A