Quantcast
Channel: SCN : Document List - Governance, Risk and Compliance (SAP GRC)
Viewing all 459 articles
Browse latest View live

EAM - For the new kid on the block

$
0
0

G’Day All,

 

Picking up from my previous topic aboutARA - For the new kid on the block, this document is just an overview of my understanding of what EAM is (from what I read here and SAP documentation) and how it works.

 

The objective of this document is to give people who are just starting out or even beginning to find their feet, a brief overview of EAM before they can get stuck into it and go all in(links provided). This is not intended for people who are well versed on this topic, so if that is you, please feel free to skip it as this might not interest you. However if you do want to stick around and point/correct any mistakes or offer advice/suggestions, please by all means do so. I am open to constructive criticism.


I understand there is a lot of content related to EAM in this site and some of the information covered herein might exist elsewhere in some shape or form however this is just meant to serve as a conduit for freshers, who might get a tad overwhelmed by all the information lying around. So I hope this document can give them a glimpse of what it is all about and then help them to venture out into the wild.

 

What is it all about?

EAM enables end-users to perform emergency activities outside the parameters of their standard role, but within a controlled and fully audit-able environment. The application assigns a temporary Firefighter ID that grants an end user(firefighter) broad yet regulated access, and logs every activity he/she performs using the temporary ID.

 

This is usually done in emergency situations, where it is imperative for a user to execute certain tasks irrespective of SOD violations and transaction code clashes however all of his/her actions are monitored and recorded making the session completely visible and transparent.

 

 

Key challenges of EAM
  1. Identification of Business Processes and creating dedicated Firefighter IDs/Roles pertinent to them.
  2. Identification of the need for usage of Firefighter ID/Role
  3. Identification of Firefighters, Firefighter Owners, Controllers, and Administrators.
  4. Identification/Standardization of Reason Codes
  5. Consistency of naming conventions for Firefighter ID/Roles and Reason Codes.
  6. Archival policy for the Firefighter Logs
  7. EAM usage policy should be created to identify tasks which can be positively supported by EAM.
  8. Last but not least, performance optimization.

 

 

Potential functional scenarios for EAM Access

Additional resources with additional roles

Approaching month/financial year end and need additional resources to speed up certain activities. Additional resources are required but they don’t have enough authorizations. This task can be easily automated by EAM and individual activity log would be generated for later review.

 

Developer access on production system

Developer access on production systems is one of the most critical scenarios, but at times it becomes necessary to allow developer access to fix certain bugs urgently. This is an ideal emergency scenario for assigning firefighter id to track each and every activity a developer or a group of developers perform. However developer access on production is never recommended but when you can’t wait for a bug-fix to travel from a lengthy procedure (Dev-Qual-Prod) then EAM works as a mighty mitigation control.

 

Contract user access

To maintain track of contract users activities for a certain period of time. This can be achieved by assigning Firefighter IDs to contract users for access on the assigned system. This allows all their activities to be recorded for an extended review and hence management oversight is achieved.

 

Auditor Access

Most companies have strict audit procedures in place, which entails both internal and external auditors to conduct audits on a regular basis. Auditors can be granted temporary access through EAM.

 

* By no means is this list exhaustive however it should give you an indication of the potential reasons for EAM Access.

* Given the fact that EAM is a form of Mitigation (Please check the ARA document), It is used in scenarios where you have exhausted all other options!!

 

 

Firefighter Users, Roles and Responsibilities
Users/FFID/FFROLERoles & Responsibilities
Firefighter ID

This is a unique user id, created with specific roles that allow the firefighter to perform the required tasks. So we can create multiple Firefighter id’s with specific roles and assign them to the designated users (Firefighters) for a set period of time.

  • SU01: Create FFID
  • Roles: SAP_GRAC_SPM_FFID (This should be exactly the same in config settings as well. Shown further in the document)
Firefighter Role

This is a unique role, which gets assigned to the firefighter to perform the requited tasks.

  • PFCG/BRM: Create FFROLE. Ensure this role is enabled for firefighting in BRM.
Firefighter

These are the users who get assigned with the required Firefighter ID/Role. Firefighter users use Firefighter ID/Role to perform firefighting tasks.

  • SU01: Create FFighter or assign the role to an existing user
  • Role: SAP_GRAC_SUPER_USER_MGMT_USER (This role might need other additional authorizations. Please check the links provided)
Firefighter Administrator

This is the person who has got the ultimate authority over the firefighter program. He/she is responsible for assigning FF ID/roles to firefighters (if they choose to), Owners. They can generate reports, ensure reason codes are up to date etc.

  • SU01: Create FF ADMINISTRTOR or assign the role to an existing user
  • Roles: SAP_GRAC_SUPER_USER_MGMT_ADMIN,  SAP_GRAC_BASE,  SAP_GRAC_NWBC
Firefighter Owner

These are the ID/Role owners and are responsible for assigning FF ID/roles assigned to them by the administrator, to firefighters and controllers. They can also act as controllers however they should not be able to assign FF ID/roles to themselves. They can only be one FF Owner per FF ID/role however one FF Owner can have multiple FF ID/roles.

  • SU01: Create FF Owner or assign the role to an existing user
  • Roles: SAP_GRAC_SUPER_USER_MGMT_OWNER,  SAP_GRAC_BASE,  SAP_GRAC_NWBC
Firefighter Controller

These are the people who monitor the actions of the firefighters. They can do this by viewing the log report and can even receive email notifications when a Firefighter logs in.

  • SU01: Create FF Controller or assign the role to an existing user
  • Roles: SAP_GRAC_SUPER_USER_MGMT_CNTLR,  SAP_GRAC_BASE,  SAP_GRAC_NWBC

* All of the aforementioned roles can/needs to be customized. One can use a naming convention that suits their company requirements


AC10 has the option of having either Centralized or Decentralized firefighting (more on this in the links provided at the end of the document).

 

Centralized

User has to go from plugin/backend system (R3PRD001) and log into a GRC System (GRCPRD001), execute GRAC_SPM(OR EAM) -> which will launch the EAM launchpad -> then access the system [R3PRD001 or something else (HCMPRD001), (CRMPRD001) etc] assigned to him/her by clicking the logon button-> perform FF tasks.

  • This is a better option when in some companies, the user has to access multiple systems. So he/she can log into GRC system (GRC Box) and can start firefighter sessions by clicking on 'logon', which will take him/her to the assigned system.
  • Firefighters can log on centrally as opposed to logging into multiple systems separately
  • FFAdministrator, FFOwner, FFController, Firefighter and their respective roles have to be maintained in the GRC system
  • FFID and its respective role has to be maintained only in the plug-in system

 

Decentralized

User has to stay on the BackEnd system (R3PRD001) execute /n/GRCPI/GRIA_EAM -> which will launch the EAM launchpad -> then click the logon button to start a session in the very same system (R3PRD001) and perform FF tasks. You can enable DC-FF by parameter 1000: GRD(RFC Connector pointing to itself), 4015.

  • The most important advantage of DC firefighting is that you can continue using firefighter even when the GRC Box is down.
  • It’s also more “user-friendly” since the firefighter doesn’t have to log on to GRC Box in order to start the firefighting session, he/she only needs to execute a transaction in the plugin/backend system.
  • Firefighter and his/her respective role has to be maintained just in the plug-in system
  • FFID and its respective role has to be maintained only in the plug-in system
  • FFController and his/her respective role has to be maintained both in the plug-in/GRC system(to receive emails of logs)
  • FFAdministrator and FFOwner and their respective roles have to be maintained in the GRC system

 

 

ID Based vs Role Based

One of  the key difference between assigning a Firefighter an FFID vs FFRole is added security.

 

An FFID is built with a certain role in mind, which has predetermined tcodes assigned to it and this gets assigned to an end user (firefighter). So if this user wishes to commit fraud, he/she can execute certain tcodes from his/her user id and then the remaining from the FFID. This way the chances of him/her getting caught, is dependent on a thorough monitoring/analysis by the controller/auditors.

 

Whereas if you build a specific firefighter role with the same tcodes, this role gets assigned to the end user not an FFID, so every transaction executed shows up against their user id, which makes his/her task of committing fraud a lot harder if not negligible.

 

key differences are as follows:

 

ID BasedRole Based

Logs in using own user ID, accesses FFID from the GRC System and logs into the system assigned to them(ECC, SRM, CRM etc).

Logs into the plug-in system using own user ID, so everything gets logged against that one ID. Multiple users can use the FFROLE at once.

Only one user at a time can use a FFID.Multiple users can use multiple FFRoles at once.
Firefighter need not exist in every system assigned to them due to central logon however they need to exist in the GRC system (This is only applicable for Centralised firefighting).

Firefighter has to exist in every system assigned to them - so multiple logons. (This is only applicable if the user needs to perform tasks in other systems).

Knows exactly when FFID is being used as he/she has to login so has a psychological effect (good thing).

Hard to differentiate between FF tasks and normal tasks as there is no login required. So easy to slip up.

Better tracking of FF tasks - Specific log reports with Reason Codes. Bonus point from Auditors!

Time consuming to track FF tasks - No Specific log reports. No Reason Codes.

Two logins so potential to commit fraud. (1 action using own UserID and 1 action using FFID).

Only one login, so everything gets logged against one id(own user id). Harder to commit fraud.

Could be hard to track and find out when a fraud has been committed so can be a problem with auditors. When two logins used

Easy to track as only one login is used however a thorough analysis is required to differentiate ff tasks from normal tasks.
  • GRAC_SPM : TCode for Centralised FFighting -> You will see FFIDs  assigned to you
  • /n/GRCPI/GRIA_EAM : TCode for DeCentralised FFighting -> You can see the FFIDs assigned to you
  • GRAC_SPM : TCode for Centralised FFighting -> You will see FFROLEs assigned to you
  • /n/GRCPI/GRIA_EAM : TCode for DCentralised FFighting -> Not applicable so wont work

 

 

Configuration in a nutshell
  1. Create all EAM users or decide amongst the existing users who gets what EAM role using ‘SU01’
  2. Create/customize all EAM roles using ‘PFCG’
  3. Assign those roles to their respective users using ‘SU01’
  4. Create an FFID/FFRole with the predetermined roles/tcodes using ‘SU01/PFCG/BRM’
  5. Maintain GRC Plug-In System Configuration Parameters:
    • SPRO -> IMG -> GRC (Plug-In) -> Maintain Plug-In Configuration Settings
    • Parameter IDParameter ValueDescription
      1000Plug-in Connector ID
      This information is used to connect to the Plug-In system.
      4000ID Based:1  Role Based:2
      Application type
      4001DaysDefault Firefighter Validity Period (Days)
      4008Yes/NoSend Firefighter Id Login Notification
      4010Z_SAP_GRAC_SPM_FFID

      Firefighter ID role name

  6. Maintain GRC System Configuration Parameters:
    • SPRO -> IMG -> GRC -> AC-> Maintain Configuration Settings
    • Parameter IDParameter ValueDescription
      4000ID Based:1  Role Based:2Application type
      4001DaysDefault Firefighter Validity Period (Days)
      4002Yes/NoSend Email Immediately
      4003Yes/NoRetrieve Change Log
      4004Yes/NoRetrieve System log
      4005Yes/NoRetrieve Audit log
      4006Yes/NoRetrieve OS Command log
      4007Yes/NoSend Log Report Execution Notification Immediately
      4008Yes/NoSend Firefighter Id Login Notification
      4009Yes/NoLog Report Execution Notification
      4010Z_SAP_GRAC_SPM_FFIDFirefighter ID role name
      4012All Users:1  Controllers:2Default users for forwarding the Audit Log workflow
      4013Yes/NoFirefighter ID owner can submit request for FF ID owned
      4014Yes/NoFirefighter ID controller can submit request for FF ID controlled
      4015Yes/NoEnable Decentralized Firefighting
  7. Maintain User Exits
    • SPRO -> IMG -> GRC (Plug-In) -> Maintain User Exits
  8. Maintain Connection Settings: SUPMG Integration scenario
    • SPRO -> IMG -> GRC -> Common Component Settings -> Integration Framework -> Maintain Integration Scenario
  9. Activate/Check Criticality Level BC Set
    • SPRO -> IMG -> SCPR20 -> GRAC_SPM_CRITICALITY_LEVEL
  10. Maintain Criticality level
    • SPRO -> IMG -> GRC -> AC-> EAM -> Maintain Criticality Levels for EAM
  11. Run Synchronization jobs
    • SPRO -> IMG -> GRC -> AC-> Synchronization Jobs
      • Check for the help option to see what does what.
  12. Schedule Background Jobs for EAM log collection on periodic basis
    • SM36 -> GRAC_SPM_LOG_SYNC_UPDATE
  13. Maintain login/log notifications - only if you want to customize the default ones.
    • SPRO -> IMG -> GRC (Plug-In) -> Maintain Custom Notification/Text Messages for EAM (Plug-In)
  14. Verify Time Zones of the Operating System and the AC server match to ensure EAM logs are captured
    • SPRO -> IMG -> GRC -> General Settings -> Time Zones -> Maintain System Settings
  15. Create/Maintain AC Owners
    • NWBC -> Setup -> Access Owners -> Access Control Owners
  16. Assign FFID/FFRoles to FF Owners
    • NWBC -> Setup -> Superuser Assignment -> Owners
  17. Assign FFID/FFRoles to end users (firefighter) and controllers
    • NWBC -> Setup -> Superuser Assignment -> Firefighter IDs
  18. Create Reason Codes
    • NWBC -> Setup -> Superuser Maintenance -> Reason Codes


