Hello!

This blog pertains to Security Weaver’s utility Process Auditor.  I recently had the opportunity to work with Security Weaver’s Process Auditor (or PA). In summary, PA is a utility that will provide continuous compliance monitoring in SAP.

This previous post gives a general overview of the utility...

  http://scn.sap.com/community/grc/blog/2013/10/09/process-audit-don-t-worry--sw-pa-can-help

PA has several out-of-the-box controls to use, however our requirement was to develop custom controls.  I was not able to find detailed documentation on how to configure and develop within the tool or about how the areas are connected within the tool and in the canned programs. The PA user guide (ProcessAuditor-UserGuideforv2 5PS3.pdf) contains user information and general information on how to create a new control and rule id.  Start with that document first.  In this blog, I will discuss other technical details that are vague or not detailed at all in the user guide as well as my observations to help your developer/configurator with an installation.

Sections covered in this blog include:

1) Our Requirements
2) The Process Auditor utility

a. Create a new Control and Rule Parameters
b. The Development Workbench:

- Output format (the format of the alert record)
- Fetch Data Code (when to generate the alert)
- Hotspot code (for hyperlink in the Inbox)

c. Online Execution
d. Execution in Background
e. How to view the Alerts
f. User Exits to Know About
g. How to Debug the Alert Generation
h. How to Import to a Target Systems
i. Observations
j. Additional Controls

Our Requirements

Our requirements were to create three custom controls in ECC for transaction codes FB01, FB05, and FB50 based on on a specific document type. I’ll only show FB01 in this blog.

Basically, I needed to...

1. Create a rule ID for each control
2. Create control IDs
3. Create hotspots
4. Create a background Jobs to trigger alerts in Process Auditor tool.

Process Auditor utility

Tcode /n/PSYNG/PA

a) Create a new Control

As explained in the user guide, here is the control I created:

Header…

Rule Parameters…

Rule parameters are passed to the program when the control is executed directly in the utility.  They are NOT passed to the batch job.  The batch job variant and special logic in Fetch Code are needed to pass these values to batch processing. I’ll explain more about that in the Fetch Data Code section.

b) The Development Workbench

Alert Output Format

In this section, enter the format of the output record that will appear in the Alert.  I used the same name for the Rule ID as I did for the Control ID for clarity.

For the accounting debit and credit amounts above, I used a custom structure…

Fetch Data Code

Any time you enter the Fetch Code tab, you need to enter the Rule ID. Then, while keeping the cursor on the Rule ID field, select ENTER. This will allow the existing code to be displayed....

If you move the cursor‘s focus to either the Selection Screen or Fetch Data Code sections, then select ENTER, the utility gets „confused“ and it will appear as if no code exists like this...

Don’t worry! Any existing code is still there. To fix this situation, just select a different tab. Select to confirm that the changes are NOT to be saved.
Then, return to the Fetch Data Code tab and keep the cursor on the Rule ID field when you select ENTER.

The Selection Screen and Fetch Data Codes sections are Includes. They are inserted into the canned program created by the PA utility.

Here is the code I used in my Selection Screen section....

{code}

tables: bkpf, bseg, /PSYNG/SACONRULE, /PSYNG/SARULEHDR.

SELECTION-SCREEN : BEGIN OF BLOCK BLK1.

* Refer to include /PSYNG/SA_001F01 form submit_programs for fields
* passed in SELTAB:

** Used to create case. Not used in Fetch Code directly. Declared in
** main program
*SELECT-OPTIONS  : cntrlid for /PSYNG/SACONRULE-CONTROLID,
*                  p_ruleid for /PSYNG/SARULEHDR-RULEID.

** Used to read data:
SELECT-OPTIONS  : BELNR  for bkpf-belnr,
                  BLART  for bkpf-blart,
                  wrbtr for BSEG-WRBTR,
                  tcode  for bkpf-tcode,

* read data fields for testing...
                  BUDAT FOR SY-DATUM.

* When executed in batch, the rule parameters are not passed, so the
* batch job does not receive stardard parms ZCNTRLID or ZP_RULEID.
* Pass them in variant, so the case id will be created by the batch job.
SELECT-OPTIONS  : zcntrlid for /PSYNG/SACONRULE-CONTROLID.
parameters      : zp_rule like /PSYNG/SARULEHDR-RULEID,

* "=X if processing batch job. Set in variant only
                  p_Batch(1).

SELECTION-SCREEN : END OF BLOCK BLK1.

{code}

Here is the code in my Fetch Data Code.....

{code}

************************************************
* Flow:
* 1) Read data for selection parameters
* 2) Populate output fields that appear in inbox
* 3) Fill rule and control ids, needed for batch processing
* 4) output for batch job spool
*
* Batch Job:
* When scheduling batch job, the data for this is extracted for
* yesterday.  Schedule batch job at 00:01 (midnight) to read all of
* yesterday's data.
************************************************

TYPES : BEGIN OF TY_BKPF,
        BUKRS TYPE BKPF-BUKRS, "company code
        BELNR TYPE BKPF-BELNR, "document no
        GJAHR TYPE BKPF-GJAHR, "year
        BLART TYPE BKPF-BLART, "document type
        BUDAT TYPE BKPF-BUDAT, "Posting date
        tcode type bkpf-tcode, "doc created in tcode
      END OF TY_BKPF.

