Avoid Import Errors, Business Outages, Downgrades, Security Vulnerabilities and Compliance Violations by Inspecting all Transports Before Import

How Onapsis Transport Inspection Works 

Onapsis transport inspection is based on over 150 test cases that have been developed over many years of experience with customer projects, focusing on five main areas security, compliance, robustness, maintainability and data loss prevention. Addressing transport issues from multiple angles helps ensure your applications remain secure, compliant and stable. Below are some examples of what is covered by each area.

Security

• Identifies hidden transport content, deactivation of authority checks, unnoticed execution of reports and function modules after import, manipulation of logical file, path definitions, jobs and OS commands

Compliance

• Reports on missing authorization group in maintenance dialog or table, inadequate settings for table logging and client dependent tables

Robustness

• Checks for completeness of all objects, downgrades, correct versions of referenced objects, accidental deletion and overwriting of table content and forecast of critical database activities

Maintainability

• Detects missing packages and namespace definition, invalid or missing repair key for namespace definition, modification of SAP objects and third-party objects, Cl-includes and append structures of SAP tables

Data Leak Prevention

• Generates warnings in case of table data with password hash values, information about the personal security environment (PSE), HR master data and critical HR customizing

All discovered issues include a level of criticality, an explanation of the vulnerability, business impact and remediation guidance. This gives you essential context to understand if you want to accept the risk and how to prioritize remediation for those findings you elect to fix.

Transports, although essential for SAP change management, can also introduce harmful or incorrectly configured content that puts system security, compliance and stability at risk. Onapsis helps mitigate these risks by inspecting every transport (including third- party) before it is released or imported and continuously monitoring the transport queue for critical security findings.

• Prevent system downtime, damage to target systems, import errors and downgrades
• Protect sensitive data from manipulation and espionage, which could result in security or compliance violations
• Find issues earlier when they are easier and less expensive to fix
• Block transports with harmful content before they are released
• Receive actionable remediation guidance for each issue Inspect third-party transports before importing into your system

Building Onapsis Transport Inspection into Your Processes 

There are two main types of implementation for transport inspection-“real time” transport inspection, which addresses all five types of issues described above, and continuous monitoring of the transport queue, which focuses on security and compliance.

Implementation Type 1: “Real Time” Transport Inspection

The first implementation type integrates at two critical steps of the standard transport process-first, before a transport is released and exported from the development system and second, before a transport is imported into production. While the focus of the first integration point is more on security and compliance, the added value of the second integration point lies in the knowledge about which transports will be imported together. This enables the transport inspection to identify potential missing objects as well as any downgrades to be expected.

Step 1: Scan Each Transport Automatically before Export/Release

Focuses on security and compliance. Nevertheless, checks on missing objects are also possible by analyzing the transport’s objects and checking how they fit into the QA system.

• Transport scan is triggered when someone tries to release and export a transport from DEVIf no findings, the transport proceeds as normal to release
• If findings, results are presented in SAP Transport Management System user interface with a description of the finding, business impact, criticality and remediation guidance
• Depending on the Risk Grading associated with the finding and depending on the developers’ authorizations, they can fix these issues and reload, continue or cancel the transport request. Or, they must request an approval, in which case all configured approvers will be notified via SAP Office Mail about this transport
• If one approver approves, the transport is released, and the creator informed. If not approved, the transport is canceled, and the creator informed

Example “real-time” scan results in Eclipse development environment.

Step 2: Scan Transports Automatically before Import

Focuses on object completeness and consistency. In order to do that, all transports that are marked for import are analyzed together. The aggregated object list of all those transports is checked for referenced objects that are missing-and thus would result in import errors, downgrades, outages and performance problems.

• Transport scan is triggered when someone tries to import one or multiple transports into the system
• If no findings, the import proceeds as normal
• If findings, results are presented in SAP Transport Management System user interface with a description of the finding, business impact, criticality and remediation guidance
• The user who started the import can either accept the findings and continue or he or she can skip the import process to follow the remediation guidance

Example inspection results from prior to transport import. 

Implementation Type 2: Continuous Monitoring of the Transport Queue

The second implementation type is not directly integrated into the transport process-instead, it is based on continuous monitoring of the transport queue, focusing solely on identifying security and compliance issues (e.g., new objects or content that would bring vulnerabilities into the production environment and potentially harm the system or lead to data theft or data loss).

Steps:

1. Transports are scanned in the background once they have been released and exported (these scans can be scheduled to run at regular intervals per user preference)
2. If errors are found, notifications are sent to assigned people showing the results of the scan
3. Detailed scan results, along with remediation guidance, can be viewed by logging into the system

SOX was enacted in 2002, and its ICFR provisions went into effect in 2003. Since then, numerous other countries have adopted similar laws, such as:

• Canada: Bill 198, commonly known as C-SOX
• China: The Basic Standard for Internal Control, or ‘China SOX’
• Japan: The Financial Instruments and Exchange Act, or J-SOX

The European Union addresses corporate financial reporting through several directives, which each member state must then “translate” into national law. The EU 8th Company Directive addresses the duties of the audit committee and internal audit functions, including the effectiveness of internal controls.

Some countries don’t have a specific law that requires attention to ICFR, but have other regulations or codes that imply management’s responsibility for ICFR. For example, Britain does not have a “UK SOX” law, but the U.K. Corporate Governance Code holds corporate boards responsible for internal control generally, including ICFR.

The Sarbanes-Oxley Act (SOX) requires publicly-traded companies to maintain adequate controls over financial reporting (Section 404 of the law) so that management can certify that the company’s financial statements are a fair and accurate representation of financial performance (Section 302 of the law).

All filers are subject to Section 404(a), which says management must assess and report on the company’s internal control over financial reporting (ICFR).  Large filers are also subject to Section404(b), which requires an audit of ICFR by a certified public accounting firm.  Smaller filers are exempt from Section 404(b).

