sap discovery system€¦ · sap discovery system october 2006 english sap discovery system sap ag...

SAP Discovery System

October 2006

English

SAP Discovery System

SAP AGDietmarr-Hopp-Allee 1669190 WalldorfGermany

SAP GRC

Virsa Compliance Calibrator for SAP

Demonstration ScriptOctober 2006

Discovery Box – Compliance Calibrator Script

© SAP AG of 14

Discovery Box – SAP GRC Compliance Calibrator

The following presentation combines the real life experiences of several of our customers to provide a meaningful scenario as we look at the functionality in SAP Compliance Calibrator.

In this scenario we introduce the character of Lawrence Soloman, SAP Security Specialist, who uses the functionality of the system to help business owners remediate real life SOD conflicts.

During our audit last year our external auditor advised we needed to implement an automated solution to identify and control segregation of duty risks in our company. It was determined that the majority of financial implications were in SAP but we also have a legacy system [LPAY] in which we manage our Payroll process. Even though SAP is our first system to remediate we wanted to ensure we could also use the same solution to monitor Payroll activities during phase two of our project.

We selected Compliance Calibrator by Virsa as it would allow us to not only monitor access in SAP butalso any other ERP or legacy application.

In July we kicked off our SOD Management project. We contracted SAP GRC to provide their two week quick start program to get us on our way.

The GRC consultant brought methodologies and best practice SOD risks which helped us move through our project in a very efficient manager.

GRC provided a SOD Management document which we followed. The first two steps of the SOD management process were to define risks in our company and build technical rules to identify those risks. As we were dealing with a very tight timeline in which to achieve SOD compliance, the business team chose to begin with the SAP GRC best practice risk set. These covered the core R/3 functionality as well as several bolt on systems such as CRM, SRM, etc. To these risks we added our custom transactions and included two other treasury risks which our Auditors had looked for previously.

Because the business needed to identify risks, our internal audit group conducted workshops with business process owners to discuss these risks and receive sign-off that monitoring these risks would be appropriate.

I assisted the team in building out the technical rules in CC for all risks which were defined. Business Analysts tested to ensure the appropriate results were achieved.

The next step in the SOD Management process is to begin remediation. As a company we decided to focus on single security roles first. So after all the rule building was complete, I ran our first full SOD analysis against our risks on the R/3 security roles to identify single role conflicts.

I was able to use the management views in Informer to size the remediation effort and determine how many roles contained SOD conflicts.

Use Informer -> Management View -> Role Analysis to identify the number of roles with conflicts – 79.

The project manager and I scheduled workshops for all the Role Owners to attend. We did these for each business process.

Finance Manager Jeffrey Bennett was the first role owner we worked with to identify remediation tasks for Finance Roles.


© SAP AG of 14

We ran Risk Analysis reports with Jeffrey, the FI role owner, to identify only the Finance roles with conflicts. Since we use a good naming convention – the second letter ‘S’ indicated a single role, the next two characters indicate the process the roles provide access to.

Run a Management Summary report for VS::FI* roles.

DataFIELD DATA

System ERP - Discovery

Role VS::FI*

Risks by Process All

Risk Level All

Rule Set GLOBAL

Report Type Permission Level

Report Format Management Summary


© SAP AG of 14

Analysis Results for FI Roles

During the meeting Jeffrey indicated the FI AP Accounts Payable Clerk was not supposed to have payment functions. FI Accounts Manager was not supposed to maintain vendors – only have view access. When viewing the conflict data at a detail level it is clear that XK02 (Change Vendor) should be removed from the role.

When the roles were clean of conflicts, we began the user analysis and remediation. The reason for this approach is if 1 role has 1 conflict but is assigned to 35 users, it is much more efficient to clear the one role of a conflict which in turn will remove the SOD exception from all 35 users.

We took the same approach when we remediated user conflicts – we set up workshops but this time with User’s Managers.

We used the charts / summaries in Informer again to size the effort. Use Informer -> Management View -> User Analysis to identify the number of users with conflicts – 13. To review users with High Risk SOD conflicts, click on the Red section of the pie chart.


© SAP AG of 14

The Informer reports can be reviewed with the User’s Manager to determine if the user requires the access. These issues are mostly going to be a result of a combination of single roles to one user. We decided to pilot a remediation project to get our plan documented and chose to remediate GRC users in the SRM business process.

During the remediation workshop with Liza, the GRC Manager, we ran a risk analysis report to come up with the list of users who had conflicts.

Run Risk Analysis for GRC

DataFIELD DATA/HINTS


© SAP AG of 14


User Group GRC

Risks by Process SRM

Risk Level All

Rule Set GLOBAL


Report Format Summary

Liza indicated that Anita Fisher should not be accepting goods or services. Using the detail level reports we were able to determine the security role providing this access.


© SAP AG of 14

We used simulation to determine if removing role SAP_EC_BBP_RECIPIENT would resolve the conflict.

Green Arrow back to the Risk Analysis Screen. And perform simulation analysis on AFISHER.



User AFISHER

Risks by Process SRM

Risk Level All

Rule Set GLOBAL


Report Format Summary

Click on Simulation button and enter the appropriate data in the fields


© SAP AG of 14



Type Role

Value SAP_EC_BBP_RECIPIENT

Exclude values Yes

Risks from Simulation Only No

Click on Simulate button. Since it does correct the violations, an access request form should be completed and sent to Security for the removal of Role SAP_EC_BBP_RECIPIENT from the SRM system.


© SAP AG of 14

Working down the list Liza indicated Letitia must retain access and a mitigation control be identified and assigned. We ran a report just on Letitia and because she is only one of two people in a very small location, she has to purchase items and sometimes she must manually enter invoices.

From the analysis click on the text of the risk. The next screen allows several follow on functions. Click on the Mitigate the risk button and Continue.


© SAP AG of 14

We had already known about Letitia and several other users who had conflicts that had to be accepted and mitigated so I had already documented these controls in CC. From the Risk Mitigation screen, I clicked on the drop down to see if there may be a control documented for this particular risk.


© SAP AG of 14

The control listed here is exactly the control which we wanted to assign so I click on the Select button to assign this control to Letitia.

The remaining step to complete mitigation is to assign a Monitor – this is the person who will monitor Letitia to ensure the control is completed as documented. Tom Hassel is a Financial Manager who monitors users and controls at several remote locations to ensure fraudulent activity is not occurring.


© SAP AG of 14

During the user remediation we documented our processes around SOD compliance to ensure we had a sustainable process. Each quarter our business owners meet to ensure we still have good rules – no new functionality implemented that needs to be covered. We have a periodic internal review of all users with conflicts and controls to ensure those controls are still valid and being performed.

This year our auditors – internal and external – ran a full user analysis to ensure there are zero unmitigated conflicts in our Production SAP System. Once that report indicates we are ‘clean’ a mitigating control report is run.

The auditors take this report and go to the business managers (Monitors) to ensure the users who have controls assigned are being monitored as documented in each control.


© SAP AG of 14

To stay clean, my security administrators simulate all changes to roles and users before making the changes in SAP. This allows us to identify potential issues and remediate them before making assignments in SAP.

sap discovery system€¦ · sap discovery system october 2006 english sap discovery system sap ag...

Documents