Let’s face it, when it comes to setting up security in AX, especially after an upgrade or an implementation, the process is usually a mess. Most of the time, setting up security is built into the timeline, but it’s always towards the end because it relies on other items to be completed first. Inevitably, security gets pushed back because other items take precedence. In short, security doesn’t get any respect. Here are five things that you’re doing wrong with AX security and some suggestions to fix them:
1. Building first then designing
Everyone gets this backward. It’s important to really think through your security first. When you build a house you don’t build it and then hire an architect. That’s not a house, it’s a shed, and one your spouse keeps wanting to tear down. Instead an architect designs a blueprint and then builders execute that vision. It should be the same with your security and permissions. It makes sense to sit down and identify the appropriate roles in your organization and then work through what duties and privileges are needed for each role. Once there is a clear vision of what the organization needs then it’s much easier to build security that won’t fall down later.
2. Giving people more
More is not always better. More pain, not better. More roaches in your house, not better. More security permission, usually not better either. Too often we hear of companies who have gone live with everyone set up as System Administrators. Frequently this is due to companies not adhering to our first point, building roles without designing in security. It’s too easy to over grant permissions with a go-live deadline looming. Having System Admins with full access to the system and development environment is very dangerous. In the wrong hands it is a huge risk for any organization. It sounds simple, but limit the amount of System Admins in your environment and review access on a regular basis.
3. Believing everything you read
When reviewing security in your environment don’t always believe what you read. The title of a duty or privilege may not adequately describe the actual permissions being granted. An item named “Read Bank Statements” sounds innocuous until you realize that the actual duty or privilege gives full control. Always verify exactly what a role, duty or privilege truly has access to do.
4. Providing generic and obtuse security names
As you build the roles for your organization make sure that they are named something that users can recognize. Try to use names and descriptions that make it easy for the reviewer to understand what the user has access to. If possible, identify the highest privilege. For example, a role named Accounts Payable Clerk is more recognizable by an accounting manager reviewing permissions than something like P&P-Q/O/I/R/C. Likewise a role named Read Only with Posting indicates that there is a higher risk privilege hiding in this role.
5. Ignoring who is changing data
Do you know who is changing your data? If you don’t know who is changing information for things like vendors, customers, and accounts, there is a significant risk that company resources could be used for personal gain. Make sure to identify some key areas to track changes in. Vendor and Customer data are two areas that auditors will recommend that you track and review on a regular basis.
It’s time to flip these items around and start doing the opposite. Security is one of those things that you can fix before it becomes a crisis, or you can fix it when it becomes a crisis, but you will eventually fix it. Fixing it in a crisis is very painful, so save yourself some pain and quit doing these five things. Do the opposite and get Dynamics AX security under control.
Learn how with our eBook "Develop and Implement Least Privilege Security in Dynamics AX".