Once all of the afore mentioned tasks are performed and successful, firefighter can perform firefighting tasks. His/her activities will be logged, which can be monitored by the Controller and viewed by relevant personnel.


* You might encounter problems in regards to FFID not showing up, Logs not getting collected properly etc. Please check the links provided for additional information.

 

This pretty much is the gist of EAM. For a more comprehensive understanding/configuration and other bits and pieces on this topic, please check out the links in the following document put together by Alessandro, which covers everything in detail. Please check under Emergency Access Management (EAM).


http://scn.sap.com/docs/DOC-57438

 

A big ‘Thank You’ to the people who created and made these posts available for the benefit of people like myself. Your time/effort is very much appreciated guys.

 

Regards,

Leo..


Helpful transactions, tools, programs, tables, etc. for a SAP GRC Consultant

$
0
0

The motivation to write this document comes with the Community Collaboration for GRC Blogs and Documents project that we have started recently in the GRC space. Leo (S A) has requested a document that elaborates which tools and transactions are used by a GRC consultant. I have extended the request to also name some programs and tables I regularly use to complete my job. The following listing will give you an overview of transactions, tools, programs and tables used by a GRC consultant. Each table is sortable by clicking on headings.


 

Transactions

 

TransactionDescriptionKey AreaWhy is this useful?Further details, links, etc.
NWBCLaunch Netweaver Business ClientAlllaunch NWBC HTML. You will need to have work centre roles assigned or build you own.
SPROCustomizingAllSelf explanatory - configuration entry point for both GRC and plug-in systems
GRAC_UPLOAD_MIT_ASGNUpload Mitigation AssignmentsARAUpload a huge number of mitigation (user, role, profile) in one shot. You can either append your current mitigations or overwrite.Mass change of Mitigation Assignments
GRAC_DOWNLOAD_MIT_ASGNDownload Mitigation AssignmentsARADownload a huge number of mitigation (user, role, profile) in one shot.Mass change of Mitigation Assignments
GRFNMW_CONFIGURE_WDMSMP Workflow ConfigurationWFMSMP Workflow Configuration - standard view (web dynpro will launch)
GRFNMW_CONFIGUREMSMP Workflow Config ExpertWFSAP GUI expert mode to configuration workflow configuration. Do not use this transaction if you not familiar or strong with MSMP configuration as you will risk corrupting your build. This is useful if you need to retransport or transport all of the MSMP in one go as you can select it like an IMG table.
GRFNMW_DBGMONITOR_WDMSMP Instance Runtime MonitorWFComprehensive view of the workflow execution for MSMP evaluation including Stage/Path calculation, provisioning notes, notifications and agents. This is useful for an Administrator to track issues with an MSMP after a request has been submitted.
SWDDWorkflow BuilderWF

Unlikely you will need to go into this transaction as the Worfklows for SAP are out of the box and MSMP is used. You can identify the MSMP integration from here.

SWIAWFSAP standard workflow. This will allow you to check the current Workflow and Task numbers. If the MSMP Instance Runtime shows the workflow is completed but SWIA is not completed then there is an issue with the workflow configuration. Check Marketplace incase there is a correction.
GRAC_ROLE_MASS_IMPRTMass Role Import from Backend SystemBRM
GRAC_SPM_CLEANUPCleanup EAM Application DataEAMProgram to clean up EAM tables.
GRAC_EAM/GRAC_SPM and /GRCPI/GRIA_EAMEAM Logon PadEAMFor centralized firefighting, you use GRAC_EAM to open the EAM Launchpad on the GRC system. For decentralized firefighting, you use /GRCPI/GRIA_EAM to open the EAM Launchpad on the plug-in systems. The launchpad for centralized firefighting displays all the plug-in systems to which you have access. The launchpad for decentralized firefighting does not display any systems because it allows you to access only the current plug-in system.
GRAC_UPLOAD_RULESUpload Access Control RulesARAThis is available in the IMG navigation and allows you to import the rule set. Note, if you have workflow activated for you ruleset it will not trigger workflow.
GRAC_COPY_RULESCopy Access Control RulesARAUtility for copying SOD rules from one system to another of same type.
GRAC_RULE_DELETEDelete Access Control RulesARAThis is available in the IMG navigation and allows you to delete the rule set. Note, if you have workflow activated for you ruleset it will not trigger workflow.
GRAC_DOWNLOAD_RULESDownload Access Control RulesARAThis is available in the IMG navigation and allows you to download the rule set. Recommend you save a selection variant with the file name and paths so you do not have to continually maintain them.
GRAC_GENERATE_RULESGenerate Access Control RulesARAThis is available in the IMG navigation and allows you to mass generate the rules. You can also execute this via NWBC, however, this program would allow you to schedule in background via SM36/37
GRAC_RULE_TRANSPORTTransport Access Controls RulesARAThis is available via IMG navigation and allows to mass transport the rule set.
GRAC_EXPORT_RAExport Risk Analysis Data (e.g. when the file is too big for the web)ARAProgram to download the results of the risk analysis to a local file.
GRAC_BATCH_RARisk Analysis in Batch ModeARAThis is available in the IMG navigation and triggers the program for you to schedule batch risk analysis. Ensure your configuration parameters are set
GRAC_GENERATE_RULESWFBuild MSMP rules (usually BRF+). Refer to comment below for creating application first.
GRAC_GEN_ERM_BRFRULEWF/BRMBuild the BRF+ Rules for BRM role methodology and approval conditions groups. Note, before running to to BRF+ and create a shell application that has been assigned to a transport and activated. Use this application in your definition. If not, it gets created in $TMP
BRFPLUSBRFplus WorkbenchWFAlternative transactions: BRF+ and FDT_Workbench. You can maintain the BRF+ rules here and transport through to Production.
STZADCustomizing Time ZonesBCDiscuss with Basis before making any changes to timezone as it can impact EAM log collections, etc.
SLG1Display Application LogsBCApplication log display. It is useful to track error messages. Most GRC authorisations errors will show in the application log
SE61SAP Documentation (Email templates, etc.)AllDocument maintenance.
SE63TranslationsAllThis transaction enables you to directly translate individual objects.
SCPR20Activate BC SetsBasisActivation of BC Sets.Activate BC Sets - Business Configuration Sets (BC-CUS) - SAP Library
PPOMMaintain Organizational PlanBasisMaintain Organizational Plan
SOST/SOSBSAPconncet Send RequestsCheck if there has been an issue with sending on email notifications or reprocess requests. Transaction SOSB can be restricted to limited functionality.Tcode SOST
SCOTSAPconnect AdministrationBasisConfiguration of SAPConnect. Discuss with your Basis team. Take care in enabling in Non-Production environment so you do not accidentally send emails to users and add confusion. If enabled for Non-Prod, recommend you put dummy email addresses on the user accounts.
ST01/STAUTHTRACE/ST05System TraceTrace for an application server. ST01 is useful for authorisation checks and include database calls, kernel and RFC. STAUTHTRACE is new version for security tracing with ALV functionality and drill down (heaps easier to intepret than ST01). ST05 comes in handy to trace SQL calls to find the table where information has been stored.
SM12Enqueue LocksBasisYou can access this in display mode only. It can be a quick way to find which tables your data is stored in. Go into the NWBC screen in change mode so it puts a lock on the tables. Open a new session and go to SM12 to find the tables.
STADDisplay Statistics for all systemsBasisEAM FF logs import STAD information
SCC4Client Administration

Ability to change client setting to enable cross-client changes. Do not make changes to these settings without discussing with Basis. Depending on your landscape strategy you may need to maintain some IMG settings directly in the client (such as integration framework)

SNOTENote AssistantBCImport and apply SAP Notes. You will need to check with your company's policy for note application responsible. If you have not applied and OSS note before, it is strongly recommended your talk to your developer or Basis to learn about pre-requisite and post-processing activities. In some cases, a developer key will be necessary.
SE01/SE09Transport OrganizerBCManage your transports
SE16 / SE16NData BrowserTransaction to easily browse thru data tables.
SM01Lock TransactionsSECLock transaction to prevent users (even if authorised) from executing the transaction. Usually security is responsible for this activity.
SM36Schedule Background JobsBCGRC Access Controls uses a job scheduler via NWBC. SM36 jobs for connector sync,etc can be set up via SM36
SM37Overview of Background JobsBCAllow you to view background jobs. All jobs runtimes will show here, even if scheduled via NWBC.
SA38ABAP ReportingABAPExecute SAP ABAP programs.
SE38ABAP EditorABAPProgram Editor
SE80Object NavigationABAPSAP Development workbench, most development functionality is available from this transaction.
SE37ABAP FunctionABAPMSMP SAP standard rules are usually function modules. You can look at the code if you want to better understand what is being evaluated. Also comes in handy for break point if you need to debug.
SE24ABAP ClassABAPuseful if you need to check the code and add a breakpoint to a method
OOCUTask Customizing
BD54Logical SystemsBasisRFC connections have to be defined as a logical system (usually same name) to then reference in the integration framework configuration
SM59RFC DestinationsBasisRFC Configuration
SM66/SM50WorkprocessBasisView the number of background work process available to define as part of the integration framework for background job processing
SUIMSECUser Information Reporting system
S_BCE_68001426Transactions for UserSECReport shows a list of all transactions assigned to a user. This is a very helpful report to identify critical transactions as user has access to.
S_BCE_68001418Roles by Role NameSECReport to find roles by complex selection criterias. This report can be used to find roles by description, etc.
S_BCE_68001419Roles by User AssignmentSECReport shows a list of all roles assigned to a user. This is very helpful to have an overview of all authorized roles a user have.
S_BCE_68001420Roles by Transaction AssignmentSECReports shows a list of all roles that includes a specific transaction. This is very helpful to easily find possible roles to assign a transaction.
SICFHTTP ServicesBCDiscuss with Basis and Security before activating these as it poses a security risk. If you receive a 403 Forbidden error in NWBC it means a service needs to be activated for the webdynpro. You can also test the services here. For PSS/End User Login screens, the SICF services need to be configured with the Service Account Username and Password stored
GRAC_REP_OBJ_SYNCObject Rep SyncAllUser + Role + Profile Synchronization Job
GRAC_USER_SYNCUser SyncAllUser Synchronization Job
GRAC_ROLE_SYNCRole SyncAllRole Synchronization Job
GRAC_ROLE_USAGE_SYNCRole Usage SyncAllRole Usage Synchronization Job
GRAC_ACT_USAGE_SYNCAction Usage SyncEAM/ARAAction Usage Synchronization Job
GRAC_PROFILE_SYNCProfile SyncAllProfile Synchronization Job
GRAC_AUTH_SYNCAuth SyncAllAuthorization data Synchronization Job
GRAC_SPM_SYNCEAM SyncEAMEmergency Access Management Master Data Synchronization Job
GRAC_SPM_WF_SYNCEAM Workflow SynchronizationEAMEmergency Access Managmement Workflow Synchronization Job
GRAC_SPM_LOG_SYNCEAM Log SyncEAMEmergency Access Management Log Synchronization Job
GRFN_STR_DISPLAY / GRFN_STR_CHANGEOrg Structure Expert ChangeAll

