The Four Myths of ERP Security
There are several myths in ERP security. One of the most common is that security is largely a matter of controlling access and segregation of duties. Another is that business applications are accessible only within internal networks. Yet another is that such applications are not a target for attack. All three are based on a simplistic and misguided take on today’s ERP systems.
The reality is that contemporary ERP systems have a highly complex structure. Complexity is the enemy of security. Vulnerabilities can be found not only in the business or application layer (which is the traditional area of focus for ERP security practitioners) but the technical layer that includes database, operating system and network components. A Fort Knox approach for the application level will provide a false sense of security if architectural, configuration and programming flaws are not addressed at the technical level.
This is compounded by the fact that most ERP instances have more than one attack surface. Almost all have direct or indirect connections to the Internet. The former includes connections to external offices, suppliers, vendors or other partners and to SAP services. The latter can include connections to user workstations with Web access. ERP resources are increasingly designed to be accessible by mobile users using Web-based protocols, ports and services. The isolated mainframes of yesteryear are a distant memory in our era of global communications.
Vectors for attack surfaces in ERP systems are generally well-known. What’s more, most can be performed with low-spec laptops and minimal technical knowledge. The idea that very few people have any motive to attack such information-rich systems is one of the most disturbing and perplexing myths in ERP security. I’m reminded of a comment that was made to me by a prominent partner in a well-known consulting firm. The partner was engaged as a security advisor by a large meat processing company during an otherwise successful SAP implementation. In his view, the client had a relatively low risk profile which justified a ‘vanilla’ security framework for its SAP systems. As a result, the company was urged to stick with SAP defaults, wherever possible.
The leads to the fourth and most damaging myth in ERP security: the notion that systems are securely configured by default and, where they are not, it’s the responsibility of the vendor to secure the system. ERP systems are designed to be flexible. They have to be capable of meeting the diverse needs of every imaginable business in all industries and sectors. As a result, there is no standard configuration that can meet the requirements of every business. Security has to be enabled. Default security settings are often highly dangerous and can leave organizations open to internal and external attacks. For this reason, SAP has issued numerous white papers, security guides and other publications to support the secure configuration of its software during and after implementation. This should be required reading for all security professionals specializing in SAP.
SAP does not take responsibility for security issues arising from architectural flaws, misconfigurations and inadequate patching. Customers are expected to design, manage and maintain their systems in a secure manner. This can prove to be a challenge in companies where there is no clear ownership over SAP resources or in cases where systems are owned by business departments that lack the technical skills to effectively manage ERP security. In these scenarios, business owners should take steps to share ownership with IT functions, especially technical resources within their organization that are more accustomed to dealing with infrastructure or platform-level security. There is often a strong relationship between the strength of SAP security in organizations and the degree of partnership between business and IT.