Upload
tranmien
View
217
Download
0
Embed Size (px)
Citation preview
Segregation of Duties on
Order to Cash and Procure to Pay
Richard Symes, Scapa
November 2011
Agenda
• Scapa
• What we wanted to achieve
• What we did
• Results
Please be aware that several extra slides included in this file are ‘hidden’ from the slide show.
If any hidden slides lead you to need explanation then email me at [email protected]
November 2011 3
Types of questions
• A good question is one that I do not have the answer to
• A very good question is one that I do have the answer to
• An excellent question is one where I have a slide coming that answers it
November 2011 4
Your presenter
• Twenty years of operations management roles and change agent roles
• Ten years on Scapa’s SAP team with a focus on supply chain management improvement
• Picked up the SAP security role in the first SAP implementation and owned the area ever since
• Currently Scapa’s “SAP competence manager” one of a SAP global core team of six people
5 November 2011
Scapa Group
Who we are • Scapa is a leading worldwide manufacturer of bonding
solutions and adhesive components for applications in the Medical, Electronics, Industrial and Transportation markets
What we do • We help customers create better products by providing
adhesive solutions and components. We design our offering around the requirements of global OEMs, distributors and consumers
Facts & Figures • Founded as Scapa Dryers Ltd in 1927 • Headquarters in Manchester, UK, with sales and manufacturing
facilities throughout Europe, Asia and North America • Approximately 1,300 employees worldwide • Annual turnover (year ending 31 March 2011) of £192.3m
November 2011 6
Core markets
November 2011 7
Medical
Electronics Transportation
Industrial
High performance products
Scapa’s unrivalled product portfolio allows customers to work with a core supplier
• who can support their whole range of bonding solutions. Some of our technical
• solutions are below.
November 2011 8
AFT = acrylic foam tape, AFFT = acrylic foam film tape, EMI = electromagnetic interference EMC = electromagnetic conductivity
Scapa’s locations
9
USA on SAP everywhere
since April 2009
Europe on SAP everywhere
since April 2002
Asia not on SAP anywhere
November 2011
Scapa’s SAP system
• We have one SAP system on one set of servers
• We have implemented the FI, CO, MM, PP, QM, SD & WM modules and xMII
• We have uniform business processes globally, except for any fiscal reasons (e.g. France, Italy)
• We have kept our custom code to a minimum
• We run ECC 6.0 and have about 680 ERP users
November 2011 10
SAP security history
• Since day one in 2000 all the roles generated in the ERP system are custom Z prefix ones
… bar one role since 2008 named SAP_J2EE_ADMIN used with Manufacturing Integration & Intelligence (xMII)
• Since 2008 master and derived roles in use
• Since 2010 central user administration in use
• Since June 2010 ProfileTailor™ Dynamics in use
November 2011 11
SAP security management
• Our underlying philosophy is restrict access where you ought to but otherwise liberate users to take advantage of the power of the information system
• No user’s access is changed without their manager’s approval
• No human user on Scapa’s system has SAP_ALL anywhere except in the sandpit client
• Scapa users who change access in user accounts cannot change access in their own user account
November 2011 12
Agenda
• Scapa
• What we wanted to achieve
• What we did
• Results
November 2011 13
What we wanted to do was:
• Reduce the risk of fraud
• Remove persistent annual negative external audit findings
• Confront issues relating to segregation of duties, that we had put off addressing for years
• Invest in a SAP security monitoring & controls system … at an affordable price
November 2011 14
Agenda
• Scapa
• What we wanted to achieve
• What we did
• Results
November 2011 15
Implementation process
November 2011 16
Define the SoD requirement
Write SAP rule set
Configure SoD as active in PTD
Look at dynamic and static picture in PTD
Deal with roles containing two sides
of a SoD conflict
Compose a SAP role re-design
Create new roles with limited transactions that are half a SoD
Give new roles to users running the transactions,
but not to users who are not running them
Take SoD transactions out of old roles
and test SoD will work
Propose who should lose what access
and give them notice
Audit the rule set
Accept or reject any appeals
Remove access
Approve SoD retention in PTD
Continuously monitor in PTD
Not a SAP security team responsibility
Implementation process
November 2011 17
Define the SoD requirement
Write SAP rule set
Configure SoD as active in PTD
Look at dynamic and static picture in PTD
Deal with roles containing two sides
of a SoD conflict
Compose a SAP role re-design
Create new roles with limited transactions that are half a SoD
Give new roles to users running the transactions,
but not to users who are not running them
Take SoD transactions out of old roles
and test SoD will work
Propose who should lose what access
and give them notice
Audit the rule set
Accept or reject any appeals
Remove access
Approve SoD retention in PTD
Continuously monitor in PTD
Procure to Pay SoD requirement
Activity 1 Activity 2 Risk associated with conflict
Vendor Maintenance
Post Invoice Create fictitious vendor and post fictitious invoice for payment
Purchase Order Entry & Maintenance
Goods Receipt Release for payment without having received goods
Goods Receipt Post Invoice Release for payment without having received goods
Vendor Maintenance
AP Payment Processing
User might create fictitious mandate details paying away monies
November 2011 18
Combinations of activities
November 2011 19
Order to Cash SoD requirement
Activity 1 Activity 2 Risk associated with conflict Customer Maintenance – Credit Limits
Process Sales Order
User can increase credit limits and process sales order beyond insured limit.
Customer Maintenance – Payment Terms
Process Sales Order
Unauthorised changes to payment terms, impacting cash position
Sales Order Maintenance – Payment Terms
Process Sales Order
Unauthorised changes to payment terms, impacting cash position … limit to Credit Control
Sales Order Release on Credit Hold
Process Sales Order
User can bypass credit control checks … limit to Credit Control
Process Sales Order Despatch Goods
User can create sales orders to hide misappropriation.
Process Sales Order Sales Price Maintenance
User can inflate or reduce prices to set against sales orders
Despatch Goods Credit Note Processing
User can create/change delivery and create/change a credit note to hide the misappropriation of goods
Customer Master Maintenance
Credit Note Processing
Set up of a fictitious customer with credits issued against the account
November 2011 20
Order to Cash
• Maintain customer credit limits: – T-code FD32 Change
customer credit management
– T-code FD37 Credit management mass change
• Release credit held orders: – T-codes VKM1, VKM2, VKM3,
VKM4, VKM5 and object V_KNKK_FRE field ACTVT value 23
Procure to Pay
• Create / change purchase orders: – T-code ME21 Create PO
– T-code ME21N Create PO
– T-code ME22 Change PO
– T-code ME22N Change PO
• Book goods in on PO: – T-code MIGO with object
M_MSEG_BWE field BWART value 101 and field ACTVT value 01
Rule set examples
November 2011 21
Authorisation detail on SAP
November 2011 22
Other roles don’t have the 101, 102 movement type access in the object M_MSEG_BWE
Activity group content
November 2011 23
Combinations of activities detail
If you want the details of the all transactions and authorisations used at Scapa in Segregation of Duties then email [email protected] and I will send you back an Excel file with all of them included.
November 2011 24
Implementation process
November 2011 25
Define the SoD requirement
Write SAP rule set
Configure SoD as active in PTD
Look at dynamic and static picture in PTD
Deal with roles containing two sides
of a SoD conflict
Compose a SAP role re-design
Create new roles with limited transactions that are half a SoD
Give new roles to users running the transactions,
but not to users who are not running them
Take SoD transactions out of old roles
and test SoD will work
Propose who should lose what access
and give them notice
Audit the rule set
Accept or reject any appeals
Remove access
Approve SoD retention in PTD
Continuously monitor in PTD
SoD analysis
• Show me all roles that contain an SoD violation
• Show me all users that have a combination of roles that cause an SoD violation
• Show me all users that have actually performed activities that are of violation of SoD rules
• Simulate adding a role to a user to check if it will cause a violation of SoD rules
• Simulate adding activities to a role to check if it will cause a violation of SoD rules
November 2011 26
Violations of single combination
November 2011 27
Activity monitoring
When a user is given SAP_ALL you can see what they have run when they had it November 2011 28
Activities to users (real use)
November 2011 29
Activities to users (real use)
November 2011 30
Activities to users (real use)
November 2011 31
Every transaction
run
You can see who uses SAP the most You can see who has never run a transaction You can use the matrix to drive user training
Activities to users (real use)
Every user
November 2011 32
Security analysis examples
• Show me a user’s capabilities (via roles, profiles) versus a user’s actual activity
• Who can perform transaction xxxx?
• Who has performed transaction xxxx?
• Show me an audit trail of system usage and transactions performed by user xxxx
• Show me an audit trail of all usage of transaction xxxx
• Show me unused or rarely used roles or transactions
November 2011 33
User profile, activities
November 2011 34
User profile, role usage
November 2011 35
Transaction use in a role by a user
November 2011 36
First
Etc.
Implementation process
November 2011 37
Define the SoD requirement
Write SAP rule set
Configure SoD as active in PTD
Look at dynamic and static picture in PTD
Deal with roles containing two sides
of a SoD conflict
Compose a SAP role re-design
Create new roles with limited transactions that are half a SoD
Give new roles to users running the transactions,
but not to users who are not running them
Take SoD transactions out of old roles
and test SoD will work
Propose who should lose what access
and give them notice
Audit the rule set
Accept or reject any appeals
Remove access
Approve SoD retention in PTD
Continuously monitor in PTD
Iteratively reduce SoD violations
November 2011 38
The easy stuff is the hard stuff
The hard stuff is the soft stuff
SoD role changes
• Changes to existing roles
– Removal of transactions or authorisations that you wish to segregate from all of the roles that they do not need to be within
• Creation of new roles
– Assignment of transactions or authorisations that you wish to segregate to unique roles … if you do not have this role you cannot perform this duty
November 2011 39
Other Order to Cash answers
• We prevented Customer Care users changing payment terms in sales orders by a customised security object Z_ZTERM and some ABAP code in the sales order user exit MV45AFZZ (we did this in 2006)
• We prevented any users bar Credit Control changing payment terms in customer masters we used the same security object Z_ZTERM to stop use of t-code XD02 and require use of both t-codes VD02 & FD02 to change payment terms and limited t-code FD02 access to Credit Control
November 2011 40
Other Order to Cash answers
• We did not need to segregate duties on credit note processing on SAP as we have an intranet credit note system with workflow for credit note authorisations and every credit note on the intranet is reconciled to SAP
• We initially wanted to segregate duties on sales order maintenance and sales price maintenance but Commercial were unprepared to make the necessary organisation structure change to do this for reasons of cost/efficiency
• One site asked for a way stop users being able to both create a sales order and despatch goods against the sales order on their user name; this bit of ABAP programming was possible with the user exit SAPMM07M_009
November 2011 42
Implementation process
November 2011 43
Define the SoD requirement
Write SAP rule set
Configure SoD as active in PTD
Look at dynamic and static picture in PTD
Deal with roles containing two sides
of a SoD conflict
Compose a SAP role re-design
Create new roles with limited transactions that are half a SoD
Give new roles to users running the transactions,
but not to users who are not running them
Take SoD transactions out of old roles
and test SoD will work
Propose who should lose what access
and give them notice
Audit the rule set
Accept or reject any appeals
Remove access
Approve SoD retention in PTD
Continuously monitor in PTD
Removing SAP access from users
November 2011 44
Remove SAP access from the users who never use one half of a SoD conflict
Prepare the SAP user accounts of users who do use both halves of a SoD conflict so that it is easy to remove one half
Give the users who are going to lose access notice of when access will be removed if they do not appeal
User appeals?
Appeal upheld?
Users lose SAP access
No
No
Yes Users keep SAP access
Yes
Start
End End
Implementation process
November 2011 46
Define the SoD requirement
Write SAP rule set
Configure SoD as active in PTD
Look at dynamic and static picture in PTD
Deal with roles containing two sides
of a SoD conflict
Compose a SAP role re-design
Create new roles with limited transactions that are half a SoD
Give new roles to users running the transactions,
but not to users who are not running them
Take SoD transactions out of old roles
and test SoD will work
Propose who should lose what access
and give them notice
Audit the rule set
Accept or reject any appeals
Remove access
Approve SoD retention in PTD
Continuously monitor in PTD
ProfileTailor™ Dynamics Dashboard
•User xxxx has performed high risk activity yyyy
•User xxxx has performed direct table access (SE16, not SE16N)
•User xxxx has been assigned a high risk profile
•User xxxx has been assigned a high risk SoD combination
•User xxxx ran a high risk SoD combination in past N days
November 2011 47
Scheduled reports
November 2011 49
Granting authorisation simulation
November 2011 51
Implementation process
November 2011 53
Define the SoD requirement
Write SAP rule set
Configure SoD as active in PTD
Look at dynamic and static picture in PTD
Deal with roles containing two sides
of a SoD conflict
Compose a SAP role re-design
Create new roles with limited transactions that are half a SoD
Give new roles to users running the transactions,
but not to users who are not running them
Take SoD transactions out of old roles
and test SoD will work
Propose who should lose what access
and give them notice
Audit the rule set
Accept or reject any appeals
Remove access
Approve SoD retention in PTD
Continuously monitor in PTD
Audit the rule set
PwC told us that we had missed:
• Procure to Pay:
– T-code MASS allows a user to change purchase orders
– 32 Finance module T-codes allowing manual posting of an accounting document in the Accounts Payable ledger
• Order to Cash:
– T-code MASS allows a user to change customer masters
– T-codes MM01 and MM02 allow sales prices to be set via material masters (but only applies if a user has the authorisation objects that t-codes VK11 and VK12 need)
November 2011 54
Agenda
• Scapa
• What we wanted to achieve
• What we did
• Results
November 2011 55
Procure to Pay events in 2010
• April
• 15-16th June
• July
• August
• September
• October
• 17th November
• Listed the conflicts
• Installed ProfileTailor Dynamics
• Began collecting users’ SAP behaviours
• Got roles ready for user access changes
• Removal of access communications
• Some job re-organisation happened
• All conflicts enforced, bar on one user … who was the only user at one location!
November 2011 56
Procure to Pay events in 2011
• July
• August
• September
• September
• September
• September
• October
• Given PwC’s findings on Scapa SAP rule set
• Added to the rule set 30+ new transactions
• Removed some static access
• Asked Risk manager about 19 new SoD users
• 7 non-Finance users’ SoD access approved
• 12 Finance users still left with a SoD conflict
• 12 Finance users’ SoD access approved
November 2011 58
Procure to Pay SoD outcome
Activity 1 Activity 2 Result
Vendor Maintenance Post Invoice Purchase Order Entry & Maintenance Goods Receipt Goods Receipt Post Invoice Vendor Maintenance AP Payment Processing
November 2011 60
Order to Cash SoD outcome
Activity 1 Activity 2 Result
Customer Maintenance – Credit Limits Process Sales Order Customer Maintenance – Payment Terms Process Sales Order by Z_ZTERM
Sales Order Maintenance – Payment Terms Process Sales Order by Z_ZTERM
Sales Order Release on Credit Hold Process Sales Order
Process Sales Order Despatch Goods 90% done;
Canada user exit
Process Sales Order Sales Price Maintenance needs too big
a re-organisation
Despatch Goods Credit Note Processing intranet
Customer Master Maintenance Credit Note Processing intranet
November 2011 61
Record to Report events in 2011
November 2011 62
Define the SoD requirement
Write SAP rule set
Configure SoD as active in PTD
Look at dynamic and static picture in PTD
Deal with roles containing two sides
of a SoD conflict
Compose a SAP role re-design
Create new roles with limited transactions that are half a SoD
Give new roles to users running the transactions,
but not to users who are not running them
Take SoD transactions out of old roles
and test SoD will work
Propose who should lose what access
and give them notice
Audit the rule set
Accept or reject any appeals
Remove access
Approve SoD retention in PTD
Continuously monitor in PTD
Questions?
November 2011 63