These transactions show all the relationships between objects in the structure considering the timeframe of each object and the timeframe of the relationship.


Both are considered super transactions which are really sensitive. They are exclusive GRC transactions to check Objects Hierarchy. The point of GRFN_STR_CHANGE is that within this transaction you can change master data that you could not using UI. It means that the structure change transaction is not recommended as you can cause severe data inconsistency in the system if you use it without knowing it.

PFCGRole MaintenanceBasisRole maintenance to create and edit roles.5 Role Maintenance in PFCG - SAP NetWeaver Business Client - SAP Library
SU01User MaintenanceBasisUser maintenance
SE16Data BrowserBasisData browser to view/add table data
SM30/SM31/SM34View MaintenanceBasisSE16 and SM30 essentially give direct access to tables information. SM30 is restricted in a way that you cannot use the SM30 interface to view all the tables. Only tables with a maintaince dialog defined can be accessed through SM30. But there is no restriction on the access to tables in SE16 as long as u have access to the authorization group pertaining to the table you will be able to access the information through SE16.
GRFNMW_ADMINMSMP Power User / DebugWF
GRFNMW_CN_VERAMSMP Process Active Version Maint.WF
GRFNMW_DEBUGMSMP Process Debug SettingsWF
GRFNMW_DEBUG_MSGMSMP Process Debug Messages SettingsWF
GRFNMW_DEV_CONFIGMSMP Development ConfigurationWF
GRFNMW_DEV_RULESMSMP Rule Generation / TestingWF
GRFNMW_GEN_VERSIONGenerate Versions for MSMP ConfigWFGenerate version is useful to run after you import a transport (post processing activity) instead of going into MSMP screen to activate.
GRFNMW_MONITORMSMP Workflow MonitoringWFMonitoring of the MSMP Workflow statistics.
GRAC_ENDUSRFORM_SICFEnd user form SICF service
GRAC_FFOBJ_DSC_MAINTMaintain EAM FF Object Description
GRAC_FFOBJ_DSC_MNT1Firefighter Object Maintenance
GRAC_IDM_SCHEMA_SYNCIDM Schema Update
GRAC_DATA_MIGRATIONAC10 Data MigrationProgram to migrate data from an earlier version.
GRAC_DELETE_REPORT_SDelete Report Spool data
GRACRABATCH_MONITORBatch Risk Analysis MonitorThis program is used to monitor the execution status of a running batch risk analysis.
GRAC_ALERT_GENERATEAlert GenerationProgram that generates alerts.SAP GRC AC 10.0 Alerting
GRAC_BATCH_RARisk Analysis In Batch ModeOffline analysis is not real-time data but is dependent on the date of the last Batch Risk Analysis. The Batch Risk Analysis is run as background job in GRC by using transaction GRAC_BATCH_RA (program GRAC_BATCH_RISK_ANALYSIS).Online vs. Offline Risk Analysis

 

Programs

 

ProgramDescriptionWhy is this useful?Further details, links, etc.
PRGN_COMPRESS_TIMESProgram to merge the assignments of identical users and roles, provided the validity periods overlap with one another or immediately follow each other. Also you can delete expired assignments.

Very helpful to easily delete expired assignments or to clean up the assignments after a system copy.

 

Please note that this program should not be run if you have ARQ in place for business roles provisioning.

Before Initial Load ...
TZCUSTHELPTroubleshooting Support for Time Zone SettingsTimezone changes best practices - Basis Corner - SCN Wiki
TZONECHECKCheck Time Zone Data for ConsistencyTimezone changes best practices - Basis Corner - SCN Wiki
RSLDAPSYNC_USERSynchronization of SAP User Administration with an LDAP-Compatible Directory ServiceSynchronization of SAP User Administration with an LDAP-Compatib - Identity Management - SAP Library
GRFNMW_BATCH_EMAIL_REMINDERJob User to send Email reminders to approvers based on number of days and frequency
GRFNMW_BATCH_STALE_REQUESTThis program was useful for deleting non-actionable old requests from the system as housekeeping activity
RSCONN01This job used for sending email (and other types of communication items)
/GRCPI/GRIA_DNLDROLESDownload roles data for mass import

 

 

Tables

 

TableDescriptionWhy is this useful?Further details, links, etc.
GRACREVREJUSERUAR Rejected Users
GRACREJREASONUAR Rejected Reasons
GRACREJREASONTUAR Rejected Reasons Texts
USR02User Logon Data
GRACOWNERMaster Table for Central Owner Administration

 

Other tools

 

ToolDescriptionWhy is this useful?Further details, links, etc.

 

 

I am really looking forward to your input to extend the listing.

 

Best regards,

Ale,Col& Madhu

SAP GRC Process Control - Useful Documents, Blogs, Resources, etc.

$
0
0

This document is a collection of the most useful SAP GRC Process Control documents, blogs, resources, links, etc. here in SCN.

 

Overview

Getting Started with SAP Governance, Risk and Compliance Solutions (GRC)

GRC Risk Management and Process Control 10.0 Content Starter Kits

SAP BusinessObjects GRC 10.0 Integration Guide – Access and Process Control 10.0

 

 

General opinion and thought-leadership

Are you ready to implement GRC 10?

SAP BusinessObjects Process Control 3.0 Implementation Checklist

Using RiskBusiness Content with GRC Risk Management and Process Control 10.0

SAP Business Objects Process Control 10.0 Automated Monitoring Overview

SAP BusinessObjects Process Control 3.0 Expert Guidelines, Tips, and Techniques to Successfully Implement SAP BusinessOb…

 

 

How To's

SAP BusinessObjects Process Control 3.0 and Risk Management 3.0 How to Enable Additional Survey Capabilities

SAP BusinessObjects Process Control 3.0 Reports Description

SAP BusinessObjects Process Control 3.0 How-To Choose the Best Technique for Master Data Uploads

 

 

GRC General

Helpful transactions, tools, programs, tables, etc. for a SAP GRC Consultant

wiki.png General tips to help in troubleshooting scenarios

wiki.png Debugging tips

 

 

Mobile Apps in SAP GRC

Administrator guides for Access Approver, Policy Survey, etc.

Fiori apps in GRC – Install two applications in 5 easy steps

 

 

Extended Workflows

wiki.pngConfiguring Workflow E-mail Notification

 

 

CLM and MDUG

GRC Process Control 10.0: Content Lifecycle Management

 

 

Reports and Dashboards (RE)

wiki.pngHow to Customize and Enhance reports in PC and RM

 

 

Automated Monitoring (AM)

How to set up a Configurable Business Rule

SAP Business Objects Process Control 10.0 Automated Monitoring Overview

 

 

See also

SAP GRC Access Control - Useful Documents, Blogs, Resources, etc.

SAP GRC Risk Management - Useful Documents, Blogs, Resources, etc.

SAP Fraud Management - Useful Documents, Blogs, Resources, etc.

 

 

Legend

 

document.pngSAP SCN Documents
blog.pngSAP SCN Blogs
wiki.pngSAP Wiki

 

Please help in updating the collection so that new users can get a well structured overview for their information.

 

Best regards,

Alessandro& Fernando

SAP GRC Risk Management - Useful Documents, Blogs, Resources, etc.

$
0
0

This document is a collection of the most useful SAP GRC Risk Management documents, blogs, resources, links, etc. here in SCN.

 

Overview

Getting Started with SAP Governance, Risk and Compliance Solutions (GRC)

GRC Risk Management and Process Control 10.0 Content Starter Kits

Overview of SAP BusinessObjects Risk Management 10.0

 

 

General opinion and thought-leadership

Are you ready to implement GRC 10?

Using RiskBusiness Content with GRC Risk Management and Process Control 10.0

 

 

How To's

SAP BusinessObjects Process Control 3.0 and Risk Management 3.0 How to Enable Additional Survey Capabilities

SAP BusinessObjects RM 3.0 Quantitative Risk Analysis v1.0

Risk Management 3.0 Architecture Requirements

 

 

GRC General

Helpful transactions, tools, programs, tables, etc. for a SAP GRC Consultant

wiki.png General tips to help in troubleshooting scenarios

wiki.png Debugging tips

 

 

Mobile Apps in SAP GRC

Administrator guides for Access Approver, Policy Survey, etc.

Fiori apps in GRC – Install two applications in 5 easy steps

 

 

Bow-Tie Risks

wiki.png Integration with Bow-Tie Builder in Risk Management 10.0

 

 

Risk Aggregation

wiki.png Risk Aggregation in RM 10.0

 

 

Integration

wiki.pngRM 10.0 Integration of Activity and Process Control local Sub processes


 

See also

SAP GRC Access Control - Useful Documents, Blogs, Resources, etc.

SAP GRC Process Control - Useful Documents, Blogs, Resources, etc.

SAP Fraud Management - Useful Documents, Blogs, Resources, etc.

 

Legend

 

document.pngSAP SCN Documents
blog.pngSAP SCN Blogs
wiki.pngSAP Wiki

 

 

Please help in updating the collection so that new users can get a well structured overview for their information.

 

Best regards,

Alessandro& Fernando

Top 10 most viewed SAP KBA's for GRC Process Control in August 2014

$
0
0

Purpose

The purpose of this document is to provide a list of the top ten most viewed SAP KBA's for GRC Process Controls in the month of August 2014.


Overview

Below are the top 10 most viewed SAP KBA's for GRC Process Controls.

 

KBA NumberKBA Title
1884797  System is throwing runtime error "SYSTEM_NO_SHM_MEMORY"
2022567  Access using a 'ZERO' object reference is not possible
2006772  Automated Monitoring Job with status Error
2039958  Export of CSV ,XML,PDF and XLS does not work after update to Adobe Flash Player

version 13.0.0.214 or later

2017507  How to Archive Data in Planner and Planner Monitor
1740512  Can not open Microsoft Office 2010
1793111  Error 'Creating TEXT/LONG TEXT failed"
1863830  Audit log report is not fetching data
2015474  Error while creating (ALL kind) of reports
2028217  Unable to export the report result


Please note, in order to view the contents of the Knowledgebase Articles (KBA), you will need to be logged into Service Marketplace.

 

Related Content

Top 10 most viewed SAP KBA's for GRC Process Control in July 2014

Top 10 most viewed SAP KBA's for GRC Process Control in June 2014

Top 10 most viewed SAP KBA's for GRC Process Control in May 2014

Top 10 most viewed SAP KBA's for GRC Process Control in April 2014

Design Considerations to reduce Password Self Service (PSS) Intruder Risk

$
0
0

The aim of this document is to focus on the system controls for password self service to enable you to consider how best to design and configure SAP GRC Password Self Service in your environment. This topic was raised as part of feedback in the document Password Self Service & End User Logon Configuration - AC10 by Leo and requested as part of the GRC Collaboration Project. If you are interested in specific configuration steps, please refer to Leo’s document or search SCN space for your requirements.

 

 

The scope of the document is SAP standard configuration specific to the SAP GRC component. If anyone would like to add suggestions on how to add additional security layers (tokens, SSO, etc) please add your comments in the section below for discussion.

 

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 

A PSS tool needs to go through the basic process which includes verifying the identity of the user before the password can be issued. A critical design requirement for PSS is the ability to prevent an intruder masquerading as a valid user to obtain access to their account.  Within GRC, there is more than way one to achieve this.

 

1 overall process.jpg

 

The above diagram is a conceptual view of the complete steps if all Password Self Service configuration steps are activated. Below is a summary on the intention of each step and impact if they are not used.

 

Network Perimeter

 

This is not so much a step in GRC configuration but recognises that network security will determine if the HTTP service for End User Login is Internet Facing. Assuming GRC system access is only accessible via internal network access, you have limited potential intruders to those who have network access. It has been included to recognise network perimeter security has a part in the GRC solution but will not be discussed in this document.

 

End User Logon


The GRC End User Logon functionality utilises a SAP Service Account to authenticate access for the HTTP service. This means, a SU01 Service Username and password is stored against the SICF web services and the end users do not require a SAP GRC account. The positive of this functionality is that end users do not need to be set up in SAP GRC component (simplify maintenance as well as license cost).

 

GRC makes use of Data Sources for User Authentication, Search and Details for end user functionality. Data Sources are configured via the GRC IMG (transaction SPRO) based on the use of connectors defined in the Integration Framework. Synchronisation jobs are then executed to import the user details. The End User Log-in page can be configured to force authentication against a specific data source. This means, when the user accesses End User Logon functionality, they will required to enter their password for a system defined in the authentication configuration (such as Active Directory or SAP ERP/ECC) and a real-time call is performed to authenticate the user. It is possible to use SAP GRC as an authentication system as well – although this would defeat the purposes in End Users not requiring a SAP GRC account.

 

2 End User Logon.jpg

Screen Shot: Impacts for configuration setting for Data Sources Verification

 

 

Risk #

Summary

Mitigation

1

End User Verification set to NO

Any user on the network can enter any valid User Id without need to know the password to access the password self service

Challenge Response requires the user to respond to questions with the correct answer. A registration process is necessary for the user to provide these details (refer further below)

 

Ultimately, the initial password or URL to retrieve password is sent to the user’s email address. If the email account is secured this prevents the intruder from accessing the account. However, if intruder has access to the user’s network login then this line of defense is broken.

2

End User Verification Relies on System Password being requested for

This creates a catch-22 situation where the user needs to know their password to request a password they cannot remember. For example, if the user cannot remember their ECC password and that is why they need to use PSS then your solution will not work if you require them to authenticate with their ECC password.

Data Sources configuration for Authentication would require more than one data source to provide back-up or Verification will need to be set to NO (refer back to Risk 1). If multiple data sources are used, you will need to consider user training impacts and update the login screen to provide some instructions. One possibility is to configure the Active Directory as a data source for authentication as users would need their network password to login to their computer.

3

Social Engineering/User

Password as an authentication method has a risk of an intruder obtaining it through social engineering means or User writing their password down or disclosing it.

Training users in the risk and consequences of sharing passwords or disclosing them to others is necessary to mitigate this risk.

4

Network Sniffing

A call to the plug-in system is performed to retrieve and validate password (synchronisation jobs do not store the other system passwords in GRC).

Implement strong system security controls. If using Active Directory connector, ensure a secure port is used for communication. Protect the system to system communication through secure network communication (SNC) to prevent eavesdropping as password will no be sent in clear text.

 

The service user account should also be restricted for permissions in the plug-in system to limit S_RFC access.

 

 

Challenge


Challenge Response provides another way for a user to prove their identity through providing answers to pre-configured questions. The system issues a challenge (secret question) to which the user must respond (provide their answer). These questions and answers are stored in GRC tables with the answers in hashed form.

 

Challenge Response requires a registration step in which the use must provide this information. System configuration can provide template/global questions and the user can also create their own.

 

3 Challenge Response.jpg

Screen Shots: Impacts for configuration setting for Challenge Response in PSS Global Settings

 

Risk #

Summary

Mitigation

1

No Challenge Response

The GRC configuration for PSS Global Configurations Values allows you to set ‘PSS Disable Verification’ for Password Self Service or ALL. If you do this, the user does not need to answer special questions

Removal of challenge-response means there is one less security layer for password self service. This risk is reduced if you have End User Verification set to YES and/or can rely on the protection of the email account.

2

Social Engineering

Depending on the question, an intruder may be able to guess or obtain the answer. For example, if the challenge is the user’s pet name, date of birth, etc, an intruder may know this information already or be in a position to obtain it (social media, access to and misuses of HR information).

GRC configuration can be used to limited questions to pre-defined Administrator questions only. User will not have the option to create questions. They will be required to register and provide their answers.

Users need to be educated to choose questions and answers that are not publicly available. System Administrators can preview the challenge questions (answers are hashed but table should also be protected from access in SE16) and also system configuration can limit question creation to administrators only. Administrators are then in a position to set appropriate questions.

3

Guessing

An intruder may guess the answers to the questions without using social engineering tactics. For example, if the challenge includes questions such as ‘What is your date of birth?’; ‘Where were you born?’; ‘What is your pet’s name?’, an intruder may have access to that information via social networks, knowledge about the user or even information user keeps on their desk.

The GRC Configuration allows you to specify the number of questions as well as attempts. To reduce the risk of guess-work, minimise the number of attempts and maximise the number of questions.

 

For example, only allow 3 attempts at an incorrect answer and require the user to answer 4 questions. The specific numbers needs to be weighted against usability – the actual user may struggle to remember that many questions (i.e. it is technically impossible to have up to 100 question but would that be feasible?).

 

Alternatively, train users to disregard the actual question and answer something different. Therefore, if the intruder knew the answer the question, they would still be incorrect. I found this idea in a news article (unable to locate source). However, in practise, this might be confusing for the user and make the solution unworkable.

4

Table Access

Questions and Answers by the user in the registration process are stored in table GRACQUESTION. Answers are stored in hash value.

GRC table GRACQUESTION must be restricted to prevent users from downloading and reverse-engineering the hash values.

5

Registration process

If a user has not registered their questions for Password Self Service then an intruder could access the account, register questions and then use those answers to request a password reset.

End User Verification would require the intruder to know the password for authentication. Secondly, there is still reliance on email address access being restricted. If you cannot rely on email address, then Verification should be used in the initial step.

 

 

Reset Password


Once a user has proven their identity (End User Logon or Challenge Response) they can now select the system they require a password reset for. Users will only see the systems for which PSS has been enabled (IMG configuration controls this) and the user has access to. In this document, the example of SAP ECC has bee chosen. Therefore, a BAPI is called via RFC connection to reset the user password.

 

Risk #

Summary

Mitigation

1

Network Sniffing

A remote function call executes a BAPI in the plug-in system to reset the password and return the information back to the GRC component to communicate to the user. If

Protect the system to system communication through secure network communication (SNC) to prevent eavesdropping as password will no be sent in clear text. The service user account should also be restricted for permissions in the plug-in system to limit S_RFC access.

2

Password Strength

Weak passwords can be guessed.

User RZ10 system parameters and PRGN_CUST table settings to control the length and complexity of the initial password as well as the validity before password expires. Use of security policy can be implemented to differentiate rules for difference user groups but this will not apply to the initial password set by GRC.

 

 

Emailing User


SAP GRC component will generate an email and send the login details to the user. System configuration can control if the password is specified in the email or if a URL is embedded instead. The URL example has been shown in this diagram.

 

Risk #

Summary

Mitigation

1

Network/Email Directory Access

System Administrators, etc may have access to the email directory and be in a position to access the users email

Do not include the password in the email but send the URL link instead (as depicted in this scenario). Refer to section below for URL link and Password Change.

2

External Email Accounts

Non-company email addresses may not be adequately secure for company policies

Limit configuration in transaction SCOT to specific domains only. Therefore, users will need to have a company email address. This solution will not work if your users have external accounts. You will also need to ensure the data sources for the user details contain the correct email address as per these rules.

3

SAP GRC access to SOST/SCOT

Transaction SOST allows you to see email communication sent by the GRC system as well as forward the message to another account.

Restrict access to this transaction or prevent the administrator from viewing the contents of the message (can only see header instead)

 

 

URL Link and Password Change


The GRC configuration allows you to choose send a password URL link or the actual password. This is set within the configuration for User Provisioning. As part of sending URL link only, you will need to specify how long the link is valid for before it expires. If Yes is chosen,the initial password is sent to the user. If no is set, the user receives an email with the URL to launch to then obtain the password.

 

Email status.jpg

 

 

At the end of this process, the user is now able to login with the initial password and change it. The change password rules adhere to the plug-in system configuration (USR40 password dictionary, RZ10 configuration parameters and security policy). These rules are not specific to GRC but based on SAP login sequence.

 


Conclusion

When you design your PSS process you need to choose the appropriate combination of steps for your organisation. At a minimum, you must define at least one step where you have confidence that only the user will know the information. This may be the Initial Logon, Challenge Response or Email.

 

Feedback and suggestions are encouraged, Please add your comments below – especially if you can contribute any more risks that should be considered as part of the PSS design process.

 

Regards

Col and Ale

Review and input by Gretchen Lindquist and S A

How to Add a custom field in Access Request

$
0
0

Every Business has its own requirement. With the feature of custom fields we can full fill it to some extent.


Adding Non-HR User-Defined Fields in Access Control 2010

 

This paper covers adding customer-specific fields for Request objects (related to compliant user provisioning).

 

Supported customer-specific fields

 

Staring release 2010 there are more flexibility in defining the customer-specific fields. You can define them as Single value for access controls.

 

Each category of customer specific fields is stored differently within the databases structures. Single value fields uses customer includes in mater tables of the entities (see chapter “Use Data Elements to Enhance the Data Storage for single value fields” for details).

 

Example

 

This example describes how to add a customer-defined field to a request object. These procedures apply to other objects also. The example shows how to add one field to the request object.

 

Overview of Tasks

 

1. Creating data elements and storage for new fields in the ABAP dictionary

2. Displaying/editing new fields in the Web UI. Custom fields are displayed on the UI automatically. There is an optional BAdI implementation to change the look of the fields or to default a value etc.

 

To perform these tasks:

 You must have the S_DEVELOP authorization profile or the equivalent

 You must test all changes in the development system first before transporting them to the test and production systems.

 

Note: The changes do not cause conflicts with upgrades since they are not considered as modifications of the delivered SAP standard.

 

Modifying the ABAP Dictionary

 

As an example, these instructions create the data element for a calendar date.

Creating an extra data element (and not reusing the existing one) is important because the User Interface and reporting take the captions from the definition of the data element.

 

1. Input transaction SE11 (ABAP Dictionary).

2. Input the name of the Domain. For the example, use ZREQSTAT. Create a logical prefix for your naming convention, starting with Z or Y to indicate that it is a customer-specific namespace.

Capture.JPG

3. Choose Create and select the data element ZREQSTAT. After you activate the object, you must put the data element into your customer-specific package.

4. To create a new data element, you have to maintain the description and the domain:

 

Capture.JPG

Note: Write the description according to your project standards. For the example, the domain is the standard one for the calendar date.

 

5. Select the Field Labels tab and maintain the texts there based on what you want to see on your Process Control screens and reports.

Note: If multiple languages are needed, input transaction SE63 and enter the text in the languages needed.

    

6. Save, check and activate your new data element.

 

Creating a field with a fixed list of possible values

1. Input transaction SE11

2. Input the name of the Data type. For the example, use ZREQSTAT. Create a logical prefix for your naming convention, starting with Z or Y to indicate it is a customer-specific name-space.

3. Choose Create.

 

Capture.JPG

4. Enter the Short Description and the Data Type (CHAR).

5. Enter the length of the field. For the example, use 1 in order to store the fixed values associated with a single character:

 

Capture.JPG

6. Select the Value Range tab and enter the set of the fixed values and their association with descriptive texts.

Note: If multiple languages needed, input transaction SE63 and enter the text in the languages needed.

 

Capture.JPG

7. Save, check and activate the new domain.

Note: Now the domain can be used to create the data element. The procedure is the same as with the data element above: transaction SE11, the data type ZREQSTAT, choose Create, provide the description, as the domain use your brand new domain ZREQSTAT and provide the field labels. Save, check, activate.

 

Use Data Elements to Enhance the Data Storage for single value fields

Here is the list of all the tables/objects that can be enhanced using similar steps:

 

Object Name               Database Table             Customer Include

Request Attributes      GRACREQ                    CI_GRAC_REQ_ATTR

 

1. Using transaction SE11, and specify the table name. For the example, use GRACREQ.

2. Choose Display.

 

Capture.JPG

3. Search through the list of components of the table GRACREQ. At the bottom, locate the customer include. This is where you can add your own fields.

 

Capture.JPG

 

This example focuses on providing one status field explicitly and uses the structure CI_GRAC_REQ_ATTR. This structure will be used within the table, but it does not yet exist. During the next steps, you will create the structure.

 

1. Select the structure CI_GRAC_REQ_ATTR. A dialog box tells you that the structure does not exist and asks whether you want to create it.

2. Confirm that you want to create it.

 

3. Provide the Description of the structure and include one field: ZZ_REQSTAT type Z_REQSTAT

 

Note:

a. The field names are prefixed with ZZ (or YY) to ensure that there is no overlap with the delivered SAP fieldnames.

b. Keep the names unique. All customer fields are used in the global reporting structure. If the same field is used twice, it causes problems.

c. Verify the field name is no longer than 16 characters. Otherwise you cannot activate your customer include structure.

 

Capture.JPG

