Please be aware that some customers who have upgraded to Internet Explorer 10 are having problems with NWBC in GRC 10.  SAP is aware of the issue and are working on it.  Please report any problems encountered, however, so all problems can be identified and corrected. 

This is part 3 of a series by Soujanya Madhurapanutula.  For the first 2, please visit nextlabs.wordpress.com

Recap: the 2-layer SAP authorization model

In our previous post, we introduced a 2-layer SAP authorisation model: a combination of Role-Based Access Control plus Attribute-Based Access Control. To comply with regulatory mandates such as export control, where access to data is dependent on multiple factors, such as location, nationality and content, it is prudent to augment SAP’s authorization model in order to control access at the data level.

Complying with Electronic Export Control (using ITAR/EAR as an example)

Let’s take the scenario of a large Aerospace and Defense firm that must comply with ITAR and EAR export control regulations.  These are pertinent today because they cover not only defense articles and services, but also the technical data associated (such as CAD drawings, Bills of Materials, etc) with the defense articles. 

To comply, the firm will need to restrict access to technical data unless an explicit export authorization is granted. Examples of violation include:

1. A  “Deemed Export” violation happens when technical data is accessed by a non-US person, even if the access is from US soil, unless an export license has been granted
2. An “Export” violation happens when technical data is transmitted outside of the US, even if the recipient is a US person, unless an export license has been granted

In order to comply, we need to identify the access-control problems at a more granular level. Identifying US citizenship and role, and location where data is accessed and used, is easier when you apply ABAC. In this scenario, we can leverage SAP GRC Access Control to administer access at the application and transaction level, and leverage ABAC to authorize access at the data level.

Supercharging the authorization model with ABAC for location and license awareness helps effectively police data entitlements in complex projects. This hybrid design fully integrates the features and capabilities of SAP authorization, such as ease of user assignment, with the efficient support of data attributes that mitigates “role explosion” and custom development that would otherwise be necessary and costly.

Types of Attributes

So what are the fundamental considerations of Attribute-Based Access Control? A combination of 3 articles…

1. Identity attributes like the ones I mentioned above (nationality, company, and department) identify who the user is in order to control access:
   • Is the person a foreign national?
   • Does the person belong to the relevant organization, department or team?
     
     
2. Context attributes help us understand how the person is accessing and interacting with the data.
   • Is the person located outside your national soil at time of access request?
   • Is the person using a VPN or a browser to make access?
   • Is the requested file associated with a specific export license?
     
     
3. The content of the document uses what it is to define its level of control. We don’t want to restrict access to all the documents in a site irrespective of whether they are controlled or not. So content attributes like metadata, custom tags, and labels extend the access control to a more fine grained level based on the data present.

A combination of GRC Access Control and ABAC can provide the best of both worlds: a way to easily administer and control access at the transaction level based on compliant user roles, and a way to dynamically authorize access at the data level.

---

Soujanya is the Product Manager for the Entitlement Manager for Enterprise Applications at NextLabs. She works with the Solutions Management team to devise best practices for securing and controlling data in order to develop solutions for Global 5000 business around partner collaboration, export regulations, IP and Data security.

In his session atGRC 2013, compliance and security Marc Jackson makes the case for auditing your SAP GRC systems – something not to be overlooked in your system audits.

In a recent online Q&A on Insider Learning Network, Turnkey Consulting's Marc Jackson took questions on GRC audits, useful transactions and tools, auditing  performance and transport paths, the affect of the ABAP stack now in release 10.0, Firefighter audits, and other topics.

Read the Q&A in our Compliance Forum, or review our edited transcript here:

Matt Moore, GRC 2013: Welcome to today's forum on strategies and tools to audit your SAP GRC system. I’m pleased that we have Marc Jackson from Turnkey Consulting here to take your questions.

Marc is a Manager with Turnkey and is responsible for delivering and developing their Audit and Risk Management services.

Marc will also be speaking at GRC 2013 in Amsterdam in June on the topics of auditing GRC systems, AB&C compliance, and SoD management.

Welcome, Marc, and thanks very much for joining us today! It was great to have you as a speaker at GRC 2013 in Las Vegas last month.  I see a number of advance questions here already, so I’ll let you tackle those.

Marc Jackson, Turnkey Consulting: Hi Matt,

Thanks for the introduction, and welcome to everyone for my Q&A session on auditing GRC systems.

I see there has been quite a bit of activity on the posting already so I'll make a start on replying straight away.

Thanks,

Marc

Ken Murphy: Hi Marc, can you suggest any steps to simplify audits of change management/transport paths? Thanks, Ken.

Marc Jackson: Hi Ken,

This is a good starter, as Change Management is just as significant for GRC systems as it is for any other SAP systems in your landscape.

If unauthorised changes are taking place in your GRC system then this could undermine the integrity of the controls and compliance related data coming out of it.

The key thing to remember around the transport path is that your GRC system should ideally have a 3-tier landscape - DEV, QA & PROD. Therefore, a quick way to check this in your system is to use transaction STMS and then hit the "Transport Routes" icon. This will provide you with a graphical illustration of the GRC systems defined as part of the transport route.

There are many other areas of Change Management which can and should be covered as part of your GRC review, such as the procedural elements which are followed when making changes to the system (e.g. change request procedure, testing steps, migration to production approval etc). The procedure should be tested using traditional sampling techniques.

You should also look for any GRC-related changes which have been made directly in the QA or production environments rather than via the Dev system (use table E070 and look at the system identifier in the initial 3 characters of the transport request name).

There's much more to talk about but I hope that helps as a starter!

malinirao: How to audit SAP GRC Process controls? What are the things to check apart from the controls library?

Marc Jackson: Hi Malinirao,

GRC Process Controls (PC) is quite a unique system to audit but there are some specific parts which need a certain level of attention.

