Mitigating controls - is this a cure for "all evil" in redundant authorizations in SAP? (part 4/5)

[FilipGRC]

Part #4/5: How to implement SoD and support for mitigating checks - tool layer (5 minutes)

The last stage of introducing mitigating controls to the organization is the implementation in systems and automation. In this part of the article, we present the key functionalities that should be implemented to effectively support SoD risk analysis and management of mitigating controls.

Challenges

The complexity of the risk analysis processes and the related SoD conflict analysis (discussed in more detail in the previous articles of the series) sooner or later force the introduction of automation mechanisms. Identifying an SoD conflict sometimes requires analyzing a dozen (or even several hundred) permutations of user permissions. For a medium-sized company, which processes several hundred license applications per month, this implies the need to have a dedicated team to carry out such analyzes and document the results. If we add to this number of periodic audits that expect the presentation of audit evidence for the access risk management process, then a complex list of dependencies is created that is difficult to control with standard tools. This is a signal that business processes are so complex that it is required to implement a dedicated platform to support the entire functionality of the organization.

Automation

The approach to process automation requires dedicated tools. Enterprises deal with this challenge in different ways. Some organizations use the possibilities offered by MS Excel, creating advanced formulas based on data on authorizations from SAP systems, and some regularly dump data and analyze it in the database, e.g. Access. However, practice very often shows that the real scale exceeds these half measures and companies start analyzing the market in search of a dedicated tool for analyzing and managing the repository of exceptions and controls.

Tools

The market for access risk management tools is very diverse, and the most common tools that appear are:

1. Tools offering ready-made solutions-> the simplest access analyzers and SoD - based on the list of conflicts and critical accesses to the system included in the tool. It very often happens that this list is unmodifiable, and the whole logic is based on checking the so-called critical points, or the so-called best practices. These solutions are derived from security management systems and most often the business or process analysis layer is completely omitted in them. In practice, you can run a report with the use of such a tool, only the question remains: what for?A tool of this type does not in any way provide us with the completeness of the analysis or consider the specificity of the system. Many years, and hence completed projects, strengthened our belief that the use of such simple solutions often leads to even greater complications. Implementing corrective actions based on such standard reports, which do not take into account the specificity of the company and business processes, is an unnecessary commitment of resources because usually, the first basic analysis of an experienced consultant will indicate numerous weaknesses and deficiencies in such "universal" tools.

2. Dedicated toolsfor access risk and SoD analysis - there are several tools available on the market that have been developed by people with extensive experience in process and business risk analysis. Tools developed by professionals allow for a much better adaptation to the specificity of processes and companies. It is worth mentioning here, for example, a solution from our local market – SmartGRC. Of course, adapting to the client's specificity is very often associated with a longer implementation process combined with consulting services. At the same time, we get a real view of access risks and SoD conflicts and an adapted action plan that will be an excellent response to the needs of the organization.

- GRC class packages - these are complex solutions that, as part of the package, provide tools for risk analysis and SoD, but enable much more: they provide dedicated workflow mechanisms that automate the entirety of SoD analyses, acceptance and assigning mitigating controls, and comprehensively map the life cycle and efficiency mitigating controls in the organization and enable the automation of these controls. In the case of SAP systems, the leading solution for this area is the SAP GRC package, but it is also possible to integrate other solutions of a similar class with SAP.

What to expect from the tool?

Implementation of the tool depends on the size of the organization, the complexity of the processes, and the budget that the company is committed to devoting to access risk management processes. Taking these criteria into account, below I present a short list of functionalities that process support tools should implement at each level:

Basic level:

• Possibility to define a list of SoD conflicts (SoD Matrix),


• Mapping activities from the matrix to authorizations in systems,


• Defining sensitive and critical activities,


• Ability to map in a tool with personalization options for a given installation,


• Possibility to generate reports (SoD risks/access to activities) - at the basic level, offline mode is enough -> periodic data dump and results generation,

An advanced level:

• Functionalities from the basic level +,


• Possibility to create and manage a mitigating controls repository,


• Possibility of linking mitigating controls with SoD conflicts on the user,


• Simulation mechanisms, i.e. the analysis of scenarios after granting a specific user the indicated permissions,


• Extended reporting in the scope of mitigating / non-mitigated SoD risks in the system,


• Possibility to generate reports online based on current data from the system,


• Possibility to set up periodic sending of reports from the system,


• Workflow integration for the circulation of access applications (workflow built into the tool or shared services for integration with other systems)

An expert level:

• Functionalities from the advanced level +


• Full management of the mitigating controls life cycle,


• Ability to document and test the effectiveness of mitigating controls from the tool level


• Possibility of automating mitigating checks (e.g. by automatic cyclical checking of indicators in the backend system and transferring to the risk management process)


• Ability to document the handling of each identified access risk and provide complete audit documentation for the actions taken


• Management reporting including the impact of access risks on individual processes, areas, or identified process risks


• Full automation of access management processes and linking of the entire workflow supported by the tool

Adjusting the level of the tool to the needs of the company or organization is an individual matter. However, the listed functionalities are, from our experience, a minimum, which indicates what class of tools we need and what we can expect from market solutions.

In conclusion, the selection of an SoD implementation tool and mitigation controls are the key points

• do not rely on the so-called universal solutions, it does not work in practice and generates redundant work,


• consider what class of tools we need and what functionalities we can use,


• automation- if there is such a possibility, let's enable the implementation of automatic mitigating controls in the tool,


• don't forget about personalization!- if our system was adapted to our processes and needs, then any tool that will analyze it should also be able to do so!

In the next, fifth part of the article, we will present a summary in which we will answer the question of why the topic of risks and access control is important and should be dealt with in an orderly manner. Why are redundant permissions dangerous and why shouldn't this problem be left for later? Why do financial audits analyze this topic in such detail? We will also select the most important points from the previous parts to present both the problem itself and the method of dealing with it in a summary. Finally, we will also look at the topic from the financial perspective and discuss what determines the cost of 'compliance' and how to reduce it. We invite you to read!

Please share feedback or thoughts in a comment section.

Read more on related topic in SAP Solutions for Governance, Risk, and Compliance Topic Page

• See our introductory post with link to other articles in this series prepared together with andrzejpartyka


• Ask questions about Governance, Risk, Compliance (GRC), and Cybersecurity and follow us


• Read other Governance, Risk, Compliance (GRC), and Cybersecurity and follow blog post


• Please follow us on and our profile for future posts fnowak and andrzejpartyka

Filip Nowak