Note: For the structure CI_GRAC_REQ_ATTR you must enter information about the Enhancement Category. Because this Customer Include Structure is already an Enhancement Structure, it cannot be further enhanced. Follow the menu path Extras -> Enhancement Category. In the window that appears, indicate that the structure Cannot Be Enhanced and choose Copy.

 

Capture.JPG

4. Save, check and activate the structure. Several dependent structures and database (DB) tables are reactivated too, as they include the structure

CI_GRAC_REQ_ATTR. You require powerful authorization to be able to activate the DB tables (for example, the authorization object is S_DEVELOP, with fields OBJTYPE=TABL and ACTVT=07). After the activation, you receive a warning which informs you about the dependent tables, which are implicitly activated with CI_GRAC_REQ_ATTR.


All the dictionary work is done. The case objects for the issues are enhanced with this additional field.

 

Regards,

Nidhi mahajan

User Defaults - GRC 10.0

$
0
0

Purpose of User Defaults:


When a new user is being created in the target system, all users of that system might require few common user defaults like Logon Language, Time Zone, Decimal Notation, Date Format, Parameters etc. Hence when a user is getting created through GRC, based on the request type these user defaults can be assigned to the users.

 

By including user defaults as part of request type (mostly New Account), user gets created with required user defaults in the target system.

 

Important SAP notes regarding User Defaults to refer before configuring User Defaults:


1615552 - GRC 10.0 How to set User Default


1665585 - User Defaults BRF+ rule not working correctly


2020712 - UAM: User group not provisioned after request provisioning

 

Steps to Implement User Defaults:


Step 1: Maintain “User Defaults “action as part of your Request Type. My Request Type 36 is for “New Account” and I have assigned “User Defaults” as shown below.

 

SPRO =>Governance, Risk and Compliance =>Access Control =>User Provisioning =>Define Request Type

 

 

 

Step 2: Go to SPRO -> IMG -> GRC -> Access Control -> User Provisioning -> Maintain User Defaults

 

Define User defaults for different connectors connected to your GRC system. One example as shown below:

 

 

You can assign default User Group and default Parameters based on the connector by using options “Set the User Group” and “Set Parameter ID” in the above screen as per your requirement.

 

 

 

Once you define the User Defaults as mentioned above and save it, a unique “Default-Id” gets created as shown below. This is the User Default Id which will be used in BRF+ decision table while configuring User Defaults.

 

 

Step 3: Existing BRF+ User Defaults application “GRAC_BRFP_USER_DEFAULTS” provided by SAP will be used during configuration of user defaults.

 

 

Copy the Function Id of USER_DEFAULT_FUNCTION from BRF+ application.

 

 

Now map the BRF+ Application for user defaults under the IMG configuration shown below:

Go to IMG->Governance, Risk and Compliance->Access Control->Maintain AC Applications and BRFPlus Function Mapping

Step 4: Add Decision Table and Loop expression to BRF+ User Defaults function as shown below:

 

Decision Table: In the decision table maintain entries as shown below

 

 

Loop: For using "System" as one of the fields in setting the conditions for User Defaults, SAP suggested for implementing a LOOP in BRF+ Rule. This might be needed since "System" field is not available under Request Header attributes, rather it is available as Role Attributes which are called as line-item fields while calling the BRF Rule. So, in such cases LOOP is a suggested solution, rather than using the Decision Table directly. Though within the LOOP, we can still call the Decision Table or implement IF/ELSE conditions.

 


 

Ruleset: When a Function is in event mode, it looks for additional logic execution depending on the Rule-set defined.


Once all above things are done, activate the Decision table, Loop, Ruleset, Function and Application.

 

Step 5:  Now Create an Access request to test the User defaults and once the User is created please cross check the User Defaults in SU01 to check if everything is fine. If all the above steps are followed properly, User defaults will get updated properly as below in SU01.

 

 

Reference Links: http://wiki.scn.sap.com/wiki/display/GRC/Setting+up+User+Defaults


BRM - For the new kid on the block

$
0
0

G'Day All,


In line with my other documents ARA - For the new kid on the block, EAM - For the new kid on the block& ARM - For the new kid on the block this is the final installment of the four components that comprise GRC AC. The objective of this post is to help people who are new to this neck of the woods/Access Control, an overview of my understanding of what BRM is all about and how it works.

 

As usual feel free to skip it if you are well versed in this topic, however please do stick around and feel free to enlighten me with your expertise if I made any mistakes or if you would like to correct/add more on/to this topic. 


Business Role Management (BRM)

This is same as PFCG in R/3 where you build a role. BRM is a web based application that automates the creation and management of Roles. Unlike in the backend system, BRM enforces best practices to ensure that the Role development, testing and maintenance is consistent across the entire implementation, resulting in lower ongoing maintenance and painless knowledge transfer.

 

BRM provides Role Owners and Security Administrators with the means to create and maintain role definitions, identify potential audit and segregation of duties issues. It empowers them to document important role information that can be of great value for better role management.

 

One key element of provisioning in BRM is the identification and mitigation of risks at an early stage, even before the creation of the roles. Risks can be identified as a conflict within a single role, composite role, derived role and templates respectively. This is done with the help of ARA, which provides means to quantify the risks associated with roles and suggests possible remediation and mitigation control procedure.


Business Role concept is the new addition to ERM (5.3). Business roles are system independent, which means you can assign a technical role from one system and another from a different system. A bit like Composite roles but the difference is, roles are not restricted to one system. Although a Business role gets assigned to an end user, it will not be reflected in the backend system. All he/she will be provisioned is a group of technical roles that are associated with the Business Role.


The Nitty Gritty

Creating Roles through BRM, helps Security Admin and Role Owners in:

  • Tracking progress during role implementation.
  • Monitoring the overall quality of the role implementation.
  • Performing risk analysis at role design phase.
  • Providing an audit trail for all role modifications.
  • Enable Firefighter roles for Firefighting
  • Flexible role building workflows, which includes preventative simulations
  • Maintaining roles after they are generated to keep role information current.
  • Enforces Segregation of duties from the ground up by starting with clean role definitions
  • Role Comparison to detect backend changes, which provides role consistency, synchronization, and compliance

 

For example, a person who has authorization to change HR Master Data, should not have authorization to change payroll information as well. If such a conflict action is found in a role, BRM proactively alerts the security team about the considered risk and hence a corrective measure can be established. BRM centralizes and standardizes enterprise wide role management, eliminating manual errors, providing an audit trail for changes, and enforcing user access best practices.

BRM allows to:

  • Create/Change a role in/for multiple systems.
  • Supports multiple landscapes – cross enterprise/cross platform
  • Risk Analysis/Simulation/Mitigation
  • Multiple Role comparison
  • Mass Role Generate/import/update/RA
  • Role Certification
  • Transaction Usage Report

Key stages in Role Creation process through BRM:

  • Role Definition: Enter the role details
  • Authorization: This is where you assign T-Codes/Authorizations
  • Risk Analysis: This is where you analyze risks through ARA
  • Approval: This is where you integrate it with ARM for role assignment/provisioning through pre-configured workflows.

BRM Best Practices

  • Design a good role naming convention.
  • Well thought out integration of BRM into ongoing role development, testing and change management processes.
  • Identify key users (e.g., Role Owners, Security Administrators, and User Administrators) and how they will use and customize BRM accordingly.
  • Define goals (e.g: role optimization or consolidation, user access optimization, reducing risk, reducing the role change requests)
  • Identify custom reports and attach them to BRM.

 

Linch.pin of BRM

Role Methodology

This is where you define the methodology processes and steps for role maintenance. The application provides a set of actions that can be used for role maintenance, such as definition, risk analysis, generation. You can select which actions to use, the order and the frequency. For example, you can define that four steps are required to maintain a role and that approval is required after each step.

 

Defining a step

SAP provides a set of actions that you can perform for role maintenance. When you define a step, you select which actions to use and assign a name that is in line with your company guidelines. For example, you can select delivered Action and Permissions, and name its phase as Maintain Authorizations.

 

Defining a methodology process

You create the methodology process as a framework to attach the methodology steps. You can create as many methodology processes as needed. For example, you may want to have one methodology for finance role requests, and another for office administration role requests.


Adding steps to the methodology process

You assign the steps to the methodology process and select the order of the steps. For example, for finance role requests, you may want to require several approval steps and risk analysis.


* If you wish to create customized methodology processes, like conditioned based workflows and approvals; then you can incorporate MSMP workflows for automation of approvals and provisioning, using BRF+ to define conditions.

 

Configuration in a Nutshell
  1. Create all BRM users or decide amongst the existing users who gets what BRM role using ‘SU01’
  2. Create/customize all BRM roles using ‘PFCG’
    • SAP_GRAC_ROLE_MGMT_ROLE_OWNER: Approver for Role Maintenance
  3. Assign the roles to their respective users using ‘SU01’
  4. Maintain GRC System Configuration Parameters:
    • SPRO -> IMG -> GRC -> AC-> Maintain Configuration Settings -> Role Management
  5. Activate/Check following BC Sets using ‘SCPR20’
    • GRAC_ROLE_MGMT_LANDSCAPE
    • GRAC_ROLE_MGMT_METHODOLOGY
    • GRAC_ROLE_MGMT_PRE_REQ_TYPE
    • GRAC_ROLE_MGMT_ROLE_STATUS
    • GRAC_ROLE_MGMT_SENSITIVITY
    • GRC_MSMP_CONFIGURATION (Optional)
  6. Maintain Connection Settings: ‘ROLMG’ Integration scenario
    • SPRO -> IMG -> GRC -> Common Component Settings -> Integration Framework -> Maintain Integration Scenario
  7. Associate actions and assign default connectors:
    • SPRO -> IMG -> GRC -> AC-> Maintain Mapping for Actions and Connector Groups
      • 001    Role Generation
      • 002    Role Risk Analysis
      • 003    Authorization Maintenance
      • 004    Provisioning
      • 005     HR Triggers (optional)
  8. Maintain Role Type Settings: You can either activate/deactivate pre-delivered role types to suit your needs and set maximum length for the name of the role
    • SPRO -> IMG -> GRC -> AC-> Role Management -> Maintain Role Type Settings
  9. Defining and manage Naming Conventions: This is where you can set a pre-defined naming convention for naming roles
    • SPRO -> IMG -> GRC -> AC-> Role Management -> Specify Naming Convention
  10. Maintain Project and Product Release Name: These are the attributes that you can assign to roles.
    • SPRO -> IMG -> GRC -> AC-> Role Management -> Maintain Project and Product Release Name
  11. Define Role Sensitivity: Sensitivity of role can be set here
    • SPRO -> IMG -> GRC -> AC-> Role Management -> Define Role Sensitivity
  12. Maintain Role Status:Maintain status of the role here. Only roles with status Production are available for user role requests
    • SPRO -> IMG -> GRC -> AC-> Role Management -> Maintain Role Status
  13. Specify Critical Level: Specify how essential a role is to the company
    • SPRO -> IMG -> GRC -> AC-> Role Management -> Specify Critical Level
  14. Define Companies:
    • SPRO -> IMG -> GRC -> AC-> Role Management -> Define Companies
  15. Maintain Functional Areas: Specify a group or department in a company that performs a specific task or function such as Accounting.
    • SPRO -> IMG -> GRC -> AC-> Role Management -> Maintain Functional Areas
  16. Define Prerequisite Types: Define role prerequisites that are required to be validated before granting access to a user
    • SPRO -> IMG -> GRC -> AC-> Role Management -> Define Prerequisite Types
  17. Define Role Prerequisites: Define prerequisites for a role to be assigned
    • SPRO -> IMG -> GRC -> AC-> Role Management -> Define Role Prerequisites
  18. Maintain Business Processes and Sub Processes: Serves similar purpose as Functional Areas
    • SPRO -> IMG -> GRC -> AC-> Maintain Business Process and Sub Processes
  19. Create/Maintain AC Owners
    • NWBC -> Setup -> Access Owners -> Access Control Owners
  20. Assign Condition Groups to BRFplus Functions: You can assign two pre-delivered condition group types (methodology and approver) to the BRFplus applications and the BRFplus functions.
    • SPRO -> IMG -> GRC -> AC-> Role Management -> Assign Condition Groups to BRFplus Functions
  21. Define Methodology Processes and Steps:
    • SPRO -> IMG -> GRC -> AC-> Role Management -> Define Methodology Process and Steps
  22. Associate Methodology Process to Condition Group: you can associate the methodology processes to a condition group. The application uses this association to determine which methodology process to use based on the specified settings in the condition group.
    • SPRO -> IMG -> GRC -> AC-> Role Management -> Associate Methodology Process to Condition Group
  23. Generate BRF+ Rules (Optional)
    • TCode: BRF+
  24. Maintain MSMP Workflows: This needs to be configured if there is an approval step in Role Creation Methodology

