SAP Role Desgin for Success: Best Practices and Tips

1
(No Transcript)
2
Is your SAP role design structure accurate and
well-organized? Do they follow a systematic
naming convention that is easy to understand?
Before making any further changes to the roles,
are you performing a Segregation of Duty
analysis? Have you received recommendations from
your auditor about a SoD matrix? The fact is
that security requirements are not often
considered when creating or modifying roles to
meet the immediate business needs. Consequently,
the sap role design structure becomes a mess,
full of segregation of duties (SoD) and contains
many critical authorizations. How does it affect
your business? Why SoD is so important? Why is
it becoming the buzz word? The concept of SoD is
that running a business shouldnt be the
responsibility of a single person. A single
individual should not have authority or control
over any task that could lead to fraud or
criminal activity. It is based on the concept of
shared responsibilities, where multiple
departments or individuals are responsible for
critical functions of a key process. This reduces
the risk of fraud or other unethical behavior. As
part of enterprise risk management and compliance
with laws such as the Sarbanes-Oxley Act of 2002
(SOX), SoD plays an important role. A division of
responsibilities among multiple personnel reduces
the possibilities that any employee or third
party could accomplish any of the following in
isolation or by collaborating with others
3

• Theft of funds
• Taking part in corporate espionage
• Inflating the stock price artificially or
  falsifying financial records to meet shareholder
  expectations.
• It is always recommended to build sap role design
  that follow a systematic process that meets
  business requirements, access frameworks, and
  standardized naming conventions.
• Before you begin a sap role design project, you
  should follow a 3-step process (DISCOVER DEFINE
  DELIVER). You will gain a deeper understanding
  of the current situation, develop a plan to fix
  or redesign it, and create roles that can be
  maintained easily in the future.
• Phase 1 Discover (Evaluate the existing
  setup)
• More than 65 of customers have problems with SAP
  authorizations. Managing authorizations will
  become a cumbersome task in time. Wider access,
  SOD risks, and other factors make it difficult
  for organizations to manage them efficiently.
  Thats why sap design role is important.
• Prior to making decisions about whether to
  perform a cleanup or a complete redesign, it is
  highly recommended to understand the existing sap
  role design setup.

4

• Prepare a comprehensive usage analysis by
  identifying transaction codes and roles. The
  Reverse Business Engineering concept can be
  used to identify what is assigned and what is
  used to clean-up the roles. Inputs from this
  phase will be used in the next phase.
• Phase 2 Define (Make-a-plan)
• After identifying existing design, business
  requirements, and gaps, the next step is to
  decide whether a cleanup or a complete redesign
  is required. Consider the following questions
• Are there a lot of manually added objects in the
  roles
• In S_TCODE, are there ranges for the roles, such
  as A-Z, etc.?
• Are the sap role design granting broader
  authorizations?
• Are there a lot of modified objects in the roles?
• Are there a lot of enabler roles in the current
  sap role design?
• Does the roles have a lot of segregation of
  duties and critical risks?
• Are your roles based on job functions rather than
  tasks?
• A complete role redesign is needed if you answer
  yes to two or more questions. The plan should
  include changes needed at the custom transaction
  code level, authorization adjustments, and sap
  role design adjustments, along with considering
  best practices from the industry.

5
Phase 3 Deliver (Cleanup or Role
Redesign) The role re-design project is always
aimed at simplifying the existing SAP role design
and optimizing the existing role setup in the SAP
system. In addition, this will re-define the way
the roles are assigned to the users by reducing
SoD conflicts when users change their job
positions. Redesigned roles with restricted
access will ensure greater compliance and fraud
prevention in the long run. They will also
improve efficiency and transparency in the SAP
access provisioning process. Below is the
detailed approach that is recommended when you
aim to redesign the sap role design
6
Create Master/Derived Roles When designing
roles, it is always recommended to use the
master/derived role concept. As a result,
Security Administrators can easily manage the
roles. They can also keep the task-based roles
consistent across the company codes and plants
(the organization elements from which the roles
are usually drawn). Developing the master and
derived roles in the ECC/S4H system follows the
below approach
Customizations Before starting the sap role
design project, custom transaction codes (also
called Z transaction codes) should be analyzed.
The impact of these transaction codes is not well
understood by many of us. Auditors and industry
experts recommend identifying and maintaining the
relevant authorization objects in SU24 check
proposals. If the custom transaction codes do not
have proper authorization restrictions, the same
must be maintained before they are added to roles.
7

• Identify transaction codes required for master
  roles
• The transaction codes required for master roles
  were gathered by
• Conducting a Role Redesign workshop and reviewing
  the process flows for all the processes such as
  ATR, OTC and P2P.
• Extracting the transaction code usage information
  for a period of 8-12 months, to make sure that we
  covered all the transaction codes.
• From both these exercises, identify the list of
  transaction codes, and map them to the master
  roles.
• Align the new roles to the business processes

8
In order to identify Segregation of Duties,
solutions such as SAP GRC are recommended. If you
dont have SAP GRC Access Control implemented,
you may opt for ToggleNows FourEdge Security as
a Service offering, which provides the SME teams
assistance in identifying segregation of duties
and critical risks, and enabling a better role
design free from inherent SoD conflict. At every
stage of Role design a SoD conflict check is
conducted to prevent SoD conflicts. Organizationa
l Element Restrictions In addition to the
transaction codes, restrictions will be applied
on various organization elements such as Company
code, Plant, Shipping point etc., a complete list
of organization elements on which restrictions
should be applied should be identified during the
workshops. Any org elements which are in-active
should be removed while designing the sap role
design. Also, the master roles shouldnt have
any limitations on the org elements, and they
should be maintained in the derived
roles. Incase if the existing role structure
gives authorizations to the org level values
through enabler roles, they have to be considered
in the new sap role design.
9
Identify non-org level values After identifying
the transaction codes that should go into each of
the new roles, identify the non-org level values
such as sales order type, document type, etc.
Typically, this is done by looking at the values
maintained in the existing roles in the
Production environment. To expedite the
identification of these values, it is recommended
that the new roles are built in the SAP
development environment without non-org level
values and compared against the existing roles in
the production environment. Once the non-org
values are identified, they should be validated
with the respective business teams. Derivation
methodology Following the creation of master
sap role design, they must be derived for various
org level values. Identifying the org level
values requires analyzing the existing
configuration and conducting discovery meetings
with the key business teams. With respect to
derivations, it is essential that they are
maintained correctly with the correct org value
restrictions. In most cases, restricting only at
the company and/or plant level is insufficient,
which is the most common mistake. Conclusion SoD
risk management is no longer a complex task as
it once was. Companies can simultaneously address
a variety of security issues with modern SOD and
Access Risk Management solutions. There is a need
for enterprises to stare the problem right in the
eye and confront the naked truth. If separation
of roles and responsibilities isnt possible,
then implement stringent processes to address
potential failure points.
10
Its not necessary to hire a whole team. You just
need smart teams, and ToggleNow has them! With
ToggleNow, enterprises have been able to
eliminate their SOD problems without building
dedicated teams or investing heavily in tools.
Through its Segregation of Duties management
service, ToggleNow provides a visualisation layer
that puts the controls over SoD surveillance in
the hands of existing System Administrators,
Business Owners, and Audit\Compliance Teams. With
top-down visibility and control of emerging SoD
risks in the ERP environment, system
administrators and audit/compliance teams do not
have to perform elaborate manual checks. Dont
wait for a SoD disaster to strike! If you would
like to learn more about FourEdge Security as a
Service , Contact us and we will schedule a
meeting with our Security experts.
11
THANK YOU