Protecting Your Entire SAP Landscape

Data at rest is a high-value target for hackers. It is a source of people, banking, product, and intellectual property information that is highly valuable for resale or creating counterfeit products. To protect it, you need to understand what it is and where in your SAP landscape to protect it.

What Is Data at Rest?

Data at rest, both in production and non-production environments, is often overlooked as an area of cybersecurity concern. Examples of data at rest include the following:

• Quality assurance systems
• Development environments
• Client copies
• Disaster recovery sites
• Archives
• Online Backups

Obfuscating financial and personal data does not thoroughly protect data at rest, it challenges hackers to correlate data and infer or recover the content through other sources. It also does not protect master data, as it relates to product development and manufacturing.

Virtualization Increases Risk

Increasing virtualization both in-house and in the cloud has made creating full system copies of data for hot failover sites, testing, and development environments cheap and easy. The commonly addressed areas of concern are connections from non-production systems out to the rest of the world. Removing connectivity from non-production copied systems out to external environments, deactivating connectors, external facing communications user IDs, and closing RFC connections are the most common tasks done to protect non-production systems. These are critical, but it is important to understand the inherent risks to master data and what steps are necessary to protect it.

Master Data

Master data is one of the most important company assets. It is specific data types that, when combined, are the core of business profitability and risk. Managing the quality of the individual master data elements is a key business initiative. Securing that master data requires a skilled team. What is master data?

• Vendor Information: Vendor contact data, purchase order history, pricing, contracts, and bank account information
• Customer Information: Customer contact data, sales order history, prices, contracts, and bank account information
• Employee Information: Employee contact data, HIPAA data, benefits information, defendant information, and bank account information
• Corporate Product Data: Formulations, BOM, Recipes, Project data, material lists, and process documents

Threat vectors for master data include hackers, nation-state actors, corporate espionage, employee fraud, disgruntled employees, outsourced resources, and contractors. Attackers are aware of the value of the master data held in an SAP datastore. If they can gain access, regardless of how old the data may appear, they will copy as much of it as they can. Their goal is to gather bank account information, identities, corporate intellectual property, processes, and trade secrets. All of these data types are included in some manner or another during a client copy or copy from backup. In many cases, these non-productions systems are not monitored to record who is accessing them and what they are doing on those systems. The risks to data at rest include a lack of data obfuscation leaving bank accounts, vendor and customer data, and employee personally identifiable data (PII) available to be accessed. Product and intellectual property data is rarely obfuscated in these non-production systems. Production user IDs are often available in non-production environments, including contractors, outsourced resources, and expanded testing access in quality assurance and development environments. There are tools and techniques for solving the problem of governing and protecting data at rest. They fall into three categories: awareness and policy, data categorization, and automation.

Awareness and Policy

Awareness and policy solutions would start with creating a policy for managing data at rest. This policy details what data should be included in a copy for testing or development environments, how all non-production environments should be monitored and what the user provisioning and access review processes should include. The policy should include performing the same risk analysis for data at rest as is done for production systems. This would mandate evaluation of systems, locations, access points, and users accessing these non-production systems. Key Questions:

• What are the systems containing data at rest—online archives, copied systems, disaster recovery sites, online backups, offline backups?
• What external access is there to these systems—cloud application test systems, external data transfer points, RFC?
• What are these systems used for—testing, who has access, are these systems common knowledge?
• Is there an access management process in place for these systems?
• Who maintains key password data and is this monitored?
• Is there a data retention policy for duration and retirement of old data/systems?

Data Categorization

Data categorization is the process of identifying critical master data elements to be secured, who makes decisions for these elements, and what is the value of the data to the business. Categorization can range from simple, like choosing fields for data obfuscation, to complex categorization of data in a confidentiality model. Key Questions:

• Who needs to be involved from the business to determine what are the critical data elements to secure? This includes speaking with finance, sales, product design and build, and Human Resources.
• How to build awareness of the problem and build an engagement process for new projects?
• What is required to implement a data categorization project to prioritize the level of security?
• Who should have access to the different categories of data?
• What is the purpose of securing this data and who should maintain what levels of access?
• What data should be entirely obfuscated in offline scenarios?

Automation

Automating the protection of data at rest can be done through the same tools used for production systems. Key Questions:

• What are we using for securing the production data?
• How are we monitoring production environments?
• What tools do we already have that could be leveraged?

Some common tools that can be used to secure and monitor data at rest include SAP GRC Access Control, SAP GRC Process Control, Field Masking, and Solution Manager. SAP GRC Access Control should be used for production and non-production environments. It should be used to lock out all production users, validate access for testers, approve provisioning of expanded access in non-production environments and monitor transaction usage, and access in non-production systems. Emergency Access Management (Firefighter) should be used for accessing the most critical data access in non-production systems. SAP GRC Process Control can be used to manage the documentation around system copy requests and approvals, disaster recovery records, and test signoffs. Manager or other similar products should used for baseline management, patch control, and review and remediation of Early Watch reports for production and non-production systems. Field masking can be done with the SAP field masking tools or with another third-party program. It provides data obfuscation at the field level. The process can be configured to manage field level access to a user’s authorization and can be used in production and non-production systems. Solution manager monitors notes, patching, and security update requirements. The Early Watch reports monitor notes and security update requirements. It also has reporting for system risk management and transaction execution. Setting this up for non-production systems allows for alerts for excessive use on a non-production system as well as monitoring cyber risk. Using a methodical approach to security data as shown will bring data at rest into the holistic data security model. The first step is awareness. From there, use the tools and policies already in place for production systems to manage non-production systems. Data classification is key to knowing what data should be obfuscated and what should be considered confidential. The business needs to be involved with the identification of these data points as well as determining when and what data should be retired from all systems. It is important to understand that just because users have access to the production data does not mean they should have access to copied systems. The mitigating controls and monitoring process used for production systems are not present in non-production systems; thus, the risk is greater.

What Does This Mean for SAPinsiders?

Managing data at rest is an important component of risk management. The value of that data is not diminished because it is not entirely current or in use in a production environment. Not managing the risk of data at rest gives hackers the entry point they need to steal that data or use that system as an entry point for other nefarious purposes. Understanding the value of the data stored in non-production systems starts with understanding the value of the data in production. That data is not only valuable for the operation of the company, but also holds valuable personnel, bank, and intellectual property data. The same care and concern for access control and data protection provided for production systems should also be given to non-production systems and data stores. Using existing tools to manage non-production systems is a quick win for risk reduction, as is using SAP GRC to manage and monitor those same non-production systems. SAP GRC administrators can set up connectors to all SAP systems in the landscape.

• Utilizing Access Risk Management for provisioning users to all systems, not just production. Managing user role assignments for elevated access assignment in non-production systems with approvals and tracking. This can include having roles assigned for quality assurance and other testing with short durations with expiration dates and automatic removal.
• Use Access Risk Analysis to create non-production rule sets to manage the most critical transactions. Segregation of Duties might not be a concern outside the production systems, but the critical transactions should still be monitored to protect system integrity and to tell if high-risk transactions are being used inappropriately. Setting up a separate rule set for those systems will reduce workload on the GRC system while still putting governance in place.
• Emergency Access Management can be used in non-production systems to segregate out transactions that should only be used in urgent situations.