Security Considerations for ERP Applications

Did you know?

• eBay suffered a serious security breach in 2014 that led all 145m customers to change passwords to secure their accounts.
• According to research performed by the Ponemon Institute, the average cost for a breach of sensitive data in 2018 is US$148 per record.
• The UK’s Information Commissioner Office (ICO), responsible for policing data protection in the UK, fines companies around £2m annually for failing to protect personal data.
• Regulation directives such as the General Data Protection Regulation (GDPR, enforcement beginning May 2018), mandate organizations to comply with security practises that ensure that any personal data for all individuals within the European Union collected is adequately protected.

Information security breaches, including non-compliance to regulatory standards, can yield financial and reputational consequences that are better avoided by any organization, large or small. Information security has become an increasing concern for organisations resulting in growing security budgets intended to tighten processes and also to conform to new and changing security regulations. An organization’s security strategy is generally aimed at managing the risk of security breaches and staying compliant with regulatory standards. Operational procedures and business applications that support them need to be strategically managed and controlled to ensure the integrity, availability, and security of sensitive data that the organization owns.

A key aspect of any security strategy is the ability to achieve a level of security that appropriately demonstrates an organisation’s commitment to information security regulations and the safety of the data collected from its trading partners. Too little security increases the risk of breaches while too much security can result in unnecessary IT overheads, compromised system performance, and loss of agility in business processes. There is no ‘cure-all’ security solution; each organization needs to evaluate its risks and set objectives that are relevant for their environment and the type of information it handles.

This article is inspired by experience and lessons learnt as a solution designer extending an enterprise application to meet custom business requirements that are not met by the standard implementation. The primary focus of this article is the extension of security objectives to the maintenance of business applications. While this specific experience is on Oracle E-Business Suite, the core principles and lessons learnt are fundamentally applicable to a wide range of commercial application environments that process and manage sensitive data. The article seeks to emphasize the importance of enterprise resource planning systems to the operational efficiency of organisations, how the maintenance and usage of these systems increase data security risk, and what can be done from a development and maintenance perspective to mitigate this risk.

Without some form of computer automation, most businesses would not be able to achieve operational efficiency. Regardless of the size of an organization, operational complexities are a reality, and the need for accurate record keeping, resource allocations, analysis, planning, and reporting is necessary. Enterprise Resource Planning (ERP) systems have evolved over the years to meet these operational requirements efficiently.

An enterprise resource planning system integrates business processes and data from all the core business functions such as sales order processing, purchasing, financial management, and payroll. It allows for different operational functions to share common data and processes. For example, Oracle E-Business Suite uses a data model known as Trading Community Architecture (TCA) that provides a single, universal definition of trading partners’ data for all business functions. TCA enables the creation and maintenance of a single record of trading partners’ information to be utilised by any of the business operations. For instance, there can only be a single trading partner record created in the system that can be qualified to be used as a customer, a supplier or any required business entity and is available across all functions. This promotes data efficiency and integrity by having a centralised source of true information.

ERP applications are typically designed as large, complex, homogeneous mission-critical systems and are generally developed and marketed as commercial off-the-shelf software by large software vendors such as SAP, Oracle, and Microsoft. The development of ERP applications is theoretically based on industry best practices, and they are intended to meet broad business requirements covering a wide range of industries. For an ERP application such as Oracle E-Business Suite, the security architecture is presented as its cornerstone, established over time and can be configured to meet specific regional or organizational requirements.

The functionality provided by Commercial ERP systems is designed to be highly configurable to allow customers to incorporate their own business rules to match specific business or industrial requirements. However, even after the configuration is completed as intended, gaps often remain between standard delivered features and specific organization requirements. In an effort to improve user acceptance, most ERP customers end up developing extensions and customizations to make sure application better supports business processes.

Because ERP systems process and hold sensitive personal and commercial information relating to employees, customers, suppliers, prospects and projects, further developments outside of the original blueprint expose the application to increased risk of data security breaches and non-compliance to regulations. Custom developments generally make up a very small portion of the whole application but, because they access and process the same sensitive data as the main application, they pose a significant security risk that could potentially cost the organization in security breach damages. ERP system vendors, while they recommend best practice standards to be followed, generally do not support custom developments. It is, therefore, a customer’s responsibility to make sure that an organisation’s security objectives are enforced and effectively embedded in the development strategy for these extensions.

