SAP corporation is an international software company that have developed its own requirements regarding the quality of products it develop, maintain and support. Some of them comes from the ISO or other quality organisation around the world but SAP as a world leading company in software development have developed its owns over time.
The SAP Quality Goal for product development at SAP is based on the following quality topics:
From now on, we will focus on Product Quality and more specifically on Product Standards that is part of a more global SAP quality policy that cover a lot more than software product development.
Product Quality at SAP is named Product Standards, aka PS, and define software product qualities which need to be fulfilled by all SAP products to enable SAP‘s business model. To do so, product standards define requirements to enable selling SAP products worldwide, efficient support, reaching all kinds of users, mitigating risk of lawsuits, up- and cross-selling into existing customer landscapes, and so on.
SAP has integrated Product Standards into the development process to achieve transparency about SAP products' qualities.
PS Accessibility defines rules for incorporating accessibility into the software development lifecycle to ensure that the resulting products can be used by people with disabilities.
PS Business Configuration (BC) supports the delivery of pre-configured content. The standard ensures high-quality best practices process and configuration content delivery as part of the product.
PS Functional Correctness concerns the completeness and correctness of SAP software products for new and existing functionality.
PS Globalization aims to align SAP’s sales and country strategy with its development efforts. The standard contains technical facets related to internationalization that ensure that SAP creates products that are flexible to meet the needs of our users around the world. It also contains nontechnical facets related to localization and translation, which help plan the product’s release strategy.
PS Licensing manages the approval process for all use and distribution of commercial, open source and other third party software and services in SAP products.
PS Operations & Support defines the criteria needed to provide customers with a standardized management concept to operate the business processes and the underlying system landscape with optimal availability, optimal performance and lowest cost of ownership. In addition it provides the criteria needed for software components to be supportable in a most efficient way via SAP standardized support processes.
PS Performance defines criteria that guarantee good performance and scalability of components, scenarios, and processes for new developments and upgrades of SAP applications.
PS Security defines a state-of-the-art security concept for all SAP software. It addresses security vulnerabilities, security legal requirements, and SAP strategy topics related to security.
PS Software Lifecycle ensures and improves the technical product qualities that make SAP software available for use within enterprise system landscapes. This includes a secure and reliable software development, an efficient shipment, a straightforward installation and easy technical configuration as well as a smooth upgrade/update, and a flawless un-installation of SAP software.
The PS Documentation is no longer in place. However, SAP absolutely needs to provide product documentation with the software to customers. This is now ensured by the corporate task User Assistance (Product Documentation) in All Relevant Languages.
Product Standard Usability have also been phased out from the PS. For guidance on usability and user experience, Product Owner must now refer to the SAP’s Ux Design Community.
The Product Standards (PS) Compliance process is a process in where every SAP product needs to plan, implement, test, and report its fulfillment of the product standard requirements. This process is a lean type governance one.
The Product Owner is responsible for the requirements of the products, which includes the level of compliance with Product Standard Requirements. The deviations and non-applicability in Product Standard compliance are approved by the Product Owner with the exception of Corporate Product Standard requirements and the Product Standard Security, where separate or additional rules apply.
The PS Owners are no longer approving PS compliance deviations and non-applicability. They will focus on continuous improvement of Product Standards, PS education, PS consulting, and PS assessments. The Product Standard Owners will conduct PS assessments for products on an ongoing basis. PS assessments are applicable only to selected programs. The selection criteria are based on multiple product factors such as: strategic importance, risk level, planned or reported PS compliance etc.
The status of the Product Standards contribute to product readiness.
In order to obtain the required quality in the PS compliance process SAP require to follow some guidelines:
Product Standard Owners no longer approve deviations and non-applicability of requirements, but provide a risk statement instead. Approvals to Product Standard deviations and non-applicability is provided by the responsible Qualification Program Director (QPD) from the Premium Qualification Team after consultation with the Qualification Project Manager and the Product Owner / Technical Owner (“Product Owner” stands for SAP Development Partner Contact). The approval process for Corporate Product Standard deviations remains unchanged, i.e. approval by L1 Management.
Product Standards Assessment is a structured analysis, conducted by one or more PS Owners, to verify planned, developed, and reported PS compliance of the product. Not all products are subject to the PS assessment. The program selection is based on multiple influencing factors such as strategic importance, risk level, planned or reported PS compliance etc. Furthermore, not all product standards will be in the scope of each PS assessment. The product standards included in an assessment will also be determined based on the influencing factors mentioned above. PS Owners are making the final decision on which program will be assessed, and what is the scope of the corresponding assessment. If you want to improve and increase compliance for your delivery, you could request an assessment via email to SAP_Product_Standards.
The Assessment Lead, in alignment with the Program Lead (PL), evaluates the product components belonging to the corresponding programs in more detail. Dates, the detailed scope, and points of contact are determined as preparation for the next phase.
For the product standards that are in scope of the assessment, the corresponding PS Owners assess the product. The methods used are determined by the PS Owners, and consist of activities such as planning inspections, code inspections, interviews etc. At the end of this phase, the PS Owners summarizes the findings of the complete PS assessment.
The draft version of the findings is presented to the program. Action items with owners and dates are agreed upon. Follow-up activities are identified, and if agreement is reached, action items in Sirius will be created and a final summary email will be send by the assessment lead. If agreement on mandatory actions cannot be reached, the issue shall be decided by product standard sponsor together with senior management (L1 or L2) of the potential owner of the action.
If there are mandatory action items, the product is marked for a follow-up assessment. The follow-up assessment is planned and conducted in the same way as a product standard assessment. In this case, the mandatory action items from the assessment are the primary influencing factors when determining the scope of the follow-up assessment.
A Product Standard consists of a set of well-defined requirements. Product Standard requirements are defined to cover various needs and expectations:
Each product standard requirement is assigned to one of the following categories:
The requirements are applicable as follows:
The product standards requirements are available internally at SAP as a Microsoft Excel sheet that contain a very comprehensive checklist that cover all the themes listed in the overview. Each item in the checklist can have a Yes/No/N.A. answer type.
Here is an example for performance :
The acquired-to-ship and vendor-branded reseller programs use the ‘Product Standard Compliance Checklist for Vendor Branded Reseller Partner’.
Requirements can be defined as corporate or non-corporate Requirement.
A corporate requirement is a rule to protect SAP as a company from material damage by taking into account legal implications, significant business risks and international standards.
Each topics covered by the PS have a huge documentation that details them.
In order to detail a bit at least one of them, I have chosen the security topic since I am currently working at the SAP Security Research.
SAP software runs critical business processes and manages most valuable assets and sensitive data of their customers and consumers. Providing secure access to and preserving integrity, confidentiality and availability, data protection and privacy of these processes and data is key to our success and must be enforced by all SAP products and services. To achieve these qualities, to prevent software security vulnerabilities, and to allow for regulatory compliant system and service operations, SAP software needs to follow a secure software development lifecycle which includes planning and design, architecture, implementation, test, release preparation, shipment, maintenance and support.
The following artefacts shall be produced as outcome of the secure SDL:
For documentation of security risks, plans and reports, Products Owner shall use the respective functionality in SIRIUS (“Security Hub”). During execution of the security plan, the documents shall be kept updated for reporting.
Sufficient Security Awareness, Training and Education of all development and development-related roles in the product or service team are considered a prerequisite to comply with this requirement. Beyond that, there are further optional measures and artefacts that can help to achieve the desired security level of SAP software, such as code reviews or external security assessments.
By introducing the risk-based secure Software Development Lifecycle the product standard security acts as product security knowledge base containing best practices of secure software development and as a threat-library for the program specific risk assessment. The question whether a program needs to comply with a product standard requirement or not depends on the underlying risk that was identified and rated during the risk assessment. According to the lean governance concept the Product Owner is responsible to ensure an adequate security level in the product by managing risks and mitigations diligently. As a consequence a program can decide which risks can be accepted and which risks need to be partly or full mitigated, as long corporate requirements are not violated.
In case of corporate violations in addition an exceptional approval needs to be requested.
List of the requirements is provided in the table below ordered by relevant security topics. In addition, further columns of the table indicate if a requirement belongs to (A) Regulatory Compliance (B) Vulnerability Prevention (C) Strategy and Reduction of Attack Surface.
Requirements | (A) | (B) | (C) |
---|---|---|---|
Zero Vulnerabilities | X | ||
SEC-102 - No database query injection vulnerabilities. | X | ||
SEC-133 - No Cross-Site Scripting vulnerabilities | X | ||
SEC-136 - No Path Traversal vulnerabilities | X | ||
SEC-139 - No backdoors | X | ||
SEC-235 - No memory corruption vulnerabilities | X | ||
SEC-220 - Protect security sensitive cookies | X | ||
SEC-221 - Manage security sessions securely | X | ||
SEC-223 - No Cross-Site Request Forgery vulnerabilities | X | ||
SEC-225 - Perform Input Validation | X | ||
SEC-226 - Encode output properly for the component which is meant to process it | X | ||
SEC-229 - Validate all data that is used to dynamically generate code | X | ||
SEC 236 - No information disclosure to unauthorized receivers. | X | ||
SEC-237 - Protect against Denial-of-Service attacks | X | ||
SEC-238 - Protect against Verb Tampering and handle HTTP methods securely | X | X | |
SEC-243 - Load shared libraries and dynamic link libraries (DLLs) safely | X | ||
SEC-263 - No operating system command injection vulnerabilities | X | ||
SEC-264 - No clickjacking vulnerabilities | X | ||
SEC-267 - Securely process incoming XML documents | X | ||
SEC-278 - Handle URLs securely | X | ||
SEC-279 - Protect against CRLF Injection | X | ||
Secure Communications | |||
SEC-218 - Provide encrypted communication connections | X | X | |
Authentication | |||
SEC-276 - Enforce authentication for all non-public resources | X | X | |
SEC-230 - Provide standard identity management, authentication and single sign-on mechanisms | X | ||
SEC-231 - Provide secure User ID / Password authentication | X | ||
SEC-232 - Provide secure X.509 certificate authentication | X | ||
Authorization | |||
SEC-248 - Enforce a secure authorization concept | X | X | |
SEC-250 - Provide administration of authorizations based on platform tools | X | ||
Secure Data at Rest | |||
SEC-271 - Protect sensitive data when stored persistently | X | X | |
SEC-272 - Encrypt sensitive data when stored persistently | X | ||
Strong Crypto | |||
SEC-266 - Use recommended cryptography only | X | ||
Secure Multi-Tenancy | |||
SEC-253 - Implement multi-tenancy support in a secure way | X | ||
SEC-273 - Provide security configuration per tenant in a multi-tenant system | X | ||
Auditing and Logging | |||
SEC-215 - Log security relevant events | X | ||
SEC-268 - Log changes to program code and version | X | ||
Data Protection & Privacy | |||
SEC-218 (see “Secure Communications”) | |||
SEC-276 (see “Authentication”) | |||
SEC-248 (see “Authorization”) | |||
SEC-271 (see “Secure Data at Rest”) | |||
SEC-224 - Capture explicit user consent before collecting any personal data | X | X | |
SEC-254 - Log read access to sensitive personal data | X | X | |
SEC-255 - Provide a retrieval function which can be used to inform the data subjects about the personal data stored about them. | X | X | |
SEC-256 - Erase personal data when all applicable retention periods have expired | X | X | |
SEC-265 - Log changes to personal data | X | X | |
Secure-by-default | |||
SEC-239 - Fail securely | X | ||
SEC-244 - Deliver with a secure default configuration | X | ||
SEC-275 - Enforce address space layout randomization, executable space protection and buffer overflow protection | X | ||
Secure-by-design | |||
SEC-219 - Provide a risk-adequate second line of defense against malicious input from the Internet | X | ||
SEC-228 - Protect upload, download and display functions of untrusted files against MIME-type sniffing and virus attacks | X | ||
SEC-240 - Implement security functions based on a consistent and documented concept | X | ||
SEC-246 - All code delivered shall contribute to documented functionality | X | ||
SEC-247 - Provide a security guide explaining how to securely setup, configure, and operate | X | ||
SEC-258 - Provide separate access to administration functions | X | ||
SEC-262 - Do not decrease the security level with updates of security settings or configurations | X | ||
SEC-269 - Provide basic compliance with Content Security Policy | X | ||
SEC-274 - Protect authenticity and integrity of all released executable code and artifacts | X | ||
SEC-277 - Run with minimal privileges required at all layers | X |
There's a wiki page per requirements so Product Owner at SAP can have all the technical details easily.
Corporate Requirements and Corporate Product Standard Requirements explained in context of product security and data protection & privacy:
SAP has defined a Corporate Requirement Framework as part of the Global Development Policy.
A corporate requirement in this framework is defined as a rule to protect SAP as a company from material damage by taking into account legal implications, significant business risks and international standards. The SAP Quality Management (QM) Board approves and enacts the Corporate Requirements. All SAP units including affiliates and acquired companies have to comply with each corporate requirement.
For Security and Data Protection & Privacy two corporate requirements are relevant:
A Corporate Requirement can also define certain product standard requirements as corporate. That means non-compliance of a corporate product standard requirement leads automatically to non-compliance to the referring Corporate Requirement of the Corporate Requirement Framework.
For Data Protection & Privacy currently five corporate requirements are defined as part of the Product Standard Security:
In case of deviations of one or more of these corporate product standard requirements an exceptional approval needs to be requested.
The Global Security Policy is a criticality driven approach. The Corporate requirement Develop and Operate Secure Software Products defines the following non-compliance:
Besides of corporate product standard requirement deviations a corporate requirement non-compliance can also happen in case of a process violation.
For Security and DPP (Data Protection & Privacy) this means: