Security Role Implementation Framework

Approach Document
XYZ Management Project
er!ion" #$%
Date: 26/06/2009
Status: Initial
Document Type:
Document Code:
XYZ Management Project
Pre&ace
For more information on this template, contact !C and "#$ %ana&ement 'ro(ect)
Telephone:
Facsimile:
*mail:


Re'i!ion (i!tory
Date er$ Author )omment!
Security Strategy er!ion *n+ *,,-mm-yyyy+ Page ii
XYZ Management Project
)ontent!
# I./R0D1)/I0.$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ #
1.1 PURPOSE................................................................................................................................ 1
1.2 AIM1
1.3 APPROACH.............................................................................................................................. 1
1.4 ROLE BASED SECURITY VS. POSITION BASED SECURITY............................................................1
1.5 RESPONSIBILITY...................................................................................................................... 1
2 A))3SS A.D )0./R04S$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ #
2.1 FRONT END ACCESS............................................................................................................... 1
2.2 SINGLE SIGN-ON ACCESS........................................................................................................ 1
5 S3)1RI/Y S/RA/36Y$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ 2
3.1 ROLE BASED AUTHORIZATION.................................................................................................. 2
3.2 ROLE DESIGN.......................................................................................................................... 2
3.3 SECURITY MATRIX................................................................................................................... 2
+)+), D*SI-. C/.SID*0TI/.S)))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))2
3.4 GENERIC ROLE....................................................................................................................... 2
7 .AMI.6 )0.3./I0.S$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ 5
8 SAP P0R/A4 S3)1RI/Y$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ 5
9 PR0:3)/ R043S$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ 5
; /3S/I.6 S/RA/36Y$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ 5
< 1S3R MAI./3.A.)3 S/RA/36Y$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ 5
8.1 AUDIENCE ANALYSIS................................................................................................................ 3
8.2 USER ACCOUNT CREATION...................................................................................................... 3
8.3 USER DEFAULTS AND PARAMETERS..........................................................................................4
8.4 MANDATORY TRAINING REUIREMENTS....................................................................................4
= R04401/ S/RA/36Y$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ 7
#% P0S/ 60>4I3 S3)1RI/Y S1PP0R/ S/RA/36Y$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$7
1!.1 SECURITY "NO#LEDGE TRANSFER........................................................................................ 4
1!.2 USER ACCESS $POST GO-LIVE%............................................................................................4
## A1DI/ S/RA/36Y$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ 8
11.1 AUDIT CONFIGURATION......................................................................................................... 5
11.2 SAP AUDIT REPORTS........................................................................................................... 5
11.3 ROLE CONFLICTS REPORTS.................................................................................................. 5
11.4 XYZ CUSTOM REPORTS........................................................................................................ 5
#2 S3)1RI/Y )0.)3P/S$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ 8
12.1 ROLE.................................................................................................................................... 5
12.2 REFERENCE&MASTER ROLE................................................................................................... 5
12.3 DERIVED&CHILD ROLE............................................................................................................ 5
12.4 SINGLE ROLES...................................................................................................................... '
12.5 COMPOSITE ROLES................................................................................................................ '
12.' USER MASTER RECORD......................................................................................................... '
12.( SAP STANDARD ROLES......................................................................................................... '
12.8 FIELDS.................................................................................................................................. '
12.) AUTHORISATION OB*ECT........................................................................................................ '
12.1! AUTHORISATION................................................................................................................... '
12.11 ROLE BASED AUTHORIZATION..............................................................................................(
Security Strategy er!ion *n+ *,,-mm-yyyy+ Page iii
XYZ Management Project
12.12 POSITION BASED AUTHORIZATION........................................................................................ (

Security Strategy er!ion *n+ *,,-mm-yyyy+ Page i1
XYZ Management Project
# Intro,uction
The "#$ %ana&ement pro(ect 2ill implement security and controls throu&hout the
lifecycle of the pro(ect) The Technolo&y Team 3 Security 2ill apply the necessary
security, controls, and procedures to ensure system inte&rity and accessi4ility across
all S' systems)
1.1 Purpose
The purpose of this document is to &i1e a hi&h le1el strate&y for the Technolo&y team
3 Security to desi&n, 4uild and implement security in accordance 2ith the "#$
%ana&ement deli1era4les)
1.2 Aim
The aim of this document is to capture the hi&h le1el acti1ities 2hich 2ill 4e employed
4y the Technolo&y Team 3 Security for each phase of the "#$ pro(ect lifecycle
1.3 Approach
The approaches as outlined in this document ha1e ta5en into consideration "#$6s
e7istin& Security, udit standards and the application of S' 4est practices)
1.4 Role based security vs. Position based security
'resently "#$6s S' security utili8es a role 4ased concept across all S' systems)
0ole 4ased security users the 4usiness roles as the 4ase for authori8ation 'osition
4ased security uses Structural authori8ations to &rant access to information for
personnel 2here 90 has 4een implemented) ccess is &ranted to a user implicitly 4y
the user6s position on the or&ani8ational plan)
1.5 Responsibility
The responsi4ility of the Technolo&y Team 3 Security is to ensure the strate&ies
documented are translated into 4oth system technical confi&uration and manual
control procedures)
2 Acce!! an, )ontrol!
The "#$ pro(ect6s user access 2ill 4e &ranted and controlled solely 4y the Technolo&y
Team 3 Security for .on:'roduction Clients) For further information on S' access
re;uirements refer to document Security 'rocedures)
ll users re;uirin& production access to the S' System must follo2 the S0F S'
ccess 0e;uest Form process for production client access) This 2ill apply across all
ne2 production clients implemented as part of the "#$ 'ro(ect)
2.1 Front End Access
ccess &ranted throu&h the S' Citri7 lo&on pad and S' -<I Front:end 2ill 4e
distri4uted as outlined in the Front:end strate&y document)
2.2 Sinle Sin!on Access
Security Strategy er!ion *n+ *,,-mm-yyyy+ Page ,
XYZ Management Project
"#$ has implemented S' Sin&le Si&n /n =S' SS/> across all our S' systems)
The user:id currently si&ned onto the 'C, 2ill 4e passed throu&h to S', and if that
user e7ists in the S' system concerned, they 2ill 4e automatically si&ned on) s part
of "#$ 'ro(ect all C0%, SC% and "I clients 2ill 4e confi&ured 2ith S' Sin&le Si&n
/n functionality) ll standard user master records =<%06s> 2ill 4e created 2ith SS/
connecti1ity) <pon creation of the <%0, a random system &enerated pass2ord is set
throu&h S' feature, automatic &enerate pass2ord function)
The creation of a user master record setup for SS/ access is outlined in the
document Security 'rocedures)
5 Security Strategy
3.1 Role "ased Authori#ation
The Technolo&y Team 3 Security 2ill 4e responsi4le for the desi&n and 4uild of all
S' system security roles 2ithin the scope of the "#$ 'ro(ect) role:4ased
authorisation concept 2ill 4e implemented as per pre1ious S' implementations
performed 4y "#$) master to child role concept 2ill 4e used 2hen appropriate to
structure the security) For more information on 0ole !ased uthorisation and the
%aster / Child role concept refer to section ,? Security Concepts)
3.2 Role $esin
ll security roles 2ill 4e created ensurin& only the re;uired access is authori8ed to the
end user) This 2ill ensure unauthori8ed transactions do not occur and pre1ents the
occurrence of erroneous or uns5illed chan&es 4y the assi&ned user)
3.3 Security %atri&
security matri7 2ill 4e created usin& the detail pro1ided from the !usiness System
Desi&n documents) The security matri7 2ill include all 5ey information re;uired to 4uild
security roles) The security matri7 2ill also record all re;uired user parameters specific
to the "#$ pro(ects re;uirements)
Inputs from the !usiness 'rocess and confi&uration teams 2ill 4e collated and
entered into the security matri7) <pon completion of the security matri7 the security
roles can 4e 4uilt) <pon completion of the security role 4uild the matri7 2ill 4e 4ase:
lined) /nce 4ase:lined all chan&es re;uired to the security desi&n must first 4e raised
throu&h the chan&e mana&ement process)
ll su4se;uent chan&es to security 2ill 4e controlled and reflected in the security
matri7 4y the Technolo&y Team 3 Security after 4aseline)
5$5$# D3SI6. )0.SID3RA/I0.S
part from security access to transaction codes it 2ill 4e necessary to ensure that
the follo2in& access refinements are considered)
-eo&raphic location
Se&re&ation of Duty
/r&ani8ational @e1el
Type of S' System
3.4 'eneric Role
Security Strategy er!ion *n+ *,,-mm-yyyy+ Page 2
XYZ Management Project
&eneric role 2ill 4e created for the C0%, SC%, and "I systems) This role 2ill contain
the 4asic le1el of access re;uired for 1ie2in& their o2n spool (o4s and maintainin&
personal user parameters) /nly non:critical 4asis authori8ations 2ill 4e included) This
role 2ill 4e assi&ned to the default user master record) The e7istin& &eneric roles 4e
used in 0/+ and !A =!I> systems and 2ill 4e updated if re;uired)
7 .aming )on'ention!
The Technolo&y team 3 Security 2ill desi&n and maintenance of all custom &enerated
!' security role names, profile names, authori8ation o4(ect names, descriptions
and portal security roles) ll ne2 security for C0%, SC%, "I 0/+ !A =!I> 2ill apply to
e7istin& "#$ namin& con1entions) For information of specific namin& con1entions
refer to document Security 'rocedures)
8 SAP Portal Security
In the e1ent S' portal functionality 2ill 4e utili8ed) The portal interface 1ie2s 2ill 4e
restricted 1ia @. -roups accessi4le to the portal 1ia @D') The @. &roups 2ill
control the 1isi4ility of the portal interface and transaction operations 2ill 4e chec5ed
a&ainst the S' 4ac5:end security roles)
*ach portal @. &roup 2ill 4e mapped to a S' 4ac5:end security role) ccess to
perform a transaction 1ia the portal 2ill re;uire 4oth the portal @. &roup and S'
4ac5:end role assi&ned to the user) For more information on portal user administration
refer to document 'ortal <ser %ana&ement)
9 Project Role!
Ahere appropriate S' standard roles 2ill 4e copied and used as a 4asis for creation of
pro(ect re;uired security roles) These roles 2ill contain the authori8ations re;uired for
pro(ect mem4ers to perform the confi&uration and de1elopment necessary) ccess to
sensiti1e transactions such as security user administration and transport mana&ement 2ill
not 4e included) 0efer to document Security 'rocedures for detail on 'ro(ect 0oles)
; /e!ting Strategy
The Technolo&y Team 3 Security 2ill create and maintain the creation of all test accounts)
ll types of testin& must 4e successful 4efore mi&ration to the production en1ironment)
< 1!er Maintenance Strategy
The Technolo&y Team 3 Security 2ill 4e responsi4le for the creation and confi&uration of all
user master records) The e7piration date on all %ahindra Satyam pro(ect staff and "#$
pro(ect staff user master records 2ill 4e applied) ll "#$ default user parameters 2ill 4e
maintained in production systems Inacti1e <%06s 2ill 4e remo1ed from the S' system in
accordance 2ith "#$ procedures)
(.1 Audience Analysis
The audience analysis 2ill 4e utili8ed to identify users to 4e created and 2hich roles
2ill 4e assi&ned in production systems) ll production security role assi&nments 2ill 4e
&ranted in accordance 2ith the audience analysis and the release of access 2ill 4e in
accordance 2ith trainin& re;uirements included in the audience analysis)
(.2 )ser Account *reation
Security Strategy er!ion *n+ *,,-mm-yyyy+ Page +
XYZ Management Project
ll users must ha1e a @. user:id and satisfy the necessary authorisation appro1al
le1el to ha1e an account created in a S' system as outlined in the Security
'rocedures document) user master record 2ill 4e created 1ia transaction S<0,
setup in compliance 2ith "#$ internal audit pass2ord and lo&on parameter policy)
(.3 )ser de+aults and parameters
The Technolo&y Team 3 Security 2ill create and confi&ure a default user master
record =<%0> for all the production systems) This default =<%0> 2ill 4e used as a
model for creation of all <%06s in production system ensurin& all "#$6s standard
access, defaults and parameters are applied)
(.4 %andatory ,rainin Re-uirements
The security roles 2ill 4e mapped a&ainst mandatory trainin& courses) <sers 2ill only
ha1e their authori8ed security roles released upon the successful completion of the
correspondin& mandatory trainin& course=s>)
= Rollout Strategy
The Security rollout 2ill 4e a 1ital part of the "#$ pro(ect6s -o:li1e acti1ities) To ensure the
transition is smooth, necessary preparation 2ill 4e ta5en 2hilst ensurin& access is not
&ranted 4efore &o:li1e) ll security transports re;uired 2ill 4e sent to the production
en1ironments and 1erified 4efore -o:li1e)
<ser accounts 2ill 4e created loc5ed in ad1ance of the rollout and security roles 2ill 4e
assi&ned delimited to the users as per the audience analysis and access acti1ated as per
the cuto1er schedule)
Durin& the rollout it may 4e necessary to &rant special access to production clients for
pro(ect mem4ers to perform data mi&rations or ;uic5ly resol1e pro4lems) To facilitate these
re;uirements special accounts 2ill 4e created) The acti1ation of these special accounts 2ill
re;uire authorisation from mana&ement and 2ill only 4e acti1ated for a 2indo2 of time
re;uired to perform the tas5)
#% Po!t 6o>li'e Security Support Strategy
s part of the post -o:@i1e security support schedule the Technolo&y Team 3 Security 2ill
4e responsi4le for the assi&nment of security roles to users and resolution of security
defects or chan&es etc) fter the t2o 2ee5 period the assi&nment of "#$ Security roles
2ill 4e performed 4y the "#$ Security ste2ard) ll maintenance of security roles and
authori8ations 2ill 4e transferred to IT Security after the t2o 2ee5 support period has
e7pired)
1..1 Security /no0lede ,rans+er
The Technolo&y Team security 2ill perform hands on 5no2led&e transfer to the "#$
Security ste2ard the 5no2led&e transfer 2ill co1er the assi&nment of security roles,
trou4leshootin& and reportin& etc) 5no2led&e transfer to a mem4er of IT Security 2ill
also 4e performed detailin& the ne2 security roles etc spects of 2hich 2ill 4e
documented in the "#$ Security 9ando1er Document
1..2 )ser Access 1Post 'o!2ive3
<sers not identified in the ori&inal audience analysis re;uirin& an account on
production C0% /SC% systems etc and or security role access 2ill 4e re;uired to
follo2 the S0F =S' ccess 0e;uest Form>)process)
Security Strategy er!ion *n+ *,,-mm-yyyy+ Page ?
XYZ Management Project
## Au,it Strategy
s 2ith any ne2 implementation it is essential to ensure the necessary security, controls,
reportin& and retention of lo&s are maintained) s part of e1ery facet of security desi&n,
confi&uration and procedures the application of "#$6s IT udit policies and S' 4est
practice 2ill 4e applied) Consultation 2ith 4oth "#$ Internal udit and *7ternal udit
&roups 2ill also 4e sou&ht for &uidance 2hen re;uired)
11.1 Audit *on+iuration
The S' standard audit confi&uration 2ill 4e adopted as part of "#$ 'ro(ect
implementation) Chan&es to this confi&uration 2ill 4e made as re;uested 4y internal
audit)
11.2 SAP Audit Reports
S' 0/+ 5eeps a 1ariety of lo&s for system administration, monitorin&, pro4lem
sol1in&, and auditin& purposes) The udit Information System =IS> 2hich pro1ides a
lar&e num4er of audit reports as 2ell as a structured audit pro&ram for 4oth system
and 4usiness audits) These tools and reports come standard 2ith S' 4ut some
reports do 2ill re;uire a small amount of confi&uration to ensure they are lo&&in& the
ri&ht data)