TYPES : BEGIN OF TY_BSEG,
        BUKRS TYPE BKPF-BUKRS, "company code
        BELNR TYPE BKPF-BELNR, "document no
        GJAHR TYPE BKPF-GJAHR, "year
        BUZEI TYPE BSEG-BUZEI,
        BSCHL TYPE BSEG-BSCHL,
        KOART TYPE BSEG-KOART,
        SHKZG TYPE BSEG-SHKZG,
        GSBER TYPE BSEG-GSBER,
        MWSKZ TYPE BSEG-MWSKZ,
        WRBTR type ZPA_WRBTR, "amount in transaction
      END OF TY_BSEG.

DATA : LT_BKPF TYPE STANDARD TABLE OF TY_BKPF WITH HEADER LINE
                                              INITIAL SIZE 0.

DATA : LT_BSEG TYPE STANDARD TABLE OF TY_BSEG WITH HEADER LINE
                                              INITIAL SIZE 0.

data: gs_output like line of GT_output.

DATA : TABIX TYPE SY-TABIX VALUE 1,
      gs_tabix type sy-tabix.

data:  ls_yesterday like sy-datum.
DATA : v_bukrs LIKE bkpf-bukrs,
      v_belnr LIKE bkpf-belnr,
      v_gjahr LIKE bkpf-gjahr.

DATA : bkpf_curs  TYPE cursor,
      l_pack_size TYPE I VALUE 999999. "limit # of alerts

*--------------------------------------------------

FREE : LT_BKPF,LT_BSEG,GT_OUTPUT.
REFRESH: LT_BKPF,LT_BSEG,GT_OUTPUT.

*-------------------------------------------------------------
* Set date range to read. If not set, process as in production and
* default to only yesterday's records. If set, we are in testing mode.
    if BUDAT[] is initial.
*    for production processing, use yesterday's date only...
      ls_yesterday = sy-datum - 1.
      BUDAT-sign = 'I'.
      BUDAT-option = 'EQ'.
      BUDAT-low = ls_yesterday.
      append BUDAT.
    else.
*    use date requested in parm
    endif.

*-------------------------------------------------------------
* 1) Read data for selection parameters
  OPEN CURSOR WITH HOLD bkpf_curs
      FOR SELECT bukrs belnr gjahr blart budat tcode
                  FROM bkpf
                  WHERE belnr in belnr
                    and tcode in tcode
                    and blart in blart
                    and BUDAT IN BUDAT.
  DO.
    FETCH NEXT CURSOR bkpf_curs  INTO TABLE lt_bkpf
                                  PACKAGE SIZE l_pack_size.
    IF SY-SUBRC <> 0.
      EXIT.
    ENDIF.

    SORT lt_bkpf BY bukrs belnr gjahr.
    SELECT bukrs belnr gjahr buzei bschl koart shkzg gsber MWSKZ WRBTR
      FROM bseg INTO TABLE lt_bseg
      FOR ALL ENTRIES IN lt_bkpf
        WHERE bukrs = lt_bkpf-bukrs
          AND belnr = lt_bkpf-belnr
          AND gjahr = lt_bkpf-gjahr.

    SORT lt_bseg by bukrs belnr gjahr.

    LOOP AT lt_bkpf.
      v_bukrs = lt_bkpf-BUKRS.
      v_belnr = lt_bkpf-BELNR.
      v_gjahr = lt_bkpf-GJAHR.

      LOOP AT lt_bseg FROM TABIX.
        IF LT_BSEG-BUKRS <> v_bukrs OR
          LT_BSEG-GJAHR <> v_gjahr OR
          LT_BSEG-BELNR <> v_belnr.

          TABIX = SY-TABIX.
          EXIT.
      ELSE.

*--------------------------------------------------
* 2) Populate output fields that appear in inbox
        GT_output-bukrs = LT_BSEG-bukrs.
        GT_output-belnr = LT_BSEG-belnr.
        GT_output-blart = lt_bkpf-blart.
        GT_output-GJAHR = lt_bkpf-GJAHR.
        GT_output-budat  = lt_bkpf-budat.
        GT_output-tcode = lt_bkpf-tcode.

        case LT_BSEG-SHKZG.
          when 'H'."credit
            GT_output-WRBTR = LT_BSEG-WRBTR.
          when 'S'. "debit
              GT_output-DMBTR = LT_BSEG-WRBTR.
        ENDcase.

        GT_output-ruleid = cntrlid.
        GT_output-CONTROLID = p_ruleid.

        COLLECT GT_output.
        CLEAR : GT_output.
      ENDIF.
      CLEAR : lt_bseg.
    ENDLOOP.

    CLEAR lt_bkpf.
  ENDLOOP.
  REFRESH lt_bkpf.

ENDDO.

*-----------------------------------------------------
* 3) Filter cumulative amounts for DEBIT based on parm value
loop at GT_OUTPUT into gs_output.
  gs_tabix = sy-tabix.
  if Gs_output-DMBTR in wrbtr. "min amt set in parms
    "...keep in list
  else. "not in alert range so filter from list...
    delete gt_output index gs_tabix.
  endif.