The master data should be checked for appropriateness and completeness (i.e. has your organisation's control framework been reflected accurately within the tool, have the relevant risks been assigned to the correct sub-processes, control and control objectives etc).

However, if your organisation is using PC to automatically monitor the operating effectiveness of controls then you must get assurance over the logic and data held within the related business rules and data sources. The primary purpose of this is to ensure they will accurately reflect the status of the control it is monitoring.

You can do this by looking in the Rule Set-up work area, and select business rules within the Continuous Monitoring section.

AlexanderHartwig: Hi,

I have some questions on GRC v10.0. My clients are now moving into v10.0 and I would like to know what are the key differences between AC5.3 and v10.0 and what would be the implications to an audit.

Are there additional risks that would need to be addressed as a result of the version (and platform) changes?

Marc Jackson: Hi Alexander,

The big difference between the 2 versions is that 10.0 uses an ABAP stack, which actually makes auditing AC easier and reduces the risk in my view!

For example, in 10.0 all non master data-related changes should use the standard SAP Transport Management System. So this means, as is the case in standard ECC systems, that a change can be made in the development system and be migrated through all of the other GRC systems along the transport path in a controlled manner. No need to manually re-apply everything which can easily lead to mistakes, as well as providing some standard tools to help protect the process.

It also means that access is assigned using standard PFCG roles as well. Therefore, it makes it easier to review and understand who has access to specific GRC functionality using traditional techniques such as SUIM reports, or even using the ruleset itself to monitor GRC access.

Another big difference is the integration between the GRC applications. So you might want to check if AC & PC are being used in this way (e.g. managing mitigating controls in PC etc).

malinirao:

• What are the available tools to audit SAP GRC?
• What are the best practices that need to be followed to ensure SAP GRC is compliant with the organization security policies and procedures?

Marc Jackson: Hi Malinirao,There aren't any specific dedicated tools to use as such when auditing GRC systems. The tools which you can use either exist in the GRC back-end system itself (i.e. reporting tools such as SUIM, displaying relevant tables, displaying PFCG, SU01d etc.)Or you should use the tools and techniques available in the GRC system for the purposes of auditing it (e.g. defining GRC-specific sensitive access in your ruleset so you can report against it, using Process Control reports to identify any risks which haven't got a control assigned against them in the control framework, digging into the business rules to understand the logic and whether it would accurately identify a control deficiency or not etc.).You can also use traditional interview techniques as well and speak to the people that own and maintain these systems.
charukesh: Hi Marc,What are the best practices for auditing the SOD rule sets?If a landscape has multiple systems like ECC, SRM , HR and no Logical Systems/Cross-systems are defined, how do we highlight the inefficiencies?Best regards,CharukeshMarc Jackson: Hi Charukesh,When auditing the GRC rulesets there are a few things to keep in mind. The ruleset is there to define those access risks that are deemed significant to the business and translates them into SAP authorizations, so that offending users can be identified as part of detective or preventative controls.Therefore, the identification of SOD & SA risks is heavily dependent upon accuracy and completeness of the ruleset. So you need to review the ruleset content, which includes:

• Risks
• Functions
• Actions
• Permissions

Now, you won't be able to say on your own whether everything is OK or not. You also need to talk to the relevant people to understand the process taken during construction of the ruleset to ensure that the right people were included in the design workshops, so that the risks are relevant to the organisation and not just out-of-the-box.

You should also ensure custom functionality has been included where it could help contribute towards a risk.

I'm not sure I completely understand the 2nd part of your question - could you please elaborate? Thanks.

charukesh: Thanks for your reply Marc.

Let me rephrase the question. Maybe now I am asking a slightly different question:

If 2 systems connected to RAR have conflicting functions (Analysis Scope for function is set to cross system) and if no cross system rules are generated, will the system detect/show correct results?

Marc Jackson: Hi Charukesh,

Thanks for your follow-up post.

Regarding your question, I haven't actually used RAR with the cross-system function as yet, but logically I would expect that if no cross system rules are generated then a 'no access rule' selected error would result. However, I can't confirm this for sure based on my lack of exposure to these situations.

Apologies I couldn't be more conclusive for you, but hopefully it's provided a little bit of help for you.

Thanks,

Marc

D.J.: We will be upgrading from GRC v5.3 to v10 later in the year. What is the best approach for migrating our rulesets, workflows, and settings from one version to another? Any other tips for upgrading?

Marc Jackson: Hi DJ,

This question is a little "off topic" as it's related to GRC upgrades rather than tips and techniques to audit your GRC system. Therefore, it's a little bit out of my own subject area and I don't want to give you any false advice.

However, I have colleagues who would be able to provide you with a full and accurate answer to these upgrade queries. Could you please email one or both of the following contacts: Simon Persin  Kehind Eseyinkehinde.eseyin@turnkeyconsulting.com

Thanks,

Marc

JuneChandler: Hi Marc,  In order to fully audit the usage of Fire Fighter in GRC10 is it possible to track from the FF log report right through the documents posted or data changed in the back end system?

We are in the process of upgrading from 5.3 and this is one of our key challenges as we end up running numerous reports in our backend ECC system to identify the impact of the FF usage.

Thanks, June

Marc Jackson: Hi June,

This is quite a common problem, so you're not alone with your challenges! Unfortunately, you are going to encounter the same problems in 10.0 as you're currently experiencing in 5.3.

The good thing is that SAP are aware of these limitations and are currently trying to enhance this transparency within the audit log of FF usage report to more explicitly tell you what actions have actually been performed with the FF user.

I hope that helps ease your frustrations a little. Although it's encouraging you are being so diligent!

Thanks.

JuneChandler: Hi Marc,

Thanks for the response.  It's great to hear that SAP are aware and looking into it.  I will keep an eye out for developments from them.  Thanks for answering the questions.  Some extremely useful information for us.

Kind Regards, June

Dave Hannon: Marc, thanks for taking our questions today.

