by
MANFRED PAUL HERTENBERGER THESIS
submitted in the fulfillment of the requirements for the degree
PHILOSOPHIAE DOCTOR in COMPUTER SCIENCE in the FACULTY OF SCIENCE at the UNIVERSITY OF JOHANNESBURG
SUPERVISOR: PROF. S.H. VON SOLMS AUGUST 2005
SAP, R/3 and other SAP products are trademarks of SAP AG.
ORACLE®, Oracle E-Business Suite® and Oracle Applications® are registered trademark of ORACLE Corporation.
Microsoft®, Windows®, Navision®, NT® and SQL Server® are registered trademarks of Microsoft Corporation.
All other product names mentioned in this thesis may be trademarks or registered trademarks of their respective companies.
SUMMARY
This thesis addresses the topic of security within Enterprise Resource Planning (ERP) software systems. Specific attention is given to the development of a reference framework that may be used to enhance the security subsystem of future ERP software packages. Due to the complexities involved, it is impractical to retrofit existing ERP software packages to cater for the requirements of the reference framework developed in this study.
Existing software packages to control business processes are widely accepted and have become the central data repository for most information relating to an enterprise. Each of these systems provides a method by which data may be protected. Access to information may be restricted to authorized users only. To protect the business, access to critical resources must be limited to authorized and authenticated users only.
The aim of this study is to investigate existing ERP systems regarding the implementation of the security subsystems employed by them. The deliverable of the study is to provide a clear and concise model to provide organizations with a better understanding of the method used to implement security within their chosen software package. Such an implementation should enable the organization to be aware of problem areas and to be able to address them confidently. Where organizations are unsure as to how security measures are implemented within their selected product, the model proposed by this study should enable such organizations to gain a better understanding of how security could and should be implemented to best effect.
With the completion of an analysis of three existing ERP software products, a number of shortcomings are identified. These shortcomings identify issues that hamper security in real-world ERP system implementations. Having identified the shortcomings, these are investigated in more detail and are used to create a reference framework for ERP security. This reference framework for ERP security is given the name ERPSEC. The ERPSEC framework addresses the exposures identified and proposes solutions to ensure that the security within ERP systems is maintained with increased integrity and consistency. The overall goal of the ERPSEC reference framework is to provide a platform on which future ERP system architectures may be based.
KEY WORDS Database security
Authentication
Enterprise Resource Planning Fraud detection
TABLE OF CONTENTS
CHAPTER 1: INTRODUCTION 1
1.1. Introduction 1
1.2. Definitions and terminology 1
1.3. Background 1
1.4. Abstract 2
1.5. Problem statement 3
1.6. Objectives of the study 4
1.7. Approach of the study 5
1.8. Study overview 6
CHAPTER 2: INTRODUCTION TO ERP 8
2.1. Introduction 8
2.2. Defining the term Enterprise Resource Planning 8
2.3. A brief history of ERP 8
2.4. Architecture of an ERP system 9
2.5. Advantages of ERP systems 11
2.6. Security in ERP systems 11
2.7. Conclusion 12
CHAPTER 3: SECURITY IN ERP SYSTEMS 13
3.1. Introduction 13
3.2. Problems with ERP security 13
3.3. Information ownership support 13 3.4. Information areas and information owners 14
3.5. Conclusion 15
CHAPTER 4: PRODUCT REVIEW – SAP R/3 16
4.1. Introduction 16
4.1.1. Scope of review 16
4.1.2. Product overview 16
4.1.3. SAP R/3 architecture 16
4.1.4. The SAP authorization model 17
4.2. Authorization checks 17
4.3. Activities within the SAP authorization concept 18 4.4. The SAP authorization check 19
4.5. Authorizations 20
4.6. Profiles 21
4.7. User master records 22
4.8. Implementing the authorization check 22 4.9. Relationships in the SAP authorization model 24
4.10. Creating authorizations 25
4.11. Moving to a role-based approach 30 4.11.1. Weaknesses of the SAP authorization model 32
4.12. Implementation 32
4.13. Securing non-standard SAP objects 33 4.14. The AUTHORITY_CHECK routine 34 4.15. Activity groups in the SAP system 34 4.16. Deficiencies and shortcomings 35
4.17. Conclusion 36 CHAPTER 5: PRODUCT REVIEW – ORACLE E-BUSINESS SUITE 37
5.1. Introduction 37
5.1.1. Scope of review 37
5.2. Product overview 37
5.3. Oracle E-Business Suite architecture 37 5.4. The Oracle E-Business Suite security system 38
5.5. Authentication 38
5.6. Application users 39
5.7. Responsibilities 40
5.8. Request security groups 42
5.9. Function security 44
5.10. User master records 46
5.11. Relationships in the Oracle E-Business Suite security system
48
5.12. The role-based approach 49
5.13. Weaknesses of Oracle E-Business Suite security 49
5.13.1. Implementation 49
5.13.2. Securing non-standard objects 50
5.13.3. Responsibilities 51
5.13.4. Request security groups 51 5.14. Deficiencies and shortcomings 52
5.15. Conclusion 53
CHAPTER 6: PRODUCT REVIEW – MICROSOFT NAVISION ATTAIN 54
6.1. Introduction 54
6.2. Scope of review 54
6.3. Product overview 54
6.4. Navision Attain architecture 54 6.5. The Navision Attain security system 55
6.5.1. Authentication 55
6.5.2. Activation of the security system 56
6.5.3. The super user 57
6.5.4. Ordinary system users 57
6.5.5. Roles and permissions 58
6.5.6. Security filters 61
6.6. Checking permissions 62
6.7. User master records 62
6.8. Relationships in the Navision Attain security system 63
6.9. The role-based approach 64
6.10. Weaknesses of the Navision Attain security system 64
6.10.1. Implementation 64
6.10.2. Securing non-standard objects 65 6.10.3. Roles and permissions 65
6.10.4. Indirect permissions 65
6.10.5. Password management 66
6.11. Deficiencies and shortcomings 66
CHAPTER 7: COMMON ERP SECURITY PROBLEMS AND THEIR PROPOSED SOLUTION
69
7.1. Introduction 69
7.2. ERP software for universal use 69 7.3. Variances and their implications on security 69 7.4. ERP software implementation 70 7.5. Centralized versus decentralized approaches 71 7.5.1. The centralized approach to security 71
7.5.2. Information ownership 73
7.5.3. Segregation of duties 75
7.5.4. Risk management 76
7.5.5. Integration across modules and systems 77 7.5.6. Corporate governance issues 78 7.5.7. Lack of an implementation methodology 79 7.5.8. Focus on technical implementation 80 7.5.9. Documenting the security configuration 81
7.6. Conclusion 83
CHAPTER 8: REQUIREMENTS OF A REFERENCE FRAMEWORK 84
8.1. Introduction 84
8.2. ERP security issues 84
8.3. Reviewing product-specific ERP security shortcomings 84 8.3.1. Securing custom-developed objects 85 8.3.2. Security check routines 85 8.3.3. Lack of true role-based security 85 8.3.4. Standard roles are not always effective 86 8.3.5. User access to reports and program execution 86 8.3.6. User master record management 86 8.4. Reviewing generic ERP security shortcomings 87 8.4.1. Centralized approach to security implementation 87
8.4.2. Information ownership 88
8.4.3. Segregation of duties 88
8.4.4. Support for integration across modules 88
8.4.5. Corporate governance 89
8.4.6. Lack of an implementation methodology 89 8.4.7. Focus on technical implementation aspects 89
8.4.8. Documentation support 90
8.4.9. Change management for security objects 90 8.5. The need for a reference framework for ERP security 90
8.6. Conclusion 91
CHAPTER 9: INTRODUCING ERPSEC 92
9.1. Introduction 92
9.2. The purpose of the ERPSEC framework 92 9.3. The role of the ERPSEC framework 92
9.4. Information ownership 93
9.5. Information areas 93
9.6. Conclusion 94
10.1. Introduction 95
10.2. Diagrammatic conventions 95
10.3. The development of ERPSEC 96
10.4. Structure of the framework components 97
10.5. Requirements of ERPSEC 98
10.6. The ERPSEC framework 99
10.6.1. An approach using open source principles 99
10.6.2. Information areas 100
10.6.3. Information owners 102
10.6.4. Ordinary ERP users 106
10.6.5. System and security administrators 107 10.6.6. ERP system functionality 110
10.6.7. Executing programs 112
10.6.8. Role definition 114
10.6.9. Change management support 121 10.6.10. Change request initiation 125 10.7. Summary of ERPSEC components 132 10.7.1. ERPSEC repository structure definitions 132 10.7.2. ERPSEC data type definitions 133 10.7.3. ERPSEC object definitions 133 10.8. The reference framework and identified requirements 134 10.8.1. Securing custom-developed objects 134 10.8.2. Adaptable security check software routines 135 10.8.3. Implement true role-based security 135 10.8.4. Creating roles effectively 135 10.8.5. Restricting user access to reports and program execution
136 10.8.6. Effective user master management 136 10.8.7. Information ownership support and a decentralized approach to security
137 10.8.8. Segregation of duties 137 10.8.9. Module integration support 137 10.8.10. Corporate governance support 138 10.8.11. Implementation methodology support 139 10.8.12. Non-technical security implementation 139 10.8.13. Documentation support 139 10.8.14. Change management support 140 10.9. Summarizing compliance of ERPSEC to the identified requirements
141 10.10. Normalizing the ERPSEC objects and structures 142
10.11. Future uses for ERPSEC 142
10.12. Conclusion 142
CHAPTER 11: CONCLUSION 143
11.1. Introduction 143
11.2. Study summary 143
11.3. Areas of future study 143
GLOSSARY 148 INDEX 150 APPENDIX A – THE OBJECT-ORIENTED APPROACH – A PRIMER 153 APPENDIX B – A CASE FOR INFORMATION OWNERSHIP IN ERP
SYSTEMS
165
APPENDIX C – ERPSEC – A FRAMEWORK TO ENHANCE SECURITY IN ERP SYSTEMS
178
TABLE OF FIGURES
Figure 1 Generic ERP system topology 10 Figure 2 Generic ERP system architecture 10 Figure 3 Example hierarchy for F:SDCLERK and F:FIDIRECTOR 21 Figure 4 Relationships in the SAP authorization concept 24 Figure 5 SAP object class hierarchy 25 Figure 6 Expanding the object class Financial Accounting 28 Figure 7 Instances of the object F_BKPF_BUK 29 Figure 8 Sample authorization for company codes relating to
accounting documents
30 Figure 9 Using the profile generator to create an activity group 31 Figure 10 Creating a responsibility in the Oracle E-Business Suite
security system
41
Figure 11 Request security groups 43
Figure 12 Form functions 44
Figure 13 The Oracle E-Business user master record 46 Figure 14 Relationships in the Oracle E-Business security system 48 Figure 15 Standard Navision Attain roles 58 Figure 16 Permissions within the role ALL 59 Figure 17 Assigning permissions to a role 60
Figure 18 User setup 63
Figure 19 Relationships in the Navision Attain security system 63 Figure 20 Centralized security within an ERP environment 73 Figure 21 Decentralized security within an ERP environment 74 Figure 22 Information ownership in ERPSEC 93 Figure 23 Information areas in ERPSEC 94
Figure 24 The evolution of ERPSEC 96
Figure 25 Relationship of the ERPSEC model components 97 Figure 26 ERPSEC entity-relationship diagram 132
CHAPTER 1 INTRODUCTION
1.1. Introduction
The purpose of this study is to define a reference framework that describes an optimal security subsystem for Enterprise Resource Planning (ERP) software systems in use by businesses and organizations. Enterprise Resource Planning systems are accounting-oriented information systems for identifying and planning the enterprise-wide resources needed to take, make, distribute, and account for customer orders. [HYPE03] Further definitions are provided in chapter 2. Typical ERP software systems, such as those under scrutiny in this thesis perform management and tracking functions for all aspects of an organisation’s operations and functions. For all organisations making use of such a software system, information security remains a constant concern.
1.2. Definitions and terminology
A number of terms are used in this document that may not be familiar to the reader. Wherever such terms occur, a definition and explanation is provided. One of the terms that will occur very frequently is the term Enterprise Resource Planning (ERP).
To facilitate the understanding of the reader, the term ERP is defined here as any software system that has been designed to support and automate the business processes of medium and large businesses. Additional information regarding Enterprise Resource Planning is provided in chapter 2.
1.3. Background
The widespread use of large-scale Enterprise Resource Planning (ERP) systems within organisations provides end users with access to business critical information. The organisations making use of these software systems are generally medium to large organisations. Such organisations require global access to all business-related information. Whenever possible, the information should be available in real-time to permit timely reaction to changing markets and conditions.
Many, if not all processes within the organisation may be managed and tracked through the use of an ERP system. Depending on the level of integration achieved, the reach of the ERP system may extend from the shop floor to the chief executive officers’ desk and from the shopper on the companies’ online store to a sales clerk. This high level of integration raises a number of security concerns. When combined with the high level of information dissemination to a large number of potentially unrelated parties, the concern for adequate data and information security grows. Protection of
the assets and information belonging to the enterprise is of primary importance.
1.4. Abstract
Existing software packages to control business processes are widely accepted and have become the central data repository for most information relating to an enterprise. Each of these systems provides a method by which data may be protected. Furthermore, access to information can be restricted to authorized users only. To protect the business, access to critical resources must be limited to authorized and authenticated users only. [WENT00]
Although all ERP systems available today provide security mechanisms in many different forms, information security concerns abound. The use of various products varies from business to business and from one industry sector to another. The many uses within various organizations and industry sectors of the same software package require enormous flexibility on the part of the particular software product. Extensive customization options must be provided by the ERP software vendor to enable the widespread use of the ERP software package.
Due to the flexibility provided by current ERP software vendors, the provision of adequate security measures for enterprise data is difficult to define. As an example, consider that the same ERP software package may be configured for use in a military environment, or for a bakery. The needs of both organizations are different, yet the features and functions of the software must provide both with the same measure of functionality. At the same time the software must provide flexibility, yet access to data must be restricted appropriately. In the example given above, it should be obvious that the security requirements of a military environment and that of a bakery differ substantially.
In the author’s opinion, one of the possibilities for providing adequate security is to provide a common mechanism for the implementation of the security subsystem. The primary mechanism for the implementation of security within such systems is access control and user authentication. In the more detailed product analyses provided later on in this thesis, it will become clear that a number of additional options are available for securing ERP systems. As stated by [PELT01], the role of security is to assist management in meeting its responsibility to adequately protect the assets of the enterprise.
ERP implementations are costly exercises. This is supported by [TUDO01]. Furthermore, a number of implementations have failed due to inadequate planning. [TUDO01] The aspect of planning for adequate security measures forms a very important part of the overall implementation plan for an ERP solution within an enterprise.
1.5. Problem statement
The aim of this study is to provide a possible solution to enhance the security of existing ERP systems by developing a reference framework for ERP security.
The problem statement may be explained quite simply as follows:
Security mechanisms employed and offered by commercial ERP software products provide role-based and transaction level security. It is not easy to configure the security objects provided by these ERP systems to assist with the control of segregation of duties issues and to provide adequate risk management of the tasks each user is able to execute within the system.
To paraphrase this: the required flexibility provided by the various ERP software packages contributes in part to a generic approach to security. However, the generic approach may simply be provided due to its ease of implementation. It is generally accepted that the security offered by simple user authentication cannot be sufficient to protect an organization using a fully integrated, real time transaction processing system. This is largely due to the diverse tasks undertaken by individual users of the system. Certain users may require access to data or functionality that should not be accessed by other users. The separation of these duties relies on a more complex approach that cannot be solved only by user authentication techniques.
Various users with various tasks and roles within the organization should not be able to perform all functions offered by the system. Tasks and functions allocated to individuals within the organization are generally fairly specific and cover only a certain subset of services offered by the organization. When personnel and financial systems are integrated, the allocation of certain tasks to certain individuals is especially critical.
The ability to access payroll records or the ability to print cheques are two examples of functions that have to be restricted to certain authorized users only. This example makes use of unrelated areas of business, however. Where users are able to perform functions that may involve segregation of duties issues, the concern for adequate security may be even greater. A user who is able to create a sales order and release a delivery may cause huge losses for a company. Similarly, a payroll administrator who is able to pay employees and hire them may create fictitious employees and commit fraud. As a further complication, the implementation and customization of user access rights is normally performed as a central function within the organization. Primarily due to the technical nature of this task, the creation of user master records with the required access controls is often left to system administrators. Although the system administrator may be aware of the technical implementation details of the required access controls, the implications of providing access to functions that are not required may lead to a number of security and audit problems.
A two-fold problem results: users requiring access know what objects they require access to but are unable, or not permitted to create the necessary access requirements in the system. Conversely, system administrators know and are permitted to create the access requirement for that user in the system, but are generally not aware of the implications when such an access permission is assigned to a user. The concept of information ownership is generally not considered when implementing security in an ERP system. This leads to a system that has been configured with security options that do not support the concept of data ownership. In other words, the information owner is not aware whether or how his data or information is protected and who is able to access it. The concept of information ownership is a core principle that is discussed in further detail in this thesis.
A number of security and audit exposures can be created by implementing security within an ERP system. Even though the basic access and authentication provided by the software packages is generally adequate, the more serious issues of segregation of duties and information ownership are not addressed. The approach of developing a reference framework during the course of this study seeks to remedy this shortcoming.
1.6. Objectives of the study
The problem statement above indicates the most important aspects that require a focussed investigation. It can be stated that there is no reference framework available at this point in time that permits organizations to evaluate and implement adequate security measures for an ERP system within an enterprise. This is true for both new installations, as well as for retrofitting such security measures in existing ERP systems.
Hence, the objective of this study is
• to determine how existing ERP systems implement security measures • to determine how effective the security measures built into existing
ERP software packages are
• to determine what weaknesses can be identified when investigating existing ERP software security implementations
• to create and describe a reference framework that is able to address the weaknesses identified within the existing product sets and offer a solution to the data and information security shortcomings present in ERP systems available today
Given the above, this study commences with an investigation regarding existing ERP systems and the implementation of security subsystems employed by them. The deliverable of the study is to provide a clear and concise reference framework to provide organizations with a better understanding of the method used to implement security within their chosen software package. Such an implementation should enable the organization to be aware of problem areas and to be able to address them confidently. Where organizations are uncertain as to how security measures are implemented
within their selected product, the reference framework proposed by this study should enable such organizations to gain a better understanding of how security could and should be implemented to best effect.
This thesis tests the following hypothesis:
It is possible and reasonable to identify and describe a reference framework for the definition of security requirements, and their enforcement, in relation to the effective administration and usage of Enterprise Resource Planning software systems.
The ERPSEC reference framework developed during the course of this thesis attempts to address this hypothesis.
1.7. Approach of the study
The approach to the development of a reference framework to describe the implementation of necessary security measures within ERP systems requires a number of steps. These steps are briefly outlined below:
1. to provide the reader with some background information, the concepts and terminology involved in the world of ERP systems are expanded upon.
2. the problem definition as set out in the introduction to this chapter is explained in more detail
3. three current ERP software products from various vendors are examined and their implementation of security discussed in some detail. This investigation provides the reader with some concrete, real-world examples of how security is implemented in ERP projects and how the technical implementation of these security subsystems is structured.
4. based on the investigation of the existing ERP software products, some critical security issues common to all of them are discussed and highlighted.
5. to provide a possible solution to the critical security issues identified, the requirements of the ERPSEC framework that forms the core of this study are discussed.
6. once the requirements of the framework have been established, the actual implementation details of the ERPSEC framework are provided. ERPSEC is the framework developed during this study to provide solutions to critical security issues in ERP software systems.
The steps outlined above are provided to the reader in the chapters of this thesis.
The reader should be aware of the fact that this thesis addresses the issues of security within an ERP environment only. There is no coverage of the concepts and potential shortcomings regarding the operating systems and database management systems supporting the ERP environments considered for purposes of this thesis. This serves to narrow the focus of the thesis and to
be able to provide a solution to one set of shortcomings. As current ERP software products provide a complete set of services, including the provision of their own security subsystems, the narrowing of focus for this thesis is considered appropriate.
The document structure and chapter content of this thesis is provided in the following section.
1.8. Study overview
This chapter has served as a general introduction to the direction this study will be taking. The study focuses on the primary goal, which is the development of the ERPSEC reference framework for security in ERP environments. The arrangement of the remainder of the study is discussed below.
Chapter 2 provides some insight into the world of Enterprise Resource Planning systems for the benefit of the reader. Some key concepts are discussed.
The direction of the study has already been briefly provided in this introduction. A more detailed examination of the requirement for a reference framework for security in ERP systems is provided in chapter 3.
In order to substantiate the need for a reference framework for information security within ERP systems, existing ERP software packages are analysed. All selected software packages have a large user base and are in use by many different organizations and businesses worldwide. In chapter 4, the product offering SAP R/3 from SAP AG is reviewed.
Chapter 5 continues the analysis of existing ERP software packages. The analysis of the Oracle E-Business Suite software package is completed in that chapter.
To ensure coverage of different software packages for different market segments, chapter 6 focuses on the Microsoft Navision Attain package. This ERP software system is more suited to the medium market segment. The products reviewed in chapters 4 and 5 are more prevalent in the medium to large market segment.
With the analyses of existing software products having been completed, Chapter 7 turns its attention to a summary of common problems found in the security implementation and approach of the products reviewed in the previous chapters. The summary of facts identified in the individual product analyses serves to highlight the need for a reference framework for information security in ERP environments.
Prior to the detailed discussion of the ERPSEC reference framework, chapter 8 provides some insight into the most common problems relating to ERP
security that have been identified by the author. The problems identified in chapter 8 form a basis for discussion of the ERPSEC framework in chapter 10.
Chapter 9 provides the reader with an introduction to the ERPSEC framework. A high-level overview of the framework is provided, prior to the detailed discussion provided in chapter 10.
The ERPSEC reference framework is based on an object-oriented approach and is introduced in chapter 10. This implies the use of object-oriented structures to describe the reference framework at a technical level. Chapter 10 provides details of the construction and operation of the ERPSEC reference framework. A discussion is provided as to how the ERPSEC reference framework assists in solving the security shortcomings found in existing ERP software products.
Chapter 11 presents the findings and concludes the study. The most important topics are reviewed in that chapter.
A bibliography is provided following the final chapter. References used in the text are provided.
Appendix A is provided for reference purposes. This appendix provides details regarding object-orientation. The principles of object-orientation are extensively used in the discussion of the ERPSEC reference framework, but may prove to be too technical for the casual reader. In this case, Appendix A provides sufficient background information to make the discussion of the ERPSEC reference framework understandable.
Finally, two additional appendices are provided, each of which contains an article presented at an international security conference. “A case for information ownership in ERP systems” is provided in Appendix B. This paper was presented at the 19th IFIP International Information Security Conference in Toulouse, France. The paper covers the security problems that are present in existing ERP software products and provides details of what a reference framework, such as ERPSEC, should contain to enhance ERP software security.
The paper titled “ERPSEC – A reference framework to enhance security in ERP systems” was presented at the 20th IFIP International Information Security Conference in Chiba City, Japan. The paper is included in Appendix C and highlights the ERPSEC reference framework in more detail. Some of the benefits of the ERPSEC reference framework are highlighted.
CHAPTER 2 INTRODUCTION TO ERP
2.1. Introduction
The previous chapter introduced the topic of this thesis to the reader and touched on the term Enterprise Resource Planning (ERP). This chapter briefly introduces key concepts to familiarize the reader with the concept of ERP systems and environments. This background information should enable the reader to gain a better understanding of the need for security within ERP systems.
2.2. Defining the term Enterprise Resource Planning
A very brief definition of the term ERP was provided in the introductory chapter to this thesis. Numerous definitions exist, but all contain the core description of an ERP system’s functions. An ERP system is an information system that provides an automated means of managing a business. The automation and support functions include manufacturing, distribution, personnel, project management, payroll, and financials.
The definition provided by [SOFT02] is lengthy in its description:
ERP (Enterprise Resource Planning) is an industry term for the broad set of activities supported by multi-module application software that help a manufacturer or other business manage the important parts of its business, including product planning, parts purchasing, maintaining inventories, interacting with suppliers, providing customer service, and tracking orders.
A more succinct definition is provided by [HYPE03], who states that ERP systems are accounting-oriented information systems for identifying and planning the enterprise-wide resources needed to take, make, distribute, and account for customer orders. Additional definitions may be found in [COMP98], [WEBO05] and [LABO05]. For purposes of this study, the author prefers to employ a more simplistic definition, namely that ERP implies the support of all business processes within an enterprise by a single software system.
2.3. A brief history of ERP
From a historical perspective, companies have always relied on hand-written ledgers to keep track of income and expenditure. The birth of the spreadsheet application allowed accountants to track similar data in more detail. The ability to control larger portions of the organization was possible once custom or tailor-made software programs where created to allow orders, sales details and ledger information to be saved in one or more databases.
Systems that were primarily used to control and track inventory were replaced in the early 1960’s. A particular type of software developed specifically for the manufacturing industry provided the basis for today’s ERP systems. The Materials Requirements Planning (MRP) application served as the method for planning and scheduling materials for complex manufactured products. [ERP01] The MRP application was developed primarily for mainframe computers and provided many companies with a competitive advantage. Within a short time period, MRP became the fundamental concept used in production management and control. Various developments and changes took place to extend the functionality of the basic MRP systems. Specifically, MRP evolved into MRP-II as a more accessible extension to manage shop floor and distribution management activities. [KAEM02]
The term ERP (Enterprise Resource Planning) was first introduced in the early 1990's when MRP-II was extended to cover areas like finance, human resources and project management. [ERP01] This extension of functionality occurred as a normal evolution from the basic MRP software. It can be stated that ERP systems provide the cross-functional coordination and integration in support of the production process by linking all necessary areas of business together. For the first time, enterprises had the ability to exchange many single systems with separate data stores for one system with a single data store. This single data store contains all information pertinent to the organization.
2.4. Architecture of an ERP system
Various vendors provide ERP system software and the architectures of these products differ. However, one core component is the same for all, namely a centralized repository. The centralized repository stores all data required by the ERP application. By utilizing the functionality provided by the ERP software package, users within the organization are able to retrieve specific data, generate reports, perform payroll runs or input sales orders. Due to the fact that the repository is centralized, common information is stored only once. Thus, users in the sales, financial and manufacturing department all have the same data available to them.
The repository is usually based on a relational database management system (RDBMS). The functionality of the ERP software itself may be coded using commercially available programming languages and development environments, or may be created using a custom-developed programming language. The programming language selected for the creation of the ERP system’s functionality may be an important consideration for a prospective customer or user. Depending on the functionality provided by the ERP vendor, additional functionality may have to be added by the customer or user.
Due to the fact that the ERP system integrates all the information within the enterprise, the ERP system is generally located in a central location that is accessible to all end users. Generally, users in the same geographical area
would access the ERP system using the local area network (LAN) of the organization. For locations that are farther away, a wide area network (WAN) or similar link is required.
The end user interacts with the ERP system through a terminal or workstation. Generally, the workstation front-end software for the ERP system is easy to use and provides the user with a pleasant environment. Using the front-end software on his workstation, the user is able to perform all required functions directly from the comfort of his desk. Due to the integrated nature of ERP systems, a manager may be able to view all financial, sales and production data directly from a head office location. This is possible even if the sales and production locations are physically separated from the head office.
Figure 1 shows a very basic, generic layout of an ERP system installation.
Figure 1 – Generic ERP system topology
To provide the reader with a better understanding of the internal architecture of an ERP system, Figure 2 shows a generic ERP system architecture, including the repository and application layer. The specific implementation details differ from vendor to vendor. Such differences will be highlighted in the product-specific chapters wherever considered appropriate.
2.5. Advantages of ERP systems
The ability to integrate all company-related data is a compelling reason for organizations to implement and use ERP systems. The centralized and integrated nature of ERP systems also permits organizations to standardize their processes and eliminate problems related to data storage in multiple repositories, such as data integrity. The ability to track and manage all aspects of the business from a single workstation located anywhere within in the organization is a useful tool for managing the business and tracking progress.
Some additional advantages that can be mentioned are:
• Faster inventory turnover by providing increased efficiency and automation of processes such as production planning and procurement • Improved customer service by ensuring that goods in demand by
customers are available
• Improved accuracy of inventory counts as compared to physical inventory
• Timely revenue collection and improved cash flow by providing financial management information that is updated and maintained in real time
• Higher employee satisfaction by providing powerful functionality at the desktop level
Numerous advantages may be added to the list above. The purpose of this section is not to be exhaustive, but to provide the reader with some useful background information for the remainder of this thesis.
2.6. Security in ERP systems
The main part of this chapter has focussed on the functionality and advantages provided by ERP systems. The integrated and centralized nature of ERP systems should make it clear that security is an important aspect to be considered when implementing an ERP system. As all data is stored in a central repository and is potentially open to the entire user population of the organization, a mechanism is required to ensure only authorized users gain access to their relevant information. This is particularly true when human resources data shares the repository with other areas of the organization. To ensure controlled access to all data, most commonly available ERP systems provide mechanisms to protect data from unauthorized access. These mechanisms are examined in greater detail in later chapters. For now, the reader should be aware that the advantages gained by implementing an ERP system are primarily for the benefit of the organization’s operation and management. Huge difficulties can be faced in trying to create rigid and secure access control policies. This study will attempt to highlight such difficulties and provide an alternative solution.
2.7. Conclusion
The purpose of this chapter was to introduce the broad field of Enterprise Resource Planning to the reader. The basic requirements, architecture and uses of ERP systems were briefly explained. The following chapter focuses on the problem this study is to address within the ERP environment.
CHAPTER 3
SECURITY IN ERP SYSTEMS
3.1. Introduction
In the previous chapter, the concept of Enterprise Resource Planning (ERP) systems was introduced. A very brief history and overview of the architecture of ERP systems was provided. It was shown, that although ERP systems offer numerous advantages for an organization, providing adequate access control and security within a centralized repository is difficult. It is this difficulty that this study wishes to address. The sections below set the scene for the remainder of this thesis.
3.2. Problems with ERP security
Existing software packages that control business processes are widely accepted and have become the central data repository for most information relating to an enterprise. Each of these systems provides a method by which data may be protected and access to information is restricted to authorized users only. To protect the business, access to critical resources must be limited to authorized and authenticated users only. [WENT00]
Various mechanisms to provide security are employed by existing ERP software systems available on the market. The primary mechanism supported by these systems is some form of access control and user authentication. In turn, the role of a security department within an organization is to assist management in meeting its responsibility to adequately protect the assets of the enterprise. [PELT01]
Though the access controls and user authentication features provided are more than adequate, existing ERP software products do not support features that enhance security beyond these boundaries. This fact is highlighted in the chapters that investigate existing ERP software security in detail.
The most important issue is the lack of support for information ownership, which the author considers a vital component to enhance overall security within an ERP software system. The concept of information ownership has been known in security circles for a number of years [WOOD03], but has never been supported by ERP software [RISS04]. Discussions in this chapter will focus on the concept of information ownership and its significance in enhancing security.
3.3. Information ownership support
Information ownership assumes that single points of responsibility exist within an organization that makes use of an ERP software system. These single points of responsibility take charge of the configuration of security objects for
the users of the system within a certain department or area within the organization. This is in contrast to the traditional approach that relies on a central point for the configuration of security objects. One may also refer to the traditional approach as the centralized approach, whereas the information ownership approach can be referred to as a decentralized approach.
Examples of these single points of responsibility may be a sales office, manufacturing department or finance department. The author will furthermore make use of the term information area to reflect such a single point of responsibility. Additionally, support for information ownership requires individuals to take responsibility for the selected information area. These individuals are generally already in charge of an information area. Hence, they have all the required business knowledge to make informed decisions. The author makes use of the term information owner to describe these individuals. Some additional information regarding information areas and information owners is provided below.
3.4. Information areas and information owners
Information areas have been defined above as single points of responsibility within an organization. Generally, one person is in charge of such an area within the business, though this depends very much on the size of the organization. In a very large multi-national company, the information area may be restricted geographically. In this case, there may be more than one owner for the same information area relating to the same function within the business. Sales offices may exist in Tokyo and New York, for example. Each of these offices would have a manager, with the responsibility to oversee operations within these regions. In certain cases, it is logical that these individuals are identified as the information owners in the organization. For smaller businesses, a single individual may be responsible for multiple tasks and roles. In this case, that individual may be required to assume ownership of more than one information area. Subtle problems result from this, primarily the difficulty in determining what degree of segregation of duties should be permitted in cases such as these. This discussion is not in the scope of this study.
As an example, the product SAP R/3 marketed and produced by the German software company SAP AG, provides a fully integrated, real-time online transaction processing system for all aspects of an enterprise. Security within the SAP system is implemented by making use of the so-called profile generator. Additional detail regarding the configuration of security objects in the SAP product suite is provided in chapter 4.
The SAP profile generator provides a user-friendly interface, which is capable of assisting an administrator with the creation and generation of authorization profiles. These define the permissible actions for each user. The profile generator is designed to be used by one or more security administrators who are in close communication with one another. The concept of information
ownership is not conveyed and is not present. This is primarily due to the fact that SAP, like other ERP software packages, does not support the concept of information ownership. A central security administrator is in charge of the configuration of security objects – this function is not rolled up to the level of individual information owners.
It is the author’s opinion that the approach to ERP security, underpinned by the concepts and techniques of information ownership, can greatly enhance security and manageability of an ERP system.
ERP implementations are costly exercises. This is supported by [TUDO01]. A number of implementations have failed due to inadequate planning. [TUDO01] The aspect of planning for adequate security measures forms a very important part of the overall implementation plan for an ERP solution within an enterprise.
It is clear from the above description that a comprehensive reference framework be developed which is able to provide organizations with sufficient information to pre-empt situations in which data security is compromised.
3.5. Conclusion
In this chapter, the reader has been introduced to the problems facing existing ERP software packages regarding their security subsystems and approaches provided by vendors to deal with security and access control issues. The problem statement this study wishes to address has been provided and an approach proposed. To provide substance for the problem definition provided above, the following chapters investigate various ERP software packages to determine how their security subsystems and approaches to access control measure up.
CHAPTER 4
PRODUCT REVIEW – SAP R/3
4.1. Introduction
The previous chapter provided the approach this study proposes. This chapter is the first of three ERP software product analyses. In this chapter, implementation of security within the product SAP R/3 is discussed in detail. The effectiveness of its security subsystem is discussed. Once the implementation of the security mechanisms built into the product have been identified and described, potential exposures will be highlighted.
4.1.1. Scope of review
The SAP R/3 system is a very complex software solution and relies on numerous components to function [SAP00]. Various hardware platforms, different operating systems and numerous relational database management systems (RDBMS) are supported. Users may connect to the SAP system using a web browser, mobile terminal or the SAPGUI software supplied by SAP. As the topics of operating system security and database security are beyond the scope of this study, only the SAP system itself will be investigated.
4.1.2. Product overview
SAP R/3 is a core component of a wide product range offered by SAP AG. The SAP R/3 product offers a wide functionality and business-wide integration of business-critical data, such as financial, sales and production data. With the advent of e-commerce solutions and the necessity of integrating business intelligence components, the SAP R/3 product integrates with numerous add-on solutiadd-ons. These include customer relatiadd-onship management, business information warehouse and supply chain management components. Many of these additional software components are systems in their own right, but are generally integrated by communicating with a central SAP R/3 system. The internal architecture for these individual systems is similar and deviates only with regard to certain solution-specific details.
4.1.3. SAP R/3 architecture
The architecture of the SAP software product is such that the core product is largely platform independent. Hence, the same product is available for a wide variety of hardware, operating system and relational database management system platforms. TCP/IP is the preferred networking technology and users may connect to the system in various ways, including SAP front-end software and web browsers. The platform independent nature of the product is assured by the provision of interfaces. The core product has been developed using the SAP fourth generation language (4GL) ABAP.
4.1.4. The SAP authorization model
The SAP system has built-in security functionality, generally referred to as the SAP authorization concept. [SAP00] The implementation of this authorization concept is realized by a number of tables within the database that contain security related information. To determine whether or not a particular user may perform a certain function or manipulate certain information, a number of lookups to these tables are necessary. Depending on the entries within these tables, access to the function or data is either permitted or denied. Such a lookup is termed an authorization check.
The type of security implemented making use of the SAP authorization model may depend on the organization owning the SAP system. For example, large organizations may have stricter requirements than smaller companies. [WEIS96]
In the following section, the concepts involved in creating the SAP authorization model are discussed.
4.2. Authorization checks
The basic method of determining whether access to a function or an object is permitted within the SAP system is by using so-called authorization checks. A user is assigned certain permissions to be able to view and manipulate information within the system.
Prior to a more detailed authorization check, the system determines whether or not the user is permitted to execute the current program or function. This high-level check ensures that the user does not gain access to the program to attempt further access to data or functionality.
Such information may be financial information as it pertains to the company’s general ledger, or stock availability of a certain item in a warehouse, for example. When the user logs on to the system using his user name and password, the system reads the contents of the user’s master record into a user buffer in the main memory of the SAP server. It is important to note that the user always logs on to the application directly. As the SAP application provides all necessary services, there is no intervention from the operating system or database management system. The user’s master record contains the permissions assigned to the user and governs the actions the user may take. Whenever the user attempts to perform a function within the system, the program code checks the required permissions against the permissions contained within the user’s user buffer. If the user has the required permissions, the action is deemed to be acceptable. Should the user be attempting an action that is not permitted given the contents of his user master record, the program code branches and denies access to the user. Denial of access is generally a message telling the user that the selected action cannot be completed.
The SAP system stores references to the objects to which the user has access directly in the user’s master record. This is an implementation of a directory control list (DCL). Many other systems make use of an access control list (ACL). [PFLE02] In an ACL implementation, each object contains a list of users that may access the object. [STRE01]
Programmers determine where and how such checks are to be made, based on the type of program being implemented and the type of information the program will allow the user to access. A user administrator determines (within the options provided by the programmer) who may execute a function or access an object.
4.3. Activities within the SAP authorization concept
An important aspect of an authorization check within the SAP system is whether or not the user is permitted to perform a certain action. Within the SAP authorization concept, a so-called activity code has been defined.
The activity code is a numeric value that has been defined by SAP to represent an action a user or a program may take (an exception to this is the SAP HR module in which values other than numeric ones are used). For example, the value 01 indicates the action “create”, the value 02 the action “change” and the value 03 the action “display”. A range of activity codes has been defined. The activity code can be identified within the SAP program code by the name ACTVT.
Hence, the authorizations check performed by the program code within the SAP system will generally query the activity code and the associated field value held by the user within the user master record. Should the user wish to change an entry within the general ledger, the program code first determines whether or not the user’s master record contains, amongst other values, the activity code 02 as it relates to entries within the general ledger. Should the user’s master record contain only the value 03 for display, the program does not permit the user to continue with the intended modification of data within the general ledger. The SAP authorization check is described in more detail below.
4.4. The SAP authorization check
The authorization check involves a number of components that are required prior to the authorization check being possible. Authorization fields and objects are such components:
• an authorization field is the smallest unit against which a check can be made (examples are company code, accounting document, program name, activity, etc.). If required, a skilled and experienced programmer may create and add additional authorization fields.
• an authorization object groups together one to ten authorization fields, which are then checked together. As an example, the authorization object F_BKPF_BUK groups together the authorization fields company code and activity. A corresponding check can then be as follows: “Does the user have display authorization in company code 0001?”, or “Does the user have change authorization in company code 0057?” The programmer creates authorization objects if required.
The programmer inserts an authorization check in the ABAP/4 program code that takes the form of a call to a function with the name AUTHORITY-CHECK. The call to this function is placed at a logical location within the program code. For example, at a point just after the screen input of the user has been validated. In some cases, the call to the function may occur as soon as the user selects the function from the menu. In more complex programs, many calls to the AUTHORITY-CHECK routine may be made at various locations within the main program and its subroutines.
AUTHORITY-CHECK has a parameter, namely the object against which the check is to be performed. The programmer names the authorization object and specifies the values to be checked per defined authorization field. As an example, the activity code may be required.
After the check, a system-defined variable that stores the latest return code generated by a subroutine (SY-SUBRC) is set to zero to indicate success or to another value to indicate a failure.
Consider the following example:
AUTHORITY-CHECK OBJECT 'F_BKPF_BUK' ID 'BUKRS' FIELD '001'
ID 'ACTVT' FIELD '03'. IF SY-SUBRC <> 0.
MESSAGE E... "NOT AUTHORISED!” ENDIF.
In this example, the authorization check takes place against the object F_BKPF_BUK. The object considers a company code and an activity the user may perform against the company code. The company code is referenced by the field BUKRS in the source code, the activity by the field ACTVT. Note that the check enforces that the user has access to company code 001.
Furthermore, the user may only display information regarding the company code.
It is important to note that the program itself rejects or accepts the user’s action. In other words, if the function AUTHORITY-CHECK determines that the user’s master record contains the correct values, the program continues. However, should the user’s master record contain other values or be missing the values required by the authorization check the program branches and does not continue with the intended function.
The reader should note that there is no intervention from the operating system or database management system supporting the SAP system for any security or authorization checks. As the SAP system provides all necessary services, it is responsible for all security checks. The users never sign on to the operating system or database hosting the SAP system. Instead, the users sign on directly to the SAP system itself, which provides all necessary services and functions.
4.5. Authorizations
An authorization represents one characteristic of an authorization object. [SAP00] In other words, the user requires multiple authorization objects to be added to his user master record to be able to have a complete collection of authorizations. The authorization object represents a combination of allowed values that may be placed in the user’s master record. For each combination of users, or user groups, a number of different instances of the same authorization object may have to be created.
Consider the following example: the sales order clerk in an organization is permitted a certain level of access to information pertaining to the area within which the sales clerk works. In contrast, the financial director of the same company has a totally different level of access to the information. This principle of least privileges has already been mentioned in a previous section of this chapter.
To enable the correct level of access to be configured for each of these users, it is important to determine which authorization objects are required. Once these have been established, it will more than likely be necessary to create different instances of these objects. In the case of the sales clerk, access may be restricted to a certain company code. Furthermore, it may be deemed necessary that the sales clerk is permitted to view the information, but not change it. The financial director will possibly have to access information pertaining to all company codes. Also, he may have to be able to change information regarding these company codes.
Given the above example, two distinct instances of an authorization object will have to be created. They are all based on the same root object, but are given different names and contain different values.
For the sales clerk, the authorization object F:SDCLERK based on the root authorization object F_BKPF_BUK, may contain the values ‘001’,’002’ and ‘003’ for the field company code and the value ‘03’ for the activity code. This is illustrated in Figure 3. Hence, the sales clerk is restricted to viewing information for company codes ‘001’,’002’ and ‘003’. For the financial director, the authorization object F:FIDIRECTOR based on the root authorization object F_BKPF_BUK, may contain the value * for the field company code and the value * for the activity code. Hence, the financial director may perform any action on any company code.
Figure 3 – Example hierarchy for F:SDCLERK and F:FIDIRECTOR
4.6. Profiles
An authorization profile represents a collection of authorizations. [SAP00] In simple terms, a profile is simply a collection of authorizations grouped together. An authorization profile contains characteristics for different authorization objects that a user requires to work within a restricted task area. This task area can be likened to a role. It is important to note that a profile in itself may not necessarily define a role explicitly. The user’s master record may contain numerous profiles, which together define the role of a user. It is generally necessary to build many different profiles to permit all actions required by the person performing a particular task. The user master record contains all the necessary profiles to enable him to perform his job functions. The user master record reflects the roles of the user. A user can have more than one role in the organization. The user master record collects all the profiles in one user master record to enable that user to perform his duties. A user master record should therefore not be likened to a role.
Company code [001, 002, 003] Activity [03] Authorization object F:SDCLERK
Accounting document: Authorization for company codes F_BKPF_BUK Company code [*] Activity [*] Authorization object F:FIDIRECTOR Class Financial Accounting
The design and implementation of the authorizations determines how the profiles are created and what they contain. Such a design and implementation is undertaken and decided by the project team. It is possible to create profiles that contain other profiles. This is named a complex or composite profile and is most useful whenever many related profiles have to be allocated to many different user master records. The security administrator is responsible for maintaining authorization profiles.
4.7. User master records
The user master record is used to log on to the SAP system and allows restricted access to the functions and objects of the SAP system with the authorization profiles allocated to the user master record. Within the SAP system it is not possible to allocate authorizations directly to a user master record. Instead, authorizations must be collected in one or more profiles. These profiles are then allocated to the user master record. Hence, profiles are nothing more than containers for authorization objects. Figure 4 provides a graphical representation of the hierarchy involved. Once created, a user master record contains no profiles and the user has no default permissions within the system.
4.8. Implementing the authorization check
An authorization check is included in an ABAP/4 program that is executed by a user. The program knows the name of the authorization object and the required values. The program checks the user master record for the required named authorization object. Once this has been done, the system uses the first authorization object and compares the values required in the program with the values in the relevant authorization object. If the required value is available for each authorization field, the check was successful. In this case the system variable SY-SUBRC returns a zero value to indicate success. If not, the system takes the next characteristic for the authorization object from the user master record and performs the same checks. If no characteristic exists for the named authorization object in the user master or if no characteristic contains the required values, the check was unsuccessful. In this case, the system variable SY-SUBRC returns a non-zero value.
It is important to note that the authorization check is not mandatory. In other words, the programmer may have decided not to include a call to the AUTHORITY-CHECK routine. In most SAP standard programs such checks exist. However, programs written as add-ons to the system may not always contain the necessary authorization checks. In cases where the checks have not been included in the source code, the systems integrity could be at risk. The inclusion of the authorization check in custom-developed programs is generally at the discretion of the programmer or developer.
The administrator creates a user master record for the user, which the user then uses to log on to the system. The user may execute all functions for which the system does not provide explicit authorization checks, as well as those functions for which he has the required authorizations in his authorization profiles. For all other functions, the user either receives an error message or no display at all.
Should the programmer wish to offer the possibility of protecting individual SAP objects, he would create an authorization object that corresponds to the SAP object to be protected and implements an authorization check on this authorization object. When creating an authorization object, the fields that are also used in the application are often used as authorization fields and are combined with the authorization field Activity (ACTVT). Some of the more common activity codes are listed below:
Activity code Activity description
01 Create or generate 02 Change
03 Display 06 Delete
08 Display change documents 77 Pre-enter
If a required authorization field does not yet exist, the programmer may create it. The security administrator is responsible for the allocation of the user master records with the appropriate authorizations for each user’s requirements and job functions.
4.9. Relationships in the SAP authorization model
Figure 4 – Relationships in the SAP authorization concept
Figure 4 illustrates the relationships between user master records, authorization profiles and authorizations. The security administrator maintains authorizations for each authorization object. The authorization objects that have to be considered are those that pertain to the area within which the user will be active. For example, for a sales clerk the area of responsibility may be sales and distribution with a limited amount of responsibility in the financial area of the company. In this case, the authorization objects for the sales and distribution module and the financial module of SAP have to be considered. The newly created authorization objects are grouped together in authorization profiles, such as 'Sales clerk - Financial Accounting'. Then, one or more authorization profiles are allocated to a user master record. Here, an authorization can be allocated as often as desired to authorization profiles and an authorization profile can be allocated as often as desired to composite profiles and users. Composite profiles are used to further organize the authorization structure, but they are not required.
From the brief discussion above, it should be clear that the implementation of such a security infrastructure within the SAP system could lead to overly
User master record Authorization profile Composite authorization profile Authorization profile Authorization profile Authorization Values
complex designs that are difficult to manage and maintain. These issues will be discussed towards the end of this thesis.
4.10. Creating authorizations
In the author’s experience, the implementation of security within the SAP system has traditionally been an area that has lacked support from project teams. The primary reason for this is the fact that the new ERP system has to be configured to provide the correct functionality for the business. Security considerations often take a back seat to this. Another reason is the fact that the company implementing a new ERP solution is often in a hurry to complete the changeover from older systems to the new system. In the race to complete the design of the new system and its implementation, time pressure often forces the company to concentrate on the business process issues, rather than on security issues.
The implementation of a robust security policy was hampered in earlier software releases due to the fact that the authorizations and profiles had to be created manually. This process was tedious and error prone. Later releases of the software include utilities to ease the burden of creating authorization objects and profiles. Instead of the authorizations being created manually, the system aids the security administrator by automating various tasks.
To illustrate how a new authorization is created, consider Figure 5 with the following SAP authorization object class hierarchy:
The object class hierarchy is the entry point for the creation of a new authorization object. To create a new authorization object that will later be assigned to a user by way of a profile, the security administrator selects an object class that represents the functional area the authorization belongs to. For example, an authorization dealing with company codes in accounting documents could be found in the object class Financial Accounting. The authorization administrator drills down into the selected class and is presented with pre-defined objects that may be protected.
Generally, authorization objects are restricted to the object class they have been assigned to. In other words, an authorization object does not belong to more than one class. Instead, similar authorization objects may be present in different branches of the authorization object hierarchy. For example, checks against company codes are fairly standard yet exist individually within different object classes. Hence, the design of the authorizations will include a number of very similar authorization objects all belonging to different parts of the object class hierarchy.
Please note that these similar authorization objects are not identical. Instead, the same field may be contained within these different authorization objects. An example is illustrated below:
Class MM: Master Data Object Material master: company code Authorization M_BUKRS_ALL Material master: maintain and display company codes
Field Values Activity * Company code *
Class Financial Accounting Object Accounting document: Authorization for company codes Authorization F_ALL All Financial Accounting authorizations
Field Values Activity * Company code *
The authorization objects indicated above are identical in structure, yet are
found in separate branches of the authorization hierarchy. M_BUKRS is found in material management whereas F_ALL is found in financial accounting. The practical implication of this example is that any user requiring access to both materials management as well as financial accounting functionality within the system will be required to have both these authorization objects added to his user master record.
An obvious disadvantage of this is that the entries for both must be identical. Should the security administrator enter different values for both, the user will be able to access all company codes and be able to perform all activities entered. This is due to the fact that authorizations are cumulative. In other words, additional values are added to the list of allowable values for that user. As an aside, it is possible to make use of the military security model proposed by [PFLE02]. In this model, [PFLE02] describes a method of securing information by compartmentalization. Compartments are used to enforce need-to-know restrictions. This means that a user may gain access to information only if that information is necessary for that user to perform his job.
A rudimentary form of compartmentalization is supported by SAP. This is indicated to some degree in Figures 5 and 6, where two subsequent screens for the Financial Accounting area are shown.
In the screenshot shown below, the object class Financial Accounting has been expanded. The reader may refer back to Figure 5. In Figure 5, the entry “Financial Accounting” has been selected to reveal its contents – this is shown in Figure 6.
Figure 6 – Expanding the object class Financial Accounting
All objects that may be protected programmatically using the standard SAP authorizations subroutine AUTHORITY-CHECK are displayed. The reader should note that only the objects relating to the selected object class (Financial Accounting) are displayed here. Note also the so-called technical name to the left of the text description. It is this name which is used by the system to perform the authorizations check. Hence, the authorization check would invoke a
