Photo designed by FreePik

I’ve written in the past about the segregation of duties area of Dynamics 365 for Finance & Operations (D365FO) but wanted to revisit this as part of the ongoing ‘security myths’ series. The ‘myth’ in this case is that segregation of duties (SOD) can be done at the ‘duty’ level within D365FO and does not need to be done at a securable object level.

Let’s take a look at what segregation of duties is, what native solution is available within D365FO, and the potential gaps that exist if a segregation of duties analysis is not done at the securable object level.

What is Segregation of Duties?

The idea of Segregation of Duties (aka Separation of Duties) is that a single user should not be able to perform certain actions in a financial system by themselves without any oversight. Normally a segregation of duty rule includes two or more actions that a user can perform. A majority of these types of risks include one of the following scenarios:

• The ability to perform an action on a master data object and also perform a transaction against the master data object
• The ability to modify a parameter or configuration area of a module and also perform a transaction with the same model of the system

An easy example of the first scenario would be that a user within an ERP should not be able to create a vendor and then pay that vendor (eg: a user could make a fictitious vendor with a family member’s bank account information and then pay that vendor). An example of the second scenario would be if you had the ability to make modifications to the Accounts Payable area of your system and also had the ability to make an AP transaction of some kind which would allow you to modify how the payments are processed (eg: a user could change an AP configuration rule which would result in payments being made erroneously).

What Functionality Does D365FO Offer?

There is a section within the System Administration area dedicated to Segregation of Duties:

Let’s go through the different sections of this area.

Segregation of Duties Rules

The first thing you have to do is set up the rules you are going to use to determine what is an SOD violation, this is done in the Segregation of Duties Rules page. The methodology D365FO uses to determine SOD is done at the duty level within the role -> duty -> privilege hierarchy, so you determine two duties you do not want one user to be assigned in my case it is ‘Maintain Vendor Master’ and ‘Maintain Vendor Payments’. You can also set a risk severity (to help classify the risk) and there is a text field for both stating the security risk and a possible mitigation or resolution to a user having this assignment.

Verify Compliance of User-Role Assignments

Once you have your SOD rules set up, you next want to check what current conflicts exist for your users, this can be done by running the ‘verify compliance of user-role assignments’ background process. When this is executed you will receive a notification with the user role assignments that are in violation based on your SOD rules.

Segregation of Duties Conflicts / Segregation of Duties Unresolved Conflicts

The  ‘Segregation of Duties Conflicts’ and the ‘Segregation of Duties Unresolved Conflicts’ forms provide similar views of current SOD conflicts but the unresolved page obviously will just show the SOD conflicts you have not provided any resolution for while the normal conflicts page will show all user SOD conflicts.

In our test case two different users actually had both duties assigned to them and therefore had our conflict. In the grid it shows the two role assignments that are causing the risk and gives the ability to either allow or deny the assignment in the menu bar.

If you allow the assignment you must provide a ‘reason for override’:

If you deny the assignment you will be prompted on which role you would like to remove from the user to remove the SOD violation:

What Gaps/Shortcomings Exist in Native D365FO functionality?

There are a couple gaps with the functionality above that may be an issue for your organization depending on your audit / compliance requirements.

1) There is no out of the box SOD ruleset – you may have noticed that when I went to create my SOD conflict that there were no other conflicts listed there. That is because Microsoft does not provide any out of the box conflicts so you have to build your ruleset from the ground up.

2) User SOD conflict analysis done at the duty level which can provide false positive and false negative results – because the SOD analysis is done only at the duty level there are scenarios where a user may actually be assigned access but is not picked up by this analysis and conversely there may be instances where a user does not have access and they trigger an SOD violation.

Let’s take a look at two examples of this happening.

Let’s say I have a role and assign every privilege in the system to it (therefore bypassing any direct duty assignment), this would give a user extremely high rights to the system and should basically trigger every SOD but when I perform this setup no SOD violations are reported. This is because the solution does not look at the access being assigned but only looks for a combination of duties being assigned.

Let’s first create a role (FpAllPrivileges) and assign every privilege in the system to it:

Then assign it to a user (in our case the ALICIA user):