A person I spoke with recently brought up the performance of their GRC system, so I'm wondering if GRC auditing can have any implication on the overall performance of the GRC system, for better or worse? Thanks.

Marc Jackson: Hi Dave,

That's a good question to ask. Because the common techniques which you will be using to audit your GRC system tend to be quite traditional methods such as running reports, or displaying tables in the back-end, or checking parameter settings etc., then there is no impact at all.

Even when you're actually doing stuff in the front-end, it tends to be navigating around to relevant parts of the tool to check master data, ruleset content, business rule logic, assignment of mitigating controls etc., all of which require no "heavy lifting" on system performance.

The only impact I can foresee is when you are using the ruleset to run risk analysis reports as part of your investigation, but these can be done smartly to avoid any detrimental impact (e.g., running it for targeted user groups at a time, running them in the background, etc.).

It might also mean you may need to set up an extra user or two on your GRC system for the auditors to use, unless you already have such users set up.

Thanks,

Marc

Matt Moore: Thanks to all who posted questions and followed the discussion!

A full summary of all the questions will be available here in the Compliance Forum. And of course, I invite you to our annual GRC 2013 conference in Amsterdam, June 11-13.

Marc will present three sessions, and we hope you have the chance to see at least one of them in person!

You can get updates on the conference by following me on Twitter at @mattmoorewis, and you can discuss the event using the hashtag #grc2013

And finally, thank you to Turnkey Consulting’s Marc Jackson for taking the time to respond to these questions.

Marc Jackson: Thanks Matt. I'd also like to quickly thank all of you for posting questions or following the session. Please don't hesitate to contact me if you have any further questions on this topic area. You can e-mail me at marc.jackson@turnkeyconsulting.commarc.jackson@turnkeyconsulting.com

Thanks,

Marc

This is part 3 of a series by Soujanya Madhurapanutula.  For the first 2, please visit nextlabs.wordpress.com

Recap: the 2-layer SAP authorization model

In our previous post, we introduced a 2-layer SAP authorisation model: a combination of Role-Based Access Control plus Attribute-Based Access Control. To comply with regulatory mandates such as export control, where access to data is dependent on multiple factors, such as location, nationality and content, it is prudent to augment SAP’s authorization model in order to control access at the data level.

Complying with Electronic Export Control (using ITAR/EAR as an example)

Let’s take the scenario of a large Aerospace and Defense firm that must comply with ITAR and EAR export control regulations.  These are pertinent today because they cover not only defense articles and services, but also the technical data associated (such as CAD drawings, Bills of Materials, etc) with the defense articles. 

To comply, the firm will need to restrict access to technical data unless an explicit export authorization is granted. Examples of violation include:

1. A  “Deemed Export” violation happens when technical data is accessed by a non-US person, even if the access is from US soil, unless an export license has been granted
2. An “Export” violation happens when technical data is transmitted outside of the US, even if the recipient is a US person, unless an export license has been granted

In order to comply, we need to identify the access-control problems at a more granular level. Identifying US citizenship and role, and location where data is accessed and used, is easier when you apply ABAC. In this scenario, we can leverage SAP GRC Access Control to administer access at the application and transaction level, and leverage ABAC to authorize access at the data level.

Supercharging the authorization model with ABAC for location and license awareness helps effectively police data entitlements in complex projects. This hybrid design fully integrates the features and capabilities of SAP authorization, such as ease of user assignment, with the efficient support of data attributes that mitigates “role explosion” and custom development that would otherwise be necessary and costly.

Types of Attributes

So what are the fundamental considerations of Attribute-Based Access Control? A combination of 3 articles…

1. Identity attributes like the ones I mentioned above (nationality, company, and department) identify who the user is in order to control access:
   • Is the person a foreign national?
   • Does the person belong to the relevant organization, department or team?
     
     
2. Context attributes help us understand how the person is accessing and interacting with the data.
   • Is the person located outside your national soil at time of access request?
   • Is the person using a VPN or a browser to make access?
   • Is the requested file associated with a specific export license?
     
     
3. The content of the document uses what it is to define its level of control. We don’t want to restrict access to all the documents in a site irrespective of whether they are controlled or not. So content attributes like metadata, custom tags, and labels extend the access control to a more fine grained level based on the data present.

A combination of GRC Access Control and ABAC can provide the best of both worlds: a way to easily administer and control access at the transaction level based on compliant user roles, and a way to dynamically authorize access at the data level.

---

Soujanya is the Product Manager for the Entitlement Manager for Enterprise Applications at NextLabs. She works with the Solutions Management team to devise best practices for securing and controlling data in order to develop solutions for Global 5000 business around partner collaboration, export regulations, IP and Data security.

A discussion I had this morning with one of our IT senior managers served as a good wake-up call to me. We were talking about our organization’s strategic direction for SAP security, and the manager expressed a great deal of confidence that our deployment of SAP GRC 10.x was going to meet our organization’s compliance needs. I was glad to hear it, since our GRC Access Control 10.0 migration project is my primary focus this year; however, I also took to opportunity to mention that, as excited as I am about our migration project, any toolset is not the “end all and be all” of compliance. Deploying a new toolset is just the start; reviewing the security and compliance processes and governance model is equally important to ensure that the organization will get the full value from the GRC toolset implementation. If you, too, are deploying, or migrating to SAP GRC 10.x, here are some things to consider.

For starters, if Access Risk Analysis is in scope, the GRC toolset is only as good as its Segregation of Duties (SOD) ruleset. Has yours been maintained when SAP has released updates and when custom transactions are implemented? Any organization can be “clean” on SOD violations if the ruleset and risks matrix have not been maintained regularly on a timely basis. In addition, if you only have rules for your ECC system, it might be time to consider implementing rules for other connected systems as well.