endloop.

SORT GT_OUTPUT BY bukrs blart belnr.

*-----------------------------------------------------
* 4) Fill rule and control ids, needed for batch processing
if cntrlid is initial.
  move-corresponding zcntrlid to cntrlid.
  append cntrlid.
endif.

if p_ruleid is initial.
    move zp_rule to p_ruleid.
endif.

*-----------------------------------------------------
* 4) output for batch job spool
if p_batch is not initial. "processing batch job?
    write: / 'For date:', BUDAT-option, space, BUDAT-sign,
              space, BUDAT-low.
    write: / 'Parameters:',
          / 'BELNR=', belnr,
          / 'BLART=', blart,
          / 'TCODE=', tcode,
          / 'cntrlid=', cntrlid,
          / 'p_ruleid=', p_ruleid,
          / 'Amount (Credit)',
          / 'Amount (Debit)'.

    skip 2.
    write: / 'Data Read:'.
    loop at gt_output.
        write: / GT_output-bukrs,
                GT_output-belnr,
                GT_output-blart,
                GT_output-GJAHR,
                GT_output-budat,
                GT_output-tcode,
                GT_output-WRBTR,
                GT_output-DMBTR.
        skip.
    endloop.
endif.

FREE : lt_bkpf, lt_bseg.

{code}

Hotspot Code

This logic is called when the Alert is selected in the Inbox (note that this does NOT apply to the Alert Report). 

This logic will call FB03 (display mode) for the accounting document hyperlink selected in the Inbox.

{code}

DATA :  lt_bkpf TYPE STANDARD TABLE OF bkpf WITH HEADER LINE.

CHECK i_column_id-fieldname = 'BELNR'.

clear gt_output.
READ TABLE GT_OUTPUT INDEX is_row_no-row_id.

SELECT SINGLE * FROM BKPF INTO LT_BKPF WHERE bukrs = gt_output-bukrs
                                          AND  belnr = gt_output-belnr.
  CHECK sy-subrc = 0.
  SET PARAMETER ID 'BUK' FIELD GT_OUTPUT-BUKRS.
  SET PARAMETER ID 'BLN' FIELD GT_OUTPUT-BELNR.
  SET PARAMETER ID 'GJR' FIELD GT_output-gjahr.

AUTHORITY-CHECK OBJECT 'S_TCODE' ID 'TCD' FIELD 'FB03'.
if sy-subrc = 0.
  CALL TRANSACTION 'FB03' AND SKIP FIRST SCREEN .
else.
  MESSAGE e077(s#) WITH 'FB03'.
endif.

{code}

When you are done with the code sections, select SAVE and GENERATE. You will be prompted to enter the program name to save it under.  This program name is the one you will want to use later if you schedule a batch job for execution.

c) Execution Online

Online execution is perfect for testing.  The parameters used in the execution online will be the ones stored on the Rule Parameter screen.

In this example, only data for transaction FB01 for document type ZG created on 12/15/2015 with debit amounts greater than $200,000 will be processed in the alert…

To trigger the execution, select tab Controls -> Header. Enter the Control ID to execute and ENTER (with the cursor’s focus on the Control ID field)…

Select Execute Control button....

A new Case ID will be created in the Inbox (of the user assigned) and in the Alert Monitor...

...The format of these roles is from the Development Workbench -> Format tab.

...The Hotspot Code (hyperlink) is executed by selecting the Accounting Document Number. It will flow to FB03 in this case.

d) Execution in Background

To create the batch job, you can create it directly in tcode SM36 or you can create a "template“  batch job using the wizard in the utility.  I use the word "template“ because the wizard does not create the batch job correctly. I needed to modify the resulting job for it to exist correctly.

I created one batch job for each custom control for clarity.

Create a Variant

The Rule Parameters are not used by the batch job, so you’ll need to create the variant to initialize those fields.

• I’m using BUDAT in the Fetch Code Data to read a specific date’s data for testing. BUDAT is not set in the variant since our requirement was to create alerts for all documents that meet the criteria. The Fetch Code Data is written for this requirement.
• P_BATCH is used to print the values to the spool file. (Refer to the Fetch Data Code section)
• The other values are similar to the Rule Parameters.

Go to tab Monitoring -> Process Controls.

To fix the incorrectly created batch job, in SM37, edit the batch job step to correct the Z program name and the variant.  Also, confirm and update the Frequency.  My Fetch Logic Code will read the data from the prior date, so it is set to run daily just after midnight to pick up all of prior day’s records.

e. How to view the Alerts

Inbox

Alerts will be set to the Inbox of the user assigned to the case id.

Alert Report

They will also be sent to the Alert Report...

f. User Exits to Know About

Program /PSYNG/SA_009  - User Exit 100
This exit allows setting flag SCHEDULE to X if controls are to be re-processed so they will appear again in the Inbox. 
If controls are not to be reprocessed, remove this flag.

Activate the Exit in tab Misc….

My Exit code looks like this when generated…

{code}

  *----------------------------------------------------------------------*
