Tip Doctor, Insider Learning Network.

The following excerpt has been taken from James Roeske’s presentation “Minimizing the cost of compliance, audit, security, and risk management in financially challenging times” which took place during the GRC 2011 conference in Amsterdam this past June.

8 Tips for SAP BusinessObjects GRC:

1.    Integration

• SAP BusinessObjects Access Control 5.3 is a single application rather than four separate independent parts.
• With this consolidation, additional integration has been created

• Tip:  Utilize SAP BusinessObjects Access Control application integration to the fullest extent to get the most benefit from you current investment and for setting the foundation for future expansion of your GRC footprint

• SAP BusinessObjects Access Control integration highlights in 5.3
• Risk Analysis and Remediation is the central SOD analysis engine and Rule repository for the entire suite
• Compliant User Provisioning is the Workflow engine for the entire suite
• This now includes Workflow capabilities for Mitigation and Risk/Rule change controls, Role maintenance approval, and Superuser Privilege provisioning integration
• SAP BusinessObjects Access Control 5.3 now provides integration and SAP NetWeaver® BW.
• Risk Analysis and Remediation and Compliant User Provisioning can now integrate, provision, and analyze risk for SAP NetWeaver Portal and UME authorizations
• With the SAP partnership with Greenlight, increased support for PeopleSoft, Oracle apps, and JDE come standard with the application

2.    Increase automation through good Workflow design in Compliant User Provisioning and leveraging its fullest capabilities, including:

• SPM Access Requests and Provisioning
• User Access Reviews
• SOD Reviews
• ERM Integration and Approvals

3. Assign responsibility to business approvers instead of requiring Security Team to review and process all requests

4.    Empower your business users to take ownership and leverage the standard reporting in SAP BusinessObjects Access Control on their own

• Rather then extracting the data in spreadsheets or printing paper reports for them out of your new SAP BusinessObjects Access Control system

5.    Establish good role design with naming conventions and descriptions that end user requests and approvers can understand

• Roles should be clean of SOD violations
• With good role design, naming conventions, and solid attribute filtering, end users should be able to find the roles they require and what to request

6.    Establish Business Role Owners and Role Approvers  

• Allows for proper distribution of accountability and work load
• Provides consistency and efficiency in approval processes

7.    Mandate SOD violations are always analyzed and mitigated before they are assigned to the users

• Always try to remediate SOD violations first
• Mitigation Controls should be second choice

8.    Utilize Superuser Privilege Management for emergency as well as “extra” access not required for daily or routine jobs

• Users’ daily jobs should be reviewed and analyzed for SOD remediation/mitigation, be careful not to remediate by moving SOD violations to Superuser IDs
• Do not allow Basis or IT personnel to use Superuser Privilege access for all of their normal daily activities
• Not a good control if no one reviews an 8-hour log of transactions

Tip Doctor, Insider Learning Network.

The following tip has been taken from Brian Ocampo’s presentation “Expert Techniques to rapidly identify, assess, and mitigate high-risk SoD Violations” which took place at the GRC 2011 conference in Las Vegas, March 8-11.

Many companies today have implemented SAP BusinessObjects Access Control, and are utilizing the risk analysis and remediation (RAR) functionality. Check out the below tip on how to customize the technical components of your RAR rule set. 

How to customize the technical components of the your rule set

• After the risk assessment process, and the functional blueprint of the rule sets have been established, the technical blueprint of the rule set can then be designed
• Map functions to the technical application landscape (consider defining logical systems for applications where common rules are expected to be applied)
• Evaluate custom functionality within each application for SoD relevance
  
  • If there are relevant custom t-code functionality, add the transactions to the rule sets, as necessary

• Disable (not delete) rules that are not applicable to preserve audit trail and for potential future use
• Perform final quality review of the technical rules sets.  Some checks to consider:
  
  • Are there t-codes (and supporting objects) that are conflicting with themselves?
  • Are there t-codes which do not have any underlying objects defined?
  • Can object level rules be added using your USOBT table?
  • Are all activity fields enabled where they are applicable? 
  • Are there display values enabled in activity fields that should be turned off?

• Implement changes to the technical rule set

More SAP BusinessObjects information, tips and advice are available on Insider Learning Network's SAP BusinessObjects Group.

From The Tip Doctor, Insider Learning Network.

This tip was created by Ms. Christa Schönberg, GRC Nordic, for a session at the GRC 2010 Europe conference presented in Barcelona, November 2010.

Whichever system you are using, the configuration of compliant user provisioning must be done. Configuration does not require any deep technical skills; simple logical thinking skills are enough. 

Make all the necessary configurations on the configuration tab page. Depending on the version that you are using, you might see some different paths available. (These paths are valid for SAP BusinessObjects Access Control 5.3 SP 11.) The assumption is that the technical post-installation steps for configuration of SAP BusinessObjects Access Control compliant user provisioning have already been completed.

Here are steps required to configure approval workflows for compliant user provisioning:

1.  Request
   • Request Type Step: Activate the relevant preconfigured request types (change user, new hire, etc.)
   • Priority Step: Create the priorities for your requests that you will be using
   • Employee Type: Create the employee types you will be using
