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. Reference Documents

3. Security in Development and Support Processes

3.1. Security of the Development Environment

The development environment must be protected from unauthorized access to prevent unsolicited program code from being introduced.

3.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) and stored as follows:

Program code from other sources must be carefully checked before it may be used.

3.1.2. Version Control

Code and all other files related to development are managed with VSHN’s distributed version control system and are thus cleanly versioned and checked for integrity.

3.1.3. Required Security Training

Management defines the requirements and the necessary knowledge required as part of the development process and proposes the training required for this purpose. Management documents appropriate training programs in the "Plan für Training und Awareness" (internal).

3.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).

The development team delivers a new software version as a defined package (for example Git Tag, Signed Software Package) together with a detailed list of changes (CHANGELOG). The operations team tests the new software version on a test system and updates the operations documentation.

4. 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 only via secure channels (for example TLS)

  • No clear text storage of authentication tokens or passwords

  • Enforcement of strong passwords, user has the possibility to change passwords

  • User accounts can be disabled

  • Prefer authentication based on PKI procedures over plain password authentication

  • Consider to use multi-factor authentication

  • Principle of least privilege

  • Role-based authorization

  • Privilege separation

  • Access to external resources via API token or service account

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)

  • 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 and analyzed on a regular base

In addition, specific guidelines apply to the individual programming languages used. These are documented in the technical guidelines in our Wiki.

5. 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

  • After completion of the test work, the data which isn’t fully anonymized must be completely removed from the test environment

  • Any transfer of production data to a test system must be logged (for example documented in the ticket)

This policy is tracked and approved by the CISO with ticket ISMS-176