* Report  /PSYNG/SA_009                                                *
* AUTHOR: Security Weaver, LLC                                        *
*----------------------------------------------------------------------*
* COPYRIGHTS Security Weaver, LLC
*
* WARNING:
* THIS COMPUTER PROGRAM IS PROTECTED BY COPYRIGHT LAW AND INTERNATIONAL
* TREATIES. UNAUTHORIZED REPRODUCTION OR DISTRIBUTION IS STRICTLY
* PROHIBITED AND MAY RESULT IN SEVERE CIVIL AND CRIMINAL PENALTIES AND
* WILL BE PROSECUTED TO THE MAXIMUM EXTENT POSSIBLE UNDER THE LAW.
*&---------------------------------------------------------------------*

REPORT /psyng/sa_009 MESSAGE-ID /psyng/sa.
DATA: schedule.

*&---------------------------------------------------------------------*
*& Form start_user_exit
*&---------------------------------------------------------------------*
FORM execute_user_exit using schedule.
schedule = 'X'.
endform.

{code}

The exit code for the Schedule Flag is read here...

Program /PSYNG/SA_001F01 – User Exit 001

I found this exit in my analysis. It is not currently in use in my implementation.

{code}

...
WHEN 'RPT_SYS'.
      SUBMIT /psyng/sa_rpt07 VIA SELECTION-SCREEN AND RETURN.

*    WHEN 'PROC03'.                    "SOD Control Report
*      submit /PSYNG/SA_SOD_BY_HISTORY via selection-screen and return.
*      submit /PSYNG/SODREPORT_BY_HISTORY
*                via selection-screen and return.
      SELECT SINGLE * FROM /psyng/sa_usrext INTO /psyng/sa_usrext
            WHERE  exitnumber = 1.
      IF sy-subrc = 0.
        l_prog_name = /psyng/sa_usrext-exitname.
        PERFORM execute_user_exit IN PROGRAM (l_prog_name).
      ENDIF.
…

{code}

Due to the length of this post, this discussion is continued under...

Security Weaver’s Process Auditor - Developer's Observations (Part 2)

This post is a continuation of Security Weaver’s Process Auditor - Developer's Observations (Part 1)

g. How to Debug the Alert Generation

This section will show where areas of the generated program to focus on in case you need to debug the logic that reads the rules and contols.

As usual, enter /H in tcode to start the debug mode  and ENTER.

... Enter form FCODE_EXECUTE_CONTROL in include /PSYNG/SA_001F01...

Logic that reads the rules and controls
Include /PSYNG/SA_001F01’s form FCODE_EXECUTE_CONTROL contains that the logic that reads the rules and controls...

Logic that calls the Fetch Data Code

Continue to single step to here...

Fetch Code program is called here...

Here are where the parameters are read for the control.....

h. How to Import to a Target Systems

To assign objects to a transport to import Development to a target system, follow the processing steps.

1. Create transport request (manually or in SolMan ChaRM). Manually add the Control program and import into the target system.

2. Now download the Control Matrix files. Please follow the below steps to achieve the same.

a) Go to the source system.

b) Run the transaction /N/PSYNG/PA.  Go to Misc.Tab

c) Click on Upload Download (Backup)

e. Check the Download Radio button.

f. Check all check boxes and specify the file path.

Select EXECUTE to download the files checked.

3. In the Target system,  upload the files. Please follow the below steps:

a) Run the transaction /N/PSYNG/PA.  Go to Misc. Tab

b) Click on Upload Download (Backup)

c) Check the Upload Radio button.

d) Check all check box and specify the file paths that you downloaded to in the source system.

Select EXECUTE.

For some reason, in my Rule Details file, two empty records were created (for reason unknown).This caused an error on the upload.  I edited the file in Notepad to delete the empty records after the download and uploaded the modified file.

To confirm the target system is as expected, check the following areas:
• The tabs
• The user exit(s) (For me, in the target system, I needed to access the screen on the tab Misc, then the entry appeared in the table.)

i. Observations

• When code changes are made, programs and the CODE file need to be downloaded/uploaded.

• By standard, files downloaded/uploaded contain data/values for ALL controls and programs, not just the ones you modified.

j. Additional Controls

For our requirements, the code to process tcodes FB05 and FB50 are had the same ABAP, so I copy/pasted to the new controls. The only differences were the tcodes noted in the control rules and in the variants.

Thank you for reading!  I hope this post will help your developer in your implementation!   If you have any questions or if I missed some details, please let me know and I will update this post.  

Cheers! 

Risk terminator is a ‘hidden’ feature of SAP GRC Access Control that can be used to analyze roles and users assignments on access risks in the backend system. Depending on the GRC configuration risk terminator can work both detective (report on access violations) or preventive (the system will prevent violations from being introduced in roles).

Whenever a change is made to an existing SAP role or a new role is created the content of the role is first checked by the access rules established in the GRC rule set (that resides in the GRC environment). By using risk terminator the role administrator can immediately remediate access violations in development and play an important role in making sure that the system will stay clean (by avoiding violations being introduced in production).

Risk terminator can also be used when assigning roles to users as well, which can be a powerful feature in production.

Now let’s take a closer look at risk terminator

Example A:

The role ztestriskterminator is created in PFCG (profile generator) by the role administrator.

