ibm igi and sap to sap & beyond - · pdf filefi:t_021_m t-g3550623 aaab . s_tcode...

© N

etStudio – Materiale riservato

IBM IGI AND SAP TO SAP & BEYOND

IBM INTERCONNECT 2017 - LAS VEGAS

TABLE OF CONTENTS

CASE STUDIES Company «A»: a circuit wafer foundry with 3000 employees Company «B»: leader in the manufacturing of 2-wheel vehicles, with 5000 employees

IGA & SAP Common Concerns Glossary Authorization Concepts

PROJECT IMPLEMENTATION

CASE STUDY: COMPANY «A» 1/2

COMPANY “A” is an integrated circuit wafer foundry, with HQ in Italy. Based in Avezzano (Italy) and Landshut (Germany), “A” is focused on offering the most advanced analogue manufacturing service (capacity of >40,000 wafers/month), innovative technology extensions (including volume 90nm and copper manufacturing), a strong emphasis on flexibility, and customer partnership. “A” is supporting own technology IP for 150nm and 110nm, with a large portfolio of process-proven libraries.

• Business driver for Access Governance: Privacy and Internal Audit requirements, starting with SoD for SAP-R3 and continued with provisioning.

• Key entry pain-point: Provisioning and fine-grained SoD for SAP-R3

• Key numbers: 3.000 employees, 1.000 users on SAP-R3

• Live since: April 2016 with SoD for SAP and October 2016 with provisioning

• Benefits: Ability to immediately react by appropriate counter-measures such as periodical review processes on SAP-R3, revoking accounts on several targets, reconciliation capabilities

CASE STUDY: COMPANY «A» 2/2

• Assessment of customer process of access governance • Definition of new processes to manage access rights • HR integration (Joiner, Mover, Leaver) • Automated provisioning on Active Directory and SAP-R3 • Definition of an SoD model for SAP-R3: tree activities, risk matrix • IGI Solution implementation in line with designed processes • Dormancy and Orphan Account Management • Reconciliation and Recertification

SOLUTION

BENEFITS

TECHNOLOGY

• Improved service • Lower Costs • Improved Compliance • Proactive SoD controls implementation

• IGI • SDI

CASE STUDY: COMPANY «B» 1/2

COMPANY “B” is the largest European manufacturer of two-wheeled motor vehicles and on the world's leaders in its sector. “B”’s product range includes scooters, motorcycles and mopeds from 50 to 1,400cc, marketed under world-famous brands. Its HQ is in Pontedera (Pisa, Italy), with production plants around the world: Pontedera, India, Vietnam, China, and USA.

• Business driver for Access Governance: Privacy and Internal Audit requirements starting with request and provisioning in 2011 and continued with SoD for SAP-R3 in 2016.

• Key entry pain-point: Provisioning and fine-grained SoD for SAP-R3

• Key numbers: 5.000 employees, 2.000 users on SAP-R3, >20.000 roles on SAP-R3

• Live since: November 2016 with SoD for SAP

• Benefits: Reduced number of Roles on SAP-R3, reduced number of illegal roles and illegal users.

CASE STUDY: COMPANY «B» 2/2

First project phase: • Assessment of customer process of access governance • Definition of new processes to manage access rights • SAP-HR integration (Joiner, Mover, Leaver) • Automated provisioning on Active Directory and SAP-R3 • IGI Solution implementation in line with designed processes Second project phase: • Definition of an SoD model for SAP-R3: tree activities, risk matrix

SOLUTION

BENEFITS

TECHNOLOGY

Strong and structured access governance processes to ensure certification, formalization, tracking, and execution of the identity processes; appropriate access for the relative business role; compliance with audit regulations; reduce fraud risks. Proactive SoD controls implementation.

• IGI

IGA & SAP: COMMON CONCERNS

• Are existing SAP Roles hiding policy violations?

• How do I properly check SoD side effects when assigning multiple SAP Roles to the same user?

• Are SAP Roles accurately designed? Do Roles name reflect what they actually deliver?

IGA & SAP: GLOSSARY • DUTY or ACTIVITY – An action, task or activity required to complete a process.

• PROCURE TO PAY – The process that goes from initiating a purchase to its payment. It includes tasks such as: Purchase Order creation / Order Approval / Payments / Vendor Master Data / Purchase Request.

• SEGREGATION OF DUTIES (SoD) — An internal control that attempts to ensure that no single individual should have control over two or more conflicting sensitive transactions.

• RISK - A probability or threat of damage, injury, liability, loss, or any other negative occurrence that is caused by external or internal vulnerabilities, and that may be avoided through preemptive action

• SENSITIVE TRANSACTION — A business transaction with the potential to impact a company’s financial statements