The extension and customization of ERP applications is a specialised technical effort that requires, over and above the necessary development skills, a good understanding of the architectural, functional, and security model of the application, including the vendor suggested best practice for product extension. Application development approaches used for ERP extensions need to ensure that the original application’s data security model is maintained and automatically enforced in all the possible states of data within the application. Otherwise, the cornerstone feature of the application becomes severely compromised. Development standards and practices should also meet security objectives defined in the organisation’s strategy and should aim to protect any sensitive data with the same attitude that is required of all business process. This calls for application developers to thoroughly understand the organization’s security strategy and how the application’s security model can be extended to custom developments.

Information security can only be adequately addressed in development if the security requirements for every solution to be implemented are explicitly identified and fulfilled at every stage of the development cycle; i.e., specific security requirements that are addressed in requirements analysis, design specification, and solution implementation. This facilitates validation and verification for conformance to security strategy. With this understanding, the following are some of the key security aspects for enterprise developers to consider when extending ERP applications.

Access Control

Access control in ERP applications is concerned with defining and managing authorized users, including granting them the relevant roles they need to access processes and data. Access control is critical to the goal of protecting data from unauthorized disclosure and modification, at the same time, maintaining appropriate levels of availability to authorized users for operational purposes.

Oracle E-Business Suite embeds the principle of least privilege in its security model. This principle is based on the practice of granting necessary privileges only – application users should not be given more privileges than necessary. This is implemented through a feature known as Role Based Access Control (RBAC). RBAC enables organizations to create roles based on specific job functions, and to assign these roles the appropriate permissions. User access is determined by assigning individual users the appropriate roles.

It is important for developers to understand how to extend the application’s security model to all custom developments in a similar way to standard functionality. Where parts of the security model are configurative, custom extensions should also similarly use the configured security features. Custom developments must be registered to the application in a manner that enables them to be appropriately assigned to the relevant users using role-based access control. This way their access is controlled, and they are only made available to users that need them for their specific job roles.

The level of data access accorded to custom processes should be relevant for intended purposes. For instance, a custom process to extract enterprise data should be given read-only access to specific database objects. A specific database user should be defined for such a process, which would be granted specific access to enforce the rule of not giving users more information than is required.

Custom processes such as interfaces or integrations that have back end access to the ERP application should have controlled access to enterprise data, giving them the right level of access to specific data. Each process needs to be associated with a user account that is granted access only to the functions and data necessary to meet the process requirements. Appropriate read and or write privileges should be defined for each interface according to its requirements. Data extracted out of the enterprise system should be nothing more than is required by the receiving system.

Access control for enterprise applications is best achieved by leveraging on existing models and technology. Software vendors employ security specialists to define, refine and rigorously validate security frameworks that meet industry standards and regulatory requirements. Commercial ERP platforms are also developed to incorporate the latest security technology, protocols, and algorithms. The custom solutions for extensions should be designed to fully utilise the established development framework. This not only provides consistency in the way security is applied across the system, but also enables a seamless environment that would be easier to manage and maintain when upgrades are delivered.

When implementing extensions, application developers need to analyse their usage and the data access that the process requires. Access to extensions should only be granted to users that are authorised to run the functionality, and this is achieved by making the new function available only to the necessary roles. Data access is controlled by associating the process with a database user that is granted only the read or write access to specific data objects as required by the process. Without this level of access control, the security of enterprise data would be at risk from both internal and external users who have the authority to log into the system.

Database Level Security

At the core of an ERP system is a relational database management system (RDBMS) that manages the data input/output and storage on the database server. The ability to logically customize data objects for a variety of users is key for any enterprise application and is fundamental to the security architecture for managing access to data. Different database platforms offer tools to create logical data objects that enable different users to view and handle common business objects in different ways.

Oracle meets this requirement with its Virtual Private Database (VPD) table feature. VPD is a concept that enables data restriction in large databases so that only a subset of the data appears to exist, without physically segregating the data into different data objects. It refers to the use of row-level security (RLS) and the use of application contexts. VPD’s row-level security allows access restriction by attaching a function that defines access rules to a table, view, or synonym. The function is known as the security policy, and it returns a predicate as an SQL filter. When a query is issued against the protected object, Oracle dynamically appends the predicate returned from the function to the original SQL statement, thereby filtering the data records by the values generated by the security policy.

A typical VPD implementation is where there is a requirement to restrict sites, departments or individuals to operate only on their own records. Ordinarily, multi-organizational enterprises would need to have multiple database instances, one for each entity or, at the very least, multiple schemas in order to maintain data security. The effort and cost to implement and maintain that would be mammoth. However, with Oracle VPD, one database does the job, and the security is proven. VPD enables different users to access the same table in a single schema yet each user gets a different view of the available data, that is, each one will see only what is appropriate for that user to see. This security feature has been proven to be airtight, given that the security policy is accurately implemented, it is logically invoked by the application, and the data is accessed securely.