The role administrator adds the Purchase order maintenance transaction codes ME21N and ME22N and ME29N PO approval transaction code to the role.

The authorization objects ‘Document type in purchase order’ and the release code and group in the role, that are required to create/change a purchase order and release a purchase order, are not restricted.

When generating the profile of the role the GRC rule set is called and the role is analyzed for possible access violations.

One access risk is detected as is shown above. The assignment of the conflicting activities maintain the purchase order and release purchase order is called a SoD-conflict (segregation of duty conflict). With the detailed information the role administrator can take proper action and remediate the violation if he or she think it is necessary.

Other views such as management view are available as well just as in standard GRC.

Depending on the risk terminator’s configuration the role administrator can chose to discard the changes, continue with the simulation or generate the profile of the role with the violations

Example B:

Risk terminator can also be used when assigning roles to users. In the example below the ztestriskterminator role will be assigned to user ZTEST.

As a result ZTEST user will be assigned the conflicting activities maintain PO and release PO which is a SoD-conflict.

The user administrator can chose to abort the role assignment or continue.

Example C:

Most organizations use the function - task role concept. This means that a (business) function is build out of one or more tasks. In SAP this is called the composite - single role approach. Risk terminator adds value here as well.

The role administrator sets up a composite role named Master Data Officer and adds two task roles. The first task role grants access to vendor master data maintenance and the other one to confirming sensitive vendor changes (such as bank details/alternative payee)

The ability to change the vendor master record (FK02) and confirm sensitive vendor master record changes (FK08) should be seperated. This SoD-conflict is detected by the risk terminator tool.

The role administrator chooses to assign the vendor confirmation role to another function in finance instead of assigning this role to the master data officer.

Especially in the development area risk terminator proves to be a valuable asset to the role administrator in preventing SoD-conflict and sensitive access violations from being introduced in roles.

I have sat on both sides of the table: I have been  the consultant working with clients to implement SAP GRC Access Control components, and I have been a customer member of the project teams. In today's tight budgetary climate, exploitation projects are sometimes the best way to get project funding: configuring and implementing some additional component of a solution already bought, installed, and licenses paid. Thus, on the one hand, such exploitation projects can be huge wins: the customer gets more value from a solution already live, for better ROI. So what's not to like?

Here is the part that can be overlooked in those rosy, halcyon early days post go-live of the additional component.  Chances are good that your project scope went to go-live, with the consultancy providing some limited  time of "hypercare." Hurrah, it works! They are using it! The process works as designed and documented. The project sponsors are happy. Bye bye, good luck, it's been great, let us know when you are ready for the next step in the roadmap. And on down the road they go to their next engagement.

Now you have to support this thing, possibly with just a few tweaks to your previous support processes, but other times the new solution requires processes that are brand new, with new risks and opportunities.

That's no biggie, there are bound to be lots of blogs, wikis, and presentations online covering leading practices for production support for all of the Access Control components.  Mmm, noooo, not really. SCN has a treasure trove of resources for going from installation to the go-live, like those listed in this compendium,

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

and discussions with tips for dealing with all kinds of issues and  the "undocumented features" of some support packs, but production support?   Welcome to "ownership:" you are on your own.

To be honest, it is not so surprising; the majority of the people who post on SCN do not work in production support, maybe never have, or are only called in when something is broken. Yes, there are some SAP customers who post here, but we seem to be rather in the minority. And who among the customers is going to boldly proclaim that they can advise on leading practices? Perhaps some of us just need a bit of encouragement.

Presentations at TechEd? If only; something process oriented would be considered "not technical enough." The SAPInsider GRC Conference? No, not there either. The SAP user groups? On ASUG.com I found some great presentations on new features and roadmaps, use cases and implementation case studies, and  one excellent presentation on administering your GRC system, but even that one was focused on best practices for dealing with problems. It seems that production support processes are not glamorous or exciting enough for presentations.

I plan to post a few specific questions but this is my ask to followers of this space: anyone who has any great ideas for production support processes for the GRC Access Control components- the field is wide open! You are cordially invited to step right up and share your experiences, especially those who have been doing it for years. Once we get this new process sorted out, I will publish a post, but don't wait for me. You don't have to claim that you have all the answers, or that your processes are one size fits all. Just sharing what works for you might help the next poor sod who implements that component and then says to herself. OK, now what?

I have illustrated to Mitigate one set of T-code . I have assumed function Id is not being shared with other risk ID if it does then Z risks will be created as equal to no of shares respectively

This is a weekly blog that will have the 5 last SAP Notes of Access Control corrections released to customer by SAP!

1 - 2271800 - Full Name column is empty in Mitigated User Organization Rule dashboard

Symptom:In NWBC -> Access Management -> Mitigated Access -> Mitigated User Organization Rule dashboard Full Name column is empty even if there are records  displayed.

2 - 2263271 - UAM: Access Control configuration parameter 2045 is not considering for the Organizational assignment request

Symptom: Create an Organizational assignment request. Add System and select any role from existing assignments , the default provisioning action maintained in the configuration for parameter 2045 is not applicable.

3 - 2246230 - Multiple issues with GRACEAM archiving object