Do you have a process and organization in place to review all custom transactions for SOD or sensitive access risks before SAP roles are updated?  Does anyone sign off on the risks of new custom transactions before they are added to end user roles? Do you have a strong governance model for security role designs, or is it pretty much anything goes? Is there a designated person or committee with the authority to veto the addition of sensitive Basis transactions and authorizations into end user roles? The latest GRC toolset without a strong governance model may not be fulfilling the promise of its investment to the organization.

When was the last time your security role design was reviewed for alignment with the organization? Whether your roles are task-based, job role based, or a combination of the two, if they are not well aligned with the way the SAP users work, your end users may continue to struggle to identify the “right” roles, even with the improved access request user interface, and many more user access requests are likely to be processed, which is expensive both from a user downtime perspective and an administrative processing perspective.  Business processes often change when new functionality is deployed; a review of the role designs and the risks should be part of that effort as well. Keeping your security role design aligned with the business processes is not something the GRC toolset will do for you, but it is an important part of the compliance picture to ensure that users have the right access to do their jobs. Getting HR engaged in the process can pay off in the long run with more quickly provisioned users, and who doesn’t want faster and better onboarding of new hires? Improve this process and you get to be the hero in your organization.

Getting the latest technology in GRC tools without a well-aligned supporting organization model and processes is a lot like a luxury sports car without a skilled driver and good roads to enable the car to run to its potential.  Consider how your security processes and governance model can be updated to enable your SAP GRC 10.x toolset to deliver the best value to your organization.

SAP Fraud Management is a cross industry solution to analyze, detect, investigate, and prevent fraud and irregulatories in ultra high data environments. It targets both internal and external fraud scenarios that can be based on SAP and non SAP data sources.

Exemplary Internal Fraud Cases

• Suspicious payments to vendors (conflict of interest in procurement)
• In appropriate HR payments (bonuses, salary increases)
• Abuse of payment cards (eg. patrol for company cars)
• FCPA (foreign corrupt practices act)
  • Each stock listed company needs to have processes and systems in place to avoid bribery and have transparency about payments
  • Violating the law leads to very large fines

Exemplary External Fraud Cases

• Insurance: Claims Management eg. car insurance
• Public Sector: Tax related fraud
• TelCo: Stolen SIM-Cards
• Retail: Online shops
• Banking: Anti Money laundering, Sanction List Screening

Fraud management enables companies to detect fraud quicker in order to prevent financial damage.

Key benefits are:

• Early fraud detection
• Quick investigation
• Continuously improvement
• Fraud Prevention

Why HANA makes a difference:

• Detection not only in batch mode but realtime: -> seamless integration into business processes
• Calibration and simulation of rules in realtime on productive data in order to iteratively optimize rules
• Predictive capabilities on full data volume and not only on data subsets
• Fuzzy Search capabilities eg for high volume address matching
• Native full text search in unstructured data

Take a look at SAP official Overview Video:

http://www.youtube.com/watch?v=L_NiH6D28Z0

Auditbot SAP Quick
GRC Compliance Tool: A User’s Perspective

Many organizations spend large sums of money deploying ERP systems yet they have
little or no visibility on how well it is being used or what types and level of
activities users are engaged in. SAP ERP is no exception. While some SAP
standard reports are available, they require specialist skills and
disproportionate amount of time in order to detect and decipher exceptions and
irregular patterns for remedial action.

To be of effective, auditor or functional security analyst should be able to pre-define
the types and levels of risk beforehand and be able to monitor those risks on a
continuous basis. Furthermore he or she should be able to promptly identify,
investigate and respond to non-compliance and other exceptions, preferably through
a single interface using a central cockpit and without having to rely on
technical experts to do so.

One such powerful yet cost effective tool we came across is AuditBot™ GRC monitoring suite.

AuditBot provides a round- the-clock view via a central cockpit security status, what
the users can do and did do in the areas of security settings, master data
changes and transaction postings.

Among many benefits of AuditBot GRC tool is reduced risk of fraud and accounting errors; lower
audit compliance costs through continuous compliance monitoring against
organizational policies on SAP security and the elimination of manual control
testing. 

AuditBot addresses the following key aspects of SAP related tasks:

• Instant Security assessment with summaries and details of vulnerabilities;
• Risk Analysis:  SOD, Sensitive Transaction and Sensitive object risks within a user or role. Also shows the documents posted with
  such risks.
• Detailed lists of transactions used during a review period broken down to individual users
  or a group of users
• Mitigation control management and authorized exception handling;
• Emergency and elevated access monitoring and control: This feature helps provision of emergency
  access to selected users as well as to track the transaction used by them;
• Master data, sensitive table update and transaction processing control and alerts:
  This gives the Auditor a list of table updates made for further review;
• Periodic review and re-affirmation of user roles by the Managers;
• FI Document Posting Analyzer gives the Functional Team an overview of the postings
  made by doc type. Alerts can also be setup to warn when certain doc types are
  posted;
• SAP license saver incorporating license cost reports and other exception reports.
• Constant monitoring of the system for inactive users with automatic locking features
• Track the Transaction used or table updates made, batch job executed of the
  particular user or group of users.
• Monitors system parameter across the landscape to ensure high level of security and
  compliance
• Monitors remote access to ensure they are authorized, restricted and secured;.
• Compliance check for custom objects developed by the customer for transaction assignment,
  authorization groups and authority check statements

My experience in using this nifty tool in most of the above features in monitoring
SAP security in a large Emergency Services Organization has been nothing short
of exhilarating.

Apart from shorter installation and configuration timeframe and low TCO the ease of use of
this product is truly amazing. As it is fully integrated with SAP, the look and
feel and shortcuts are much akin to the standard SAP Gui interface.

AuditBot System Architecture 

AuditBot Quick GRC tool is written in SAP ABAP language and does not require additional
hardware to run. We were advised by AuditBot that as a SAP Certified- Powered
by Net Weaver Partner that they have their our own name space and hence will
not interfere with the clients custom programs.

Configuring AuditBot

