ERP security for process manufacturers: what to bear in mind

According to TechTarget process manufacturing is defined as the “production of goods that are typically produced in bulk quantities, as opposed to discrete and countable units. Process manufacturing industries include chemicals, food and beverage, gasoline, paint and pharmaceutical.” In this context, data security associated with ERP operations becomes particularly sensitive, since any systems breach that threatens high-volume data stabilities, can quickly evolve to create problems of enormous import.

Consequently we thought we’d go through some of the more critical security levels to offer a way that operators can define where ERP security incidents occur, and respond accordingly. The sections below are ordered on the basis of an ‘outside/in” threat model in an attempt to simplify the overarching environment. As such, they do not necessarily imply a particular priority, since depending on the characteristics of a hack; any area of interest can be involved.

External network threat vector

Over the last several years most, if not all, enterprises have begun to harden or ruggedize internal security systems. However, when it comes to ERP in the process manufacturing environment, how does one protect against external network attacks?

Recommended reading: choose the best process manufacturing ERP for your company using our seven-step guide to selecting process manufacturing ERP.

Consider this; process manufacturing ERP involves active transactions ranging from plant, warehouse, distribution and third-party sales outlets, to direct-to-customer operations. Consequently, while a public network, or even a company’s VPN may be secure as an individual element, anyone who already operates within this larger camel’s tent, can provide for a handy opening from which bad things may occur.

The primary way to deal with this threat is to enact and adhere to rigid sets of extended network security policies relating to ‘insider’ authorizations, compartmentalization of database and applications servers, limitation of functional environments, and even individual record locks in some cases. However, the hard truth is that other than those kinds of protections, if you are not vigilant every day, if an individual really wants to work against your company’s network security systems, you are always going to operating on the back foot.

In the end of the day, this is the reason all enterprises should establish granular disaster/recovery plans, sweep for malware and backup databases daily, and ensure that HR immediately kills any passwords or other credentials when an employee leaves the company.

Administrative threat vector

As mentioned above, process manufacturing ERP authorizations are critical to a stable security environment. However there are other administrative elements that should be considered as well.

To wit:

Policy and administration: Security folks within the ERP cadre should establish and explain specific and clearly stated security plans; then propagate those doctrines enterprise-wide.

Examples here include: Overarching systems access policy, specific security rules by department.

FTE authentication: As a practical matter the majority of hacks occur after breaching a system due to lax password discipline. Consequently, both enterprise security and HR cadres should work together to ensure that all FTEs are constantly accounted for at a systems level; then manage their daily operations accordingly.

Examples here include: user identification and access rules, departmental caveats and limitations.

Compartmentalization of operations: all system tasking should be classified on the basis of a ‘sole purpose’. For example, it is rare that accounting needs to go to inventory to execute a financial operation. Consequently, these task participants should be rigidly separated within the enterprise environment.

On the other hand, in this case that there is a legitimate reason to collaborate at the departmental level, proper rationales should be provided formally.

Examples here include: general/Specific Department collaboration forms, Descriptions relating to tracking and rules constraints, discrete data record maps

Schedule limitations: Depending on the configuration of the particular enterprise some transaction elements should only be active at certain times. For example, if your enterprise transacts business in Asia/the Pacific, but your headquarters operation is located in the midwest, a logical security decision would be to allow only specific enterprise operators to communicate across its larger network, and only during particular times.

Examples here include: published access schedules, this primarily associate’s itself with multi-continent operations.

Active tracking: All log activities should be tracked in real-time, and activity schedules monitored. For example, if a user is logged into the enterprise system, and that individual leaves his/her workstation to attend a meeting, the system should timeout and terminate the log call. Granted this characteristic may be a pain in the rump from time to time, but the alternative is to leave the network open to attack due to inattention, with the result being lost information, time, cost or worse.

Examples here include: Descriptions of how user tracking works, User implementation guidelines, Necessary policies associated with privacy and affiliated operational limitations etc.