[In this series, we’re looking at quick fixes to improve GP security. ]
Most people involved at all in accounting understand that if a user has access to manage vendors and payments that it is pretty easy to create false vendor records and generate payments to those false vendors. In other words, it’s the fast lane to fraudville.
Only slightly more complicated are similar schemes involving customers. Payment redirection fraud can be just as dangerous and harder to detect. All this risk leads to some pretty simple advice, don’t allow users with access to manage vendors to also manage payables transactions. The same advice goes for customers.
In GP, vendor and customer access correspond to the Vendor Maintenance and Customer Maintenance windows respectively.
That’s it. The end.
If only it was that simple. It’s also possible to manipulate a vendor address and redirect a legitimate payment to a different address. In GP, as with many other systems, address records are separate from master record records to accommodate multiple addresses. Additionally, electronic payment setup (EFT/ACH) is also tied to specific vendor addresses to allow multiple options. This adds another dimension of security to addresses since we’re not just talking about redirecting a check, but electronic payments as well.
GP’s tasks reflect this connection between master records and addresses. The task Cards_0301* provide access to vendors and vendor addresses, while Cards_0201* provides access to customers and customer addresses.
The biggest issue out of the box is that these tasks belong to a large number of roles and many of those roles also provide access to vendor or customer transactions. Simply separating these tasks into roles that can be used to better manage master record access is an easy fix, but there’s one more catch.
Often, users need to access the data in vendor and customer cards. The obvious answer is to grant access to corresponding inquiry windows. These are read-only windows intended for users who only don’t need to make changes, but there is one big problem, inquiry windows don’t always include every present on an entry window. For example, the Vendor Inquiry window doesn’t show if a vendor is on hold. Nor does it include the related 1099 address. Vendor Inquiry also doesn’t provide access to accounts to review accounts associated with a vendor, nor is there a way to review email or project settings via the inquiry window.
These missing fields are often used as an excuse for granting broad access to maintenance windows. That excuse is a trap. If read only access is required for information not available on an inquiry window, find it someplace else in Dynamics GP. For example, the Vendor Navigation list can identify if a vendor is on hold. SmartLists are also a great option for showing data in a read only format. A SmartList is just as fast as an inquiry screen and provides the necessary information without exposing the organization to the unnecessary risk.
Finally, if there is simply no way to separate customer/vendor master records from transactions, consider using Dynamics GP’s Workflow features as a mitigating control. But mitigating controls are not as good a primary controls so companies should make a determined effort to separate these functions before turning to mitigation here.
You can find all of the fixes in this series at GP Easy Security Fixes.