I’ve referred to the Segregation of Duties (SOD) feature in Dynamics 365 for Finance & Operations before but haven’t really gotten into the specifics of the feature itself, what it allows you to do and the shortcomings/gaps.
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. An easy example would be that a user within an ERP should not be able to create a vendor and then pay that vendor as this could lead to fraudulent transactions. Depending on the size and risk tolerance of your organization there are many ways to avoid situations like this, you could have one user who creates the vendors and another user who pays them or in smaller departments where users have to ‘wear multiple hats’ you may have to assign risky access like this and then have some sort of transaction sampling or review to validate that the user did not perform those actions.
Here are is some more information on SOD:
https://en.wikipedia.org/wiki/Separation_of_duties
What Functionality Does D365FO Offer?
So how does D365FO address this? There is a section within the System Administration area dedicated to SOD:
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 severity (to help classify the risk posed), 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?
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 object level requires you revalidate 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.
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.
So how do you address the above gaps?
The solution we have at Fastpath is built to perform the SOD analysis for all of our integrations at the securable object level. For D365FO, this means we define our SOD rules at the menu item, table, data entity, service operation level.
This allows us to be very precise on where your SOD violations occur and remove the false positive/false negative issues you would have. Also it means that regardless of how you have your security set up within D365FO we will be able to find the SOD conflicts (whether you are assigning privileges to roles, utilizing Azure AD group security, or any other security setup scenario) . Finally we provide an out of the box ruleset (for D365FO its 115 different conflicts) to help get you started, if you want to know more feel free to reach out to me or to our contact page.
Trackbacks/Pingbacks