<company_name> Security Design

<company_name> Security
Design Document

Page 1
 <company_name> Security Design

Document Control
Author Diane Davis /Ramesh Babu/Barry Roberts/Bill Wade
File Name <company_name> Security Design.doc

Version Revision Date Revision Description Author Sign-off

V1 04/27/10 1st Draft of All Sections SI 1 N/A
V2 11/28/10 Focus on XXX specific Ramesh B Kommaddi
decisions

Target Readership
This document is intended for anyone who has responsibility for, or has a vested interest in SAP
Security & GRC Administration at XXX. This includes:
 Business Executives
 Information Services management
 Technical staff
 Application development teams
 User Administration teams
 Help Desk teams
 SAP Security Administrator
 Internal Auditor and External Auditors
 Training Team and Business owners

Page 2
 <company_name> Security Design

1. Introduction_____________________________________________________________________
1.1. Purpose.................................................................................................................................4

2. Scope__________________________________________________________________________

3. <company_name> Security Practices________________________________________________

3.1. Roles and Responsibilities.................................................................................................5
3.2. Naming Convention.............................................................................................................5
3.3. General Security Approach................................................................................................6
3.4. Security Testing....................................................................................................................7
3.5. User and Role Provisioning Processes............................................................................7
3.6. Other table access...............................................................................................................8

4. Application Specific Considerations_________________________________________________

4.1. SAP ECC...............................................................................................................................8
4.2. BW/BOB J...........................................................................................................................15
4.3. SAP GRC............................................................................................................................17
4.4. SAP Solution Manager......................................................................................................19
4.5. Vertex...................................................................................................................................19

5. Terminology____________________________________________________________________

6. Tables_________________________________________________________________________
6.1. Security RACI Chart..........................................................................................................24
6.2. ECC Security Parameters................................................................................................25
6.3. System Profile Parameters..............................................................................................26
6.4. SAP ECC Sensitive Authorization Objects....................................................................29

Page 3
 <company_name> Security Design

1. Introduction
This document is to describe the overall SAP Security Design that will be adopted for XXX SAP systems.
This design supports the configured business processes within the XXX SAP system, whilst ensuring an
adequate level of security and controls.
1.1. Purpose
The purpose of this document is to identify the high level design in order to
 Define the build that will provide guidance for the build and run of SAP ECC security and GRC
 Provide an overview of the approach for defining the various user roles in a typical SAP
application environment.
 Specify particular security configuration decisions for the <company_name> solution

2. Scope
This document refers to the Security concept within the <company_name> solution for end users.
Both the production and non-production environments are considered within the scope of the security and
GRC teams.
The following systems components are considered in scope for this document:
 SAP ECC
 SAP BW & BOBJ
 GRC modules implemented
 SAP Solution Manager
The following systems components are not in scope for this document and will follow current XXX
practices for their categories, where applicable
 Database and operating system security
 All peripheral SAP components not specified above
 All components associated with the operation of the IT infrastructure upon which the SAP
systems operate are out of scope of this document
 Disaster recovery (DR) and business continuity planning (BCP) for SAP and related components
will fall under the XXX’s current IT policies and procedures
 All components of systems subsidiary to and interfacing with the mySAP.com systems will be
maintained and secured following existing procedures, guidelines and standards.
 Business Process Controls Strategy, risk assessment and controls recommendation shall be the
responsibility of the <company_name> Process Teams and the <company_name> Internal
Control and Compliance team. See the Governance Risk and Compliance Strategy Document
For non-SAP application security requirements, please refer to the standards and guidelines defined
within the policies and standard operating procedures as documented on the XXX intranet.

Page 4
<company_name> Security Design

Page 5
 <company_name> Security Design

3. <company_name> Security Practices

While specific applications will have unique security considerations, all of the <company_name>
components are subject to similar practices to ensure consistency and compliance with the Security
Strategy. The following areas will be common to all applications.
3.1. Roles and Responsibilities
Security and GRC Administration requires active involvement from XXX throughout the project. A
Responsibility, Accountability, Consult and Inform Chart (RACI) lists the security specific roles and
responsibilities for the <company_name> SAP implementation. See the Terminology area for a
definition of each role listed.
3.2. Naming Convention
3.2.1. Roles
Where possible, security roles will be kept to a minimum and XXX will first use the out of
the box roles provided they sufficiently address access needs and risk management
concerns. When custom roles are required a consistent naming convention should be
observed across all <company_name> applications as much as possible. See the role
naming convention document at:
https://thesource.XXX.com/sites/sharedservices/<company_name>/ImplementationTeam
/Shared%20Documents/<company_name>%20Program/Realization/ICC/Security/Role
%20Naming%20Conventions.docx

