Sunteți pe pagina 1din 28

c

c <company_name> Security Design c

c
c
c
c
c
c
c
c
 
 


 

c ñage 1
c
c
c <company_name> Security Design c

 
 

 
Diane Davis /Ramesh Babu/Barry Roberts/Bill Wade


<company_name> Security Design.doc

 



 
 


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

 
  

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

c ñage 2
c
c
c <company_name> Security Design c

1.c £  


c ñurposec cc

À.c 


.c  
 
#   

c Roles and Responsibilitiesc cc
c Naming Convention cc
c General Security Approachc cc
c Security Testingc cc
c User and Role ñrovisioning ñrocessesc cc
c †ther table accessc cc

u.c  


 
  

c SAñ ECC cc
c BW/B†B Jc cc
c SAñ GRCc cc
c SAñ Solution Managerc cc
c Vertexc cc

o.c  


X.c (


c Security RACI Chartc cc


c ECC Security ñarametersc cc
c System ñrofile ñarametersc cc
c SAñ ECC Sensitive Authorization †bjectsc cc

c ñage 3
c
c
c <company_name> Security Design c

1.
£  

This document is to describe the overall SAñ Security Design that will be adopted for XXX SAñ systems.
This design supports the configured business processes within the XXX SAñ system, whilst ensuring an
adequate level of security and controls.

1.1.
# 

The purpose of this document is to identify the high level design in order to
V Define the build that will provide guidance for the build and run of SAñ ECC security and GRC
V ñrovide an overview of the approach for defining the various user roles in a typical SAñ
application environment.
V Specify particular security configuration decisions for the <company_name> solution

À.


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:
V SAñ ECC
V SAñ BW & B†BJ
V GRC modules implemented
V SAñ Solution Manager
The following systems components are not in scope for this document and will follow current XXX
practices for their categories, where applicable
V Database and operating system security
V All peripheral SAñ components not specified above
V All components associated with the operation of the IT infrastructure upon which the SAñ
systems operate are out of scope of this document
V Disaster recovery (DR) and business continuity planning (BCñ) for SAñ and related components
will fall under the XXX¶s current IT policies and procedures
V All components of systems subsidiary to and interfacing with the mySAñ.com systems will be
maintained and secured following existing procedures, guidelines and standards.
V Business ñrocess Controls Strategy, risk assessment and controls recommendation shall be the
responsibility of the <company_name> ñrocess Teams and the <company_name> Internal
Control and Compliance team. See the Governance Risk and Compliance Strategy Document
For non-SAñ application security requirements, please refer to the standards and guidelines defined
within the policies and standard operating procedures as documented on the XXX intranet.

c ñage 4
c
c
c <company_name> Security Design c

c ñage 5
c
c
c <company_name> Security Design c

.
 
 
#   

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.

.1.


(

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> SAñ implementation. See the Terminology area for a
definition of each role listed.

.À.



.À.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 ro le
naming convention document at:

https://thesource.XXX.com/sites/sharedservices/<company_name>/ImplementationTeam/S
hared%20Documents/<company_name>%20ñrogram/Realization/ICC/Security/Role%20N
aming%20Conventions.docx

.À.À.
Îsers
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 SAñ 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
ñolicy requirements.

User Groups

c ñage 6
c
c
c <company_name> Security Design c

For the SAñ solutions in <company_name>, there are two types of User Groups to
consider, Administrative User Groups and Authorization User Groups.
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:
V DEVEL†ñMENT Application Developers (ABAñ) team
V BASIS Basis Support Team
V C†NFIGURE Configuration Development Team
V HELñDESK1 Helpdesk Support Team
V HELñDESK2 Helpdesk Support Team
V SECURITY1 Security Design team
V SECURITY2 Security Design team
V TEST IDs
V USER All end-users
V DESKT†ñ 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.

..
+ 
 
  

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 ñolicies and ñrocedures. 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:
V Transactions listed by process and role
V Role Build Templates
V †rg level security is high maintenance for user provisioning and therefore has been
determined within XXX that the benefits do not outweigh the costs.
V XXX will use the ñrofile Generator as a tool to develop authorization profiles. †nce 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.
V Roles will be directly assigned to a user.

c ñage 7
c
c
c <company_name> Security Design c

V <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
V †bserve best practices where possible:
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.
Minimize use of child roles to avoid breakage of parent ± child relationship.
Identify sensitive data and restrict access to transactions/reports capable of
accessing that data.
Group like functions together into single roles.
Follow principle of least privilege
Ensure correct naming convention is used.
Add tcode (s) in alphabetical order to the folder in Role Menu.
XXX will use the default profile names which start with t, unless a custom profile
name has already been assigned to a role/
Do not maintain/update authorization field values that would result in Changed
objects (as opposed to standard or Maintained) without assessing the situation.
Do not manually insert authorization objects without assessing the situation/change
requirements
Role descriptions are to be kept current with the latest change
Role †wner approval will be obtained before any role modification.

.u.
 


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:
V Unit Testing
V Integration Testing
V 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.

.o.
,


# 
#  

Role builds will follow controls defined in the GRC Role Build and ñrovisioning ñDD¶s.
<company_name> will utilize the GRC RAR simulation functionality to prospectively identify potential
S†D 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 ñDD. Security role builds
must be transported using the transport process defined.

c ñage 8
c
c
c <company_name> Security Design c

.X.
-
(
 

Access to tables can occur at the database layer. As such, <company_name> will implement
alternative procedures consistent with legacy S†X 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 ñolicy. Access to databases requires approvals as stated in
the XXX IT Information Security ñolicy.

u.
 
 
  

u.1.
#
.

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 ñrofile Generator
are about 90-95 percent of what is needed to be considered complete.

u.1.1.
† er ew
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
SAñ technical design while adhering to
V GRC Access Controls best practice
V †bservance of identified critical sensitive transaction codes × 
Insert hyperlink to role
ECC will deploy a compliant security build. Authorization object level access control rules build
based on the data needed to be accessed will be incorporated around these transactions to
provide more granular protection. The ECC build consists of:
V Transactions listed within the ñDDs or Bññs
V RICEF †bject and sensitive transaction areas identified by best practice resources.
V Creation of small task-based roles that are free of S†D violations
V Utilization of the GRC RAR for S†D reviews prior to deployment for role and user
reviews for SAñ ECC security
V 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. × 
hyperlink
V Use SU24 Maintenance process. Avoid inserting objects manually.
V Composite roles reduces visibility within roles, therefore limit their use
V S†D tools interpret the use of * wildcards for administering roles or authorizations
widely which causes issues around S†D and excessive access.
V 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.
V 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.
V Use of composite roles will be used where consistency in the combination of roles
warrants this structure for maintenance

c ñage 9
c
c
c <company_name> Security Design c

V Use of single roles instead of master roles because derived roles will not be used
for org level.
V All reports or programs for end users to run will be assigned to a transaction.
†nly 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 ñFCG. ñrofiles can be created
manually using transaction SU02 and automatically by using SAñ ñrofile Generator. It will
be XXX¶s policy to rely on ñrofile Generator for creation of security profiles whenever
possible as per our systems integrator leading practice design.

SAñ 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 ABAñ/4 program

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

u.1.À.
Authortons †ects
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:
V Entities defined by SAñ which secure or protect transactions.
V 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.
SAñ has pre-defined sets of authorization objects for each of the SAñ modules.
  

  
   
  



   



   
 
 
 
 

    


  
 
 



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
SAñ supplied authorization objects. Refer to the SAñ supplied on-line documentation or an
actual client for a detailed listing. The objects are maintained in the table T†BJ and can be
viewed via transaction SE16.

The system access to execute the transaction is controlled by the authorization object
S_TC†DE. 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

u.1..
Authorton nd Feld Vlues
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

c ñage 10
c
c
c <company_name> Security Design c

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.
      !  
 

  
 
  
           
 
 

  "  "    

      
 
     #$ 




 

" " % 

  

  


 

  &  
 ! 


u.1.u.
Authorty Check n 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, ñlant, etc.) All custom programs, SAñ scripts, and interface routines
are required to use appropriate authority checks. ñrior 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 SAñ ECC ñrofile 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

u.1.o.
Act ton Concept
ñrofiles 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

u.1.X.
àystem àecurty Prmeters

c ñage 11
c
c
c <company_name> Security Design c

The SAñ Security Administrator must periodically check the SAñ ECC system parameters
on each instance. This can be accomplished by using transaction SE38 to execute the
ABAñ/4 program RSñARAM on each system. In particular, the SAñ Security Administrator
must verify that the following system parameters are set appropriately. SAñ 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 SAñ ECC Security ñarameters Table.
/
#  


(

.0

12
3

u.1.7.
Custom Trnsctons
There are two minimum requirements for all new custom transactions:
V S_TC†DE must be activated
V 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
ñDD. 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 SAñ
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.

u.1.8.
àenst e Trnsctons
There are specific transactions contained within SAñ 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 SAñ GRC RAR rule set.
GRC ñrocess Controls will be used for the IT Basis critical areas for Release 1.

u.1.9.
àenst e IDs & Profles
In addition to monitoring sensitive transactions, SAñ has a several powerful userids and
profiles that should be monitored closely for appropriate use. ñowerful ids will not be
granted to individuals in production. In the rare circumstance where it is required, GRC
SñM 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 SAñ ID and profiles should be restricted:




c ñage 12
c
c
c <company_name> Security Design c

ñrofile SAñ_ALL
SAñ_NEW
S_A.SYSTEM
S_A.ADMIN
S_A.USER
S_A.CñIC
S_A.CUST†MIZ
S_A.TMSADM
S_A.TMSCFG
S_A.TMSWF
ID SAñCñIC
SAñ*
DDIC
EARLYWATCH

u.1.10.
Restrcted Authorton †ects
In addition to powerful IDs and profiles with SAñ, 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 SAñ ECC Sensitive Authorization †bjects Table.

u.1.11.
Progrm àecurty
ñrograms in SAñ are written in a standard fourth generation called ABAñ/4; this language
was created by SAñ and is the foundation for all functionality in SAñ. Access to create,
maintain and execute ABAñ/4 programs will be restricted to those individuals properly
trained. Use of ABAñ/4 will follow SAñ development standards. Access to ABAñ/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 ñDD
requiring these to be incorporated into an ECC role. XXX will not utilize additional
maintenance/assignments at the object or authorization group levels.

u.1.1À.
Tle àecurty
The ability to perform configuration or view raw SAñ data requires access to specific
tables within SAñ. The ability to maintain table level data affects the integrity and
accuracy of information maintained by SAñ. Changes to tables must take into
consideration the XXX Change Management ñolicy 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

c ñage 13
c
c
c <company_name> Security Design c

layer, there are two general definitions of tables each having unique security requirements
in SAñ: 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.
De elopment Instnce
V Limited table access to the user allowed to perform configuration
V Within the ABAñ client, grant the ABAñ programmer client dependent table
access
V Client independent table access should be limited to the key people within the
configuration master client
V Restrict all users, in every client from having access to Basis and Security related
tables, authorization groups starting with an µS¶
II.
Integrton/QA
V Allow display access to tables
V There should be no configuration allowed based on client settings
III.
Producton
V Display only
V No configuration allowed based on the client settings
V Functionality within the ñrofile Generator is considered configuration and may
require special procedures

u.1.1.
Tle Query àecurty
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.

u.1.1u.
Tle Authorton †ect àecurty
Client dependent table access is controlled through the SAñ 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 SAñ basis and security related tables are assigned to an authorization
group starting with µS¶. The SAñ 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.

u.1.1o.
Role Buld àequentl Process

c ñage 14
c
c
c <company_name> Security Design c

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

u.À.
1241-1
5

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.

u.À.1.
† er ew
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
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 SAñGui but will login from the B†BJ front end,

u.À.À.
BW àecurty àtrtegy
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 B† system accessed through B† 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 (ñower 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 ñower 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. †nce the Role has been created and
users assigned to that role, authorizations are generated to enable access to the Business
Warehouse. .

c ñage 15
c
c
c <company_name> Security Design c

ñower 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
†bjects
BW Reporting Authorizations will be based on hierarchy of authorizations as defined in the
ñDDs a spreadsheet will be used to assign the end user roles to individual users as part of
the overall role to job position matrix.

u.À..
BW Reportng 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 Info†bjects. All InfoCubes attached to any of these authorization objects require
special consideration.

u.À.u.
BW Admnstrtor 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.

u.À.o.
àAP B†BJ àecurty
u.À.X.
Authortons †ects
u.À.7.
Authorton nd Feld Vlues
u.À.8.
Authorty Check n Custom ABAP
u.À.9.
Act ton Concept
u.À.10.
àystem àecurty Prmeters

u..
#
+

<company_name> will implement the following SAñ GRC Modules during Release 1:
V SAñ GRC Risk Analysis and Remediation (RAR)
V SAñ GRC Super User ñrivilege Management (SñM)
V SAñ ñrocess Controls (ñC)

c ñage 16
c
c
c <company_name> Security Design c

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 ñrovisioning (CUñ) and Enterprise Role
Management (ERM). See the GRC Strategy & Design Document. CUñ may have hundreds of users × 
Diane hyperlink
depending on the configuration since CUñ 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.

u..1.
† er ew
There are 2 different types of roles needed for GRC ± Front-end and Back-End Roles. See
the GRC Role Build.
V Front-end Roles - Front-end roles grant application rights to configure and run the tool
V Back-end Roles - Back End roles are used with ECC for SñM to provide certain master
data update functionality needed to run the tool
GRC is a java based tool that has security administered using the SAñ 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
on need. Where possible, XXX will use out of the box GRC roles. At a minimum the main
users for GRC are as follows:

  
6 
7

 

System Administrator All Full

S†X Finance All Read

Internal Audit All Read

Role †wners RAR S†D/CUñ

Firefighter Support SñM TBD based on function

u..À.
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 SAñ. 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 S†D reporting by using standard UME
RAR roles including VIRSA_CC_ADMINISTRAT†R, VIRSA_CC_SECURITY_ ADMIN,

c ñage 17
c
c
c <company_name> Security Design c

VIRSA_CC_REñ†RT and VIRSA_CC_BUSINESS_†WNER and custom roles will be made (if


required).

u...
GRC àPM

Super User ñrivilege Management enables users to perform emergency activities outside
their role as a ³privileged User´. SñM provides the solution for systematic handling of all
emergency situations in a controlled and auditable environment. The typical roles and
functions assigned for SñM include SñM User role, SñM †wner role and SñM
Administrator role.

u..u.
GRC PC
text × 
ñrotiviti to advise
.

u..o.
Authortons †ects
u..X.
Authorton nd Feld Vlues
u..7.
Authorty Check n Custom ABAP
u..8.
Act ton Concept
u..9.
àystem àecurty Prmeters
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. × 


 8
9

, 
/

 


  
:

u.u.
#
 
6

 ;

× 
Scott Rolfs to do
Text

u.u.1.
† er ew
u.u.À.
Authortons †ects
u.u..
Authorton nd Feld Vlues
u.u.u.
Authorty Check n Custom ABAP
u.u.o.
Act ton Concept
u.u.X.
àystem àecurty Prmeters

c ñage 18
c
c
c <company_name> Security Design c

u.o.
 <
× 
Bill to provide

Text

u.o.1.
† er ew
u.o.À.
Authortons †ects
u.o..
Authorton nd Feld Vlues
u.o.u.
Authorty Check n Custom ABAP
u.o.o.
Act ton Concept
u.o.X.
àystem àecurty Prmeters

u.X.
#  
£ 
:#£;

× 
Michael wei to fill in
something
Text

u.X.1.
† er ew
u.X.À.
Authortons †ects
u.X..
Authorton nd Feld Vlues
u.X.u.
Authorty Check n Custom ABAP
u.X.o.
Act ton Concept
u.X.X.
àystem àecurty Prmeters

o.
 

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

  =
 
Values used to define an authorization for an authorization object
A system template for authorization that relates to a particular system object.
  =
(> 

Authorization objects consist of fields for specific values relating to certain


data or activity with that data.
  =
 
A group of up to 150 authorizations that are automatically generated via the
ñrofile Generator. If a Role contains more than 150 authorizations, more than
one profile is generated

c ñage 19
c
c
c <company_name> Security Design c

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

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

  
c c c A member of the ICC is responsible for establishing the security strategy,
  
cc GRC strategy, related designs and establishing the associated administration
 c processes.

  c A security profile is a collection of Authorization †bjects and Authorizations


Values.


Single Roles consist of authorization profiles, which are generated using the
ñrofile Generator tool. Roles can be directly assigned to user ids.
Consists of a collection of single/individual roles grouped together. As such,


these do not have authorizations or profiles directly assigned to them.


Composite Roles may be directly assigned to user ids.
  c May be created for a generic job role (e.g. Accounts ñayable Clerk) or task
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.

   c Single roles consist of one or many authorizations that are required by the
SAñ system in order to perform transactions (single profile).

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


 c cc 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 SAñ ñrofile
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


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

c  c Application support having three primary pieces.


V 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.

c ñage 20
c
c
c <company_name> Security Design c

V XXX SAñ 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
V Basis Administrators perform critical application functions except
configuring users, profiles and authorizations. These users have
access to perform ABAñ functions and full access to all needed SAñ
transactions, tables and client independent tables to complete their
job function on a day-to-day basis.


   !c Responsible for monitoring that XXX practices are followed and that XXX
" c  c c information resources are properly protected.
  
c"c

# $c Application users that can log on to specific application

#%c 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.

,
£ c Represents the User Identification in the XXX system. User Id¶s are required
to log on to XXX systems

,
  
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
,

 

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.

c ñage 21
c
c
c <company_name> Security Design c

X.
(

X.1.
 
£
 


-?


-?

+


  

 

 

8







£

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
ñrovision 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 SAñ Security and GRC A R R I I C
Administration processes
†btain approval for the defined processes R, A I I I
Communicate the SAñ 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
ñrovide 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

c ñage 22
c
c
c <company_name> Security Design c

Validate accuracy of content C I R, A

X.À.
.
 
#  

# 
 

4? 
This parameter is used to specify the minimum length of a password. The

Default is three characters. You can set it to any value from 3 to 8. The
minimum length will be set to 6 characters. SAñ 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
4? < 
This parameter is used to specify the number of days after which a password


must be changed. The SAñ 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
4 Defines the number of unsuccessful logon attempts before the system does

not allow any more logon attempts. The SAñ 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
4  
This parameter is used to specify the number of times that a user can enter
8

an incorrect password before the system locks the user against further logon
attempts. The SAñ default is 12 and can be set to any value between 1 and
99. For XXX, the setting will be 3 times
4    
Defines whether user locks due to unsuccessful logon attempts should be
  8

automatically removed at midnight. For XXX, the setting will be set to no=0
4 

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.
4   
This parameter is used to restrict special default properties for SAñ*. If the
 @

parameter is reset to 0, it would allow logins with SAñ*, password ³ñASS´,


and unrestricted system access privileges. The parameter should be set to 1.

c ñage 23
c
c
c <company_name> Security Design c

4   

This parameter is used to specify the number of seconds before automatically


disconnecting inactive users from the system. The SAñ default for all
instances is 0 and each instance may require a higher setting. This time
represents the number of seconds.
 4  8
This parameter is used to enable SU24 to activate authorization checks for
 

transactions and to work with the ñrofile Generator. By default, the function is
inactive and the parameter value is N. To activate, the parameter should be
set to value Y.
4< 

External security activated


 4  8 
This parameter is used to check on object S_TC†DE. In certain cases, this


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.
 4   
Transaction codes that can run without the proper authorization. Examples
8

maybe SU53 and SU56 that helps analyze authorization failures when a user
can¶t run a transaction

X..

# 
#  


AAA
 

#6..
. £#£-

 

# 

.

#

B

74
Number of times a user can enter an incorrect 3 4 4 3
password before the system terminates the
logon attempt. Default is 3.

74   8
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.

74 
Specifies the default client. This client is 100
automatically filled in on the system logon
screen. Users can overwrite this.

74      8


Enable automatic unlock of locked users at 0 0 0 1

c ñage 24
c
c
c <company_name> Security Design c


AAA
 

#6..
. £#£-

 

# 

.

#

B

midnight. Default is 1 ± allowed

74? 
Minimum length of a password. Default is 3. Any 6 6 6 3
values from 2 - 8. SAñ also provides a
mechanism for additional customization of
password restrictions. See Security Strategy
document for details.

74? < 


Number of days after which a password must be 60 90 90 0
changed. When the expiration time is reached,
the user is asked to enter a new password.
Default is '0' - no time limit.

74    @


Disables special properties for user SAñ* 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 SAñ* using the default delivered
password and unrestricted system access
privileges. The default is 0 - permitted.

 4   

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

 4  8 


Used to enable SU24 to activate authorization Y Y Y N
checks for transactions and to work with the
ñrofile Generator. Default is N.

 4  8  
Checks on object S_TC†DE. 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.

 4  8 ? 


Enables the transaction for authorization analysis 1 1 1
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 SAñ
ECC6 authorization issues and is essential for
Security Administrators

.,73#7
To make the parameters globally effective in a
SAñ system, set them in the default profile. To
make them instance-specific, you set them in the
profiles of each application server in your SAñ

c ñage 25
c
c
c <company_name> Security Design c


AAA
 

#6..
. £#£-

 

# 

.

#

B

system.

 4    


Enables easier diagnosis of security failures Y Y Y
since allows running of System Trace
(transaction ST01).

4 (  


Disable multiple sapgui logons (for same ECC6 0 1 1 0
account). Default is '0' - off.

 4    


Hold user session information after session 0
termination. Set to the value of '0' if preventing
multiple dialog logons

c ñage 26
c
c
c <company_name> Security Design c

X.u.
#
.

  =
-(> 

#
 
 
  =
-(> 
S_ADMI_FCD Allows various system administration functions
S_BDC_M†NI 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 †nly certain programs should be allowed to access data files. The
field ABAñ: program name should be limited to the program name.
†ften this object is used in custom transactions (starting with µZ¶).
For those a system trace ST01 has to be performed in DEV QA.
S_DEVEL†ñ ñermits ABAñ development. µActivity¶ field is critical. End users
should only have value 03 ± Display
S_IMG_ACTV Authorization to perform IMG functions
S_L†G_C†M Authorization to execute Logical †perating system commands
S_ñR†GRAM 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 SAñ 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_TC†DE 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_TRANSñRT 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. †nly Security
Administration should have all access rights for this object.
S_USER_GRñ Ability to display changes to all user master data. This object is only
granted with display ability. †nly the ñA Administration and Security
Administration should have the change ability. Help desk should
have lock / unlock and password change ability.

c ñage 27
c
c
c <company_name> Security Design c

#
 
 
  =
-(> 
S_USER_†BJ Ability to globally deactivate authorization objects
S_USER_ñR† Ability to display profiles and their change history. This object
should be only used with display ability. †nly Security
Administration should have all access rights for this object.

c ñage 28
c