This pretty much is the gist of BRM and should be enough to get you started. For a more comprehensive understanding/configuration and other bits and pieces on this topic, please check out the links in the following document put together by Alessandro, which covers everything in detail. Please check under Business Role Management (BRM).

http://scn.sap.com/docs/DOC-57438

 

 

Regards,

Leo..

SAP_ALL replace role for user WF-BATCH -ARM,GRC10

$
0
0

Dear all,

 

Generally we will assign SAP_ALL to user id WF-BATCH for mail communication and background jobs to avoid missing authorizations.

 

But we have requirement not to use SAP_ALL for WF-BATCH user id,instead use role for the same.

 

Hence we created role which replaces SAP_ALL profile for communication and background jobs

 

Added 444 authorization objects manually and tested for ARM,the workflow is working fine with approvers and provisioning in back-end.

 

I thought to share the document(As attachment) with you all,might be use full if anybody is looking for same requirement.

 

 

 

BR

Baithi

EAM - For the new kid on the block

$
0
0

G’Day All,

 

Picking up from my previous topic aboutARA - For the new kid on the block, this document is just an overview of my understanding of what EAM is (from what I read here and SAP documentation) and how it works.

 

The objective of this document is to give people who are just starting out or even beginning to find their feet, a brief overview of EAM before they can get stuck into it and go all in(links provided). This is not intended for people who are well versed on this topic, so if that is you, please feel free to skip it as this might not interest you. However if you do want to stick around and point/correct any mistakes or offer advice/suggestions, please by all means do so. I am open to constructive criticism.


I understand there is a lot of content related to EAM in this site and some of the information covered herein might exist elsewhere in some shape or form however this is just meant to serve as a conduit for freshers, who might get a tad overwhelmed by all the information lying around. So I hope this document can give them a glimpse of what it is all about and then help them to venture out into the wild.

 

What is it all about?

EAM enables end-users to perform emergency activities outside the parameters of their standard role, but within a controlled and fully audit-able environment. The application assigns a temporary Firefighter ID that grants an end user(firefighter) broad yet regulated access, and logs every activity he/she performs using the temporary ID.

 

This is usually done in emergency situations, where it is imperative for a user to execute certain tasks irrespective of SOD violations and transaction code clashes however all of his/her actions are monitored and recorded making the session completely visible and transparent.

 

 

Key challenges of EAM
  1. Identification of Business Processes and creating dedicated Firefighter IDs/Roles pertinent to them.
  2. Identification of the need for usage of Firefighter ID/Role
  3. Identification of Firefighters, Firefighter Owners, Controllers, and Administrators.
  4. Identification/Standardization of Reason Codes
  5. Consistency of naming conventions for Firefighter ID/Roles and Reason Codes.
  6. Archival policy for the Firefighter Logs
  7. EAM usage policy should be created to identify tasks which can be positively supported by EAM.
  8. Last but not least, performance optimization.

 

 

Potential functional scenarios for EAM Access

Additional resources with additional roles

Approaching month/financial year end and need additional resources to speed up certain activities. Additional resources are required but they don’t have enough authorizations. This task can be easily automated by EAM and individual activity log would be generated for later review.

 

Developer access on production system

Developer access on production systems is one of the most critical scenarios, but at times it becomes necessary to allow developer access to fix certain bugs urgently. This is an ideal emergency scenario for assigning firefighter id to track each and every activity a developer or a group of developers perform. However developer access on production is never recommended but when you can’t wait for a bug-fix to travel from a lengthy procedure (Dev-Qual-Prod) then EAM works as a mighty mitigation control.

 

Contract user access

To maintain track of contract users activities for a certain period of time. This can be achieved by assigning Firefighter IDs to contract users for access on the assigned system. This allows all their activities to be recorded for an extended review and hence management oversight is achieved.

 

Auditor Access

Most companies have strict audit procedures in place, which entails both internal and external auditors to conduct audits on a regular basis. Auditors can be granted temporary access through EAM.

 

* By no means is this list exhaustive however it should give you an indication of the potential reasons for EAM Access.

* Given the fact that EAM is a form of Mitigation (Please check the ARA document), It is used in scenarios where you have exhausted all other options!!

 

 

Firefighter Users, Roles and Responsibilities
Users/FFID/FFROLERoles & Responsibilities
Firefighter ID

This is a unique user id, created with specific roles that allow the firefighter to perform the required tasks. So we can create multiple Firefighter id’s with specific roles and assign them to the designated users (Firefighters) for a set period of time.

  • SU01: Create FFID
  • Roles: SAP_GRAC_SPM_FFID (This should be exactly the same in config settings as well. Shown further in the document)
Firefighter Role

This is a unique role, which gets assigned to the firefighter to perform the requited tasks.

  • PFCG/BRM: Create FFROLE. Ensure this role is enabled for firefighting in BRM.
Firefighter

These are the users who get assigned with the required Firefighter ID/Role. Firefighter users use Firefighter ID/Role to perform firefighting tasks.

  • SU01: Create FFighter or assign the role to an existing user
  • Role: SAP_GRAC_SUPER_USER_MGMT_USER (This role might need other additional authorizations. Please check the links provided)
Firefighter Administrator

This is the person who has got the ultimate authority over the firefighter program. He/she is responsible for assigning FF ID/roles to firefighters (if they choose to), Owners. They can generate reports, ensure reason codes are up to date etc.

  • SU01: Create FF ADMINISTRTOR or assign the role to an existing user
  • Roles: SAP_GRAC_SUPER_USER_MGMT_ADMIN,  SAP_GRAC_BASE,  SAP_GRAC_NWBC
Firefighter Owner

These are the ID/Role owners and are responsible for assigning FF ID/roles assigned to them by the administrator, to firefighters and controllers. They can also act as controllers however they should not be able to assign FF ID/roles to themselves. They can only be one FF Owner per FF ID/role however one FF Owner can have multiple FF ID/roles.

  • SU01: Create FF Owner or assign the role to an existing user
  • Roles: SAP_GRAC_SUPER_USER_MGMT_OWNER,  SAP_GRAC_BASE,  SAP_GRAC_NWBC
Firefighter Controller

These are the people who monitor the actions of the firefighters. They can do this by viewing the log report and can even receive email notifications when a Firefighter logs in.

  • SU01: Create FF Controller or assign the role to an existing user
  • Roles: SAP_GRAC_SUPER_USER_MGMT_CNTLR,  SAP_GRAC_BASE,  SAP_GRAC_NWBC

* All of the aforementioned roles can/needs to be customized. One can use a naming convention that suits their company requirements


AC10 has the option of having either Centralized or Decentralized firefighting (more on this in the links provided at the end of the document).

 

Centralized

User has to go from plugin/backend system (R3PRD001) and log into a GRC System (GRCPRD001), execute GRAC_SPM(OR EAM) -> which will launch the EAM launchpad -> then access the system [R3PRD001 or something else (HCMPRD001), (CRMPRD001) etc] assigned to him/her by clicking the logon button-> perform FF tasks.

  • This is a better option when in some companies, the user has to access multiple systems. So he/she can log into GRC system (GRC Box) and can start firefighter sessions by clicking on 'logon', which will take him/her to the assigned system.
  • Firefighters can log on centrally as opposed to logging into multiple systems separately
  • FFAdministrator, FFOwner, FFController, Firefighter and their respective roles have to be maintained in the GRC system
  • FFID and its respective role has to be maintained only in the plug-in system

 

Decentralized

User has to stay on the BackEnd system (R3PRD001) execute /n/GRCPI/GRIA_EAM -> which will launch the EAM launchpad -> then click the logon button to start a session in the very same system (R3PRD001) and perform FF tasks. You can enable DC-FF by parameter 1000: GRD(RFC Connector pointing to itself), 4015.

  • The most important advantage of DC firefighting is that you can continue using firefighter even when the GRC Box is down.
  • It’s also more “user-friendly” since the firefighter doesn’t have to log on to GRC Box in order to start the firefighting session, he/she only needs to execute a transaction in the plugin/backend system.
  • Firefighter and his/her respective role has to be maintained just in the plug-in system
  • FFID and its respective role has to be maintained only in the plug-in system
  • FFController and his/her respective role has to be maintained both in the plug-in/GRC system(to receive emails of logs)
  • FFAdministrator and FFOwner and their respective roles have to be maintained in the GRC system

 

 

ID Based vs Role Based

One of  the key difference between assigning a Firefighter an FFID vs FFRole is added security.

 

An FFID is built with a certain role in mind, which has predetermined tcodes assigned to it and this gets assigned to an end user (firefighter). So if this user wishes to commit fraud, he/she can execute certain tcodes from his/her user id and then the remaining from the FFID. This way the chances of him/her getting caught, is dependent on a thorough monitoring/analysis by the controller/auditors.

 

Whereas if you build a specific firefighter role with the same tcodes, this role gets assigned to the end user not an FFID, so every transaction executed shows up against their user id, which makes his/her task of committing fraud a lot harder if not negligible.

 

key differences are as follows:

 

ID BasedRole Based

Logs in using own user ID, accesses FFID from the GRC System and logs into the system assigned to them(ECC, SRM, CRM etc).

Logs into the plug-in system using own user ID, so everything gets logged against that one ID. Multiple users can use the FFROLE at once.

Only one user at a time can use a FFID.Multiple users can use multiple FFRoles at once.
Firefighter need not exist in every system assigned to them due to central logon however they need to exist in the GRC system (This is only applicable for Centralised firefighting).

Firefighter has to exist in every system assigned to them - so multiple logons. (This is only applicable if the user needs to perform tasks in other systems).

Knows exactly when FFID is being used as he/she has to login so has a psychological effect (good thing).

Hard to differentiate between FF tasks and normal tasks as there is no login required. So easy to slip up.

Better tracking of FF tasks - Specific log reports with Reason Codes. Bonus point from Auditors!

Time consuming to track FF tasks - No Specific log reports. No Reason Codes.

Two logins so potential to commit fraud. (1 action using own UserID and 1 action using FFID).

Only one login, so everything gets logged against one id(own user id). Harder to commit fraud.

Could be hard to track and find out when a fraud has been committed so can be a problem with auditors. When two logins used

Easy to track as only one login is used however a thorough analysis is required to differentiate ff tasks from normal tasks.
  • GRAC_SPM : TCode for Centralised FFighting -> You will see FFIDs  assigned to you
  • /n/GRCPI/GRIA_EAM : TCode for DeCentralised FFighting -> You can see the FFIDs assigned to you
  • GRAC_SPM : TCode for Centralised FFighting -> You will see FFROLEs assigned to you
  • /n/GRCPI/GRIA_EAM : TCode for DCentralised FFighting -> Not applicable so wont work

 

 

