The Dangers of Overlooking WMS Security
It’s almost too easy. Your warehouse is filled with products—some of them potentially valuable or in high demand—just sitting on shelves until they’re picked to fulfill an order. One day, an associate finds a quiet minute to see if he’s able to insert his own “order” in the warehouse management system (WMS). Turns out, he can. Bingo. Not only that, it doesn’t appear to link the entry with his profile, so he keeps on creating false orders and simply lowering inventory levels week after week, pocketing the money from selling the stolen goods on the side. He’s even pulled in one of the truck drivers known to do a bit of moonlighting to sneak these goods out during pickups.
The sad reality is that employees with malicious intent can cost your business dearly if the right security protocols aren’t in place within your IT infrastructure. In fact, the combination of lax IT security and opportunistic employees looking to game the system is common in warehouses everywhere. The good news is that 
with the right internal security policies in place, you can prevent or greatly reduce the incidence of such events. In this post, we’re narrowing in on WMS and database security as a starting point. Together, these represent just one area where tightening security is essential. However, there are many points throughout your overall supply chain which should be addressed. This is a vast undertaking that encompasses both physical and digital elements across warehouses, trading partners, and more.
Using Role-Based Permissions for WMS Security
Preventing unauthorized access to information or functionality is certainly your goal. But the ability to identify instances of improper use as well as correct any resulting issues is also important. In the situation above, the employee never should have been able to create an order in the system. One of the first things to look at in your WMS is the types of information each role should be able to access. There’s a hierarchy of information access that directly relates to the hierarchy of roles in your operations. There may be specific reports, labels, or menu options that only those in a supervisor role should be able to access. But in the receiver role, some of these options are simply not necessary, and therefore aren’t displayed. If someone is both a shipper and a receiver, their profile in the system would indicate this, and access can be granted accordingly. Some companies such as 3PLs will assign permissions by account. In this multi-account system, only those assigned to tasks associated with particular customers will have access to in-depth information.
In addition to associating roles with the right level of permissions, there should be processes in place at key vulnerability points to prevent misuse, such as having daily inventory checks validated by multiple people. Audit trails are also important along the way so you have full visibility into the activities each associate completes and when.
In general, the thing to remember is that individual or one-off permissions can cause trouble because exceptions to the level of access normally granted to that role are often forgotten. If exceptions are needed, evaluate whether that’s a different role within the system so it can be accounted for and reviewed on a regular basis.
Database Security
Whether your business has databases on premise, in the cloud, or in a hybrid IT environment, database security is another area to evaluate for security practices. Not only can malicious insiders access the wrong information for their own gain, associates can inadvertently delete critical components or alter seemingly small bits of code with disastrous effects. (Remember how a well-intentioned Amazon Web Services employee inadvertently brought down many well-known sites in February 2017 when debugging an issue?) The only people who should have deep database access are those who are fully trained and highly knowledgeable about this realm of IT. Random associates should not be running scripts against your database.
Establish a Security Policy With Regular Reviews
WMS and database security are not a ‘set and forget’ component of your operations. You need a documented security policy for your WMS that includes regular (at least annual) review of your tactics, particularly as your business grows and changes. As those subject to Sarbanes-Oxley (SOX) compliance are aware, you are required to document and report on these types of internal controls. Regular reviews of your WMS and database security policies are also an important consideration in your continuous improvement initiatives.
Mapping out Security During Implementation
If you’re preparing for an implementati
on, it’s a great time to determine your security strategy. There are generally two directions you can take, both with pros and cons:
Option 1: Start with more open permissions during the project and tighten them after go-live once the system is stable. The benefit here is that employees can really learn the ins and outs of the new system and its capabilities as they complete training. You can likely move more quickly through setup processes with an ‘all hands on deck’ approach that otherwise may be slowed by employees’ lack of access. The challenge with this approach is that if you tighten protocols and access once the system is live, employees may feel something has been taken away from them and they aren’t trusted. By starting with looser permissions, it can be difficult to determine when you’ve reached the right level of access until you lock controls down to the point that associates start complaining they don’t have the right access to do their jobs effectively. But they may find workarounds in lieu of voicing their concerns, which can have serious ramifications on your efficiency.
Option 2: Start with tight permissions during the implementation and then open them up as it makes sense. This, of course, ensures high levels of security throughout the project but may frustrate users who need to make frequent requests for access to the locked-down functionality or information required to do their jobs. For example, they may not have the access required to run a certain inventory report but feel they need it to investigate inventory discrepancies. In this “option 2” scenario employees may not know about WMS capabilities that exist but that they don’t have access to simply because they’ve never been exposed to it. This could impede efficiency or cause bottlenecks in certain areas of your operations. Perhaps it’s useful to have a sandbox area in the WMS where you can show associates new functionality to see if they need to incorporate it. In this model it’s easier to know when you have granted the right level of access for each role because new requests stop coming in.
Next Steps
Simply put, if you don’t have the right level of security configured in your WMS and your databases, you could be putting your operations—and your bottom line—at risk. The right time to evaluate your WMS security policies is now, whether you’re planning an implementation, nearing a go-live, or have been using your technology for years. Also remember that keeping your WMS (and related software) up to date with the latest hot fixes and patches is critical to ensure the latest security threats have been addressed. Work with your WMS provider and 4SiGHT to evaluate the security protocols you have in place and whether you need to update them to address the potential for internal threats.
Learn more about our expertise in warehousing environments or contact us today.
