Moreover, he added, there's the belief that the only relevant security measure for these systems is the concept of Segregation of Duties (SoD).
Most security planning for ERP and SCM platforms focus on limiting the operator's access rights to those functions that are essential to their task. The goal is to ensure that no single user can commit acts of fraud or abuse of the system. However, while it's important, SoD only solves one part of the security equation.
It ignores the possibility that an unauthenticated person (attacker) could abuse vulnerabilities and configuration errors, issuing commands and instructions outside of the process controlled by SoD. So considering these types of challenges, it's understandable that organizations struggle with ensuring the complete security of their ERP systems, Nunez said.
When asked about recommendations, Nunez offered five things that organizations should be aware of when ERP/SCM/SAP systems:
Ask questions about the systems that handle and store core business data:
What are they? Where are they? How are they accessed, and who can access them? Make sure that every system involved in critical business is identified and categorized correctly.
Establish a vulnerability management program for ERP and SAP systems:
This program should have key metrics and report on the level of security and changes in security on a month to month basis.
Attack and vulnerability surface mapping:
The attack or vulnerability surface of the critical ERP and SAP systems should be mapped periodically. The frequency of the mapping should be in a direct relationship with the critical nature of the data the system stores or processes for the business.
Develop real-time situational awareness of the risk level of all core business systems:
Through the use of vulnerability scanners, traffic monitoring and real-time user behavior analysis the office of the CISO should be able to report on the current security posture and threats of and to their core business systems.
In order for CFOs to accurately report on risk to the organization, they should be able articulate the security posture and current state of risk as it applies to the core business systems.
Develop a security baseline and measure systems against the baseline:
Any deviation by a system below the baseline should be investigated and the cause identified. In addition, the security team should be able to identify how the security of the system was reduced, when and how long it was in an insecure state before it was detected.
"Traditionally people have employed a lot of parameter defensive technology based on the assumption the attack will come from outside the network. With the success of phishing and drive-by attacks, and the new threat of any piece of hardware-running software being a point of attack, businesses will stop worrying about where the attack will likely come from and instead focus on what in their environment is critical and could be attacked," Nunez said.
Sign up for Computerworld eNewsletters.