We found AuditBot’s configuration menus to be intuitive and easy to use. With the full
features of ABAP engine available at the Administrator’s fingertips,  the system was up and running use in a matter
of few hours, only pre-requisite being to predefine and be ready with having
necessary Sensitive TCodes and SOD conflicts roles lists and user IDs for
monitoring and Transaction alerts etc.

Navigating AuditBot Menu Tree

We found Auditbot’s navigation menu tree to be intuitive and easy to follow, some menu
items could even be accessed through several different menu paths. For example,
Security assessment Cockpit provides a snap shot of all security exposures at
the present moment, from Users, Roles, Authorizations and Tcodes:

Once the Security Assessment Cockpit is activated, the following summary report giving
an overview of SAP security is displayed:

In this  example, the reports highlights 24 users having T-Code full access. This can be further drilled down to determine who
they are which then enables the management to determine whether continued access is needed:

Checklists

The Checklists available for monitoring SAP system usage and transaction processing
are also very broad as shown in the menu options screen:

User Log Analysis:

The AuditBot in-depth log analysis tool facilitates:

• Determining what program was run at the time
• Monitoring all transport and objects moved in to the system
• Monitoring critical table changes including user master changes and system changes
• Analyzing time spent in the system  by individual
  users
• Repeated transaction failures
• Sensitive transaction access
• Excessive access rights
• System errors
• Job failures

 
Log Summary Report

One drawback in using standard user log reports is the need to run multiple log
reports and review individually. This could be both time consuming and prone to
error due to risk of overlooking some logs. When individual logs are obtained viewed
separately the reviewer fails to get a single unified view of the situation.

In Auditbot we found that obtaining all the logs (all 11 of them –see diagram x below) in a
single report can be achieved with click of a button.

The output could be refined further by using one or more of the 13 filtering options
available:

The line items could be drilled down further for detailed information.

Trending Reports

Another fascinating feature of AuditBot is its ability to provide comparisons of audit
security status among almost any two dates. This is provided in a number of
Trending reports – Risk Trending, User Trending, Role Trending and User/ role
assign Trending reports just to name a few.

We found this feature particularly useful in periodic review of new user creation,
change to authorizations and roles. For example answers to questions like these
are only a mouse click away in AuditBot Trending reports:

• Who are the new users created during the current year with monthly
  break-downs? 
• What roles were assigned to them and what Tcodes and what authorizations were
  granted?

System Parameter Analyzer

When there are multiple systems in multiple environments and these keep changing, matching
system profile parameters manually for non-compliance become increasingly
difficult for the Audit team. AuditBot System Parameter analyzer automates this
task, highlighting non-compliant parameters through dashboard buttons. It also
allow simulated parameter changes and evaluate the outcomes.

SOD Conflicts, Critical Transactions and Sensitive Objects

Using Auditbot it is possible to define SOD conflicts in roles through to the Transaction code and authorization object level and then to test
the system to determine whether SOD violations exist.

Sensitive object access Risk monitoring:

AuditBot allows to determine users assigned with sensitive general authorization objects
(create, change, delete etc.) as well as specific authorization objects (e.g.
table maintenance or program execution) which would constitute a risk unless
they are properly secured.

Critical Transaction Risk monitoring

These are mostly system related transactions or mass change transactions which can affect
large amount of data. Auditbot can be configured to monitor access and execution
of single sensitive transaction code.

Segregation of duties (SOD) Risk monitoring

Using AuditBot, SOD risk can be defined and then monitored.

Monitoring elevated SAP access

Another valuable feature we found AuditBot was its user provisioning and emergency
access management feature whereby extensive privileges granted to System
Administrators and Basis Administrators to facilitate emergency fixes can be
documented, authorized, monitored and removed with ease.

We are yet to review License cost saver, Sensitive table update monitoring and several
other options although we are confident these too would be as easy to configure
and use with similar value adding value adding features.

Conclusion

Overall we found AuditBot GRC tool to be versatile, easy to configure and easy to use
powerful set of tools. Using Auditbot, we have effectively addressed several pressing
audit issues regarding security and user provisioning with significant reduction in time and expertise required

in continuously monitoring the use of SAP ERP system.

To register: http://bit.ly/12Gex8R

SAP Sensitive transaction risk is created when the user or role has access to a particular transaction. For example user could have transaction
SCC4 which is to create a client or SU10 which is a mass change user. There are many SAP Sensitive Risk transactions in the SAP System. The majority of them will be basis, configuration or mass change. 

Example User Administration Transactions

GCE1     Maintain User

OOUS    Maintain User

OP15     Production User Profile

OPE9     Maintain User Profile

OPF0     Maintain User

OTZ1      C FI Users

OVZ6     C SD Maintain User Profile

OY21      User profiles-Customizing

OY27      Create super user Customizing

SCUG    Transfer Users

SCUM   Central User Administration

SU01      User Maintenance

SU05      Maintain Internet Users

SU10      User Mass Maintenance

SU12      Mass Changes to User Master Records

SU80      Archive user change documents

SU81      Archive user password change doc.

SUGR    Maintain User Groups

Key benefits of running SAP Sensitive Risk analysis report

1. You can identify all the display roles having access to change or sensitive transactions.  Most of the time if the sensitive transaction
   is not part of the SAP SOD Rule set this risk may be hidden   

1. Identify the functional roles having access to other functional area transactions. For example a Sales and distribution roles having
   access to human resources transactions or basis transactions.  

1. When the SAP Sensitive risk analysis is performed at the user level it can identify the user getting access to other
   functional area transactions due cross pollinations of authorization.

Ongoing monitoring:

A monthly review of the SAP Sensitive risk at the role and user level has to be performed to monitor the risk constantly

Before moving on to the third video in our SAPinsider series I wanted to highlight that you can find the previous two interviews we conducted with Mico Yukhere and Luke Marsonhere! They both got some great input on the bi2013 and HR2013 streams at the event.