Symptoms: User schedules a write job on the GRACEAM archiving object with the following setting: Detail Log: Complete, Log Output: Application Log.

     Symptom 1: The job will be canceled with the following error message: "Message incomplete (severity, area, number, or exception missing)".After a           complete archiving was performed, the following issues were experienced regarding the job:

     Symptom 2: The progress indicator line of the 'Job Log' includes invalid data.

     Symptom 3: After a delete job, the 'Number of Deleted Data Objects' field always shows zero in the 'Spool List'.

4 - 2205515 - Clean up invalid mitigation assignments

Symptom: Enhancement Delete Invalid Mitigation Assignments and extend Expired Mitigation Assignments

5 - 2266383 - SQL error in Role Relationship with User / User Group report

Symptom: Dump on executing Role Relationship with User / User Group report for all user (*).

To receive updates bookmark the blog and have updates every week!

Rafael Guimbala

Scenario: There can be terminated users whose user id has been locked with security administrative lock and all roles are removed from the account or maybe they are completely removed from the system and then those users have pending reserved workflow items, still hanging to be completed.

Solution 1: GRC Process Control provides provision to reassign these workflow to a different user using the functionality Replacement/Removal.

For this, under Access Management tab and go to ‘Replacements’.

Click on button ‘Replace or Remove’.

Now under in: choose ‘Deleted User Name’ and in Find: give the exact and complete user id of the terminated user. And then go ahead click next and do the replacement as for other users

. Related notes: 1904421, 1927964.

Solution 2: If you have administrative rights in backend system, you can also forward these hanging workflow items directly from backend using the transaction SWIA.

Simply search for the work item id and use the icon  to forward. Just remember this does not allow you to forward the work item to your own user.

Scenario: HR Trigger requests make use of the same workflow notification as other Access Control requests. Customers may want to disable notifications when the request is created by HR Trigger, and all other requests should continue to generate notifications normally.

How can customers disable email notifications for HR Trigger requests only?

Solution: This can be achieved by following the steps below:

1) Create Enhancement Spot/BADi per Note 1589130 or per Note 1727135. You can also apply both notes and merge the code.

2) Thereafter, customized code can be done in method SEND_OVERRIDE of the BADi's implenting class. It is a stable solution and does not get overwritten by SP upgrades.

The customization code attached is a suggestion that has been tested in my internal system as works effectivelly.

In my sample code, I am suppressing e-mail notifications for HR Triggers that create request type 23.

Please note that you need to replace the request type 23 with your own number based on you HR actions maintained in SPRO.

Navigate to SPRO>...>Access Control>User Provisioning>Maintain Settings for HR Triggers,
.

If you would like to suppress e-mail for more than one action triggered by HR, then you need to slightly modify the sample code to achieve it.

Hope this is useful!

Scenario: There can be terminated users whose user id has been locked with security administrative lock and all roles are removed from the account or maybe they are completely removed from the system and then those users have pending reserved workflow items, still hanging to be completed.

Solution 1: GRC Process Control provides provision to reassign these workflow to a different user using the functionality Replacement/Removal.

For this, under Access Management tab and go to ‘Replacements’.

Click on button ‘Replace or Remove’.

Now under in: choose ‘Deleted User Name’ and in Find: give the exact and complete user id of the terminated user. And then go ahead click next and do the replacement as for other users

. Related notes: 1904421, 1927964.

Solution 2: If you have administrative rights in backend system, you can also forward these hanging workflow items directly from backend using the transaction SWIA.

Simply search for the work item id and use the icon  to forward. Just remember this does not allow you to forward the work item to your own user.

I am looking forward to presenting "The Road Ahead:  Practical Options for Extending your Investment Beyond SAP Access Control" at the SAPinsider GRC 2016 event.

This session will describe the functionalities of the SAP GRC solutions available as well as benefits of integrating these solutions to increase your GRC effectiveness and efficiency.

Please make a point to check out the websites for a full listing of the tracks and sessions taking place this year.

http://www.grc2016.com

http://www.financials2016.com

See you in Vegas!

Some customers are experiencing the following issue after upgrade to GRC 10.1 SP 10 and SP11:

Despite repository sync job is completed without any dumps the table GRACUSERCONN is not updated,

To solve this issue implement SAP Notes below

2221261 - Code changes in repository sync for performance improvement

2168872 - Inconsistent entries in table GRACUSER and GRACUSERCONN

IF the issue still persists follow the steps in SAP Note below:

2253834 - Repository sync collection of corrections

For missing user type in GRACUSERCONN please implement SAP Note below:

2250690 - Some Portal Users missing in Repository Sync

2259378 - Repository Sync issue with expired and locked users - plugin

Regards

Rafael Guimbala

This is a weekly blog that will have the 5 last SAP Notes of Access Control corrections released to customer by SAP!

1 - 2269665 - Central Controller is misspelled in the Access Control Owners screen

Symptom:Open NWBC and go to the Setup tab. Click on the Access Control Owners link. The spelling of the Central Controller is wrong on the screen.

2 - 2171822 - SAP GRC Access Control - standard SOD rules for SRM Webdynpro Application

Symptom: .SAP has extended scope of running risk analysis to analyze Webdypro Applications. This is enhanced with SP06 of GRC 10.1. Refer to SAP Note 2048207 for more details.With this, SAP GRC SOD standard rules library is also now enhanced with SRM Webdynpro application rules.