• SoD CONFLICT / VIOLATION — The pairing of two conflicting sensitive transactions or business activities

• REMEDIATION – The action taken to address SoD Conflict.

• MITIGATION - If an access violating cannot be remediated by removing the SoD conflict, and if there is a legitimate business purpose for maintaining the access, then mitigation is required. Mitigating controls are designed to cover the residual risk of a user having that access.

IGA & SAP: AUTHORIZATION CONCEPTS 1/2

Is at least granular element that we

can restrict

Provide Authorization based

on authorization Object

Grouping of 1 to 10 Authorization Field

Not more 170 authorization

object

Provide Authorization based

on provided authorization

object and authorizations

Combinations of menu’s, auth profiles and personalization

Role Profile Auth. Object Class

Authorization Object Authorizations Field And

Activity

The SAP Authorization Model:

• Is based on Transactions + Authorization objects

• Has some peculiar implications…

Emerging unintended permission resulting from cross-contaminations of Transaction and Authorization Objects:

• Within the same SAP-Role

• Due to multiple role assigned to the same user

IGA & SAP: AUTHORIZATION CONCEPTS 2/2

Field & Value Authorization

Auth. Object

Auth. Object Class

Profile Role

FI:T_021_M T-G3550623

AAAB S_TCODE T-G355062300 TCD F-03;F.13

BC_C S_PROGRAM T-G355062300

P_ACTION SUBMIT

P_GROUP F_001

CO K_TP_VALU T-G355062300

ACTVT 02;03;10

KOKRS *

VALUTYP 0

SAP AUTHORIZATION

PROJECT IMPLEMENTATION 1/67

Carrying out a SoD project is not simple and involves the active participation of business representatives and business processes.

The project steps are:

1) Business process analysis and definition of SOD rules

2) Identification of SOD conflicts through risk analysis

3) Analysis and clean-up of conflicts by modifying roles

4) Implementation of compensating controls, when removing conflicts is not possible

5) Establish periodic validations to ensure they do not increase conflicts


1. Business process analysis and definition of SOD rules.

After performing a process analysis with the business owners, we defined the activity tree and the risk matrix.

The risk matrix is based on SAP standard market matrix.


2. Identification of SOD conflicts through risk analysis.

With Access Risk Control for SAP we can identify user violations and illegal roles.

Based on the risk matrix implemented, in Company “B” there are 1996 users, out of a total 2185 active users (91%), who have at least one risk.

The most significant risk (P005 Code), which involve 1036 users (47%) is due to the conflicting tasks: “PO Management” and “Incoming Goods Management”.

The second most significant risk (code M011), involving 796 users (36%), is due to conflicting tasks: “Perform Inventory Adjustments” and “Perform inventory counts and revenue goods”.


2. Identification of SOD conflicts through risk analysis.

In the case of Company “B”, almost all of the users had at least one SoD risk.

Remember, that:

We used a standard market matrix. The standard matrix can produce many false positives because requested authorization objects may not be assigned appropriately. Some of these conflicts may not be SOD relevant.

Custom transactions were not present in this example case. Custom transaction, however, are often a much greater cause of SOD conflicts than standard transactions.


3. Analysis and clean-up of conflicts by modifying roles.

• When you implement a segregation of duties project, it is important to evaluate, immediately following the SOD matrix definition, if current roles can be modified. It may be the case to define a new set of roles that will gradually replace the current ones, rather than modify existing roles.

• In our experience, reviewing the roles represented the most economical way, and with better returns, for the SOD project.

• With Customer “B”, there was no dedicated, internal professional to facilitate the analysis and management of roles and SOD. This is a fundamental figure.

• In many cases, the technical content of the roles does not respect SAP best practices (unaligned transactions and authorization objects)

A separation of duties project should actively involve both business and ICT.


4. Implementation of compensating controls, when removing conflicts is not possible.

• In any SAP system, there are two special profiles: SAP_ALL and SAP_NEW.

• SAP_ALL contains authorizations for all authorization objects in the system. With it, a user is able to do everything and is limited only by the closure of the SCC4 system.

• SAP_NEW, instead, is used when promoting new releases to production new releases, in order to give users extended permissions on authorization objects, introduced in each release.

• Theoretically, none of these two profiles should be assigned to users.

• It often happens that SAP_ALL and SAP_NEW and are assigned only to a very limited, and known, number of users. This situation is however considered critical by auditors.

• There are 3 users who have SAP_ALL and SAP_NEW and for these users the customer has applied the compensating controls


5. Establish periodic validations to ensure they do not increase conflicts.

The business should establish a process to monitor conflicts and remediate/mitigate risks, in a continuous improvement cycle.

Thank You!

ibm igi and sap to sap & beyond - · pdf filefi:t_021_m t-g3550623 aaab . s_tcode...

Documents