This time around you’ll be watching Babak Hosseinian on the topic of GRC and hear what he took away from the Amsterdam sessions. Babak is a recognised GRC subject matter expert in the independent consulting market and have numerous times provided my company and our clients with high-quality consulting services. He was not one of the presenters at this year’s event, which means he’s providing the viewer with insight he gained purely as an attendee. Not everyone got early access to SAP technology and I believe his replies reflect what level of product exposure you would typically get by attending this type of event.

I didn’t find the coverage (pre and post) of grc2013 being that extensive, so this video with Babak is a great piece of content to capture where the market is heading and helps bring some light to a few of the current drivers in the GRC space.

Now enjoy:

That wraps up the 3^rd video in our 6 part video series. The remaining two is Martin Gillet on HCM and Joshua Fletcher on BI and EIM. You will be seeing Martin later this week. I’m sure Babak will be keeping an eye on this post, so if you got any questions for him I’m sure he’ll get back to you.

I also believe it would be worthwhile reading this SCN post by Erin Hughes, which was written prior to the event, as it further highlights some of the key takeaways and focus areas at this year’s GRC2013 SAPinsider - Countdown to #GRC2013 – Getting the Most ‘Bang for Your Buck’

EDIT:

Part 1 of the series: Mico Yuk BI2013 - SAPinsider Video series part 1 of 6

Part 2 of the series: Luke Marson HR2013 - SAPinsider Video series part 2 of 6

Part 4 of the series: Martin Gillet HR2013 - SAPinsider Video series part 4 of 6

Part 5 of the series: Joshua Fletcher BI2013 - SAPinsider Video series part 5 of 6

Updates will follow soon..

Last month I had the pleasure of presenting at the SAP Inside Track in Toronto.  A well-attended event that drew nearly 200 partners and customers my session on enterprise risk management drew a much focused crowd.  “How do we plan for things we don’t know?” “How do we consider managing our processes given constant business changes?” These are compelling questions which have faced organization processes and supply chains with increasing impact over the past five years.  Automotive companies had to figure out how to resource black pearl paint when the Japanese Tsunami hit.  Disney left Bangladesh as a contract manufacturing base after a devastating building collapse and failure on the part of the government to see key safety issues transparently before disaster struck. Companies are giving more attention to SWIFT account financial audits to make sure global payments are using proper account numbers to avoid error and reduce fraud.  These and other factors add up to a growing attention and acknowledgement at the corporate board room and practitioner level that enterprise risk management (ERM) is a necessary business process in its own right.

My presentation on SlideShare is attached.  In the SAP landscape, the key five elements to any ERM program are:

1. The SAP Business Suite or Line of Business Applications
2. SAP Risk Management
3. SAP Access Controls
4. SAP Process Controls
5. NetWeaver Audit Management

My overview article on Tech Target will be available shortly here.

• To leverage the best in class driver allocation capability to distribute cost/revenue from one legal entity to another to reflect fair consumption
• Best Practices to perform what-if analysis to simulate the effect of: tax changes and changing consumption
• The SAP Transfer Pricing solution in depth and see how the solution provides a multi-dimensional framework across geographies, legal entities, brand, products and services.
  

The webinar will discuss not only the drivers of costs related to compliance efforts such as Sarbanes-Oxley, but also , how using SAP GRC Process Control can help companies better mitigate risks and improve their business processes. The session will also cover:

• How SAP GRC Process Control capabilities (such as a unified control framework, best practice workflows, automated control testing and monitoring, certification and disclosure…) can reduce compliance efforts and enhance performance
• How these automated features, can be implemented across SAP and other legacy applications

How flexible reporting can improve management's insight into the company's control environment and ultimately increase confidence that key risks are mitigated and business processes are sound and efficient Hear how one of the leading multinational manufacturers of electronic products Sharp, was able to implement a scalable control environment, take advantage of best practice workflows and control automation capabilities to streamline their compliance effort, improve risk mitigation and provide their Management with confidence in the effectiveness of business processes.

Join us for the webinar on: Wednesday, August 21, 2013 01:00 PM ET | 10:00 AM PT

Speakers:

Jerome Pugnet,GRC Solution Marketing, SAP\

Jan Gardiner, Senior Director in GRC Solutions, SAP Labs LLC

Mike Kosonog, Partner, Deloitte and Touche

Wyatt McNamus, Information Security, Sharp Electronics Corporation

To register:http://event.on24.com/r.htm?e=669768&s=1&k=536F03BC315606BCB0302B539E715353

As of Monday, August 12, 2013, SAP Fraud Management is released to customers in Release 1.1, Support Package 00. SAP Fraud Management, powered by SAP HANA, combines an intelligent and efficient infrastructure for performing fraud detection and supporting investigation with the speed and power of the SAP HANA database. With SAP Fraud Management, you can detect fraud in big data environments with unprecedented speed and responsiveness, and you can bind real-time online checks for fraud by SAP Fraud Management into your purchasing, claims management, and other business processes.

With this release, SAP Fraud Management is enhanced in the following ways:

• Improved design for the Home screen
• Improved work area for investigating alerts, providing an Investigator’s Task List
• Improved searching: Free-text searching in uploaded documents is now available from every screen in SAP Fraud Management, and search hits are highlighted in texts
• New platform:  SAP Fraud Management now runs on NetWeaver Release 7.4 Support Package Stack 03.

Release 1.1 SP00 of SAP Fraud Management also offers content for strengthening your compliance efforts with anti-corruption laws and regulations such as the US Foreign Corrupt Practices Act of 1977 or the United Kingdom’s Anti-Bribery Act of 2010.  This content is downloadable and installable from the wiki pages of SAP Fraud Management in the SAP Community Network: http://wiki.sdn.sap.com/wiki/display/GRC/Anti-Corruption+Content+for+SAP+Fraud+Management+Release+1.1+SP00

