ISMS Development Security Policy
1. Purpose, Scope and User
This policy documents VSHN’s fundamental rules for secure development.
This document applies to the development and maintenance of all services, architecture, software, and systems developed by VSHN AG.
Users of this document are all technical employees of VSHN AG.
2. Security in Development and Support Processes
2.1. Security of the Development Environment
The development environment must be protected from unauthorized access to prevent unsolicited program code from being introduced. Engineers at VSHN are responsible for securing their development environments.
2.1.1. Storage Location
Program code and all other files related to development are managed with distributed version control system (as of now mainly git).
Our Engineering Manifesto defines where to store which kind of source code.
2.1.2. Version Control
Code and all other files related to development are managed with distributed version control system (git) and are thus cleanly versioned and checked for integrity.
Software releases should be versioned according to our Engineering Manifesto.
2.1.3. Required Security Training
VSHN defines the requirements and the necessary knowledge required as part of the development process and proposes the training required for this purpose. Training programs are documented in our wiki (internal) in the "Plan für Training und Awareness" and VSHNeer Certifications & Accreditations
2.2. Management of System Changes
The transition from development to operation is performed according to the change procedure documented in Betriebsverfahren für Informations- und Kommunikationstechnik (internal).
Further the guidelines in the Engineering Manifesto have to be followed.
3. Principles for the Analysis, Development and Maintenance of Secure Systems
The following basic principles apply to all internal and external developments of VSHN:
- Input/data validation
User input must always be validated
Input validation must be done in the back end / server
Client-side validation only supplementary (for example to improve usability)
- Authentication
Authentication only via secure channels (for example TLS)
No clear text storage of authentication tokens or passwords
User accounts can be disabled / removed
Prefer authentication based on PKI procedures over plain password authentication
Use to use multi-factor authentication
Connect to the SSO infrastructure if possible
- Authorization
Principle of least privilege
Use role-based authorization if possible and appropriate
Privilege separation
Access to external resources via API token or service account
- Sensitive data
See Information Calssification Policy what considered sensitive data
If possible, refrain from storing sensitive data
If sensitive data is stored, it’s stored in encrypted form
Sensitive data only transmitted via secure channels (for example TLS)
- Cryptography
Use proven existing implementations, no proprietary developments
When using PKI, secure rotation of key material must be ensured
Storage of private keys in designated systems
- Error handling
Don’t log sensitive data such as passwords or private keys
Structured exception handling
Integration into central monitoring systems
- Audit trail
Operations with access to sensitive data must be logged
Operations that modify data should be logged
Log files should follow a clearly structured format to facilitate automated analysis
Log files should be backed up
Analysis of log files according to process in ISMS-1265
In addition, specific guidelines apply to the individual programming languages used. These are documented in the technical guidelines in our Wiki.
4. Handling test data
To test a system, usually test data is required. This test data should be as close as possible to the production data. The following principles apply to the use of test data:
Test data should be anonymized if possible
The same access control procedures apply to test and production systems
Any transfer of production data to a test system must be logged (for example documented in the ticket)
5. Reference Documents
| ISO 27001:2022 | ISO 27001:2013 | Control |
|---|---|---|
A.8.4 | A.09.4.5 | Access to source code |
A.8.25 | A.14.2.1 | Secure development life cycle |
A.8.27 | A.14.2.5 | Secure system architecture and engineering principles |
A.8.29 | A.14.2.8, 14.2.9 | Security testing in development and acceptance |
A.8.30 | A.14.2.7 | Outsourced development |
A.8.31 | A.12.1.4, 14.2.6 | Separation of development, test and production environments |
A.8.32 | A.12.1.2, 14.2.2, 14.2.3, 14.2.4 | Change management |
A.8.33 | A.14.3.1 | Test information |
Approval date | 2024-06-13 |
|---|---|
Approved with | |
Last reviewed | 2024-06-13 with ISMS-1331 |
Classification | Public |