To effectively implement VPD tables, the concept should be implemented from design. It requires an appropriate table structure with distinct partitioning (or labelling) column(s), proper configuration of user accounts, and implementing the security policy via a SQL function. Routines that populate the protected tables must be designed to enforce NOT NULL constraints on the partitioning columns and to validate the values in these columns as they are key to policy implementation. All routines that access data from these tables should always reference the appropriate object where the security policy is applied. In most cases, the security policy is applied to a view or a synonym for that table, and this has to be determined during design to assign object privileges appropriately

VPD is an Oracle database feature that can be utilised to implement data security at the database level. Custom tables handling sensitive data that needs to be securely accessed must be defined following the rules for virtual private databases. This enables the data to be logically partitioned and for security policies to be defined and applied for secure access. There are standard security policies delivered with Oracle E-Business Suite that can be extended to custom development. Application developers need to understand how this hangs together with user profiles in order to appropriately use it in custom developments. Application development standards should explicitly embed these security development rules so that they can be checked in quality reviews.

Data Encryption/Data Masking

In addition to controlling functional and data access, ERP data can be encrypted to reduce exposure risks. Encryption is an essential tool for securing sensitive information, more commonly used for in-transit data, to ensure the confidentiality and integrity of data are not compromised. For static data, data encryption is not necessary for all security scenarios, but for sensitive personal data such as credit card numbers or passwords, it is an essential tool.

The encryption process uses mathematical algorithms to change information into incomprehensible characters thus providing a fundamental form of defence on the data itself. This means that even in the event of an access control breach, compromised data is still only intelligible to authorized users who possess the right encryption keys.

Databases can be made quite secure, with proper configuration, but they can also be vulnerable to host break-ins if the host is compromised. In well-publicized break-ins, hackers have managed to obtain a large list of credit card numbers, or customer passwords, by breaking into a database. But if the data is encrypted, the stolen information would be useless. The encryption of stored data is, therefore, an important tool in limiting information loss even in the normally rare cases that access controls are bypassed.

Data masking is a technique that is used to protect further data where encryption is not necessary. This allows sensitive information to be transposed in a manner that will not hinder ordinary database operations, such as maintaining referential integrity and data type constraints. Data values are changed yet conform to schema requirements, allowing database extracts that ordinarily contain sensitive data to be used for development and testing purposes. Data masking can be done by scripting, but tools are also available such as Redgate’s Data Masker for Oracle.

Developers need to understand organizational policy concerning the handling of personal data and apply the necessary security tools appropriately. With the rise of e-commerce, if custom developments handle sensitive financial information such as credit card numbers, this ought to be handled with the utmost care. Sensitive information such as credit card numbers or account passwords should always be encrypted even in storage. Data masking should be used for development and testing environments to protect personal or commercial data from illegal disclosure and yet giving developers a more realistic domain on which to work. Business sensitive or personal data should also be encrypted when transporting across networks.

Conclusion

Data Security is becoming increasingly critical for organizations as the consequences of a security breach are becoming more and more significant. Hackers are getting more sophisticated, protection laws are getting tighter, and penalties are on the increase. ERP systems lie at the core of business processes, and they process and maintain most of the business data that is considered to be sensitive. ERP vendors play their part by investing in platforms and technologies that secure the data so much that the security model is often presented as the cornerstone of the application, but as long the application is extensible, any custom developments pose a risk of breaching security rules. It is important that the organisation’s security strategy is well understood by all personnel especially those who develop and maintain applications handling sensitive data. Security requirements for all developments need to be explicitly defined and specifically considered in the solution design and test strategy. There are many security tools available, but for commercial ERP systems, there is no need to re-invent the wheel. The security implementation that comes with the application should be extended as much as possible to all custom developments. Proper analysis of each requirement is also essential to determine the right level and tool to meet security requirements appropriately.

References:

https://www.esecurityplanet.com/network-security/ebay-data-breach-exposes-145-million-user-records.html – Ebay Data Breach

https://www.ibm.com/security/data-breach – Ponemone Institute Report

https://www.gov.uk/government/publications/data-protection-act-2018-overview – Data Protection Act

Oracle eBusiness Suite Security Guide – Part Number E22952-22

Oracle Database Security Guide 12c Release – Part Number E48135-19

The post Security Considerations for ERP Applications appeared first on Simple Talk.

from Simple Talk https://ift.tt/2CPUIkQ
via