Table Security

Find the auth group of the Table. Use SE11 and Table Maintenance
generator from utilities menu
TDDAT table has the link between Table and auth group
Table creation is controlled by S_DEVELOP ( SE11 and Developer
KEY and Table entry is controlled be S_TABU_DIS and
S_TABU_CLI ( Client Independent table) (SM30, SE16, SE16N,
SE17)
S_TABU_DIS has Activity and Auth group fields
Create a T-code in SE93 using call transaction SM30
Update SU24 with S_TABU_DIS and particular auth group.
Add the T-code to the role and make sure the proper auth group is
brought into the role.
If SU24 is changed after the object is added do adjust derived in
PFCG
SE54 to assign auth group to table

Project Requirement

Collect Requirement
Process Team member Contact
Develop Roles
Consult process team member for object
Values

Program Security

Find the auth group of the program. Use SE38 and display attribute
TRDIR table has the link between program and auth group
Program creation is controlled by S_DEVELOP (SE38 with Developer Key)
and execution is controlled be S_PROGRAM ( SA38) High sensitive T-codes.
S_PROGRAM has Activity and Auth group fields
Create a T-code in SE93
Update SU24 with S_PROGRAM and particular auth group.
Add the T-code to the role and make sure the proper auth group is brought into
the role.
If SU24 is changed after the object is added do adjust derived from advanced
menu in PFCG
Transaction used for Creation SE38 and Execute SA38
RSCSAUTH Update TRDIR RSABAUTH- Update TPGP

Security redesign

Security Requirement Documentation describing the Role name tcodes, Plant Derivations, Object Value restriction and any org value
restrictions
User access approval and change process
Profile Naming Convention
Approval process for addition of T-code, removal T-codes, object
Value Changes and org level changes
Approval Process for Addition of Single role to composite role
Security Custom Program and Tables
User ID expiration and deletion process
System Security parameters
Securing Batch jobs, Batch jobs and Spool request

Batch Session Security

SM35 to execute in Batch
Batch input sessions enter data non-interactively into an R/3 System. Batch
input is typically used to transfer data from non-R/3 Systems to R/3 Systems
or to transfer data between R/3 Systems.
Fields
Values Comments
BDCGROUPID *
Name of batch session for which a user is
authorized (e.g. FRANK)
BDCAKTI
ABTC Submit sessions for execution
AONL Run sessions in interactive mode
ANAL Analyze sessions, log and queue
FREE
Release sessions
LOCK Lock/unlock sessions
DELE
Delete sessions
SE38 SAPF120

Batch Job

You can define and schedule background jobs in two ways from the
Job Overview:
Directly from Transaction SM36. This is best for users already
familiar with background job scheduling.
use the Job Wizard, start from Transaction SM36, and either select
Call Transaction SM36 or choose CCMS Jobs Definition .
Assign a job name. Decide on a name for the job you are defining and

enter it in the Job Name field.

Set the jobs priority, or "Job Class":
High priority: Class A
Medium priority: Class B
Low priority: Class C
In the Target server field, indicate whether to use system load balancing
S_BTCH_ADM
S_BTCH_JOB
S_BTCH_NAM
Example Program: RFSKPL00

Transports General Concept

Moving Development objects and Customizing Setting in orderly Manner

Development Class is grouping of objects belonging to same project
Any modification will trigger Transport request and can be transported as long as it is assigned
to a transport layer
Transport Requests are released from SE10 and SE09 transactions
Transport Layer defines the which path they will move ( Testing Path, Production Path)
Change request CUST ( system) and SYST ( Tables) SID K Number
Objects S_CTS_ADMI and S_TRANSPORT
Version Management so they can compare
SID denotes different database server
DEV Test QAS and PRD system landscape
Dev Class is Table TDVEC and SE80 to create new class
Role can be transported or Downloaded
Single role transport and Composite role transport
Transport takes the Table entries

New Virsa Implementation

Scan all the Single Role for NO SOD
Remediate ( Fix objects values or Remove
Transaction or Mitigate with Mitigation Controls
Scan all the composite Roles
Remediate ( Remove Roles ) or Mitigate
When Assign Role to users run Virsa on Users to
make sure they have no SOD
When Making Changes always Run virsa

Spool Request Security

2. Spool request authorizations

The spool request authorizations define which user is authorized to use which
operations on which spool requests, or which requests are displayed for the particular
user.
A distinction is made between:
a) Selection authorization
The selection authorization defines which user may see which spool requests. The
selection options of a user are limited in the SP01 display transaction if the relevant
authorizations are missing. S_ADMI_FCD is used as an authorization object for this
purpose.
b) Operation authorization
A user can only edit those spool requests that can be displayed using transaction SP01
and the selection authorizations given here. S_SPO_ACT is used as the authorization
object for this.
When dealing with spool requests, we distinguish the process of creating them and
editing them

Virsa

Tool for Finding SOD /n/virsa/zvrat Compliance Calibrator

Predefined T-code combination Eg: Me21N ( Create PO and F-41 (
approve Invoice)
Confliction T-codes- SOD (Segregation of duties)
Mitigation Control- Oversight by process or system to monitor the user
even if the person has the conflicting transactions
Function: Grouping of Transaction = Role
Risk: Conflicting Functions