2. Number Range
   • Activate your number range
3. Risk Analysis
   • Specify some detail data on how the risk analysis will work in conjunction with CUP. Make all necessary settings here.
4. Mitigation
   • Specify some detail data on how the mitigations should work in conjunction with CUP. Make all necessary settings here.
5. Attributes
   • Configure how the request form looks in this step (i.e., are certain fields available or not, are they drop down lists or not).
6. Request form customization
   • Configure how the rest of the request form looks in this step (i.e., make fields mandatory, editable or visible).
7. Workflow configuration
   • Initiator: All workflows need an initiator. Make sure there is only one initiator valid for each of your scenarios. You can use many of the predefined attributes as initiators (e.g., company, action of role or request type). 

•  
  • Stage: In the stage you will define most of the things that determine how the approval workflows will work.

•  
  • Path: The path combines all the data, the stage, and the initiator. You may connect many stages to one path.
  • Email reminder: In this step, you can configure how the reminders are sent out, for example, the approvers, in case they do not react to the access requests.
  • SMTP server: This is mandatory if you want to send emails out from GRC CUP to the approvers.

In addition to these steps, you will need to ensure that the roles are available in GRC CUP. Those can either be loaded from MS Excel, or taken from GRC Enterprise Role Management (ERM). This is configured in the step Roles – Import Roles.

Finally, you need to schedule the following background jobs: Email Dispatcher, Email Reminder, and Escalation for the emails to be sent out. The emails get sent out each time a job is run and the jobs can also be run manually if needed.

For more information about configuring SAP BusinessObjects GRC Solutions, the sessions presented at GRC 2010, 9-11 November, Barcelona, Spain, or the 2011 dates for SAPinsider's GRC conference, visit the GRC Conference Group on Insider Learning Network. 

This tip was taken from the presentation “Technical Landscape and Architecture Requirements for Implementing SAP BusinessObjects GRC Solutions,” presented by Kurt Hollis, Deloitte Consulting, at the GRC 2010 conference in Orlando. 

There’s good news for customers who are running multiple SAP BusinessObjects SAP solutions and wish to consolidate them.  In the past, running the full suite of GRC solutions required 6 separate systems to accommodate ABAP and Java stacks individually.  Now, common components can be consolidated.  ABAP and Java components, while still separate stacks, can share the same server. This greatly simplifies the tasks of preparing and maintaining the SAP landscape for GRC solutions.

 SAP BusinessObjects GRC applications can run together as follows:

SAP BusinessObjects Process Control and SAP BusinessObjects Risk Management may run on a physical server with other applications, as long as the server has the resource capacity available to handle the sizing load for the customer need overall, plus any other applications running on that server.

SAP BusinessObjects Process Control 3.0 and SAP BusinessObjects Access Control 5.3 can run together on the same SAP NetWeaver system (separate stacks!) provided that the server has adequate resources to handle the additive sizing load calculated for each system. NOTE: Be sure to consider the memory size!

SAP BusinessObjects Process Control and SAP BusinessObjects Risk Management require a Java stack for SAP NetWeaver Portal support,  which can reside and share the same Java stack running Access Control.

SAP BusinessObjects Process Control and SAP BusinessObjects Risk Management portal applications can be deployed on existing SAP NetWeaver Portals; otherwise, a separate portal installation is required.

One important thing to note: Sharing Java stacks may require the installation of additional usage types such as BI Java, EP, or EP Core if they are not currently installed.

There are special considerations you must keep in mind if you are running global trade services (GTS) functionality:

Best practice is to install a separate SAP NetWeaver 7.0 system for GTS as recommended by SAP

GTS SLL-LEG main core component is only supported on SAP NetWeaver 7.0 currently, not on SAP enhancement package 1

GTS SLL-LEG depends on SAP AP_700 component which must be installed first

A possibility exists to install GTS into a separate client in an existing SAP ERP system

SAP ERP system needs to be SAP ERP 6.0 based on SAP NetWeaver 7.0

Life cycle of SAP ERP and GTS may change and a need to upgrade to different SAP NetWeaver versions in the future may occur

GTS SLL-PI supported on all SAP ERP systems from 4.6C to SAP ERP 6.0 EHP4 +

SAP enhancement packages can also affect your GRC landscape.  They are compatible with SAP BusinessObjects GRC solutions as follows:

The Process Control RTA is currently compatible with SAP ERP 6.0 and SAP enhancement package 2, 3, or 4

SAP BusinessObjects Access Control RTA:

VIRSANH – Supported on SAP NetWeaver 7.0, 7.01, 7.10 based systems and supported with ERP EHP 2, 3, or 4

VIRSAHR – Supported on SAP ERP 6.0 with EHPs because SAP_HR remains 600 version

Global Trade Services SLL PI – Supported on SAP ERP 6.0 with EHP 2, 3,
or 4

You should install the core SAP BusinessObjects GRC solutions components on SAP NetWeaver 7.0 SAP enhancement package 1 system (except for Global Trade Services)

Find out how you can take advantage of additional GRC education at the upcoming GRC 2010 event in Barcelona (www.grc2010.com) or GRC 2011 US conference in Las Vegas (www.grc2011.com)