Configuration in a nutshell
  1. Create all EAM users or decide amongst the existing users who gets what EAM role using ‘SU01’
  2. Create/customize all EAM roles using ‘PFCG’
  3. Assign those roles to their respective users using ‘SU01’
  4. Create an FFID/FFRole with the predetermined roles/tcodes using ‘SU01/PFCG/BRM’
  5. Maintain GRC Plug-In System Configuration Parameters:
    • SPRO -> IMG -> GRC (Plug-In) -> Maintain Plug-In Configuration Settings
    • Parameter IDParameter ValueDescription
      1000Plug-in Connector ID
      This information is used to connect to the Plug-In system.
      4000ID Based:1  Role Based:2
      Application type
      4001DaysDefault Firefighter Validity Period (Days)
      4008Yes/NoSend Firefighter Id Login Notification
      4010Z_SAP_GRAC_SPM_FFID

      Firefighter ID role name

  6. Maintain GRC System Configuration Parameters:
    • SPRO -> IMG -> GRC -> AC-> Maintain Configuration Settings
    • Parameter IDParameter ValueDescription
      4000ID Based:1  Role Based:2Application type
      4001DaysDefault Firefighter Validity Period (Days)
      4002Yes/NoSend Email Immediately
      4003Yes/NoRetrieve Change Log
      4004Yes/NoRetrieve System log
      4005Yes/NoRetrieve Audit log
      4006Yes/NoRetrieve OS Command log
      4007Yes/NoSend Log Report Execution Notification Immediately
      4008Yes/NoSend Firefighter Id Login Notification
      4009Yes/NoLog Report Execution Notification
      4010Z_SAP_GRAC_SPM_FFIDFirefighter ID role name
      4012All Users:1  Controllers:2Default users for forwarding the Audit Log workflow
      4013Yes/NoFirefighter ID owner can submit request for FF ID owned
      4014Yes/NoFirefighter ID controller can submit request for FF ID controlled
      4015Yes/NoEnable Decentralized Firefighting
  7. Maintain User Exits
    • SPRO -> IMG -> GRC (Plug-In) -> Maintain User Exits
  8. Maintain Connection Settings: SUPMG Integration scenario
    • SPRO -> IMG -> GRC -> Common Component Settings -> Integration Framework -> Maintain Integration Scenario
  9. Activate/Check Criticality Level BC Set
    • SPRO -> IMG -> SCPR20 -> GRAC_SPM_CRITICALITY_LEVEL
  10. Maintain Criticality level
    • SPRO -> IMG -> GRC -> AC-> EAM -> Maintain Criticality Levels for EAM
  11. Run Synchronization jobs
    • SPRO -> IMG -> GRC -> AC-> Synchronization Jobs
      • Check for the help option to see what does what.
  12. Schedule Background Jobs for EAM log collection on periodic basis
    • SM36 -> GRAC_SPM_LOG_SYNC_UPDATE
  13. Maintain login/log notifications - only if you want to customize the default ones.
    • SPRO -> IMG -> GRC (Plug-In) -> Maintain Custom Notification/Text Messages for EAM (Plug-In)
  14. Verify Time Zones of the Operating System and the AC server match to ensure EAM logs are captured
    • SPRO -> IMG -> GRC -> General Settings -> Time Zones -> Maintain System Settings
  15. Create/Maintain AC Owners
    • NWBC -> Setup -> Access Owners -> Access Control Owners
  16. Assign FFID/FFRoles to FF Owners
    • NWBC -> Setup -> Superuser Assignment -> Owners
  17. Assign FFID/FFRoles to end users (firefighter) and controllers
    • NWBC -> Setup -> Superuser Assignment -> Firefighter IDs
  18. Create Reason Codes
    • NWBC -> Setup -> Superuser Maintenance -> Reason Codes


Once all of the afore mentioned tasks are performed and successful, firefighter can perform firefighting tasks. His/her activities will be logged, which can be monitored by the Controller and viewed by relevant personnel.


* You might encounter problems in regards to FFID not showing up, Logs not getting collected properly etc. Please check the links provided for additional information.

 

This pretty much is the gist of EAM. For a more comprehensive understanding/configuration and other bits and pieces on this topic, please check out the links in the following document put together by Alessandro, which covers everything in detail. Please check under Emergency Access Management (EAM).


http://scn.sap.com/docs/DOC-57438

 

A big ‘Thank You’ to the people who created and made these posts available for the benefit of people like myself. Your time/effort is very much appreciated guys.

 

Regards,

Leo..

GRC Document Collaboration Topics

$
0
0

Hi All

 

If you are wondering what this document is all about then please refer to: Community Collaboration for GRC Blogs and Documents - you will find an overview of what this community collaboration is about and the rules on how you can contribute. You are still encouraged to write your own blogs and documents without participating in this process (it would be nice if you could update this document to let the community know you are working on something).

 

You are also welcome to be both the person who suggests the topic and the author. This can advertise you are working on the topic and hold yourself accountable to a deadline that the community is aware of.

 

 

Remember: Add a row below the 3rd row of the table to included your suggestion. Please do not change the first three heading rows as these rows indicate the title and a short summary of the content below. When including your name, please include your SCN profile as a hyperlink (easiest way to open your Profile in a new browser tab and copy the URL)

 

 

Step 1: Requester to CompleteStep 2: Author to completeStep 3: Option (collaborator to complete)Step 4: Author to PublishModerator and Coordinator Override
DateSuggestedSuggested ByDocument TypeIdeaAuthorDate DueAssistance?NameLink to itemModerator and reason for rejection
DD/MM/YYYYYour SCN  Profile URLblog or documentTitle or topic ideaYour SCN  Profile URLDD/MM/YYYY

do you want any assistance?

If yes, summarise (input, review, etc)

Your SCN profile URLSCN document or blog linkModerators or Coordinators to advise if topic is not appropriate.
27/08/2014Alessandro Banzer / Colleen LeeDocumentAnalysis of the SAP delivered rule-set - do you accept as it is? Do you build your own or do you do something in between?Approved
13/09/2014Colleen LeeDocumentBusiness Role Management - overview and use of the methodology customisation
13/09/2014Colleen LeeBlogBusiness Role Manager - What are the benefits and issues with using BRM and integrating with ARA and ARQ?
02/10/14S A)DocumentPSS - Best practices, pitfalls to avoid and things to consider while enabling PSS?Colleen Lee12/10/2014Reviewed by S.A, Alessandro & GretchenDesign Considerations to reduce Password Self Service (PSS) Intruder RiskApproved
02/10/2014Colleen LeeBlogBRM - discussion use of profile generation to distribute role to different systems vs system transports
02/10/2014Colleen LeeDocumentSummary of the GRC Org structure - which sections apply to AC, PC and RM and any tips on integration with ERP
30/10/2014Darnell SuggsDocumentLink or Page to latest Configuration and Integration Documents for GRC AC 10.1 similar to SAP BOBJ AC 10.0

SAP GRC Access Control - Useful Documents, Blogs, Resources, etc.

$
0
0

This document is a collection of the most useful SAP GRC Access Control documents, blogs, resources, links, etc. here in SCN.

 

Overview

Getting Started with SAP Governance, Risk and Compliance Solutions (GRC)

GRC Processes, Lifecycles and Responsibilities

 

 

General opinion and thought-leadership

Are you ready to implement GRC 10?

A lot of help from my friends

If I had it to do all over: looking back on GRC 10 projects

Lessons learned from SAP GRC projects

Remediating Access Control SoD Risks

Internal Controls - a step towards strong controls

Defining Mitigating Controls / Compensating Controls

IT Control Testing - SOX Compliance

A #GRC tool is just part of the solution

 

 

GRC General

Helpful transactions, tools, programs, tables, etc. for a SAP GRC Consultant

NWBC screen layout options for GRC

Customizing NWBC for New Menus with our own Transactions, Reports and Accessing SAP Backend Systems from NWBC

Configure LaunchPad for Menus

Customizing Access request and approval screens in GRC Access Control

Issues, Bugs in GRC SP13 - Related Fixes

wiki.pngGeneral tips to help in troubleshooting scenarios

wiki.pngAccess Control Debugging tips

SAP GRC AC 10.1 - Enhancements

 

 

HR Triggers

wiki.png Understanding HR Triggers in Access Control 10.0 - Governance, Risk and Compliance - SCN Wiki

wiki.png GRC 10.0 - HR Trigger configuration - Governance, Risk and Compliance - SCN Wiki

Example of decision table for GRC 10 HR Trigger rule, using BRF+ tool

GRC Access Control - Compliant User Provisioning: HR Triggers

wiki.png Debugging HR Trigger - GRAC_HR_TRIGGER_EVENT_RECIEVER

wiki.png Debugging HR Trigger - Simulation

wiki.png Debugging HR Trigger - PA40 changes to infotypes

 

 

MSMP Workflows

AC 10.0 - Customizing Workflows for Access Management

MSMP - Multi Step Multi Process – GRC’s answer to Workflow Configuration Flexibility

 

 

LDAP

Configuring LDAP Connector in Compliant User Provisioning of GRC Access Control

LDAP Group parameter mapping.. what does it mean?

 

 

Mobile Apps in SAP GRC

Administrator guides for Access Approver, Policy Survey, etc.

Fiori apps in GRC – Install two applications in 5 easy steps

 

 

Access Control with Identity Management (IdM)

SAP BusinessObjects GRC 10.0 Integration Guide – Access Control 10.0 and NetWeaver Identity Management

SAP Access Control 10.0 Interface for Identity Management

 

 

Access Risk Analysis (ARA)

ARA - For the new kid on the block

Rule set - Rules & Rule Types

Business Risks / Rule Set

How to set up a Configurable Business Rule

Online vs. Offline Risk Analysis

Creation of Mitigation Controls in GRC 10.0

Organizational Rules in GRC Access Control

Mass change of Mitigation Assignments

SAP GRC AC 10.0 Alerting

wiki.png The Action Usage Sync job in technical details - GRC Access Control 10.0

wiki.png The Repository - GRC Access Control 10.0 

 

 

Access Request Management (ARM)

ARM - For the new kid on the block

AC10.0/10.1: Create Rule Based on Risk Violation in Request, Using BRF+ Procedure Calls

Approve/Reject Own Requests

How to Change Subject Line in SAP GRC Email notification

Recommendations for using Business roles provisioning in access request

Configure Manager Look-Up in ARM for GRC 10

Role Search Screen Enhancement – GRC 10

Terminate Account - Request Process - GRC 10

Creating Access Request: Template Based Requests and Configuring End User Personalization forms for use with Access Requ…

GRC Request with both System and Role Line Items

Access Control 10 (ARM) – Risk Analysis Report Type is editable in Access Request.

Access Control: - Create Access Request Using Web Service in GRC10

Design Considerations to reduce Password Self Service (PSS) Intruder Risk

wiki.png User Access Review(UAR) Workflow Configuration and Description - Governance, Risk and Compliance - SCN Wiki

 

 

Business Role Management (BRM)

BRM - For the new kid on the block

Maintain Default Roles in BRM GRC AC 10.1

Role Import - GRC 10

Import Role from ECC to GRC system

wiki.png Business Roles concept and usability in GRC AC10 

 

 

Emergency Access Management (EAM)

EAM - For the new kid on the block

EAM - Provisioning Strategies

ID-Based Firefighting vs. Role-Based Firefighting

AC 10.0 - Centralized Emergency Access

Configure Emergency Access (EAM) in GRC 10

De-centralized EAM GRC 10.0

EAM - Approve through Wrokflow

Emergency Access Management Reporting

 

 

See also

SAP GRC Process Control - Useful Documents, Blogs, Resources, etc.

SAP GRC Risk Management - Useful Documents, Blogs, Resources, etc.

SAP Fraud Management - Useful Documents, Blogs, Resources, etc.

 

 

Legend

 

document.pngSAP SCN Documents
blog.pngSAP SCN Blogs
wiki.pngSAP Wiki

 

 

Please help in updating the collection so that new users can get a well structured overview for their information.

 

Best regards,

Alessandro

SAP GRC Process Control - Useful Documents, Blogs, Resources, etc.

$
0
0

This document is a collection of the most useful SAP GRC Process Control documents, blogs, resources, links, etc. here in SCN.

 

Overview

Getting Started with SAP Governance, Risk and Compliance Solutions (GRC)

GRC Risk Management and Process Control 10.0 Content Starter Kits

SAP BusinessObjects GRC 10.0 Integration Guide – Access and Process Control 10.0

 

 

General opinion and thought-leadership

Are you ready to implement GRC 10?

SAP BusinessObjects Process Control 3.0 Implementation Checklist

Using RiskBusiness Content with GRC Risk Management and Process Control 10.0

SAP Business Objects Process Control 10.0 Automated Monitoring Overview

SAP BusinessObjects Process Control 3.0 Expert Guidelines, Tips, and Techniques to Successfully Implement SAP BusinessOb…

 

 

How To's

SAP BusinessObjects Process Control 3.0 and Risk Management 3.0 How to Enable Additional Survey Capabilities

SAP BusinessObjects Process Control 3.0 Reports Description

SAP BusinessObjects Process Control 3.0 How-To Choose the Best Technique for Master Data Uploads

 

 

GRC General

Helpful transactions, tools, programs, tables, etc. for a SAP GRC Consultant

wiki.png General tips to help in troubleshooting scenarios

wiki.png Debugging tips

 

 

Mobile Apps in SAP GRC

Administrator guides for Access Approver, Policy Survey, etc.

Fiori apps in GRC – Install two applications in 5 easy steps

 

 

Extended Workflows

wiki.pngConfiguring Workflow E-mail Notification

 

 

CLM and MDUG

GRC Process Control 10.0: Content Lifecycle Management

 

 

