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


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

Approval date

2024-06-13

Approved with

ISMS-1331 in MR 1054

Last reviewed

2024-06-13 with ISMS-1331

Classification

Public