Microsoft Dynamics Security: 10 Common SoD Mistakes and How to Avoid Them

Microsoft Dynamics Finance and Operations (D365F&O) is a powerful cloud-based Enterprise Resource Planning (ERP) system that provides organizations the ability to centralize master data and provide real-time transaction processing and reporting. As organizations begin to transition ERP to the cloud, it requires them to rethink business processes and how they are managing their company. Many times, this journey considers the finest details of the process but does not consider application security as part of its overall implementation plan.  We continue to see organizations make a number of common mistakes around key risks, in particular around Segregation of Duties (SoD). According to the Institute of Internal Auditors (IIA), a fundamental element of internal control is the segregation of certain key business functions. SoD is designed to prevent one person from having the ability to multiple business functions that, when combined, can pose a risk to the organization through fraudulent activity or error in transaction recording. I recently presented this “Microsoft Dynamics Security 101” session at an ISACA conference and want to share these ten common SoD mistakes that resonated with much of the audience.

1. Relying on Security by Obscurity – “It’s not risky if nobody knows how to do it, right?” This is a common mindset that we see across clients which can lead to more than a few issues. The best way to prevent SoD issues is by removing the access entirely. A majority of SoD violations occur unintentionally and having a strong plan in place for controlling role security at the start is a smarter strategy.
2. Trusting that Out-of-the-Box Roles are SoD Compliant – Out-of-the-box roles from Microsoft are meant to be a suggestion of how access can be split among team members. We typically recommend developing new security roles which are broken down into business tasks, then rearranging those tasks into jobs. Examples of task roles include vendor maintenance, purchase order display and journal entry posting.
3. Neglecting to Remove Old Access from Users Once They Change Job Responsibilities – Most high-conflict users are assigned many roles within the system, typically between different process or business areas. This occurs because the user aggregates new access as they change jobs within the organization. If possible, remove old access immediately, and allow for the user or new Manager to request the new access. If a transition period is required, put a timeline on the remaining access. I should add that copying access from other users can also be a dangerous practice. Instead of copying access from others, assign only the minimum amount of access required for a user’s job. It is helpful to pre-define a group of roles required for each job to make this task easy and repeatable.
4. Allowing Widespread Assignment of the System Administrator Role – The system administrator role is not built from any security objects, which means it has access to everything but does not show up in SoD reporting. The role should be restricted to the absolute fewest number of users possible. Also, if possible, lock down all system administrator access and retain one ID with sys admin in a safe location with a secure password.
5. Neglecting to Define Processes for Sustainable Security – Security governance practices are critical to controlling a secure and compliant environment. These processes will check and regulate risk on a consistent basis and reduce painful exercises at year-end. These processes could include:
   • Compliant provisioning
   • User access review
   • Role change management
   • User SoD review
   • Ruleset review
6. Relying on the Out-of-the-Box SoD Tool to Perform Reviews – The standard Microsoft Dynamics SoD tool can be great for companies just getting their feet wet in security, but has some drawbacks:
   • The basic SoD tool looks at risks at the duty level, which is not the lowest level of security. This increases the potential for both false positive and false negative risks
   • There is no standard ruleset packaged with the basic SoD tool

We often recommend our clients invest in purpose-built SoD tools, like Fastpath, which take reporting to its core and perform analysis at the securable object level. They also provide a ruleset that can be leveraged as a starting point.

7. Using a Ruleset that is Not Tailored for the Business – Standard rulesets are meant to give a general picture of what most businesses would consider being risks. But every company is different and has unique objectives and business risks. The standard ruleset will not be a true reflection of an organization’s risk until it is reviewed and updated for the organization’s specific risk tolerance.
8. Not Involving All Stakeholders When Making Security Decisions – One of the most common questions we hear in our security redesign/remediation projects is around who should own security. We have found a joint effort by IT and the business, with input from internal audit works best. The business knows what they need, IT knows how to make things happen and audit understands the risks and can provide valuable input into key controls.
9. Approaching Security Without Management Buy-In – Management buy-in is crucial to achieving compliance goals. The “tone from the top” ensures the organization understands and prioritizes security items and reinforces that all involved will be held accountable for their part of the process.
10. Waiting Until Late in the Year to Start Compliance Conversations – Governance takes time to understand, roll out and fully adopt. Start early! The earlier an organization begins the process and leverages key, repeated governance processes, the easier compliance becomes.

I like to quote the late Walt Disney: “the way to get started is to quit talking and begin doing.” Knowing the SoD pitfalls before getting started is the best way to succeed with D365F&O.

To learn more about our Microsoft consulting services, contact us.