Reports and Dashboards (RE)

wiki.pngHow to Customize and Enhance reports in PC and RM

 

 

Automated Monitoring (AM)

How to set up a Configurable Business Rule

SAP Business Objects Process Control 10.0 Automated Monitoring Overview

 

 

See also

SAP GRC Access Control - Useful Documents, Blogs, Resources, etc.

SAP GRC Risk Management - Useful Documents, Blogs, Resources, etc.

SAP Fraud Management - Useful Documents, Blogs, Resources, etc.

 

 

Legend

 

document.pngSAP SCN Documents
blog.pngSAP SCN Blogs
wiki.pngSAP Wiki

 

Please help in updating the collection so that new users can get a well structured overview for their information.

 

Best regards,

Alessandro& Fernando

SAP GRC Risk Management - Useful Documents, Blogs, Resources, etc.

$
0
0

This document is a collection of the most useful SAP GRC Risk Management documents, blogs, resources, links, etc. here in SCN.

 

Overview

Getting Started with SAP Governance, Risk and Compliance Solutions (GRC)

GRC Risk Management and Process Control 10.0 Content Starter Kits

Overview of SAP BusinessObjects Risk Management 10.0

 

 

General opinion and thought-leadership

Are you ready to implement GRC 10?

Using RiskBusiness Content with GRC Risk Management and Process Control 10.0

 

 

How To's

SAP BusinessObjects Process Control 3.0 and Risk Management 3.0 How to Enable Additional Survey Capabilities

SAP BusinessObjects RM 3.0 Quantitative Risk Analysis v1.0

Risk Management 3.0 Architecture Requirements

 

 

GRC General

Helpful transactions, tools, programs, tables, etc. for a SAP GRC Consultant

wiki.png General tips to help in troubleshooting scenarios

wiki.png Debugging tips

 

 

Mobile Apps in SAP GRC

Administrator guides for Access Approver, Policy Survey, etc.

Fiori apps in GRC – Install two applications in 5 easy steps

 

 

Bow-Tie Risks

wiki.png Integration with Bow-Tie Builder in Risk Management 10.0

 

 

Risk Aggregation

wiki.png Risk Aggregation in RM 10.0

 

 

Integration

wiki.pngRM 10.0 Integration of Activity and Process Control local Sub processes


 

See also

SAP GRC Access Control - Useful Documents, Blogs, Resources, etc.

SAP GRC Process Control - Useful Documents, Blogs, Resources, etc.

SAP Fraud Management - Useful Documents, Blogs, Resources, etc.

 

Legend

 

document.pngSAP SCN Documents
blog.pngSAP SCN Blogs
wiki.pngSAP Wiki

 

 

Please help in updating the collection so that new users can get a well structured overview for their information.

 

Best regards,

Alessandro& Fernando


SAP Fraud Management - Useful Documents, Blogs, Resources, etc.

$
0
0

User Access Review - Issues and Fixes - SP13

$
0
0

User Access Review - Nightmare in GRC SP13 I will update this regularly with all our issues and fixes.

 

Customize Review Instructions

For customizing the UAR review instructions in the UAR request approval screen, please implement the below SAP notes:

 

Below note is for creating a program and then creating a SE61 template for maintaining the customized instructions for UAR

 

1926795 - Not possible to customize UAR review instructions

 

Below is note is to format the instructions in the same way as maintained in SE61 in request approval screen:

 

1946444 - UAR Review Instruction Format in Access Request

 

 

BRF+ Fields for UAR requests

During UAR implementation, in BRF+ rule use ROLE_CONNECTOR and however your BRF+ rule doesn't work. To fix this issue and to route your UAR requests based on System implelment below SAP note:

 

1917837 - UAM : Connector based brf + rule is not working

 

Basic UAR Issues


In the UAR request approval screen, we observed some below mentioned issues.

 

1. User Name is not coming

2. Individual Role can be forwarded to another approver

3. Sometimes only UserID shows up and no role details

 

We fixed all above issues mentioned using below SAP note:

 

1868950 - UAM: UAR request display, print and forward assignment issue

 

UAR Jobs - Issues


When we schedule UAR jobs, although they are completed, they are still shown with In-process status. For this SAP has provided a note specific to few customers only.


1997960 - UAM: Unable to generate request for UAR/SOD.

 

UAR Reports - Issues


When UAR request is forwarded to another approver, in the UAR status report Approver ID is showing wrong. To correct this we implemented below SAP note:

 

1895571 - UAM: User Access Review status report not working

 

We have raised a OSS message to SAP as there is no connector based search available for UAR status reports. Below is the note provided to us which is not yet released to all customers.

 

2072384 Connector Criteria available in UAR Status report

 

Attachment of this note also attached in this post. Please check.

 

Symptom:

1. UAR history and status reports dump due to huge data.

2. No system/connector criteria availabe in user review status report.

 

Reason and Prerequisites

All data for all request was being stored in an internal table

 

Solution

Implement attached correction instructions


Add connector in User review status report


   1. Go to T-code SE 11 and select View radio button.

 

   2. Enter V_GRFNREPFILTER and click on display button.

 

 

3. Click on highlighted icon.

 

4. Enter report name ‘GRAC_CUP_USR_RVW_RPT”.

 

5. Click on edit icon, a window will pop up and press enter.

6. Click on new entry and enter as new entry for connector as mentioned below.

 

7. Save and activate the view.

 

Other terms

UAR history, UAR status, reports, dump, memory overflow, connector

 

------------------------------------------------------------------------

|Manual Pre-Implement. |

------------------------------------------------------------------------

|VALID FOR |

|Software Component GRCFND_A GRCFND_A |

| Release V1000 SAPK-V1004INGRCFNDA - SAPK-V1017INGRCFNDA |

------------------------------------------------------------------------

Kindly follow the steps as mentioned in attached file

(Connector_add.docx)

________________________________________________________________________

Valid Releases

GRCFND_A

V1000

V1100

________________________________________________________________________

 

After implementing the SAP note 2072384, we got another issue in the UAR status report where Stage column in the report is showing the same stage for all requests. For this SAP has released another note for us which is not yet released to all customers. Below is the SAP note:

 

2096437 - UAM: User review status report showing Incorrect Stage details


Symptom

UAR- User Review status report shows incorrect stage details.

 

Reason and Prerequisites

Wrong value is passed.

 

Solution

Implement the correction instruction.

 

Other terms

GRC, AC, UAR, Stage, User Review Status, Report.

Usage of EAM

$
0
0

This document elaborates the usage of Emergency Access Management (EAM) and its dangers of inappropriate usage. To get more information about EAM in general please refer to the excellent collection document from Leo: EAM - For the new kid on the block.

 

Before you start using EAM you have to think why you are using it and what you are going to analyze in log review. SAP's official GRC300 course (GRC300 - SAP Access Control 10.0 - Implementation | SAP Training and Certification Shop) says that EAM is used as a form of remediation/mitigation for SOD (Segregation of Duties). This document focuses more on firefighting in emergency situations rather than on mitigating critical access.

 

In the section "Inapproriate Usage" I have mentioned that daily business tasks should not be performed with a firefighter. In case you define EAM as mitigation/remediation of critical access, as mention in GRC300 course, then this isn't an inappropriate action as it covers an end user's business function for supporting user. Also you might have support users have daily activities that they use Firefighter for (from security point of view it's recommended as a way to capture service call numbers for audit trail).

 

 

Short Overview

 

EAM in general offers a number of advantages for the management of emergency access, including

  • Mitigates the most common open audit issue faced by virtually every company (e.g. with profile SAP_ALL and SAP_NEW)
  • Eliminates emergency phone calls to approve access outside the business hours
  • Tracks and logs transaction code usage and changes made within the firefighting session
  • Allows to provide defined authorizations and validity dates
  • Sends email notification of emergency access logon immediately to defined controllers
  • Generates auditable reporting logs

 

 

Appropriate Usage

 

Appropriate usage of emergency management includes:

  • Emergency changes required in productive environment
  • Sensitive transactions not available via end user security roles
  • SOX sensitive and restricted transactions
  • Infrequent and sensitive tasks (e.g. opening and closing of posting periods)
  • Cutover activites

 

 

Inappropriate Usage

 

Inappropriate usage of emergency management includes:

  • Daily business tasks by support users (e.g. creating purchase orders, etc.)
  • Non-sensitive tasks available via security roles (e.g. display access)
  • Displaying sensitive reports
  • Using EAM as a crutch to support a bad security design

 

 

Dangers of Inappropriate Usage

 

Excessive usage represents one of the largest EAM issues.

  • Frequently, EAM is used as a crutch for a poor security role concept. End users tend to rely on their Firefighter ID instead of using their regular access given to their personal user ID. Simple table display (e.g. SE16) or daily activities for supporting business tasks are both examples of inappropriate usage seen in several companies.
  • The high volume of use generates longer logs, requiring more system resources, and more time to review.
  • As a result logs are not reviewed in detail and EAM cannot be relied on as a security control.

 

It is important that the concept of firefighting is defined properly as excessive usage might cause real danger to your organization as fraudulent actions might remain undetected due to the high volume of logs. Inappropriate usage could be eliminated with a proper provisioning strategy (see also EAM - Provisioning Strategies), the proper type of firefighting (see also ID-Based Firefighting vs. Role-Based Firefighting), as well as a proper authorization concept defined by your basis/security team.

 

Furthermore it is required to correctly assess the role design of the FF roles as role design has an impact on the size of the logs. Firefighter Logs (see also Emergency Access Management Reporting) do not differentiate between display and change and hence EAM collects all information that is logged. This means the file can become overwhelming for the Controller to review.

 

Instead of using Firefighter, if you are on 7.40 release, you could configure RAL (Read Access Logging (RAL)) that allows you to monitor and log read access to sensitive data.

 

Hope this document helps for the general understanding of how EAM should and shouldn't be used. Your feedback is always highly appreciated to improve the quality.

 

Best regards,

Ale& Col

Top 10 most viewed SAP KBAs for GRC Access Control in September 2014

$
0
0

Purpose

The purpose of this document is to provide a list of the top 10 most viewed SAP KBAs for GRC Access Controls in the month of September 2014.

 

Overview

Below are the top 10 most viewed SAP KBA's for GRC Access Controls.

 

KBA NumberKBA Title
1638100

  Print version Communication Failure: RFC Destination SALV_WD_EXPORT_PDF

  does not exist

1900049

  ABAP Dump TSV_TNEW_OCCURS_NO_ROLL_MEMORY, how to verify if it’s a

  memory issue

1800347  Short Dump on FF Login
1701047  Is it mandatory to use trusted connection in the RFC destination for Firefighter Connector?
1735971  User exit to prevent direct firefighter login
1755767

  Repository object sync from LDAP fails

1674530  Supported Browser and Operating Systems for GRC 10
1955397  Background jobs fail with SYSTEM_NO_ROLL error message in ABAP dump

2033172

  How to resolve error "ORA-30036: unable to extend segment by 8 in undo tablespace

  "PSAPUNDO" during GRC 5.3 upgrade?

1843287

  Submitting a request there is an error while inserting request reason

 

Please note, in order to view the contents of the Knowledgebase Articles (KBA), you will need to be logged into Service Marketplace.

Top 10 most viewed SAP KBAs for GRC Process Control in September 2014

$
0
0

Purpose

The purpose of this document is to provide a list of the top 10 most viewed SAP KBAs for GRC Process Controls in the month of September 2014.

 

Overview

Below are the top 10 most viewed SAP KBA's for GRC Process Controls.

 

KBA NumberKBA Title
2062652  Extended Notifications for SAP Business Workflow
2063237  GRC Sync-up Programs
2054169  SAP Process Control 10.0 Multi-Compliance Framework Configuration
2054253

  How to proceed 10.1 plug-ins installation when GRCPCRTA 250_700 exists in

  plug-in system

2017507  How to Archive Data in Planner and Planner Monitor
2054120  Report Framework for PC/RM 10.0
1740509  No Authorization to execute job step AM_JOBP/XXXXXX (External ID)
2062650  How the aggregation method will work?
1689784  Ad-hoc issue results in assertion failed error
1700847  Required to re-activate the couple of BC-Set's at the for GRC PC/RM 10.0


Please note, in order to view the contents of the Knowledgebase Articles (KBA), you will need to be logged into Service Marketplace.

Viewing all 459 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>