For help with installing or upgrading SAP Fraud Management to Release 1.1 SP00, see the SAP Service Marketplace at http://service.sap.com/instguides - SAP In-Memory Computing> SAP Fraud Management.

For access to the SAP Fraud Management documentation, including the links above, see the SAP Help Portal at http://help.sap.com/fra.

The Governance, Risk & Compliance (GRC) space has generated worldwide interest after the enactment of specific corporate laws by the regulators. Many organisations focus mainly on the “C” part, through internal & external audits, to ensure that they comply with the laws & regulations of the land and policies & procedures. However, when laws specifically prescribe that a governance system must exist, risks identified and controls are tested for its effectiveness, the consequences can be far reaching.

Lo & behold!, SAP’s comprehensive GRC tool, (GRC 10) provides the functionalities to meet the requirements of these regulations and seamlessly integrates across modules. An enterprise GRC platform approach allows companies to manage all risks and controls from a single repository, which should give comfort to Directors, Auditors and other stakeholders.

In order to get the best out of GRC 10, it is important that consultants have a good understanding of:

• the integration between Process Control (PC), Risk Management (RM) and Access Control (AC)
• business processes, risks & controls
• regulations
• frameworks on GRC & controls
• risk management standards
• the holistic view of GRC and the benefits an organization can derive

Most organizations start with AC and then move on to implement PC and RM, which is more like a “bottom up” approach. The reason for this is that reporting on SOD violations gained importance worldwide, with the enactment of the Sarbanes Oxley Act and other equivalent regulations. Most consultants in this space come from a technical background, whereas PC & RM requires very good domain knowledge. There is a need for PC & RM consultants to “cross-pollinate” with AC consultants and vice versa. I do appreciate the fact that these modules are vast and finding consultants having an understanding of PC, RM & AC is going to be difficult. However the reality is that this is required for a successful implementation of GRC 10 and for starters, I believe, consultants should at least understand the main integration points.

Continuous Control Monitoring is a very powerful functionality in GRC 10 and can immensely benefit organizations in establishing whether the controls are working effectively and efficiently. This can also help auditors pass an opinion on the effectiveness of controls. In today’s world, the words “control effectiveness” have become buzzwords in the vocabulary of regulators and have been included as responsibilities of Directors and Auditors. Testing of controls should not be done on an “as at” basis, rather it should be done “for the year”, which boils down to continuous monitoring. Organizations need automated tools like GRC 10 to meet these objectives. An effective GRC Consultant must have a “Board View” of governance, enterprise risks and controls and not be restricted to specific modules.

TIPS for Reviewing your SAP GRC Rule Set for Completeness and Relevance

SAP GRC provides rule is provided out of the box and relevant for most of the companies. The rule has to be reviewed regularly as your business need and functionality in the SAP system changes. Here some tips for reviewing your SAP GRC Rule Set

Industry Specific Rule Set:

SAP GRC Rule set does not cover all the specific industry niches. So you may have transactions which are specific to a specific industry and you may not be analyzing the risk based on your industry specific transactions. 

For example in the Federal Government area most of the risks are not based on Sales but by the funds management.  So some of the risks have to be turned off and new SAP GRC Risks have to be added to the Rule set.

Functionality Specific Rule Set: 

There are two schools of thought here. One option is to turn off the risks if you are not implementing a specific functionality. Other option is keep them ON,  so you can see why people are having the risk when the functionality is not being used.

It is better to keep the risks turned on so you can see if the risks are showing up within the SAP users or SAP Roles.  If you are not using HR Functionality and if 50 % of your users are showing SAP HR Risks then there is a bigger problem.

This indicates that your role design is out of sink and transaction belonging to the functionality which has not been implemented has been included in your roles.

Customer Specific Rule Set:

In this scenario you will have custom SAP transactions or Standard SAP transactions which have been configured to behave differently.  These transactions have to be added or removed based on the situation. 

One of key areas to focus on is the Custom SAP Transactions developed internally which is usually ignored.

In MSMP, Access Controls 10.0 and 10.1 provides extremely flexible and powerful tool to configure Access Control workflows. In this blog we will try to understand some basic concepts about MSMP and BRF+.

Before we can start creating any BRF+ rule for MSMP, we need to understand the difference between MSMP BRF+ rule and BRF+ flat rule ( lineitem by lineitem ). The logic executed in both the rules is same but the difference is in the input, output and the way it is processed.

Following are some of key differences:

1.) MSMP BRF+ flat rule (lineitem by lineitem):

This rule is called flat rule or lineitem by line item rule because this rule is called by MSMP multiple times, once for each lineitem. So if in access request you have added 3 roles/systems, then this BRF rule will be called 3 times. As an input to this rule, MSMP sends detail of one lineitem at a time and this BRF rule provides result for that one lineitem only. BRF+ flat rule is easy to create as no loop is required and only one decision table (or other expression) is required for the logic. For example, consider an access request with 3 roles/system. In this case the BRF flat rule is called 3 times by MSMP with following input and output:

Input provided by MSMP to BRF+ flat rule in first call:

Output given by BRF+ to MSMP in first call:  

Input provided by MSMP to BRF+ flat rule in second call:

Output given by BRF+ to MSMP in second call:  

Input provided by MSMP to BRF+ flat rule in third call:

Output given by BRF+ to MSMP in third call:  

So the flat rule is called once for each lineitem which makes its creation easier as no looping is required which is required in case of BRF+ rule.

2.) MSMP BRF+ rule:

In this case, all the lineitems (roles, systems and FFID...) present in the Access Request are sent to the BRF rule in form of a table. After processing, this rule has to return a table with lineitem key and result. For example, in case of initiator rule the input to BRF rule can be following table. The roles/system shown here are one that are added to access request.

INPUT sent by MSMP to BRF+

OUTPUT given by BRF+ to MSMP

