Dangers of Inappropriate Usage
Document on SCN: http://scn.sap.com/docs/DOC-59695
Document on SCN: http://scn.sap.com/docs/DOC-59695
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 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.
|Transaction||Description||Key Area||Why is this useful?||Further details, links, etc.|
|NWBC||Launch Netweaver Business Client||All||launch NWBC HTML. You will need to have work centre roles assigned or build you own.|
|SPRO||Customizing||All||Self explanatory - configuration entry point for both GRC and plug-in systems|
|GRAC_UPLOAD_MIT_ASGN||Upload Mitigation Assignments||ARA||Upload 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_DWLOAD_MIT_ASGN||Download Mitigation Assignments||ARA||Download a huge number of mitigation (user, role, profile) in one shot.||Mass change of Mitigation Assignments|
|GRFNMW_CONFIGURE_WD||MSMP Workflow Configuration||WF||MSMP Workflow Configuration - standard view (web dynpro will launch)|
|GRFNMW_CONFIGURE||MSMP Workflow Config Expert||WF||SAP 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_WD||MSMP Instance Runtime Monitor||WF||Comprehensive 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.|
|SWDD||Workflow Builder||WF||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.|
|SWIA||WF||SAP 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_IMPRT||Mass Role Import from Backend System||BRM|
|GRAC_SPM_CLEANUP||Cleanup EAM Application Data||EAM||Program to clean up EAM tables.|
|GRAC_EAM/GRAC_SPM and /GRCPI/GRIA_EAM||EAM Logon Pad||EAM||For 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_RULES||Upload Access Control Rules||ARA||This 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_RULES||Copy Access Control Rules||ARA||Utility for copying SOD rules from one system to another of same type.|
|GRAC_RULE_DELETE||Delete Access Control Rules||ARA||This 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_RULES||Download Access Control Rules||ARA||This 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_RULES||Generate Access Control Rules||ARA||This 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_TRANSPORT||Transport Access Controls Rules||ARA||This is available via IMG navigation and allows to mass transport the rule set.|
|GRAC_EXPORT_RA||Export Risk Analysis Data (e.g. when the file is too big for the web)||ARA||Program to download the results of the risk analysis to a local file.|
|GRAC_BATCH_RA||Risk Analysis in Batch Mode||ARA||This 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_RULES||WF||Build MSMP rules (usually BRF+). Refer to comment below for creating application first.|
|GRAC_GEN_ERM_BRFRULE||WF/BRM||Build 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|
|BRFPLUS||BRFplus Workbench||WF||Alternative transactions: BRF+ and FDT_Workbench. You can maintain the BRF+ rules here and transport through to Production.|
|STZAD||Customizing Time Zones||BC||Discuss with Basis before making any changes to timezone as it can impact EAM log collections, etc.|
|SLG1||Display Application Logs||BC||Application log display. It is useful to track error messages. Most GRC authorisations errors will show in the application log|
|SE61||SAP Documentation (Email templates, etc.)||All||Document maintenance.|
|SE63||Translations||All||This transaction enables you to directly translate individual objects.|
|SCPR20||Activate BC Sets||Basis||Activation of BC Sets.||Activate BC Sets - Business Configuration Sets (BC-CUS) - SAP Library|
|PPOM||Maintain Organizational Plan||Basis||Maintain Organizational Plan|
|SOST/SOSB||SAPconncet Send Requests||Check if there has been an issue with sending on email notifications or reprocess requests. Transaction SOSB can be restricted to limited functionality.||Tcode SOST|
|SCOT||SAPconnect Administration||Basis||Configuration 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/ST05||System Trace||Trace 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.|
|SM12||Enqueue Locks||Basis||You 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.|
|STAD||Display Statistics for all systems||Basis||EAM FF logs import STAD information|
|SCC4||Client 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)|
|SNOTE||Note Assistant||BC||Import 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/SE09||Transport Organizer||BC||Manage your transports|
|SE16 / SE16N||Data Browser||Transaction to easily browse thru data tables.|
|SM01||Lock Transactions||SEC||Lock transaction to prevent users (even if authorised) from executing the transaction. Usually security is responsible for this activity.|
|SM36||Schedule Background Jobs||BC||GRC Access Controls uses a job scheduler via NWBC. SM36 jobs for connector sync,etc can be set up via SM36|
|SM37||Overview of Background Jobs||BC||Allow you to view background jobs. All jobs runtimes will show here, even if scheduled via NWBC.|
|SA38||ABAP Reporting||ABAP||Execute SAP ABAP programs.|
|SE38||ABAP Editor||ABAP||Program Editor|
|SE80||Object Navigation||ABAP||SAP Development workbench, most development functionality is available from this transaction.|
|SE37||ABAP Function||ABAP||MSMP 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.|
|SE24||ABAP Class||ABAP||useful if you need to check the code and add a breakpoint to a method|
|BD54||Logical Systems||Basis||RFC connections have to be defined as a logical system (usually same name) to then reference in the integration framework configuration|
|SM59||RFC Destinations||Basis||RFC Configuration|
|SM66/SM50||Workprocess||Basis||View the number of background work process available to define as part of the integration framework for background job processing|
|SUIM||SEC||User Information Reporting system|
|S_BCE_68001426||Transactions for User||SEC||Report 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_68001418||Roles by Role Name||SEC||Report to find roles by complex selection criterias. This report can be used to find roles by description, etc.|
|S_BCE_68001419||Roles by User Assignment||SEC||Report 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_68001420||Roles by Transaction Assignment||SEC||Reports shows a list of all roles that includes a specific transaction. This is very helpful to easily find possible roles to assign a transaction.|
|SICF||HTTP Services||BC||Discuss 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_SYNC||Object Rep Sync||All||User + Role + Profile Synchronization Job|
|GRAC_USER_SYNC||User Sync||All||User Synchronization Job|
|GRAC_ROLE_SYNC||Role Sync||All||Role Synchronization Job|
|GRAC_ROLE_USAGE_SYNC||Role Usage Sync||All||Role Usage Synchronization Job|
|GRAC_ACT_USAGE_SYNC||Action Usage Sync||EAM/ARA||Action Usage Synchronization Job|
|GRAC_PROFILE_SYNC||Profile Sync||All||Profile Synchronization Job|
|GRAC_AUTH_SYNC||Auth Sync||All||Authorization data Synchronization Job|
|GRAC_SPM_SYNC||EAM Sync||EAM||Emergency Access Management Master Data Synchronization Job|
|GRAC_SPM_WF_SYNC||EAM Workflow Synchronization||EAM||Emergency Access Managmement Workflow Synchronization Job|
|GRAC_SPM_LOG_SYNC||EAM Log Sync||EAM||Emergency Access Management Log Synchronization Job|
|GRFN_STR_DISPLAY / GRFN_STR_CHANGE||Org Structure Expert Change||All||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.
|PFCG||Role Maintenance||Basis||Role maintenance to create and edit roles.||5 Role Maintenance in PFCG - SAP NetWeaver Business Client - SAP Library|
|SU01||User Maintenance||Basis||User maintenance|
|SE16||Data Browser||Basis||Data browser to view/add table data|
|SM30/SM31/SM34||View Maintenance||Basis||SE16 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_ADMIN||MSMP Power User / Debug||WF|
|GRFNMW_CN_VERA||MSMP Process Active Version Maint.||WF|
|GRFNMW_DEBUG||MSMP Process Debug Settings||WF|
|GRFNMW_DEBUG_MSG||MSMP Process Debug Messages Settings||WF|
|GRFNMW_DEV_CONFIG||MSMP Development Configuration||WF|
|GRFNMW_DEV_RULES||MSMP Rule Generation / Testing||WF|
|GRFNMW_GEN_VERSION||Generate Versions for MSMP Config||WF||Generate version is useful to run after you import a transport (post processing activity) instead of going into MSMP screen to activate.|
|GRFNMW_MONITOR||MSMP Workflow Monitoring||WF||Monitoring of the MSMP Workflow statistics.|
|GRAC_ENDUSRFORM_SICF||End user form SICF service|
|GRAC_FFOBJ_DSC_MAINT||Maintain EAM FF Object Description|
|GRAC_FFOBJ_DSC_MNT1||Firefighter Object Maintenance|
|GRAC_IDM_SCHEMA_SYNC||IDM Schema Update|
|GRAC_DATA_MIGRATION||AC10 Data Migration||Program to migrate data from an earlier version.|
|GRAC_DELETE_REPORT_S||Delete Report Spool data|
|GRACRABATCH_MONITOR||Batch Risk Analysis Monitor||This program is used to monitor the execution status of a running batch risk analysis.|
|GRAC_ALERT_GENERATE||Alert Generation||Program that generates alerts.||SAP GRC AC 10.0 Alerting|
|GRAC_BATCH_RA||Risk Analysis In Batch Mode||Offline 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.||Online vs. Offline Risk Analysis|
|Program||Description||Why is this useful?||Further details, links, etc.|
|PRGN_COMPRESS_TIMES||Program 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|
|TZCUSTHELP||Troubleshooting Support for Time Zone Settings||Timezone changes best practices - Basis Corner - SCN Wiki|
|TZONECHECK||Check Time Zone Data for Consistency||Timezone changes best practices - Basis Corner - SCN Wiki|
|RSLDAPSYNC_USER||Synchronization of SAP User Administration with an LDAP-Compatible Directory Service||Synchronization of SAP User Administration with an LDAP-Compatib - Identity Management - SAP Library|
|GRFNMW_BATCH_EMAIL_REMINDER||Job User to send Email reminders to approvers based on number of days and frequency|
|GRFNMW_BATCH_STALE_REQUEST||This program was useful for deleting non-actionable old requests from the system as housekeeping activity|
|RSCONN01||This job used for sending email (and other types of communication items)|
|/GRCPI/GRIA_DNLDROLES||Download roles data for mass import|
|Table||Description||Why is this useful?||Further details, links, etc.|
|GRACREVREJUSER||UAR Rejected Users|
|GRACREJREASON||UAR Rejected Reasons|
|GRACREJREASONT||UAR Rejected Reasons Texts|
|USR02||User Logon Data|
|GRACOWNER||Master Table for Central Owner Administration|
I am really looking forward to your input to extend the listing.
SAP SCN document: http://scn.sap.com/docs/DOC-57466
See the original version of the document: http://scn.sap.com/docs/DOC-57447
This document describes the provisioning strategies of Emergency Access Management. Basically SAP GRC Access Control offers two different strategies how EAM can be utilized.
Some users are pre-approved for specific Firefighter IDs and have pre-assigned access in GRC. When a Firefighter ID is checked out, the application sends notification to the controller whenever the firefighter logs onto a system (Parameter 4008). Additionally the controller gets informed when the log report is available (Parameter 4007) and it is his responsibility to confirm that the actions taken were appropriate. The application sends the notification either as email or workflow item to the controller (Notification settings in the Firefighter ID Assignment).
On the contrary, a user must request access to EAM before the Firefighter ID can be used. Access can be requested in Access Request Management. Super User Access Request Type is available to automate provisioning access to Firefighter IDs via workflow in ARM.
Both strategies have as well advantages as also disadvantages. Having pre-approved firefighters have the advantage that the IDs are available at any time and emergency activities can be provided immediately (e.g. during weekends), whereas it might be critical that fraudulent activities can be executed and are reviewed afterwards. If a user must request access to EAM, emergency access is delayed due to the fact that the approval from the controller is required before usage. In case of an emergency e.g. during weekends the controller might not be available and the work can't be done.
I would like to know which strategy you prefer and do you have other concerns than mine?
Looking forward to your feedback and contribution.
Refer also to SAP SCN GRC Community: http://scn.sap.com/docs/DOC-57322
An der ersten Clubmeisterschaft des BC Schaan in diesem Jahrtausend konnten sich die etablierten Spieler durchsetzen. So gingen die erstmals vergebenen Bergkristalle an Alessandro Banzer (Clubmeister), Marco Cristoforetti (2. Rang) und Michael Biedermann (3. Rang), allesamt Spieler der diesjährigen Vizemeistermannschaft in der 1. Vorarlberger Landesliga.
Im Kampf um den Finaleinzug duellierten sich Biedermann und Cristoforetti auf hohem Niveau - mit besserem Ende für den letztgenannten (6:3). Im Finale konnte sich dann der formstarke Banzer mit einem 7:4 gegen Cristoforetti durchsetzen und sich so den ersten Clubmeistertitel in der neuzeitlichen Vereinsgeschichte des BC Schaan sichern. Der Vorstand bedankt sich bei allen Mitgliedern für die rege Teilnahme.
This document describes the difference between Online and Offline Risk Analysis in SAP GRC Access Control based on several SAP Notes.
In order to be able to run offline analysis at all, the configuration option "Enable Offline Risk Analysis" must be set to YES (Parameter 1027) in Access Control configuration settings in SPRO.
This configuration option is now selectable in the Risk Analysis > Additional Criteria.
Offline 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 program GRAC_BATCH_RA. This is the same batch risk analysis that is run to update the management reports and companies should be running this on a frequent basis to ensure their management reports are accurate. Running the Offline analysis is the same as drilling down via the Management View.
The benefits using offline analysis is mostly in response time. By using offline analysis, Risk Analysis and Remediation does not have to make as many calls into the connected systems so the analysis will return much faster than using online analysis. However, please keep in mind that offline analysis is not real-time and will not take into account any changes made since the last Batch Risk Analysis.
Also, it's important to understand that even when you run offline analysis it will have to make a call to the back-end system to obtain composite role names. Therefore, if the back-end system is down, offline analysis will not work.
Using offline analysis, you can obtain both summary and detail reports. The one exception is that if you run Report types Critical Action or Critical Permission, you will not be able to see the detail report, only the summary report. Please note that this is only for Critical Action and Critical Permission. Report types of Permission level and Action level can go down to the detail level in offline mode.
Please keep in mind that how you have the Batch Risk Analysis set up for defaults will impact the data you have to run offline analysis on. For example, in Configuration under Risk Analysis you have the option "Exclude Locked Users". If this is set to YES, when running the batch risk analysis, it will not evaluate locked users which means the tables holding the conflicts will not include any data for locked users.
When you run Risk Analysis, you have the option to change Ignored Users field to something other than what is set up in the Configuration. However, if you change this to NOT ignore locked users and run in offline mode, you will not receive any conflicts because no locked users were evaluated during the batch risk analysis. Running this report in online mode may turn up conflicts with locked users.
The following listing shows the impact on each workflow which uses date from the risk analysis.
Segregation of Duty (SoD) Review
The system uses Offline Risk Analysis data to update management graphics and to generate SoD Review workflow requests. When the system detects SoD violations, it automatically sends reports to managers so that they can take actions to either remove user access or to mitigate the SoD risks.
User Access Review
The system uses Offline Risk Analysis data to update and generate UAR Review workflow requests.
Access Request Submission
The application automatically performs an online risk analysis when the requestor submits the request. This behaviour can be configured in parameter 1071 (Enable risk analysis on form submission). Note: The risk analysis results are intended for the approver. Therefore, the risk analysis results appear on the approver’s screens but not on the requestor’s screens. SoD violations for access requestes are stored in table GRACSODREPDATA.
Role Approval Workflow
In Business Role Management (BRM), some customers may have a business requirement that once a role is sent for approval to Role Approval workflow, the role owner(s) must re-run the risk analysis and mitigate a risk before approval. The risk analysis has to be performed during Analyze Access Risk methodology step and is always performed as Online Risk Analysis.
The following listing shows the impact on Reports which uses data from the risk analysis.
Risk Analyisis in Access Management
The risk analysis results in Access Management, like User Level, Role Level, Profile Level or HR Objects, are based on real-time risk analysis. Also simulation uses real-time risk analysis data.
Risk Analysis in Reports and Analytics
The risk analysis in Reports and Analytics tab is always offline analysis and hence you should have run the Batch Risk Analysis to populate the violations data.
See the document also in SAP GRC Community: http://scn.sap.com/docs/DOC-56653
In this article I take a look at the importance of good internal controls and how automating those controls can streamline your business and help you catch the exceptions to the rule. Please also see my other document regarding Defining Mitigating Controls / Compensating Controls.
Almost every problem that a company confronts can be traced back to a lack of good internal controls. Good internal controls mean that you know what is going on in your business. The definitions of the key business processes are different from each company and therefore it is necessary to understand how these processes run. Strong internal controls can also help you monitor and reduce risks. Internal controls are really the essence of good governance, taking a policy and translation it into details of day-to-day business practice.
First of all it is important to understand internal controls in general. Internal controls may mean different things to different people. Let me give you an idea what internal controls mean to me and how such controls can be defined. Controls encompass all the actions, processes or physical barriers that direct or guide a resource to achieve a desired result. Often they prevent, detect or correct risks from becoming barriers to success. Here are some different types of controls:
The adoption of good internal controls in order to become SOX (or regulation) compliant is a top-down process that starts with management. Management recognizes that the regulations exist and cannot be ignored. They select a team to define how the regulations will be implemented as controls in the company. Control owners and business process owners work out how to incorporate these regulations into the business through automated controls.
After the controls were implemented they help close off avenues of risks. Companies may then enjoy such happy side-effects as preventing unintentional errors, improving efficiency and keeping auditors smiling.
As mentioned internal controls deliver a happy side-effect as they offer some benefits to companies. Each company has their own processes to handle different business scenarios. These processes contain risks which are barriers to success and avenues for fraud and negligence. Hence companies must have strong internal controls to avoid their occurrence. Nowadays, with the compliance requirements of regulations such as SOX (Sarbanes-Oxley Act), companies are trying to be more proactive about their controls. Being more proactive about controls requires effort and input, but also has many benefits.
From my point of view a company has four main benefits with the implementation of strong internal controls. Let me shortly give you an overview of these four:
Business process improvement - as a nice side effect of implementing strong internal controls is the improvement of business processes. While taking a close look at the business processes, companies often find potential to make them more efficient and streamlined. It gives companies a chance to examine their processes closely and to recap how other companies or how best practise works.
Management by exception - By establishing a norm companies learn to manage by exception. e.g. a dedicated process works this way and when it doesn’t, a control will alert us. Controls start to function as a barometer of how things are operating in the company and give an early warning of how things could go awry, or an indication of trends. Controls can also flag how companies need to change or improve their processes. If companies don't continue to assess their controls and respond to the changes that controls indicate are necessary, they could be considered negligent.
Real time monitoring - automated internal controls are like traffic cops. They prevent accidents (by directing the flow of traffic), detect accidents (by listening to the radio) and clean up after accidents (removing damaged cards and calling an ambulance to take the injured to hospital). Like traffic cops, automated internal controls can be on duty 24 hours a day, seven days a week, monitoring both past activity and activity taking place in real time.
Mindset changes - Implementing automated controls requires more than changes to software. Doing so also requires a mindset change. Management commits to a code of ethics and to a new control consciousness, but they also have to ensure that this filters down throughout the company.
I hope this article helps you to understand why strong internal controls are highly recommended and necessary for all companies. I am looking forward to your feedback and input.
Article in the SAP GRC Community on SCN: http://scn.sap.com/docs/DOC-56548
In regard to my document about Rule Set / Business Risks I would like to give some detailed information about rules and rule types. As we learned rules (or risk rules) are possible combinations of transactions and permissions for a business risk.
Rules must be generated when ever risk contents change. This can be done in SPRO (GRC > Access Control > Access Risk Analysis > SOD Rules > Generate SoD Rules). Generally rules are combinations of actions and aren't maintained manually (done automatically by the program).
The number of rules defined from a risk is determined by
The following graphic shows the rule structure in more detail:
Now let me give you a short overview of the different types of rules considered by GRC.
List of actions considered critical. Option to run at both Action and/or Permission level. Critical Actions are created same way as Segregation of Duty risks, exept Risk Type = Critical Action, and can contain only 1 function (as shown above with SCC4).
List of objects/permission considered critical. Created same way as Segregation of Duty Risks, exept Risk Type = Critical Permission, can contain only 1 function, and function cannot contain actions.
Roles and profiles considered critical. Critical roles and profiles will be excluded from analysis if the configuration parameter 1031 (Ignore Critical Roles & Profiles) is set to YES.
Used to eliminate false positive SOD reporting based on organizational level restrictions for users. Organziational rules should not be created for mass org level reporting as it should only be enabled for functions that you specifically need to segregate. Most companies are controlling what data a user has access to via role assignment. There are only very few companies who have a business need to create org rules.
Additional security parameters other than authorizations a user must have to enable access. First checks to see if the user exists in the supplementary table, then checks if conditions are met. Based on exclusion setting, it will include or exclude the user in the risk analysis.
Please share and contribute in this document to make it better. See also my document on SAP SCN GRC community: http://scn.sap.com/docs/DOC-54530
With respect to my document Rule set - Rules & Rule Types and as I've got some requests to discuss the org rules in more detail I would like to share some more information about organizational rules.
Organizational rules in GRC Access Control are used to eliminate false positive SOD reporting based on organizational level restrictions for users. Organizational rules should not be created for mass org level reporting as it should only be enabled for functions that you specifically need to segregate. Most companies control what data a user has access to via role assignment. There are only very few companies who have a business need to create org rules.
Basically organizational rules allow you to filter false positives from the risks analysis. What does that mean? If you have a role concept where you derive roles from master roles, for example the leading organizational level is the company code, the risk analysis might show a risk which is due to the limitation of the authorization based on the organizational level no risk. Let me give you an example:
Role A contains transaction FB60 (posting of vendor invoices) for company code 1000, whereas Role B contains transaction FK02 (changing vendor master data) for company code 2000.
The combination of FK02 and FB60 is a SOD risk, as posting of vendor invoices and changing of vendor master data shouldn’t be performed by the same person. A user who gets the two roles would have both transactions assigned hence the risk analysis shows a risk. Actually this isn’t a risk, but as the organizational values are not considered it shows as a risk. This behavior is false positive as the user cannot execute FB60 and FK02 for the same company code. To filter these false positives you can utilize organizational rules.
While running a regular risk analysis, the user would show up with a SOD conflict, as he has both conflicting transactions assigned. To find out if the risk exists for the same company code you can use the organizational rule. Therefore create an organizational rule hat filters the company code 1000 and apply this org rule to the risk analysis. After adding the org rule to the analysis the user won’t show up with the risk. Please be aware that after creating org rules the SOD rules must be regenerated (GRAC_GENERATE_RULES).
In most of the cases org rules are created for designated risks. Alternatively it is also possible to define org rules for all possible false positives by using wildcards (e.g. XGPR*).
Looking forward to your input.
See also on SAP SCN: http://scn.sap.com/docs/DOC-55986
To ensure seamless GRC processes it is highly recommended to guarantee that a single user is not allowed to initiated and approve his/her own requests. The principle which stipulates how many users must be involved in approving access requests must be defined by each company and can be slightly different from one to another. This may be a 2, 4 or even 6-Eyes-Principle as given from your management.
In this document I would like to share how we can technically guarantee that a user who initiates the request is not allowed to approve, so that at least the 4-eyes-principle is given.
Basically I recommend that the Requestor is not allowed to approve his own requests (neither for his own user nor for requests submitted by him) as Manager at the Manager Stage. As Role Owner he should be allowed to approve requests for his user account and also for requests submitted by him. In case you have different requirements this document gives you a basic idea how this can be handled.
Go to the IMG Configuration (SPRO) > GRC > Access Control > User Provisioning > Maintain End User Personalization.
I suggest having separate EUP configurations for each stage. Therefore create a new EUP for each stage (Manager, Role Owner and Security). Preferred way is to copy from an existing (e.g. DEFAULT) as most of the settings are available and can be modified easily.
The EUP has to be assigned in MSMP configuration for each stage. Below is an example for the Manager Stage with reference to the EUP configuration 920 (Manager View). All others are similar.
The EUP configuration can be defined in different ways:
Define the field as not editable and not visible as it isn’t required to be seen by the approver.
In the Access Request approval screen you will see the error message “You are not allowed to approve your own requests”.
As mentioned it is possible to define who can approve/reject own requests at each stage. In my example I have maintained only for Manager Stage as I assume a 4-eyes-principle is sufficient for most of the companies.
Let me know if you need further ideas and do not hesitate to contribute.
See also my document on the SAP SCN GRC Community: http://scn.sap.com/docs/DOC-55401
This document describes how to perform mass change of mitigation assignments. I would like to give you an overview how the down-/upload program for mitigations can be used and in which business scenarios it might be helpful.
Problems which can be handled:
The most complex scenario is to change a monitor of mitigating controls and this best practice process I would like to share in this document. All other scenarios are similar and can be handled analog to this.
Removing an existing monitor, who still monitors mitigations, must be changed before he can be removed from a control. The following error message will appear if you try to remove the monitor.
First we have to define the new monitor by adding a new row and define with assignment type = Monitor. Please be aware that the new monitor must be assigned to the organization unit and must be an owner (pre-requirements).
The following picture shows that BANZER_A is still monitoring an active mitigation for the user T-BANZER as we could see above. It is also possible that the user monitors more than one mitigation.
Updating all mitigations in NWBC would take some time and therefore you can use the following programs.
GRAC_DOWNLOAD_MIT_ASSIGNMENTS To download all mitigations to a local file
GRAC_UPLOAD_MIT_ASSIGNMENTS To upload all mitigations from a local file
Start the program via transaction SA38.
Beside user mitigations it is also possible to download profile, roles and role/user organizational mitigations. In this example we are going to change user mitigations and therefore we choose USER.
Personally I always download all mitigations as XLS file as it is easy to change the content with Excel (filter, search, etc.).
After downloading the file you will see all mitigations in the Excel. In my example I have only one mitigation for the user T-BANZER.
The structure of the file, as the titles are missing, is given below.
It is possible to update each column (system, validity, etc.) and also to add an additional lines for new user mitigations. Please be aware that the values are checked while uploading and wrong data will abort the upload.
As we can see in the following picture I have updated the monitor in column H to LIJA (user name of the new monitor).
After I am done with editing the file I save and upload via the upload program. Therefore I use again SA38.
Here it is also possible to upload user, role, profiles and organizational mitigations. Uploading mitigations can be done in two different modes. Append means the uploaded mitigations will be added to the existing, whereas overwrite will overwrite all existing mitigations. Please be aware if you have for example 1000 mitigations and you upload a single record and choose overwrite, all others will be deleted and the single mitigation is the only one existing in the system.
To avoid such scenarios I always download all mitigations to a file, copy the file, modify the copied and upload the modified file. In case if something goes wrong I can upload the old file.
If the file is uploaded successfully you will see the following message. Errors will also be reported.
In NWBC we had the following mitigation before uploading.
After uploading we can see the new monitor.
Now the old monitor can be removed and the mitigating control is successfully updated.
As mentioned above it is also possible to change other values in the local file such as validity date, systems, etc. which offers great functionalities to easily change a huge number of mitigations.
Let me know if you have other inputs to extend this document. Please also see my document on SAP SCN: http://scn.sap.com/docs/DOC-55082
SAP GRC Access Control delivers a comprehensive, cross-enterprise set of Access Control that enables all corporate compliance stakeholders, including business managers, auditors, and IT security managers, to collaboratively define and oversee proper SoD enforcement, standardized role management, compliant provisioning and superuser privilege management.
SAP GRC Access Control in its latest version includes four modules which offer the above mentioned functionalities. The modules are Access Risk Analysis (ARA), Access Request Management (ARM), Emergency Access Management (EAM) and Business Role Management (BRM). When deployed together, they provide an end-to-end access control solution that addresses the following areas:
- Access Risk detection: the ARA applications detect even the most obscure access and authorization risks across SAP and non-SAP applications, providing protection against every potential source of risk, including segregation of duties and transaction monitoring.
- Risk remediation and mitigation: these applications for access and authorization control enable fast and efficient remediation and mitigation of access and authorization risks by automating workflows and enabling collaboration among business and technical users.
- Reporting: the applications deliver the comprehensive reports and role-based dashboards businesses need to monitor the performance of compliance initiatives and to take action as needed.
- Risk prevention: once access and authorization risks have been remediated, SAP GRC Access Control can prevent new risks from entering a production system. By empowering business users to check for risks in real time and automating user administration, the applications make risk prevention a continuous and proactive process.
Also see in the following overview graphic how each module ensures that an enterprise stays clean after getting clean.
Das diesjährige Osterturnier - und die Trophäe in Form eines 2,5kg-Schokohasen - wurden eine Beute von Alessandro Banzer. Nachdem er sich in der Gruppe souverän durchsetzte, konnte er im Halbfinal Michael Biedermann und im Final Sascha Ludwig, der sich in der anderen Hälfete mit einem 6:5 gegen Marco Cristoforetti fürs Finale qualifizieren konnte, in eindrücklicher Manier bezwingen.
Das Trostturnier konnte Martin Heeb für sich entscheiden und damit seine ebenfalls starke Form unter Beweis stellen. Überaus erfreulich ist die Leistung unseres jüngsten Mitgliedes Sandra Winkler, die 2 Siege feiern über arrivierte Spieler feiern und sich den 3. Platz im Trosttableau sichern konnte.
Der BC Schaan bedankt sich für die rege Teilnahme (22 Anmeldungen) und gratuliert den Genannten recht herzlich!!!
To get a better understanding how a business risk occur, we have to understand the process how GRC identifies a risk and its key terms which are used. One or more business risks can be covered in a rule set which is also shown below. Let’s start with the key terms which are used by specialist to talk about GRC.
Business Process – used to classify risk, rules and rule sets by business functions. E.g. Order to Cash, Purchase to Pay, etc. are all types of Business Processes. All risks and functions are assigned to business processes.
Business Risk – identify potential problems your enterprise may encounter, which could cause error or irregularities within the system.
Business Function – identifies the tasks an employee performs to accomplish a specific portion of their job responsibilities. This can be analogous to a role, but more often a role comprises multiple functions.
Actions – known as transactions in SAP. To perform a function, more than one transaction may be required to be performed.
Permissions – authorization object in SAP, which form as part of transactions.
Risk Rule - possible combinations of transactions and permissions for a business risk.
Rule set – categorize and aggregate the rules generated from a risk. When you define a risk, you attribute one or more rule sets to that risk. Similar to business processes.
Belows graphic shows the architecture of a Business Risk. Basically two business functions, for example accounts payable payments and vendor master maintenance, are defined as a business risk. The business risk is called “SOD required between accounts payable payments and vendor master maintenance” and says that this two functions should be segregated properly. The business risk, technically named XGPR0005 in my example, is assigned to a rule set. While analyzing the user, GRC compares the rule set with the actual authorization in SAP. Technically GRC compares the given authorization by the rule set and the actual authorization in SAP on permission level and reports if there is a match which should be segregated.
To make it more clear another graphic specifically designed for the above mentioned SOD conflict „SOD required between accounts payable payments and vendor master data maintenance“.
As seen above business risks are a combination of two business functions which shouldn't be performed by one single person. One or more business risks can be categorized in a rule set which is required to run the risk analysis. Another example, based on the architecture shown above, shows a typicall example of a rule set.
This example also shows that a business function (here Business Function 2) can conflict with one or more other business functions. Let's say Business Function 2 is "Accounts payable payments" which is conflicting with "Vendor masterdata maintenance" (shown as Business Function 1) and as well with "Bank Reconciliation" (shown as Business Function 3). Hence it might be possible to have a business function assigned in two or more business risks.
I hope this document helps to understand the concept of a rule set and how a rule set works from its architectural point of view.
This article is also online on the SAP SCN GRC community: http://scn.sap.com/docs/DOC-54434
Please do not hesitate to collaborate and share your knowledge.
(Page 1 of 19, totaling 277 entries)