Now if we rerun the SOD analysis we can see that the only user showing is still the SARA user from the previous example. So the ALICIA user has basically full rights to a majority of the system but is not picked up by the the SOD analysis.

Also the reverse can happen, let’s say I go in and remove all access from the duties I have specified in my SOD rule (therefore effectively meaning there is no access being assigned). When I run the SOD analysis again these users are marked as having this SOD violation. This is again because the Microsoft methodology does not look at the access being assigned but only looks for a combination of duties being assigned.

First we modify the ‘Maintain vendor master’ and ‘Maintain vendor payments’ duties to no longer have any privilege assignments:

Next rerun the SOD analysis and the SARA user is still listed even though the duty assignments provide no additional security (and therefore risk) to the user.

3) The above scenarios also point out another issue, once you set up your SOD rules any change to security at a privilege or securable object level requires you re-validate your SOD rules to ensure they are still an SOD conflict. This is a very time consuming process if you change security on any sort of frequent basis or do not have stringent controls around who is making changes to your security.

4) If you are using Azure AD groups to set up your security in D365FO, the SOD functionality will not work as the users themselves are not assigned the access and instead inherit their access from the Azure AD group they are a part of.

What Does It All Mean?

With all that said you may wonder what this means for you, and you may have some follow up questions like:

Why doesn’t Microsoft analyze segregation of duties at the securable object level?

While I have no knowledge of the internal decision at Microsoft on why this choice was made, I think I can speak as someone who has actually written the logic to do this analysis at the object level that the primary decision was probably in part because of the complexity it adds to your analysis. It is levels of magnitude tougher to do this analysis at the object level than it is to do it at the entitlement or other security layer levels.

Does my organization need to analyze risks at the securable object level or can I utilize the native solution from D365FO and analyze my risks at the duty level?

This question is harder to answer as each organizations needs are going to be different however it really comes down to the ‘risk appetite’ of your organization and their audit requirements.

If you are a private entity and do not have any audit requirements you may be able to utilize the out of box solution from Microsoft. If you go this route I would highly recommend placing stringent controls in place around changes to security, as demonstrated above, changes to security can have far reaching impacts on your risk analysis.

If however you are a publicly traded company, have a parent company that is publicly traded, or are in a highly regulated industry (food, healthcare, government, etc) then you may need to look at doing your analysis at the object level as the risk potential of using out of the box functionality is too great.

Does the new ‘Security Governance’ features from Microsoft change the way that segregation of duties analysis are performed within D365FO?

While the new ‘Security Governance’ features from Microsoft add a lot of new functionality in the security space (watch for a new blog post on that shortly!) it does not change the methodology used by D365FO to analyze SOD risks.

How to Perform an Object Level Segregation of Duties Analysis

If you fall into the category of needing to do a thorough SOD analysis at the securable object level, you may wonder what options you have to accomplish this if you can’t use native functionality within D365FO.

If you would like to do this process manually, here are the high level steps you would need to perform:

1) Identify the business processes that introduce risk into your environment and the securable objects that are associated with those processes – this can be done via task recordings or using the right click -> ‘Form Information’ menu option on a particular form.

2) Group the securable objects required to perform a business process and create your SOD risk matrix using those business processes (eg: a user should not be able to perform process A and process B).

3) Gather all role access down to the object level – this can be done via the ‘View Permissions’ report within the Security Configuration area.

4) Gather a user -> role association – this can be done via the User Role Assignments report.

5) Create a user -> object access matrix by combining the role access for all roles assigned to each user (a user’s access is the aggregate of all role access assigned to the user).

6) Run your user access against your risk matrix and analyze where risks are found based on a user having access to perform both sides of a risk.

If the above process seems arduous and you would like to look at alternative options, there are ISV solutions available (I currently help lead development at Fastpath (now part of Delinea) which has a solution that performs this object level analysis for 25+ out of the box integrations) as well as audit partners that are available to help with this as well depending on your requirements.

Please reach out if you would like more information on this!

Conclusion

I hope this blog posts helps to ensure that you understand what segregation of duties is, what options are available to perform an analysis, and what scenarios to look out for to determine which SOD analysis methodology is right for your organization.

As always, feel free to reach out with any questions!