Please note that we have not shown the decision table which contains the logic to determine the path in case of initiator rule. Since complete request details are sent by MSMP to BRF+ rule for execution, so this rule is called only once by MSMP. Hence it is required that the logic to loop on all the lineitems has to be done within BRF+ rule. The decision table or other condition is called within the loop so that it is executed for all the lineitems one by one.

Key differences between BRF+ rule and BRF+ flat rule are again summarized below:

What is influence?  Do I have influence? How can one customer make a difference?  Is SAP really listening to my requirements? 

These are all questions that you may have.  Speaking from experience, you do have influence.  You could be the one person needed to take an idea from an enhancement request to a functional requirement.  SAP does listen. But to ensure that accepted functional requirements are a collaborative solution, SAP looks for ideas that are supported by a minimum of five installed customers.  And we need your ideas and support – now.

Currently GRC Access Control 10.1 is in ramp up for several SAP customers.  In this period between ramp up and general availability, SAP is requesting feedback on the latest functionality, and has engaged with us to do so.  Although SAP has great ideas, there are always usability improvements that increase the acceptance of an applications design.

If you currently have GRC Access Control 10 installed or you are part of the GRC Access Control 10.1 ramp up process, now is the time for you to provide your ideas to SAP.  If you would like to participate you until have until September 20, 2013 to submit your ideas.  The longer you wait, the less likely you will have four other customers to review and support your enhancement request.

Why does my voice matter?

It’s worth getting your feedback in and your voice heard.  I have found that SAP is moving past just getting the application to work without defects, and instead, is now working on improving its usability.  And now that GRC AC 10 has been in productive use for a couple of years, customers have great ideas for improving the usability of the application.

When I think of usability I pretend to be the user and validate that the application is intuitive.  Can an untrained user launch an application without any training or knowledge transfer?  Is a user required to enter the same data in more than one field?  If one application has performed an update such as deleting a user’s access, are other related master data elements deleted or made inactive?  Does the application have the proper security or change management controls available?  If two different users test an application, are they both happy with the functionality?

One huge way a customer can influence the usability of the application is to participate in user group influence opportunites and customer connection programs.  As my company participated in the GRC 10 ramp up process, I used the influence options to increase usability, reduce complexity, and add missing functionality.

How do I get involved?

Access to the GRC Access Control 2013 Customer Connection process is restricted.  If you would like to participate, send an e-mail to katrin.pietsch@sap.com requesting to participate in the GRC Customer Connection for 2013.  Once you have access to the site you can use this link to go directly to the site: https://cw.sdn.sap.com/cw/community/influence/.  Then you will scroll down and select the “GRC Access Control 2013” link. 

I hope to see you there soon as we can influence change with your help.

Note:This Blog does not give details about the creation of Business Roles or realted initial activities. It deals only with the functionality that is enhanced, and the new behaviour of Business roles.

The functionality related to Business Role is enhanced in SP13 to support the removal of single roles that are part of business role, based on the validity. Also, the roles which are specific to the business role will be removed from user, when a business role is selected for removal.

Below are more details of the scenarios.

1)  Assign two Business roles to user having two Technical roles each, one of the technical role is common to both business roles (Say BR1 having T1 and T2 and BR2 having T2 and T3).

Till SP12: When trying to remove one Business Role (say BR1), the common technical role (T2) is also getting removed from the backend system which actually was assigned through other Business role (BR2).

2)  Assign one Business Role having two technical roles (say B1 having T1 and T2) to a user, also assign one of the technical roles directly to user (say T1).

Till SP12: When trying to remove the single technical role (T1), the technical role (T1) assigned through business role is also removed from the backend system, irrespective of the validity with which business role and single technical role is assigned.

From SP 13 Onwards:

Validity dates are considered for role removal, below is description of scenarios about how role removal will work.

1) Assign wo Business roles to user having two Technical roles each, one of the technical role is common to both business roles (Say BR1 having T1 and T2 and BR2 having T2 and T3).

SP13 Onwards: When trying to remove one Business Role (say BR1), it will be completely removed without affecting the assignments through Other Business role (BR2), i.e. assignment of T2 and T3 through BR2 will remain unaffected.

2) Assign one Business Role having two technical roles to a user (say B1 having T1 and T2) with validity Period say 01.01.2012 to 31.12.2013. Also assign one of the technical roles (say T1) of business role, directly to user with same validity as of Business role (i.e. 01.01.2012 to 31.12.2013).

SP13 Onwards: When trying to remove the single technical role that is directly assigned.

a)  If parameter 4011 is set to NO only the single technical role (T1) will be removed and assignment of T1 and T2 through Business Role remains unaffected.

b)        If parameter 4011 is set to YES then single role (T1) assigned to user directly as well as the single role (T1) assigned through business role is removed. Since now the business role assignment is now partial, so the other technical role (T2) that was assigned as a part of business role is reflected in existing assignment as if it is directly assigned to user and is no longer a part of business role. Apart from this, at the time of request generation as well as all the approval stages a warning message appears "Role <Role_name> (T1 Here) is a part of Business role of user".

3)  Assign one Business Role having two technical roles to a user (say BR1 having T1 and T2) with a validity period say 01.01.2012 to 31.12.2013. Also assign one of the technical roles of business role (T1), directly to user with different validity as of Business role say 02.02.2012 to 30.11.2015.

SP13 Onwards: Now on removing the single technical role (T1), only the single role assigned directly (T1 with validity dates 02.02.2013 to 30.11.2015) will be removed irrespective of parameter 4011 as the validity for the assignment through business role is different.

4)  Assign one Business role having any number of technical role to a user (say B1 having T1, T2, T3, T4). On trying to remove (say T2) directly via access request:

SP13 Onwards:

a) If parameter 4011 is set to NO then the end user will not be able to create a request and an error message "Role <Role_name> cannot be deleted as it is part of business role of user" will be generated.

b) If parameter 4011 is set to YES then request will be created with a warning message "Role <Role_name> (T2 here) is a part of Business role of user", which will also appear at the time of approving the request.