Secure Development Management Standard
Establish and align secure development approach across all Corporate Group products according to industry leading best practices
Purpose
Establish and align secure development approach across all Corporate Group products according to industry leading best practices as well as meeting specific requirements and needs of the Corporate Group throughout the entire development lifecycle - to ensure integrity of the applications and systems from external and internal threats, and to prevent user information disclosure, theft, modification, destruction.
Scope
This Standard is applicable to all Corporate Group employees, interns, Third-parties who are either directly or indirectly control, support, maintain, are in any other capacity involved with past, current or future Corporate Group’s development environments, infrastructure and any systems relating to development processes and their integration.
Roles and Responsibilities
Software security roles, responsibilities, expectations and skills required must be clearly defined and assigned to appropriate software development personnel, individually or in teams.
Software Development Team Leads roles and responsibilities:
Must decide on the exact details and implementation
Prepare secure development principles and guidelines
Must help train and maintain secure development practices
Considering team structure, needs and realities of the product development processes, for example: Developers must follow secure coding rules, and should diligently apply secure development training; QA must make sure that all mandatory secure coding checklists are complete.
Training and culture
A continuous process of training, developing and maintaining software security skills must be established for technical personnel involved in development and security.
Privacy in the Software Development Lifecycle (SDLC)
The principles of personal data protection must be integrated into the Software Development Life Cycle from the design phase onwards to protect the privacy of the people whose data is processed.
Put privacy protection at the center of development process by adopting a Privacy By Design and by Default methodology which includes, but is not limited to:
Considering privacy protection, including data security requirements, at the design stage of the application or service
For any development aimed at the general public, considering the privacy settings, and in particular the default settings, such as the characteristics and user content visible by default
Using programming standards that take into account safety
Thinking about the different types of data that is needed to be collected before collection and trying to limit the collection to what is strictly necessary
Remembering that personal data cannot be kept for an indefinite period of time: this must be defined according to the purposes of the processing. Once this purpose has been achieved, the data should be archived, deleted or made anonymous.
Secure the Software Development Lifecycle (SDLC)
Security must be integrated into all layers and phases of the Software Development Life Cycle by logically adapting the following stages as guiding building blocks: Requirements (both functional and non-functional), Design, Development, Test, Release, End of Life.
It is recommended, but not mandatory, that a team adopts and adapts an already industry standard framework and methodology such as, but not limited to - BSIMM10, MSSDL, ISO/IEC 27034, OpenSAMM.
An example of a Secure SDLC workflow can be found in Appendix A.
Security checkpoints should be established within the project milestones to check if the requirements have been met.
The adopted Secure SDLC and auxiliary processes must be documented and published:
Continual feedback should be gathered to improve upon the process and redesign it, if necessary.
Secure development environments
This includes people, processes and technology associated with system development and integration, including but not limited to developers, QA personnel, Security testers, as well as repositories, code version control, CI/CD pipelines, development frameworks.
The possible attack surface where possible must be minimised with a consideration for the ability to effectively develop and use the systems.
The CI/CD pipeline must be trusted, secured and ensured that controls cannot be bypassed or re-ordered.
Environments within the broader software development ecosystem must be separated into at least development, testing and production.
Roles, duties and their distinct level of access and authorization must be clearly defined and based strictly on least-privilege principle, as well as properly documented.
Where possible additional layers of access security must be used, like 2FA or physical security tokens.
Re-use of passwords between different environments should be discouraged if possible, for example by making password vaults available to employees.
Access whitelist by IP address must be established.
If possible, physical network segregation is strongly recommended to be established between different environments, including appropriate controls, like firewall configurations.
Whenever possible, different environments should be run on different processors or different domains, or directories.
Zero Trust principles should be considered for overall development environment architecture methodology.
Test data and environment:
Personally identifiable or any other confidential information should be avoided for testing purposes, or at least modified or otherwise protected
Separate access controls must be used for test environments
Separate authorization each time operational information is copied to a test environment must be used
Operational information must be immediately disposed of after testing is done
Securing Repositories:
Only a trusted and authorised code repository with version control functionality must be used.
At a minimum, the version control system must describe the change, record who made the change, retain the date and time of change, retrieve past versions, and compare versions; with appropriate measures to ensure integrity of this information.
Repository must not contain and mix different projects
All software development environment access controls must follow and comply with Access Control Policy
Change control must be performed in accordance with Change Management Standard.
Tools and 3rd party libraries:
A list of approved tools and their associated security checks, such as compiler options and warnings, must be defined, published, and thoroughly introduced to the development personnel
All 3rd party libraries and components in use must be inventoried, documented, audited and monitored for security vulnerabilities and changes
Monitoring and audit trail:
All activity should be captured in at least minimum acceptable detail to correctly identify what activity was performed, who performed them, the time they were performed, and which assets were impacted
A discrete process should be implemented and documented for at least monthly offsite backups of critical data according to Information Backup and Recovery Standard.
Processes, guidelines and playbooks of setup, maintenance and management of the secure development environments must be documented and appropriately stored.
Secure development principles and guidelines
A secure coding standard should be implemented, led and guided by development team leads, or appropriate level/seniority personnel, and may be based on an industry staple, for example - CERT Secure Coding project, CWE and CWE Top 25, CVE, OWASP and OWASP Top 10, PA-DSS, IEC 62443.
Team leads, or appropriate level/seniority personnel, should initiate and curate documentation of principles, design guidelines, best practices and requirements that are realistic and enforceable, and represent the working environment and tools.
Examples of secure coding principles and guidelines can be found in Appendix B., Sections 1 and 2 accordingly.
Vulnerability management and security testing
An internal channel to report vulnerabilities and issues must be established and make widely known.
A robust system of code review must be implemented.
Where applicable, within the SDLC continual testing mechanisms must be implemented, such as:
Vulnerability scanning
Static application security testing
Dynamic application security testing
Penetrating
Other types of industry standard automated or manual testing methods that are reasonable for the software and frameworks in use
Vulnerabilities must be addressed in ways described in Vulnerability Management Process.
If reasonable and possible the following may be implemented:
External responsible disclosure system and as an extension - bug bounty program
Security debt documented, assessed and addressed before becoming a vulnerability
Post-mortems performed and made available as exemplary cases to learn from, as well as add them to secure coding documentation
Review and update process
This Policy is maintained in accordance with the Information Security Policy.
An annual process should be implemented to identify, monitor, and satisfy external regulatory and compliance requirements.
All methodologies and processes should be reviewed and updated at least once a year following internal needs, industry best practices, or as frequently as necessary - depending on the established security metrics, system changes (i.e., operating systems, databases, middleware platforms), platform migrations and similar cases.
All linked standards, policies and plans, such as Business Continuity plan, should be followed-up upon and edited if necessary.
Continuous improvement of the whole software security ecosystem should be established to match evolving threats, updates, as well as to meet any external requirements and regulations.
Outsourced development
Any outsourcing of software development, where logical, should address, document, and verify acceptance of the following points using appropriate methods (i.e., questionnaires, interviews, contracts):
Any licensing arrangements, code ownership, and property rights
Contractual requirements for secure design, coding, and testing practices
Provision and instruct upon an approved threat model to the external developer
In fair detail describe the acceptance testing for the quality of the product
Delineate provisioning of evidence that security thresholds and standards were used to establish least minimum acceptable levels of security, integrity, and privacy.
Process of delivery evidence that sufficient testing was performed:
To guard against absence of both intentional and unintentional malicious content
Presence of known vulnerabilities
Any other agreed upon and reasonable testing standards
Contractual right to audit development process and control
Sufficient documentation of the build environment used to create deliverables
Updating process and patching systems from future vulnerabilities
Evaluate the outsourced Third-parties security stance in comparison to this Standard.
Standard Review and Update
This Standard must be maintained in accordance with the Information Security Policy.
Appendix A
Example of a Secure SDLC workflow:
Concept and planning
Security objectives
Requirements
Security training
Architecture and design:
Threat modelling
Secure design
Third party software tracking
Implementation:
Secure coding
Static scanning
Code review
Testing and bug fixing:
Dynamic scanning
Vulnerability scanning
Pen-testing
Fuzzing
Release and maintenance:
Environment management
Incident Response plan
Ongoing security checks
End of Life:
Data Retention
Data disposal
Appendix B
Example of secure coding principles:
Security is part of the design
Assume a hostile environment
Use open standards
Minimize and protect system elements to be trusted
Protect data at the source
Limit access to need-to-know
Authenticate
Do not subvert in-place security protections
Fail Securely
Log. Monitor. Audit
Accurate system date and time
Example to Design Guidelines (based on OWASP Top 10) to prevent the following vulnerabilities:
Injection flaws
Buffer overflows
Insecure cryptographic storage
Insecure communications
Improper error handling
Cross-site scripting (XSS)
Improper access control
Cross-Site Request Forgery
Broken authentication and session management
Revision History
0.1
LŠ
GK
2023-05-20
2023-05-23
0.2
LŠ
DM
2023-11-02
2023-11-02
0.3
GK
DM
2024-09-10
2024-09-10
Last updated