This Secure Development Life Cycle Instruction (“SDLC Instruction”) forms a part of the service agreement (the “Agreement") entered into by Company and Developer (jointly referred to as ‘parties’), in which this SDLC Instruction is incorporated by reference.
1. Definitions
1.1 In this SDLC Instruction the following capitalised terms shall have the meanings set out below:
|
Company |
means AWIN AG of Otto-Ostrowski-Straße 1A, 10249 Berlin, Germany, incorporated in Germany with company number HRB 75459, an AWIN Group Company; |
|
Developer |
means the party carrying out the software development under this Agreement; |
|
Privacy Principles |
means a set of mandatory privacy requirements to be observed by Developer when providing Services to the Company; |
|
Security Principles |
means a set of mandatory security requirements to be observed by Developer when providing Services to the Company; |
|
Services |
means the design, development, maintenance, implementation, support, testing, and documentation services and other services as may be required to create, enhance, improve, modify, update, or upgrade software applications in scope of this Agreement. |
2. General
2.1 To ensure fulfilment of information security requirements, security shall be considered during all stages of the system development life cycle. This SDLC Instruction is intended to clarify the security-related rights and obligations of all the parties to a software development relationship.
2.2 At the highest level, the parties agree that:
2.2.1 Security decisions will be based on risk: Decisions about security will be made jointly by both Company and Developer based on a firm understanding of the risks involved.
2.2.2 Security activities will be balanced: Security effort will be roughly evenly distributed across the entire software development lifecycle.
2.2.3 Security activities will be integrated: All the activities and documentation discussed herein can and should be integrated into Developer’s software development lifecycle and not kept separate from the rest of the project. Nothing in this SDLC Instruction implies any particular software development process.
2.2.4 Vulnerabilities are expected: All software has bugs, and some of those will create security issues. Both Company and Developer will strive to identify vulnerabilities as early as possible in the lifecycle.
2.2.5 Security information will be fully disclosed: All security-relevant information will be shared between Company and Developer immediately and completely.
2.2.6 Only useful security documentation is required: Security documentation does not need to be extensive in order to clearly describe security design, risk analysis, or issues.
2.3 Requirements of this SDLC Instruction must be specified and applied towards all actors in the Developer’s supply chain, including when any parts or deliverables of the Services is outsourced.
3. Lifecycle Activities
3.1 Risk understanding: Developer and Company agree to work together to understand and document the risks facing the application. This effort should identify the key risks to the important assets and functions provided by the application. Each of the topics listed in the Privacy and Security Principles section should be considered.
3.2 Requirements: Based on the risks, Developer and Company agree to work together to create detailed security requirements as a part of the specification of the software to be developed. Each of the topics listed in the requirements section of this SDLC Instruction should be discussed and evaluated by both Developer and Company. These requirements may be satisfied by custom software, third party software, or the platform.
3.3 Design: Developer agrees to provide documentation that clearly explains the design for achieving each of the security requirements. In most cases, this documentation will describe security mechanisms, where the mechanisms fit into the architecture, and all relevant design patterns to ensure their proper use. The design should clearly specify whether the support comes from custom software, third party software, or the platform.
3.4 Implementation: Developer agrees to provide and follow a set of secure coding guidelines and to use a set of common security control programming interfaces (such as the OWASP Enterprise Security API (ESAPI)). Guidelines will indicate how code should be formatted, structured, and commented. Common security control programming interfaces will define how security controls must be called and how security controls must function. All security-relevant code must be thoroughly commented. Specific guidance on avoiding common security vulnerabilities must be included. Also, all code must be reviewed by at least one other developer against the security requirements and coding guideline before it is considered ready for unit test.
3.5 Security Analysis and Testing: Developer will perform application security analysis and testing (also called ‘verification’) according to the verification requirements of an agreed-upon standard (such as the OWASP Application Security Verification Standard (ASVS)). The Developer must document verification findings according to the reporting requirements of the standard. The Developer must provide the verification findings to Company.
3.6 Secure Deployment: Developer agrees to provide secure configuration guidelines that fully describe all security relevant configuration options and their implications for the overall security of the software. The guideline must include a full description of dependencies on the supporting platform, including operating system, web server, and application server, and how they should be configured for security. The default configuration of the software must be secure.
4. Privacy and Security Principles
4.1 The following topic areas shall be considered during the risk understanding and requirements definition activities. This effort should produce a set of specific, tailored, and testable requirements Both Developer and Company shall be involved in this process and should agree on the final set of requirements.
4.2 Privacy Principles:
4.2.1 Data protection issues must be considered as part of the design and implementation of systems, services, products and business practices;
4.2.2 Data protection should be made an essential component of the core functionality of data processing systems and services;
4.2.3 Risks and privacy-invasive events should be anticipated before they occur and adequate steps must be taken to prevent harm to individuals;
4.2.4 Processing of personal data must be limited to ensure that only such personal data is processed that is needed for the purposes(s) of providing Services, and that the use of this data is only for those purposes;
4.2.5 It must be ensured that personal data is automatically protected in any IT system, service, product, and/or business practice, so that individuals should not have to take any specific action to protect their privacy;
4.2.6 Strong privacy defaults, user-friendly options and controls shall be offered to ensure that user preferences are respected;
4.2.7 Identity and contact information of those responsible for data protection should be provided to both our Company and to individuals or organisations whose data will be processed as part of providing the Services;
4.2.8 Only such data processors can be used that provide enough guarantees of their technical and organisational measures for data protection by design. When other systems, services or products are being used while and in connection with delivering the Services, it must be ensured that only those whose designers and manufacturers take data protection issues into account are being used;
4.2.9 Where applicable and technically feasible, privacy-enhancing technologies must be used to assist in ensuring compliance with privacy by design obligations.
4.3 Security Principles:
4.3.1 Secure defaults: The requirements shall specify that, by default, the experience should be secure, and it should be up to the user to reduce their security – if they are allowed.
4.3.2 Defence in depth: The requirements shall sufficiently consider the defence in depth principle to ensure that where one control would be reasonable, more controls that approach risks in different fashions are better.
4.3.3 Minimise attack surface: The requirements shall consider the rules for reducing the overall risk by reducing the attack surface area.
4.3.4 Input validation and encoding: The requirements shall specify the rules for canonicalizing, validating, and encoding each input to the application, whether from users, file systems, databases, directories, or external systems. The default rule must be that all input is invalid unless it matches a detailed specification of what is allowed. In addition, the requirements must specify the action to be taken when invalid input is received. Specifically, the application must not be susceptible to injection, overflow, tampering, or other corrupt input attacks.
4.3.5 Authentication and session management: The requirements shall specify how authentication credentials and session identifiers will be protected throughout their lifecycle. Requirements for all related functions, including forgotten passwords, changing passwords, remembering passwords, logout, and multiple logins, must be included.
4.3.6 Access control: The requirements shall include a detailed description of all roles (groups, privileges, authorizations) used in the application. The principles of least privilege and separation of duties shall be considered when defining all roles in the application. The requirements shall also indicate all the assets and functions provided by the application. The requirements shall fully specify the exact access rights to each asset and function for each role. An access control matrix is the suggested format for these rules.
4.3.7 Error handling: The requirements shall detail how errors occurring during processing will be handled. Some applications should provide best effort results in the event of an error, whereas others should terminate processing immediately.
4.3.8 Logging: The requirements shall specify what events are security-relevant and need to be logged, such as detected attacks, failed login attempts, and attempts to exceed authorization.
The requirements shall also specify what information to log with each event, including time and date, event description, application details, and other information useful in forensic efforts.
4.3.9 Connections to external systems: The requirements shall specify how authentication and encryption will be handled for all external systems, such as databases, directories, and web services. All credentials required for communication with external systems must be stored outside the code in a configuration file in encrypted form.
4.3.10 Encryption: The requirements shall specify what data must be encrypted, how it is to be encrypted, and how all certificates and other credentials must be handled. The application shall use a standard algorithm implemented in a widely used and tested encryption library.
4.3.11 Availability: The requirements shall specify how it will protect against denial of service attacks. All likely attacks on the application should be considered, including authentication lockout, connection exhaustion, and other resource exhaustion attacks.
4.3.12 Secure configuration: The requirements shall specify that the default values for all security relevant configuration options must be secure. Developer should avoid the use of double negatives and complex architectures when a simpler approach would be faster and simpler. Security by obscurity shall be avoided. For audit purposes, the software should be able to produce an easily readable report showing all the security relevant configuration details.
4.3.13 Specific vulnerabilities: The requirements shall include a set of specific vulnerabilities that must not be found in the software. If not otherwise specified, then the software must not include any of the flaws described in the current ‘OWASP Top Ten Most Critical Web Application Vulnerabilities’.
4.3.14 Fail securely: The requirements shall specify that security mechanism should be designed in such a way that a failure shall follow the same execution path as disallowing the operation.
5. Personnel and Organization Requirements
5.1 Security Architect: Developer will assign responsibility for security to a single senior technical resource, to be known as the project Security Architect. The Security Architect will certify the security of each deliverable.
5.2 Security training: Developer will be responsible for verifying that all members of the developer team have been trained in secure programming techniques.
5.3 Trustworthy developers: Developer agrees to perform appropriate background investigation of all development team members.
6. Development Environment
6.1 Secure development environment: A secure development environment should be maintained throughout the entire development life cycle. This should include such measures as:
- segregation between different development environments,
- control of access to the development environment, and
- control of movement from and to the environment.
6.2 Secure coding: Developer shall disclose what tools are used in the software development environment to encourage secure coding.
6.3 Configuration management: Developer shall use a source code control system that authenticates with two factors and logs the team member associated with all changes to the software baseline and all related configuration and build files.
6.4 Distribution: Developer shall use a build process that reliably builds a complete distribution from source. This process shall include a method for verifying the integrity of the software delivered to Company.
7. Libraries, Frameworks, and Products
7.1 Disclosure: Developer disclose all third party software used in the software, including all libraries, frameworks, components, and other products, whether commercial, free, open-source, or closed-source.
7.2 Evaluation: Developer shall make reasonable efforts to ensure that third party software meets all the terms of this agreement and is as secure as custom developed code developed under this agreement.
8. Security Reviews
8.1 Right to review: Company has the right to have the software reviewed for security flaws at their expense at any time within 60 days of delivery. Developer agrees to provide reasonable support to the review team by providing source code and access to test environments.
8.2 Review coverage: Security reviews shall cover all aspects of the software delivered, including custom code, components, products, and system configuration.
8.3 Scope of review: At a minimum, the review shall cover all of the security requirements and should search for other common vulnerabilities. The review may include a combination of vulnerability scanning, penetration testing, static analysis of the source code, and expert code review.
8.3.1 Non-production code that is assessed by Company to be essential to the operation of the platform and where a failure to include in analysis may lead to increased risk to the confidentiality, integrity or availability of the platform and the data it contains must be identified.
8.4 Review method: Automated testing should be used to detect security issues during code review. Where no automated process is available all code must be peer reviewed and evidenced before deployment, referencing the Secure Code Guidelines, OWASP Top Ten and CWE Top 25.
8.5 Issues discovered: Security issues uncovered will be reported to both Company and Developer. All issues will be tracked and remediated as specified in the Security Issue Management section of this SDLC Instruction.
8.6 Security review upon changes: Company has the right to perform additional security review upon any changes that it may become aware of that may impact the confidentiality or integrity of the software or the data processed within that software.
9. Reporting of vulnerabilities and security issues
9.1 Reporting of vulnerabilities: A process must be established between the Company and Developer to accept and address reports of software vulnerabilities or security issues identified outside of the Security Reviews described in section 8 of this SDLC Instruction. This includes agreeing on the process and providing means for external entities to report vulnerabilities to the Company and Developer.
10. Security Issue Management
10.1 Identification: Developer will track all security issues uncovered during the entire lifecycle, whether
a requirements, design, implementation, testing, deployment, or operational issue. The risk associated with each security issue will be evaluated, documented, and reported to Company as soon as possible after discovery.
10.2 Protection: Developer will appropriately protect information regarding security issues and associated documentation, to help limit the likelihood that vulnerabilities in operational Company software are exposed.
10.3 Remediation: Security issues that are identified before delivery shall be fixed by Developer. Security issues discovered after delivery shall be handled in the same manner as other bugs, vulnerabilities and issues as specified in this Agreement.
11. Assurance
11.1 Assurance: Developer will provide a “certification package” consisting of the security documentation created throughout the development process. The package should establish that the security requirements, design, implementation, and test results were properly completed and all security issues were resolved appropriately.
11.2 Self-certification: The Security Architect will certify that the software meets the security requirements, all security activities have been performed, and all identified security issues have been documented and resolved. Any exceptions to the certification status shall be fully documented with the delivery.
11.3 No malicious code: Developer warrants that the software shall not contain any code that does not support a software requirement and weakens the security of the application, including computer viruses, worms, time bombs, back doors, Trojan horses, Easter eggs, and all other forms of malicious code.
12. Security Acceptance and Maintenance
12.1 Acceptance: The software shall not be considered accepted until the certification package is complete and all security issues have been resolved.
12.2 Investigating security issues: After acceptance, if security issues are discovered or reasonably suspected, Developer shall assist Company in performing an investigation to determine the nature of and the root cause of the issue. The issue shall be considered “novel” if it is not covered by the security requirements and is outside the reasonable scope of security testing.
12.3 Novel security issues: Developer and Company agree to scope the effort required to resolve novel security issues, and to negotiate in good faith to achieve an agreement to perform the required work to address them.
12.4 Other security issues: Developer shall use all commercially reasonable efforts consistent with sound software development practices, taking into account the severity of the risk, to resolve all security issues not considered novel as quickly as possible.
13. Changes to this SDLC Instruction
13.1 Company may make changes to this policy by giving at least 30 days’ written notice (including by email) to Developer.
13.2 Developer shall notify Company in case it cannot meet the new requirements and the parties will enter into discussions in good faith to find an agreeable solution. Should the parties not be able to reach an agreeable solution within 30 days, Company may terminate the service agreement with Developer, giving 14 days’ written notice (including by email).