3 - 2276030 - UAM: Completed requests are still having pending approver in the instance status

Symptoms:  Search for an approved request from the administration and click on instance status. Check the pending approvers at the selected path. The instance status is showing pending approvers even for the approved requests.

4 - 2278287 - Error message text not displayed in Validity dialog in Mitigated Users dashboard

Symptom: In NWBC -> Access Management -> Mitigated Access -> Mitigated Users -> Validity change dialog, if Mitigation Control is not valid the exclamation mark appears alone, without an error message text.

5 - 2278377 - Violation Comparisons dashboard report shows invalid comparison data

Symptom: You use the Violation Comparison report. Define an arbitrary criteria set and press 'Go' button. The diagram on the right-hand side shows invalid values for Comparison.

To receive updates bookmark the blog and have updates every week!

Rafael Guimbala

The Three Lines of Defense concept was first introduced in 2006 as a proposal for better equipping audit committees. Figure 1 below is a simple illustration of how it is supposed to work

Is it working?

The concept s blindingly simple. No one seems to disagree on its merits/ It may come as a shock to some GRC professionals that it is not working, not even a little.

What’s the problem?

Historically GRC professionals have never really collaborated. A vague conceptual framework saying they should was never going to work. Surveys show everyone likes it but no one is doing anything about it.

The problem is the framework did not suggest any performance measures or provide any implementation guidance.

What’s the solution?

At SAP we think the first step is defining some reasonable outcomes.

Figure 2 below is a summary of what we thing management and Boards should expect

What’s needed?
Implementing the Three Lines of Defense means overcoming a number of obstacles and inventing tools and processes for practitioners to follow and use.

The Three Lines of Defense advocates a risk based approach, but which one and how would it work?

What tools and technologies are available and how do they work?

GRC silos have proven impossible to break down, but do they need to be broken down? Can we have specialization without silos?

What reports are necessary and who should get them?

The Three lines of Defense framework does not provide guidance on these or most other implementation requirements.

Finding the answers

We’d like to know your experience in implementing the Three Lines of Defense. Does it work in your business?

Do you agree with the outcomes we have listed above?

“Implementing the Three Lines of Defense: Getting Risk Compliance and Audit to talk to each other” offers some of our ideas and introduces some tools we have developed for the journey.

Join me at SAP GRC Insider. Click the link below to get more information along with a discounted registration.

Bruce McCuaig

Introduction

Risk Terminator provides a framework where Risk analysis can be triggered during User and Role maintenance activities using SU01, SU10 and PFCG directly in the plug-in system.

Key Concept

The Risk Terminator is a service that runs in the SAP ABAP back-end system and triggers automated risk analysis check when defined segregation of duties (SoD) access risks are violated during User or Role maintenance directly in the plug-in system..

Below are the configuration details to configure Risk Terminator.

GRC Configuration

In GRC system maintain the below configuration settings in the path: SPRO -> IMG -> GRC -> Access Control -> Maintain Configuration Settings

Plug-In System Config

Make sure that below mentioned User Exits exist in the plug-in system in the path: SPRO -> IMG -> GRC (Plug-in) -> Maintain User Exits for Plug-in systems. If they don’t exist, create the entries and save them.

In Plug-In system maintain the below configuration settings in the path: SPRO -> IMG -> GRC (Plug-in) -> Maintain Plug-In Configuration Settings.

1. Connector Name maintained in Configuration Parameter 1000 in Plug-In system must be same as the connector name maintained in Configuration Parameter 1080 in GRC system.
2. GRC Connector name must be maintained in Configuration Parameter 1001 in Plug-In system as shown below.

The Risk Terminator functionality can be applied to different business cases around user maintenance (creation and modification) and role maintenance (creation and modification). To simulate how risk analysis works for role maintenance and user role provisioning, I used below business scenarios. They are based on the configuration settings defined in the GRC system and the Plug-in system.

Risk Terminator Scenarios

Scenario 1: Testing role creation with conflicting Tcodes using PFCG.

Role Name: RT_TEST_ROLE

Tcodes: Conflicting Tcodes have been added as defined in our Rule set

Since the user exit before profile generation is also maintained, you can see from the below screenshot that “Risk Terminator” is triggered as the message shows “Checking for Access Risk Violations”.

Risk Violations will be shown as below

Risk Terminator Triggers during role assignment using PFCG as well

Scenario 2: Testing SU01 conflicting role assignment to users.

Before you test scenario 2 make sure to implement the below SAP note in your Plug-In system if your Basis Release is 701 as Risk Terminator is not working for SU01 and SU10.

Followed few SCN links in preparing this blog post.

GRC 10 - Risk Terminator

Some customers are experiencing the following issue after upgrade to GRC 10.1 SP 10 and SP11:

Despite repository sync job is completed without any dumps the table GRACUSERCONN is not updated,

To solve this issue implement SAP Notes below

2221261 - Code changes in repository sync for performance improvement

2168872 - Inconsistent entries in table GRACUSER and GRACUSERCONN

2256786 - All data for Portal Users not updated in Repository Sync

IF the issue still persists follow the steps in SAP Note below:

2253834 - Repository sync collection of corrections

For missing user type in GRACUSERCONN please implement SAP Note below:

2250690 - Some Portal Users missing in Repository Sync

2259378 - Repository Sync issue with expired and locked users - plugin

Regards

Rafael Guimbala

This is a weekly blog that will have the 5 last SAP Notes of Access Control corrections released to customer by SAP!

1 - 2275603 - Existing User Assignment GRC Web Service GRAC_IDM_USER_BUSROLE_DETAIL

Symptom:A New webservice GRAC_USER_ASSIGN_BUSRL_WS has been created for existing user assignment for business role .The web service works for user id * and provide business role as well technical roles.

2 - 2275031 - 10.1: Change delegation link cannot be hidden if only AC application is active

Symptom: .It is not possible to hide change delegation link on the NWBC page, if only AC application is active in IMG and only AC delegation functionality is being used.

3 - 2244581 - GRACACTUS archiving session terminates with SAPSQL_SQLS_INVALID_CURSOR error

Symptoms:  The user schedules an write job with the GRACACTUS archiving object. The internal session terminated with the following runtime error: SAPSQL_SQLS_INVALID_CURSOR.

4 - 2220583 - EAM - Transaction Log and Session Details results blank, when executing for ‘Critical Transaction only’

Symptom: The EAM report output shows blank when executing the report 'Transaction Log and Session Details' by selecting ‘Critical Transaction only’ parameter.

5 - 2273497 - Consolidate Note for Greenlight adapter and GRC integration

Symptom: The purpose of this article is provide a central point for direct text finding on note titles of GRC Access Control and Greenlight Integration.

To receive updates bookmark the blog and have updates every week!

Rafael Guimbala

Lately during discussions with some customers and partners, the topic of differences between SAP Fraud Management and Continuous Control Monitoring Framework in Process Control came up. In other words the customer (sometimes the partner representing the customer) is looking for a justification for having a dedicated Fraud Solution, given that the customer has an existing instance of SAP Process Control. This question arises because sometimes the customer has a perception that CCM, a monitoring framework within PC, can fully meet their Fraud detection and prevention related requirements.

Before I delve into the details, below is a list of abbreviations that will be used, and the corresponding elaborations. I have added hyperlinks for each item below which would be helpful in case you wish to explore these in more detail.

1. CCM: Continuous Control Monitoring

2. FM: Fraud Management

3. PA: Predictive Analytics

4. PC: Process Control

5. GTS: Global Trade Services

As a customer it is important to understand that both these solutions (SAP PC and SAP FM) are complimentary and play an important role in addressing your overall compliance requirements. Whilst PC helps in documenting, testing and design assessing your controls, Fraud Management can scan through a large volume of data for potential Fraud and flag suspicious records. Both these solutions are integrated, which is exemplified by integration scenarios such as ability to create issues in PC from FM.

Fighting organizational Fraud requires a multi-pronged approach and having a dedicated Fraud detection software solves just one piece of the puzzle , additional measures such as ensuring SOD free access and ensuring all key controls are effective at all times are also a must. Such requirements can be managed by implementation of additional solutions such as SAP GRC Access Control and Process Control, however for more specific requirements, such as managing trade compliance, other solutions such as SAP GTS would be necessary.

Now coming back to the question. How does SAP FM stack up against SAP PC CCM? Below is a list of some key differentiators.

1. Fraud Management can perform online detection.

If you wish to read in depth about online detection, click here. To put it simply, it's a feature that allows calling the Fraud Algorithms from an external application, in which you are performing a business process such as your ECC system, and stopping the transaction in case a Fraud check is positive. This is a powerful feature which allows you to embed Fraud Detection within your business process. However enabling this feature also requires calibration and fine tuning of Fraud Rules, something that a customer should discuss in detail with the implementation team. CCM on the other hand is built for Control Monitoring and hence does not facilitate online detection out of the box.

2. Integration with Predictive Analytics.

Fraud Rules consist of a detection strategy, which in turn comprises of one or more detection methods. These detection methods are procedures in HANA that contain the logic of data retrieval, Fraud detection and rendering of the results. Although the logic of Fraud detection can be generated manually (by coding directly these HANA procedures) Fraud Rules can also be generated using the Predictive Analytics software. What that means is that while implementing a rule in process control CCM, you must be fully aware of the logic beforehand but for Fraud Management you can generate the rule logic by presenting a set of data containing confirmed Fraud records to SAP PA and use the SQL generated by the PA Solution in your execution procedure in FM. Predictive Analytics is a separate solution and more details about it can be found here.

3. Enhanced Simulation.

In PC CCM, one can perform simulation using the ad-hoc query option within a business rule and that is quite sufficient if the objective is to view the results of a query, as is required for control monitoring. However in Fraud Management a lot more can be done for simulating results. For instance, you can check the results of a simulation by providing different weightage to each of the detection methods and also see the breakdown of generated alerts based on each detection method.

To summarize, SAP Process Control CCM is an important feature within PC that facilitates control monitoring and corresponding issue remediation .However if the requirement is to scan data in a transactional system for potential fraud, corresponding remediation and performing online detection, Fraud Management is a better fit.