3.2.2. Users
Dialog users are assigned an application specific account-user master record that may be
assigned one or many application roles. XXX Employees and Contractors user ids will be
the same as their XXX network ID (Active Directory (ADID). Application userids will model
this same convention. Each XXX employee will have one and only application userid (if
needed). No generic SAP userids will be created and no userids will be allowed to be
shared.
Exceptions will be made for testing role functionality and model users in a non-production
environment and for service/batch accounts in production. When service accounts are
required to support batch processing and Tier 3 level support, a separate batch-id will be
established for each process area. Jobs in production systems should not be scheduled
using the individual user ids. Each business area will have at least one batch-id to run the
jobs related to that area. These accounts will comply with the XXX Information Security
Policy requirements.

User Groups

For the SAP solutions in <company_name>, there are two types of User Groups to
consider, Administrative User Groups and Authorization User Groups.

Page 6
 <company_name> Security Design

The Administrative user group is used to distribute the administration of user maintenance.
User administrators can be authorized to maintain specific administrative user groups.
Administrative user groups do not provide the ability to grant transactional access to users.
It just allows for ease of maintenance within security administration. There is no plan to
use administrative user groups during the initial release. The following administrative user
groups are examples of what may be created and used to assign access for these groups:
 DEVELOPMENT Application Developers (ABAP) team
 BASIS Basis Support Team
 CONFIGURE Configuration Development Team
 HELPDESK1 Helpdesk Support Team
 HELPDESK2 Helpdesk Support Team
 SECURITY1 Security Design team
 SECURITY2 Security Design team
 TEST IDs
 USER All end-users
 DESKTOP IT Desktop Support Technical team
The second type of user groups is the authorization user group which is used to assign
roles to groups of people at one time. For <company_name> use of ECC, there is no plan
to use this type of group during the initial releases. The preference is to assign to the end
user due to the need to be flexible with assignment of task based roles.
3.3. General Security Approach
The security design and build is based on an approach with the goal of reducing risk of access to
sensitive areas, content while complying with XXX IT Security Policies and Procedures. To align with
the internal control requirements and prevent potential deficiencies that can impact an organization,
user functions will be segregated with respect to the user’s job descriptions and responsibilities. In
general, transactions with a very high sensitivity (IT and Business Sensitive Transactions) will not be
combined with other transactions. Unique use of transactions per role is the preferred approach with
duplication of transactions within other roles only when no other alternative is present. The role
definition process will provide a high level of flexibility, visibility and control to appropriately manage
the high-risk transactions and remediate users when necessary.
For each of the in-scope systems, transactions, queries, reports and web addresses, etc. will be
included into the role menu. The XXX <company_name> approach to security is to follow standard
SDLC methodology that includes “Design, Build, and Test”. The approach took into account:
 Transactions listed by process and role
 Role Build Templates
 Org level security is high maintenance for user provisioning and therefore has been
determined within XXX that the benefits do not outweigh the costs.
 XXX will use the Profile Generator as a tool to develop authorization profiles. Once activities
have been saved in a role, the profile generator is used to generate the necessary
authorizations and profiles. If a Security Role contains more than 150 authorizations, the
profile generator will automatically create additional profiles.
 Roles will be directly assigned to a user.
 <company_name> Training will identify the “to be” operational job function for job role
mapping. Security will collaborate to map task based roles to the specified function in time
for UAT
 Observe best practices where possible:

Page 7
 <company_name> Security Design

o Limited use of * wildcards for administering roles. Unless there is a thorough

understanding of the scope of transactions or field values a wildcard represents, the
use of wildcards can lead to the granting of unintentional access.
o Minimize use of child roles to avoid breakage of parent – child relationship.
o Identify sensitive data and restrict access to transactions/reports capable of
accessing that data.
o Group like functions together into single roles.
o Follow principle of least privilege
o Ensure correct naming convention is used.
o Add tcode (s) in alphabetical order to the folder in Role Menu.
o XXX will use the default profile names which start with t, unless a custom profile
name has already been assigned to a role/
o Do not maintain/update authorization field values that would result in Changed
objects (as opposed to standard or Maintained) without assessing the situation.
o Do not manually insert authorization objects without assessing the situation/change
requirements
o Role descriptions are to be kept current with the latest change
o Role Owner approval will be obtained before any role modification.

3.4. Security Testing

A security testing strategy will be coordinated with the overall project testing strategy for the
appropriate cycle and type of testing. Security testing will consist of:
 Unit Testing
 Integration Testing
 User Acceptance Testing
During each phase, the Security Team will resolve appropriate authorization failures and make the
appropriate changes and/or modifications to the levels associated with each Role per the testing
feedback. Considerations for job role mapping will be coordinated with the Testing and Training
teams to ensure consistency in the testing objectives and efficient use of the resources deployed for
all these areas simultaneously. Role owner approval of role definitions and role assignments will be
a required output from the testing cycles. See the Testing Strategy document for specific objectives
per testing cycle.
3.5. User and Role Provisioning Processes
Role builds will follow controls defined in the GRC Role Build and Provisioning PDD’s.
<company_name> will utilize the GRC RAR simulation functionality to prospectively identify potential
SOD risks before role or provisioning efforts are made for ECC. This is a new capability to XXX that
will increase role owner visibility and improve work efficiency. Security role builds will utilize the
change management controls specified in the GRC Change Management PDD. Security role builds
must be transported using the transport process defined.

Page 8
 <company_name> Security Design

3.6. Other table access

Access to tables can occur at the database layer. As such, <company_name> will implement
alternative procedures consistent with legacy SOX systems to monitor highly privileged access at
the database and server layers. Associated security will follow principle of least privilege and will be
reviewed in accordance with IT Global Policy. Access to databases requires approvals as stated in
the XXX IT Information Security Policy.

4. Application Specific Considerations

4.1. SAP ECC
ECC is a transactional processing system and most of the action is based on the use of
transactions. For ECC, the transactions that have been selected for a role are entered in the menu
of the role and the profile generator includes in the authorization data all of the authorization objects
that are checked for these transactions. The authorization objects that are brought in to the Profile
Generator are about 90-95 percent of what is needed to be considered complete.

4.1.1. Overview
In addition to the general approach for security, the ECC security design and build aims to
reduce and potentially eliminate the existence of segregation of duties conflicts within the
SAP technical design while adhering to
 GRC Access Controls best practice
 Observance of identified critical sensitive transaction codes
ECC will deploy a compliant security build. Authorization object level access control rules
based on the data needed to be accessed will be incorporated around these transactions to
provide more granular protection. The ECC build consists of:
 Transactions listed within the PDDs or BPPs
 RICEF Object and sensitive transaction areas identified by best practice resources.
 Creation of small task-based roles that are free of SOD violations
 Utilization of the GRC RAR for SOD reviews prior to deployment for role and user
reviews for SAP ECC security
 Roles will be defined based on a task. Therefore, tasks are assigned to a role
owner having significant functional knowledge of what is required to perform the
task. See the detailed security role build.
 Use SU24 Maintenance process. Avoid inserting objects manually.
 Composite roles reduces visibility within roles, therefore limit their use
 SOD tools interpret the use of * wildcards for administering roles or authorizations
widely which causes issues around SOD and excessive access.
 Single roles containing similar functions/transactions can be more easily added or
removed from composite roles. Single roles containing dissimilar
functions/transactions will typically require more analysis to determine whether a
transaction can added or removed.
 Limited use derived roles to represent similar job roles. Derived roles are derived
from parent roles. Changes to parent roles automatically transfer to derived roles,
thus simplifying role maintenance.
 Use of composite roles will be used where consistency in the combination of roles
warrants this structure for maintenance

Page 9
 <company_name> Security Design

 Use of single roles instead of master roles because derived roles will not be used
for org level.
 All reports or programs for end users to run will be assigned to a transaction.
Only those people with active user master records can access the system. User ids, roles,
profiles, transaction codes and authorization objects protect the system from unauthorized
access. Roles are created and maintained via transaction PFCG. Profiles can be created
manually using transaction SU02 and automatically by using SAP Profile Generator. It will
be XXX’s policy to rely on Profile Generator for creation of security profiles whenever
possible as per our systems integrator leading practice design.

SAP transactions are secured through three methods:

1. System access to execute the transaction
2. Check object for activity to execute the transaction
3. Authority checks within the supporting ABAP/4 program

All three of these must be taken into consideration when administering transaction level
security.

4.1.2. Authorizations Objects

An authorization object is a template for testing access privileges. It groups up to 10 fields
and tests for execution rights utilizing AND-logic in programs to see if a user has the right to
carry out an action. A user's action is approved only if the user passes the access test for
each field listed in an object. Authorization objects can be described as:
 Entities defined by SAP which secure or protect transactions.
 Consists of fields whose values determine the type of access granted for specific
transactions.
Fields identify an element of the system that is to be protected by an access test.
SAP has pre-defined sets of authorization objects for each of the SAP modules.
Example: an authorization object for securing accounting documents identifies the type of document that can
be processed (invoice, customer payment, credit memo, etc.) and what type of processing can be performed
with the document (create, change, display, delete, etc.).

The authorization objects used to secure transactions are dependent on the functional area
being executed. There are approximately 22 object classes used to logically group the
SAP supplied authorization objects. Refer to the SAP supplied on-line documentation or an
actual client for a detailed listing. The objects are maintained in the table TOBJ and can be
viewed via transaction SE16.

The system access to execute the transaction is controlled by the authorization object
S_TCODE. This particular object requires that the transactions needed for a user, position
or role be explicitly defined. This means, that if a user needs access to transactions FB01,
FB02, and FB03, then these transactions must be specifically stated. Alternatively, putting
in the value of FB* can provide the same access but is not recommended anywhere but in
the development environment

4.1.3. Authorization and Field Values

Page 10
 <company_name> Security Design

An authorization is a set of permissible values that grant system access privileges based
upon an authorization object. A user is permitted to perform an action only if he/she
passes the test for each field in an authorization object. In this way, objects allow complex,
multi-conditional testing of user access privileges. Creating a unique name and assigning
values to the fields that are defined for the object create an authorization for an
authorization object. Values determine the actions that are permissible. Authorizations
must be assigned to simple profiles.
Example: A G/L account authorization object has two fields to which varying degrees of access can be
granted, Activity and Company Code. An authorization could be created with a value of 03 (display)
assigned to the Activity field and a value assigned to the Company Code field. This authorization would be
assigned to a single profile along with the other authorizations required to access G/L accounts.

4.1.4. Authority Check in Custom ABAP

Much of the data in an ECC6 system has to be protected so that unauthorized users cannot
access it. Therefore, the appropriate authorization is required before a user can carry out
certain actions in the system. When you log on to the ECC6 system, the system checks in
the user master record to see which transactions you are authorized to use. An
authorization check is implemented for every transaction. In addition to transaction code,
the ECC authorization concept includes other authorization objects to secure activities
(create, display, delete, modify, etc.), to restrict access to specific parts of the organizations
data (Company Code, Plant, etc.) All custom programs, SAP scripts, and interface routines
are required to use appropriate authority checks. Prior to the configuration and security
being transported to the QA system, the Security Team and Functional Team will verify that
the authority checks are in place and functioning adequately.

ECC performs authority checks to ensure execution of the code with security
considerations. During the creation process XXX will perform the following when creating
new authority checks:
1. Evaluate the need to create new authorization objects or use existing objects
2. If necessary, create the new authorization objects and associate them with an
existing object class. All new objects must be transported across the entire system
client landscape
3. Identify the values necessary to execute the program
4. Identify the position or role that should have access to execute this program, this
may be dependent on each client
5. If necessary, add the transaction code to the SAP ECC Profile Generator using
SU24
6. If using the profile generator, generate the new activity group necessary to execute
the program
7. If necessary, create the manual authorizations and profiles necessary to execute
the program
8. Transport the profile and/or activity group across the system client landscape

4.1.5. Activation Concept

Profiles and authorizations exist in maintenance and active versions in the system. When
creating or editing a profile or authorization, the maintenance version is being used. This
concept helps prevent errors in defining or editing authorizations from affecting the system.
Changes to profiles and authorizations have to be “activated” or generated before they go
in to affect

Page 11
 <company_name> Security Design

4.1.6. System Security Parameters

The SAP Security Administrator must periodically check the SAP ECC system parameters
on each instance. This can be accomplished by using transaction SE38 to execute the
ABAP/4 program RSPARAM on each system. In particular, the SAP Security Administrator
must verify that the following system parameters are set appropriately. SAP has specific
default parameters in the system that can be tailored for each instance. You can use these
system profile parameters to set password characteristics, incorrect logon limits, and the
default client. The following parameters are presented for later review. Additional details
and recommendation can be found in SAP ECC Security Parameters Table.
Note: Parameters apply to both the ECC6 and BW systems.

4.1.7. Custom Transactions

There are two minimum requirements for all new custom transactions:
 S_TCODE must be activated
 All new transaction must have a check object assigned to them (Table TSTCA)
Creation of custom transactions will follow the process defined in the GRC Role Creation
PDD. The following are the necessary steps to establish a check object for a new
transaction
1. Review the existing authorization objects to determine the ability to use an SAP
supplied object
2. If necessary, create the new authorization object
3. Execute transaction SE93
4. Enter the new transaction code and click on the ‘Maintain’ icon
5. Enter the authorization object selected to be the check object
6. Enter the field level values required
Note, this information can be manually entered into the table TSTCA via transaction SE16.

4.1.8. Sensitive Transactions

There are specific transactions contained within SAP that are considered sensitive and
powerful in nature. The misuse of these transactions within the system could negatively
affect the performance and integrity of the system by providing users with powerful rights.
It is important to understand the risks associated with sensitive transactions. The security
team will make sure those transactions are accounted for in the SAP GRC RAR rule set.
GRC Process Controls will be used for the IT Basis critical areas for Release 1.

4.1.9. Sensitive IDs & Profiles

In addition to monitoring sensitive transactions, SAP has a several powerful userids and
profiles that should be monitored closely for appropriate use. Powerful ids will not be
granted to individuals in production. In the rare circumstance where it is required, GRC
SPM controls will be used to allow for a mitigating control of the activity performed. In non-
production environments, these ID’s will be highly restricted to technical personnel only and
assigned only as needed for the limited time needed to perform mandatory functions not
able to be performed under the properly provisioned ID. Segregation of duties and
observance of highly confidential information must be taken into consideration in all
environments. The following is a list of SAP ID and profiles should be restricted:

Type Detail

Page 12
 <company_name> Security Design

4.1.10. Restricted Authorization Objects

In addition to powerful IDs and profiles with SAP, there are some authorization objects that
should be closely monitored. These authorization objects are considered sensitive in
nature. The misuse of these authorization objects within the system could negatively affect
the performance and integrity of the system. Some transaction codes do require
authorization to some of these objects. However, careful consideration should be taken
wherever access is granted. See SAP ECC Sensitive Authorization Objects Table.

4.1.11. Program Security

Programs in SAP are written in a standard fourth generation called ABAP/4; this language
was created by SAP and is the foundation for all functionality in SAP. Access to create,
maintain and execute ABAP/4 programs will be restricted to those individuals properly
trained. Use of ABAP/4 will follow SAP development standards. Access to ABAP/4
programs will be granted based on three elements:
1. Type of access being requested (display, maintain, execute)
2. Client where requested
3. User making the request
Custom programs will be assigned to custom T-codes which will follow the GRC Role PDD
requiring these to be incorporated into an ECC role. XXX will not utilize additional
maintenance/assignments at the object or authorization group levels.

4.1.12. Table Security

The ability to perform configuration or view raw SAP data requires access to specific
tables within SAP. The ability to maintain table level data affects the integrity and
accuracy of information maintained by SAP. Changes to tables must take into
consideration the XXX Change Management Policy and therefore access at the
application layer will be tightly controlled to protect the integrity, reliability and consistency
of the results of the underlying transactional system. Considerations for access will take
into account the instance and client needed for compliance purposes. At the application
layer, there are two general definitions of tables each having unique security requirements
in SAP: client dependent and client independent. When making changes to client
dependent tables/data, you only impact the client that you are currently logged into when
making the changes. When making a change to a client independent table (T000), you
impact every client within that particular instance. When the GUI level access is
provisioned, the following should be followed (transaction SE16 and SM31).
I. Development Instance
 Limited table access to the user allowed to perform configuration
 Within the ABAP client, grant the ABAP programmer client dependent table
access
 Client independent table access should be limited to the key people within the
configuration master client
 Restrict all users, in every client from having access to Basis and Security related
tables, authorization groups starting with an ‘S’
II. Integration/QA
 Allow display access to tables

Page 13
 <company_name> Security Design

 There should be no configuration allowed based on client settings

III. Production
 Display only
 No configuration allowed based on the client settings
 Functionality within the Profile Generator is considered configuration and may
require special procedures

4.1.13. Table Query Security

SQVI table queries provide powerful SE16 like access into ECC tables which can result in
negative system performance. As a result, <company_name> will deploy reporting
solutions for adhoc query that may involve other tools than ECC where performance can be
better controlled. Access to ECC queries will be limited based on critical business need.

4.1.14. Table Authorization Object Security

Client dependent table access is controlled through the SAP supplied authorization object
S_TABU_DIS with two fields: activity and authorization group. There are three basic
activities – 01 create, 02 change and 03 display. The authorization group is the key to
ensuring that a user only has access to the tables that is required to perform their function
or job responsibility. The critical authorization group that should always be restricted is that
starting with ‘S’. All SAP basis and security related tables are assigned to an authorization
group starting with ‘S’. The SAP supplied authorization object S_TABU_CLI controls
access to client independent (cross client) tables. Granting access to configure/maintain
client independent cross client should be properly approved and review by the Basis team.
This particular object consists of a single field, which a value of “X” grants a user the ability
to configure/maintain client independent tables.

4.1.15. Role Build Sequential Process

In order to develop the detailed role build matrix used as the foundation for develop security
roles, the process used included…..

4.2. BW/BOB J
The BW system is an analytical processing system that performs complex calculations on data stored in
it. As a data warehouse, it does not use transactions the way that ECC does but instead uses three
primary types of restrictions to secure reports.

4.2.1. Overview
BW roles can be restricted by the BW structural elements – InfoAreas and InfoCubes. This
type of specification gives access to all of the data housed in the InfoArea(s) or InfoCube(s)
specified. To be consistent with the overall Security Strategy, organization level (i.e., plant,
company, etc) will not be integrated into the design and therefore will also not be built into
BW. The security structure for BW is intended to restrict normal functionality where it is
important to protect the integrity of the results, but not to restrict similar content. A role in
BW typically identifies a collection of reports and queries for a specific business area. Roles

Page 14
 <company_name> Security Design

often correspond to job titles. Roles are associated with tasks and include all activities that
are carried out by the respective users.
The vast majority of XXX’s BW end users will never directly logon to the BW system using
the SAPGui but will login from the BOBJ front end,

4.2.2. BW Security Strategy

The strategy for ensuring security in the Business Warehouse is based on a two-part
approach that distinguishes between different types of users and the various types of
queries or reports they are authorized to read/change/create. BW users can be thought of
in three broad groups. These groups are aligned with the nature of their required BW
usage according to their job responsibilities. The first group consists of those who go into
the BO system accessed through BO infoview to display or execute reports that have been
created for them (End Users or Report Users). The second group consists of those who
will create queries and reports to be used by them or for the general use of others within
their organization (Power Users or Report/Query Creators). The third group consists of
those who will administer the BW system. This group generally consists of Basis and
Security Administrators. Both End Users and Power Users will be assigned to one or more
specific role as required by their XXX responsibilities. When the user logs into the
Business Warehouse environment, the user will only see the menu for the access that has
been granted via the assigned role.

The first step is to identify the roles that need to be created and what the users will need to
access for each role. The simplest way to give access to the End Users is by info provider.
For EX: GL Users will have access to GL cubes. Once the Role has been created and
users assigned to that role, authorizations are generated to enable access to the Business
Warehouse. .
Power User roles will also need to be defined with the ability to create, change and display
queries and reports both for themselves and others in their department. BW Authorization
Objects
BW Reporting Authorizations will be based on hierarchy of authorizations as defined in the
PDDs a spreadsheet will be used to assign the end user roles to individual users as part of
the overall role to job position matrix.

4.2.3. BW Reporting Roles

The 2 main groupings will be called Menu Roles and Security Roles. The menu roles will
define the folders that users will see (in addition to their favorites). There are no
authorization profiles defined for menu roles. The different security roles may be defined to
allow access to an Infoprovider. The idea is to give functional area access to begin with
and then build it up by giving appropriate security roles for an individual to perform his/her
function. Defining security for BW users becomes a simple exercise of combining the
appropriate Menu and Security roles.
When developing report queries, developers should be aware of the defined authorization
relevant InfoObjects. All InfoCubes attached to any of these authorization objects require
special consideration.

Page 15
 <company_name> Security Design

4.2.4. BW Administrator Roles

The Administrator users will have the same roles as they have in R3 system as the Basis
and Security activities are common to both. There will be a BW specific delta role built and
assigned to Basis and Security users to cover any access needs arising out of special t-
codes unique to BW environment.

4.2.5. SAP BOBJ Security

4.2.6. Authorizations Objects
4.2.7. Authorization and Field Values
4.2.8. Authority Check in Custom ABAP
4.2.9. Activation Concept
4.2.10. System Security Parameters

4.3. SAP GRC

<company_name> will implement the following SAP GRC Modules during Release 1:
 SAP GRC Risk Analysis and Remediation (RAR)
 SAP GRC Super User Privilege Management (SPM)
 SAP Process Controls (PC)
All modules will have a small number of users. Administrator rights for will be restricted to just a few
individuals. For business users of each tool, security rights with update capability will be given based
on just on the functions that each user actually needs to complete his/her job.
Subsequent releases of RAR may include Complaint User Provisioning (CUP) and Enterprise Role
Management (ERM). See the GRC Strategy & Design Document. CUP may have hundreds of users
depending on the configuration since CUP is a tool that helps provide automation for user
provisioning process. ERM is typically just used by basis/security users to help build security using
pre-defined leading practices. For Release 1, XXX will not deploy these features of RAR.

4.3.1. Overview
There are 2 different types of roles needed for GRC – Front-end and Back-End Roles. See
the GRC Role Build.
 Front-end Roles - Front-end roles grant application rights to configure and run the tool
 Back-end Roles - Back End roles are used with ECC for SPM to provide certain
master data update functionality needed to run the tool
GRC is a java based tool that has security administered using the SAP User Management
Engine (UME) for the front-end roles. UME provides a portal like security. GRC comes with
preconfigured UME roles which contains various UME actions. These UME roles can be
assigned to the UME user ids directly or may be copied in to a custom role and then
assigned to the UME users. Customization of these roles is typically not needed.
However, it is leading practice to copy the standard GRC UME roles into custom UME roles
to prevent any issues related to GRC upgrades. UME roles will be assigned to users based

Page 16
 <company_name> Security Design

on need. Where possible, XXX will use out of the box GRC roles. At a minimum the main
users for GRC are as follows:

Function Modules Level of Access

System All Full

Administrator

SOX Finance All Read

Internal Audit All Read

Role Owners RAR SOD/CUP

Firefighter Support SPM TBD based on function

4.3.2. GRC RAR

XXX’s GRC Risk Analysis and Remediation is a web-based, fully automated security audit
and segregation of duties (SoD) analysis application. It provides the largest and most
comprehensive database of SoD rules available for SAP. Risk Analysis and Remediation
can be used to identify, analyze, and resolve all SoDs and audit issues relating to
regulatory compliance. The typical roles and functions assigned for RAR include
administrator, Security Admin, control monitor and SOD reporting by using standard UME
RAR roles including VIRSA_CC_ADMINISTRATOR, VIRSA_CC_SECURITY_ ADMIN,
VIRSA_CC_REPORT and VIRSA_CC_BUSINESS_OWNER and custom roles will be made (if
required).

4.3.3. GRC SPM

Super User Privilege Management enables users to perform emergency activities outside
their role as a “privileged User”. SPM provides the solution for systematic handling of all
emergency situations in a controlled and auditable environment. The typical roles and
functions assigned for SPM include SPM User role, SPM Owner role and SPM
Administrator role.

4.3.4. GRC PC
text
.

Page 17
 <company_name> Security Design

4.3.5. Authorizations Objects

4.3.6. Authorization and Field Values
4.3.7. Authority Check in Custom ABAP
4.3.8. Activation Concept
4.3.9. System Security Parameters
GRC configuration will follow best practice and minimization of customizations. Default
settings will be evaluated to ensure associated risks are being managed in according with
<company_name> Control requirements. See the GRC Configuration Document.
4.4. SAP Solution Manager
Text

4.4.1. Overview
4.4.2. Authorizations Objects
4.4.3. Authorization and Field Values
4.4.4. Authority Check in Custom ABAP
4.4.5. Activation Concept
4.4.6. System Security Parameters

4.5. Vertex
Text

4.5.1. Overview
4.5.2. Authorizations Objects
4.5.3. Authorization and Field Values
4.5.4. Authority Check in Custom ABAP
4.5.5. Activation Concept
4.5.6. System Security Parameters

4.6. Process Integration (PI)

Text

Page 18
 <company_name> Security Design

4.6.1. Overview
4.6.2. Authorizations Objects
4.6.3. Authorization and Field Values
4.6.4. Authority Check in Custom ABAP
4.6.5. Activation Concept
4.6.6. System Security Parameters

5. Terminology
Authorization A set of authorization object specific values that allow a user to perform
certain functions within the XXX system.

Authorization fields Values used to define an authorization for an authorization object

A system template for authorization that relates to a particular system object.
Authorization object
Authorization objects consist of fields for specific values relating to certain
data or activity with that data.
Authorization profile A group of up to 150 authorizations that are automatically generated via the
Profile Generator. If a Role contains more than 150 authorizations, more than
one profile is generated

Data Owner The data owners are responsible for protecting (controlling access to) the
transactions, tables, and reports that they own.

Functional Team Member of the core development team, with responsibility for a specific
functional area and specifying security requirements from a business
perspective.

Governance Risk and A member of the ICC is responsible for establishing the security strategy,
Compliance (GRC) GRC strategy, related designs and establishing the associated administration
Team processes.

Profiles A security profile is a collection of Authorization Objects and Authorizations

Values.

Role Single Roles consist of authorization profiles, which are generated using the
Profile Generator tool. Roles can be directly assigned to user ids.
Consists of a collection of single/individual roles grouped together. As such,
Role-Composite
these do not have authorizations or profiles directly assigned to them.
Composite Roles may be directly assigned to user ids.
Role-Master May be created for a generic job role (e.g. Accounts Payable Clerk) or task

Page 19
 <company_name> Security Design

based roles (e.g. Create Vendor) and may be used as a template. If a role is
to be used for multiple divisions where each clerk would perform the same
functions, but should be restricted to data for their own division, a role will be
derived from the Master role.

Role-Simple Single roles consist of one or many authorizations that are required by the
SAP system in order to perform transactions (single profile).

Role Owner A business representative assigned with responsibility for certain roles and
the assignments of those roles to end users for a functional area.

Security Roles A security role is a collection of linked or associated activities, such as tasks,
reports, and transactions. A role is a data container for the SAP Profile
Generator to generate authorization profiles and usually represent either a
task or job role in the company. A particular task or job may consist of one or
more profiles

Security Team Member of the Technical Services team, and is responsible for the security
administration process.

System Support Application support having three primary pieces.

 The Global Service Center (GSC) - first line of support and the focal
point for receiving security requests and problems. The GSC handles
the initial contact with end users for all support requests and provides
ticketing and escalation support.
 XXX SAP Support (Support) provides technical information or
support. Support personnel diagnose and document user access
issues, troubleshoot user access issues, route requests to
appropriate queues based on escalation process flows and provide
assistance regarding
 Basis Administrators perform critical application functions except
configuring users, profiles and authorizations. These users have
access to perform ABAP functions and full access to all needed SAP
transactions, tables and client independent tables to complete their
job function on a day-to-day basis.

<company_name> Responsible for monitoring that XXX practices are followed and that XXX
Internal Controls and information resources are properly protected.
Compliance (ICC)

User-Dialog Application users that can log on to specific application

User-End Have functional access based on transactions and hierarchy. Access is

defined based on job responsibilities, positions within XXX’s organizational
structure and environment utilization (i.e., production vs. stage). Access is
further restricted based upon segregation of duties restrictions identified by
ICC.

Page 20
 <company_name> Security Design

User Id Represents the User Identification in the XXX system. User Id’s are required
to log on to XXX systems

User group User groups facilitate the process for user reporting within the XXX system.
User groups enable security administration of users within the specified user
group
Each user has a unique user account called a master record. A user master
User master record
record contains a user’s personal data such as name, surname, address, and
other often used system parameters such as printer preferences, system
access rights, etc. The user master record is automatically associated with a
userid.

Page 21
 <company_name> Security Design

6. Tables
6.1. Security RACI Chart

ICC

GRC Team

TeamFunctional

Role Owner

System Support
Security Team

Data Owner
Task

Establish security review activities A R I

Design security builds A R I C
Configure/Modify security builds R, A I
Ensure critical activities are not combined. A R I
Provision users for <company_name> components R A
and environments.
Identify potential compliance issues A R
Assist the security team in preparing for an audit. R, A
Security is compliant with XXX policies. A R I
Define & document SAP Security and GRC A R R I I C
Administration processes
Obtain approval for the defined processes R, A I I I
Communicate the SAP Security & GRC Administration R, A I I I I I
processes to stakeholders
Resolve complex situations A R R
Define and document security and GRC architecture A R R
Review the design documents for completeness of R,A C C C
Security and GRC requirements
Provide system administration knowledge for post A R R I
release administration
Support Security Testing resolution A I R I C
Specify business needs for access to area I I I R C R
Define navigation expectations impacted by security I I R I
design
Understand security capability to area of responsibility C I R A A I
Assign access to user for area of responsibility C R A A
Security tests results successful C R I A
Role training C R, A
Access Reviews I C R, A R, A I
Validate accuracy of content C I R, A

Page 22
 <company_name> Security Design

6.2. ECC Security Parameters

Parameter Description
login/min_password_ln
This parameter is used to specify the minimum length of a password. The
g
Default is three characters. You can set it to any value from 3 to 8. The
minimum length will be set to 6 characters. SAP also provides a mechanism
for additional customization of password restrictions. Using transaction SM30
and maintaining table USR40, password restrictions for acceptable values
may be implemented. Table USR40 is used during logon validation
procedures and password checking to make sure the password does not
violate any of the guidelines. USR40 is a table with impermissible values.
There are two wild card characters that may be used (“?” represents any
single character and “*” represents a sequence of any combination of
characters of any length.) For XXX, the setting will be 8 characters
login/password_expira
This parameter is used to specify the number of days after which a password
tion_time
must be changed. The SAP default is zero, which never requires the user to
change their password. Users should be required to periodically change their
password every 30 days. For XXX, the setting will be 90 days
login/fails_to_session_ Defines the number of unsuccessful logon attempts before the system does
end not allow any more logon attempts. The SAP default is 3 and can be set to
any value between 1 and 99. The typical approach is to permit three
attempts. For XXX, the setting will be 3 times
login/fails_to_user_loc
This parameter is used to specify the number of times that a user can enter
k
an incorrect password before the system locks the user against further logon
attempts. The SAP default is 12 and can be set to any value between 1 and
99. For XXX, the setting will be 3 times
login/failed_user_auto
Defines whether user locks due to unsuccessful logon attempts should be
_unlock
automatically removed at midnight. For XXX, the setting will be set to no=0
login/system_client
This parameter is used to specify the default client. This client is
automatically filled in on the system log on screen. Users can type in a
different client.
login/no_automatic_us
This parameter is used to restrict special default properties for SAP*. If the
er_sap*
parameter is reset to 0, it would allow logins with SAP*, password “PASS”,
and unrestricted system access privileges. The parameter should be set to 1.
rdisp/gui_auto_logout
This parameter is used to specify the number of seconds before automatically
disconnecting inactive users from the system. The SAP default for all
instances is 0 and each instance may require a higher setting. This time
represents the number of seconds.

Page 23
 <company_name> Security Design

auth/no_check_in_som
This parameter is used to enable SU24 to activate authorization checks for
e_cases
transactions and to work with the Profile Generator. By default, the function is
inactive and the parameter value is N. To activate, the parameter should be
set to value Y.
login/ext_security
External security activated
auth/no_check_on_tco
This parameter is used to check on object S_TCODE. In certain cases, this
de
can be shut off, but this results in a big security risk for the system. By
default, the function is inactive, and the parameter value is N. To activate, the
parameter should be set to value Y.
Auth/tcodes_not_chec
Transaction codes that can run without the proper authorization. Examples
ked
maybe SU53 and SU56 that helps analyze authorization failures when a user
can’t run a transaction

6.3. System Profile Parameters

XXX Values

Prod

QA

DEV

SAP Default
PARAMETER DESCRIPTION

Login/fails_to_session_end Number of times a user can enter an incorrect 3 4 4 3

password before the system terminates the
logon attempt. Default is 3.

Login/fails_to_user_lock Number of times a user can enter an incorrect 3 6 6 12

password before the system locks the user
against further logon attempts. The lock is
released at midnight. The default is 12.

Login/system_client Specifies the default client. This client is 100

automatically filled in on the system logon
screen. Users can overwrite this.

Login/failed_user_auto_unlock Enable automatic unlock of locked users at 0 0 0 1

midnight. Default is 1 – allowed

Login/min_password_lng Minimum length of a password. Default is 3. Any 6 6 6 3

values from 2 - 8. SAP also provides a
mechanism for additional customization of
password restrictions. See Security Strategy
document for details.

Page 24
 <company_name> Security Design

XXX Values

Prod

QA

DEV

SAP Default
PARAMETER DESCRIPTION

Login/password_expiration_tim Number of days after which a password must be 60 90 90 0

e changed. When the expiration time is reached,
the user is asked to enter a new password.
Default is '0' - no time limit.

Login/no_automatic_user_sap* Disables special properties for user SAP* when 1 1 1 0

this parameter is set to a value greater than
zero. When the parameter is reset to 0, it would
allow logins with SAP* using the default
delivered password and unrestricted system
access privileges. The default is 0 - permitted.

Rdisp/gui_auto_logout  Specifies the number of seconds a user session 900 1800 1800 0
can be idle before being automatically logged off
by the system. Default is 0

auth/no_check_in_some_cases Used to enable SU24 to activate authorization Y Y Y N

checks for transactions and to work with the
Profile Generator. Default is N.

auth/no_check_on_tcode Checks on object S_TCODE. In certain cases, N N N N

this can be shut off, but it results in a big
security risk for the system. Default is N. Do not
change unless absolutely necessary.

Auth/check_value_write_on Enables the transaction for authorization 1 1 1

analysis SU53, when this parameter is set to a
value greater than zero. This is highly
recommended as it is the key to determining
and resolving SAP ECC6 authorization issues
and is essential for Security Administrators

DEFAULT.PFL To make the parameters globally effective in a

SAP system, set them in the default profile. To
make them instance-specific, you set them in
the profiles of each application server in your
SAP system.

Auth/authorisation_trace Enables easier diagnosis of security failures Y Y Y

since allows running of System Trace
(transaction ST01).

login/disable_multi_gui_login Disable multiple sapgui logons (for same ECC6 0 1 1 0

account). Default is '0' - off.

Page 25
 <company_name> Security Design

XXX Values

Prod

QA

DEV

SAP Default
PARAMETER DESCRIPTION

Rdisp/gui_cleanup_delay Hold user session information after session 0

termination. Set to the value of '0' if preventing
multiple dialog logons

Page 26
 <company_name> Security Design

6.4. SAP ECC Sensitive Authorization Objects

SAP Standard Description

Authorization Object
S_ADMI_FCD Allows various system administration functions
S_BDC_MONI Allows to manipulate batch jobs
S_BTCH_ADM Enables control Batch Jobs in all clients
S_BTCH_ADM This object for Background Administrator ID with value ‘Y’ should be
only given to Basis team and special users that process background
processes like cutting checks and mass processing vendors.
S_CTS_ADMI Access to perform administration functions in transport system
S_DATASET Only certain programs should be allowed to access data files. The
field ABAP: program name should be limited to the program name.
Often this object is used in custom transactions (starting with ‘Z’).
For those a system trace ST01 has to be performed in DEV QA.
S_DEVELOP Permits ABAP development. ‘Activity’ field is critical. End users
should only have value 03 – Display
S_IMG_ACTV Authorization to perform IMG functions
S_LOG_COM Authorization to execute Logical Operating system commands
S_PROGRAM Allows specified programs or reports nodes to be called. When this
object is used most roles should have limitation only to the specific
program or report node that is necessary to call. This can be
achieved by using authorization groups defined by developers.
S_QUERY Authorization for SAP Queries
S_TABU_CLI Ability to maintain client independent tables
S_TABU_DIS Ability to display or change tables. If a user has access to
transactions SM30, SM31 or SE16, this object should be used with
authorization groups for tables. Authorization Administrator can
specify authorization groups by using SE54. The value 02 - change
access should be granted with special care and authorization from
the process owner and system owner, and it should never be used
without authorization groups
S_TCODE Access rights to start transactions and should never have value ‘*’ -
All for end users, but instead it should have the definition of
transaction that the user needs to perform.
S_TRANSPRT Access to transport system
S_NUMBER Number Range maintenance
S_USER_AGR Ability to maintain and display roles
S_USER_AUT Ability to display profiles and their change history. This object
should be only used with display ability. Only Security
Administration should have all access rights for this object.
S_USER_GRP Ability to display changes to all user master data. This object is only
granted with display ability. Only the PA Administration and Security
Administration should have the change ability. Help desk should
have lock / unlock and password change ability.
S_USER_OBJ Ability to globally deactivate authorization objects

Page 27
 <company_name> Security Design

SAP Standard Description

Authorization Object
S_USER_PRO Ability to display profiles and their change history. This object
should be only used with display ability. Only Security
Administration should have all access rights for this object.

Page 28