11.3 Role *on+licts Reports
The Technolo&y Team 3 Security 2ill identify security role com4ination conflicts and
include them in a role conflict report this report 2ill notify 2hen a user has 4een
assi&ned conflictin& roles) Then action 2ill 4e ta5en to identify and rectify the
situation)
11.4 456 *ustom Reports
s part of the "#$ 'ro(ect implementation re;uirements for customi8ed reports 2ill 4e
re;uired) The technolo&y team 2ill ensure that the necessary security authori8ations
are applied to these reports and access &i1en to the re;uired roles)
#2 Security )oncept!
12.1 Role
role is a collection of indi1idual tas5s that are routinely performed to&ether)
uthorisations are entered into profiles) These profiles, in turn, are assi&ned to
acti1ity &roups)
12.2 Re+erence7%aster Role
reference role also referred to as the master role and is an e7istin& role =standard or
created> 2hich contains specific transactions and authorisation o4(ects for access to
all 4usiness &roups)
12.3 $erived7*hild Role
deri1ed role also referred to as child role, uses the e7istin& master role as a
reference 3 the child role inherits the transactions from the master role) ll updates
Security Strategy er!ion *n+ *,,-mm-yyyy+ Page B
XYZ Management Project
are made in the master and then passed on to the child roles 3 the only part that is
not passed on from the master is the 1alues for the or&anisational le1els)
12.4 Sinle Roles
sin&le role is a collection of authori8ation for performin& tas5s and acti1ities on a
S' system) sin&le role is created 2hen no standard S' role is ser1in& the
re;uirement, a sin&le role can 4e created as per the re;uirement)
12.5 *omposite Roles
composite role is a container 2ith se1eral simple roles) Composite roles do not
contain authori8ation data, the authori8ation is pro1ided 4y the roles inside the
composite roles) &roup of roles on a particular 4usiness area can 4e clustered as
composite roles and assi&ned to users of that &roup Instead of addin& each user
separately to each role) The users assi&ned to a composite role are automatically
assi&ned to the correspondin& =elementary> roles durin& comparison)
12.8 )ser master record
The user master record contains data a4out a user such as user:id, pass2ord, full
name, address, user parameters and system access pri1ile&es =roles C profiles>)
12.9 SAP Standard Roles
S' comes 2ith a lar&e num4er of standard roles that can 4e used as deli1ered, 4ut
a 4etter approach is to 4uild specific roles) This ensures that only the re;uired access
is pro1ided) The standard roles &enerally pro1ide access ri&hts that are too 4road for
typical a (o4 responsi4ilities) The standard roles ho2e1er can 4e used as a template
and can 4e copied and customised)
12.( Fields
The !' Dictionary is the central and redundancy:free repository of all data used in
the S' systems) Fields are lin5ed to data elements =o4(ects 2hich descri4e the
meanin& of a field> in the !' Dictionary) 'ermissi4le 1alues constitute an
authorisation)
12.: Authorisation ob;ect
n authorisation o4(ect allo2s access to related data in the system) It is comprised of
fields that are tested 2hen a user e7ecutes a transaction)
Testin& an authorisation follo2s D.DE lo&ic, 2here a statement is true if and only if all
the conditions are true) Thus, in an authorisation chec5, the system compares a
user6s authorisation profile 1alues =assi&ned 4y the administrator> to the 1alues
needed to access a certain o4(ect or perform a certain transaction) userFs action is
appro1ed only if the user passes the access test for each and e1ery field listed in the
authorisation o4(ect)
12.1. Authorisation
n unlimited num4er of system access pri1ile&es can 4e defined 4ased upon an
authorisation o4(ect) n access pri1ile&e is defined 4y specifyin& the set of authorised
1alues for each field in an authorisation o4(ect) Collecti1ely, this set of 1alues is
referred to as an authorisation)
Security Strategy er!ion *n+ *,,-mm-yyyy+ Page 6
XYZ Management Project
12.11 Role "ased Authori#ation
0ole:4ased security is a form of user:le1el security 2here the application doesnFt
focus on the indi1idual userFs identityG 4ut rather on a lo&ical role they occupy) This
concept 2or5s throu&h the identification of 4usiness scenarios and the lo&ical
&roupin& of these scenarios into roles 4ased on the roles of indi1idual users 2ithin a
4usiness area) "#$6s S' Security desi&n employs a role:4ased authorisation
concept)
12.12 Position "ased Authori#ation
'osition !ased authori8ation is &rantin& access to personnel on the 4asis of their
position in the or&ani8ational structure) This concept depends on the users 2or5in&
area on the 4asis of the position in the or&anisation) 'osition 4ased authori8ation is a
top do2n approach, 2here /r&ani8ational structure is the 5ey)
Security Strategy er!ion *n+ *,,-mm-yyyy+ Page H