A company does not need effective ICFR to meet filing standards for the Securities and Exchange Commission: it can report that it has ineffective ICFR, usually by disclosing one or more weaknesses in its internal controls.  It does, however, need to make accurate disclosures about internal controls over financial reporting.

For example, if management attests to effective ICFR under Section 404(a), but auditors find weaknesses as they perform their duties under Section 404(b), then the certification senior executives make about financial statement accuracy under Section 302 of SOX are no longer reliable. 

Ineffective ICFR is often the precursor to a financial restatement. In the worst cases, CEOs and CFOs could be personally liable for making false statements under Section 302.

The Role of Cybersecurity in ICFR

Cybersecurity is crucial to ICFR and SOX compliance, but too often, the threat is misunderstood.

For example, user access controls to financial systems are one potential weakness; so are poor password reset policies, internal control frameworks already exist to help companies implement strong controls over those areas, and audit firms review and test those controls regularly. 

Those examples, however, only address cybersecurity at the application level.  Companies subject to SOX compliance must also consider cybersecurity risks at the infrastructure and data levels.

That is, an unauthenticated attack targeting a misconfiguration or vulnerability in your ERP system could let hackers manipulate underlying financial data without touching financial applications or leaving an audit trail. Even with strong internal controls and audits at the data and infrastructure layers, those other security weaknesses in the application layer can still leave financial data subject to exploitation.

So declarations about ICFT would not be correct, and the company would not be in SOX compliance like executives (and auditors) might mistakenly believe.

Steps to Take

• Understand the nature of this security threat and assign responsibility for it. CISOs may not understand the nuances of SOX compliance, while internal audit teams may not grasp how weak ERP security creates risks that evade internal control. Don’t let the issue go ignored.
• Develop a security strategy for mission-critical applications that encompasses ICFR concerns.  That strategy should address system configuration, log management, custom application development, patches, continuous monitoring and more. Otherwise your ICFR will remain vulnerable.
  
• Find the right tools to do the job.  Security, finance and audit teams need to identify weaknesses  that jeopardize ICFR, and then seal those gaps.  With ERP systems’ complexity supporting mission-critical applications,that’s no easy task. Using the right technology is crucial to success.

GDPR came into force in 2018. It has since become the model for other new data privacy laws cropping up around the world, such as:

• The California Consumer Privacy Act (CCPA)
• Brazil’s General Law for Protection of Privacy (LGPD)
• Canada’s Personal Information Protection and Electronic Documents Act (PIPEDA)
• Japan’s Act on Protection of Personal Information
• Australia’s Privacy Act 

All of these laws work from the premise that personal data belongs to the individual, so companies collecting that data must meet certain duties of care to protect it. Chief among those duties is keeping the data secure from unauthorized access or  processing— including from hackers that might exploit weaknesses in mission-critical applications to reach PII in your company’s control.

The European Union’s General Data Protection Regulation (GDPR) is a far-reaching law that provides a set of privacy rights for all EU citizens. Any business working in the EU, as well as any business anywhere in the world that collects personal data about EU citizens, must comply with those GDPR standards or risk severe financial penalties. Some of these GDPR guarantees include:

• Right of access: an individual has the right to see all personal data a company has collected about him or her, upon request;
• Right of rectification; an individual can demand that inaccurate personal data about him or her be corrected, which the company must do within 30 days;
• Right of erasure: an individual can also request that personal data a company has collected about him or her be deleted.

GDPR doesn’t specify how a company must fulfill these rights; it only requires that a company covered by GDPR fulfill those rights somehow. 

Likewise, the GDPR mandate does not expressly say that businesses must encrypt the personal data they collect about individuals. Instead, GDPR repeatedly cites encryption and pseudonymization as examples of the “appropriate technical and organizational measures” a company must take to assure the security of personal data it collects.

GDPR has also become a model for other privacy laws, such as the California Consumer Privacy Act. While CCPA and GDPR aren’t identical, both are rooted in the principle that personal data belongs to the person, rather than to the company collecting the data. As such, the company must meet certain standards of care while personal data is in its possession—such as keeping the data secure.

The Role of Cybersecurity in GDPR Compliance

Article 5 of the GDPR mandate states that personal data must be protected against “unlawful or unauthorized processing; and against accidental loss, destruction, or damage.” This is where cybersecurity enters the GDPR compliance picture. The data must be protected from unlawful or unauthorized manipulation.

Part of that challenge is to keep unauthorized users away (PII) resides. Another part, however, is to protect data itself, at the data and infrastructure layers.

That is, hackers could target a misconfiguration or vulnerability in the company’s mission-critical applications, and gain access to personal data without using business applications or leaving an audit trail. Even with strong internal controls and audits at the infrastructure or database levels, weaknesses in the application layer can still leave personal data exposed to unauthorized manipulation—and leave the company violating GDPR.

The potential fines for violating GDPR are substantial; to €20 million or 4% of an organization’s global revenue, whichever is greater.

Steps to Take

• Understand the security nuances of GDPR compliance. CISOs may not understand the details of GDPR compliance, while internal audit and compliance teams, as well as the Data Protection Officer (DPO) may not grasp all the attack vectors that could create GDPR risk. You need a thorough assessment of GDPR risk.
  
• Develop a security strategy for mission-critical applications that encompasses GDPR compliance. That strategy should address configuration management, log management, custom application development, patches, continuous monitoring and more.
  
• Find the right tools to do the job. Security teams, in conjunction with internal audit and compliance, need to identify weaknesses that jeopardize GDPR compliance and seal those gaps. With modern ERP systems supporting mission-critical applications, that’s not easy. Using the right technology is crucial to success.