Version: 3.0

Valid until: 2025-04-10

Classification: Low

Version Management

Purpose & background

In the interest of all the stakeholders, the top management of anDREa B.V. (hereafter called anDREa) is actively committed to demonstrably maintain and continually improve an information management system in accordance with the requirements of the ISO 27001:2017.

The purpose of this document is to describe the secure development policy of anDREa and the associated controls, checks and administrations. 

This document will be reviewed at least annually and when significant change happens.

Objectives

The objectives of this control are:

• To ensure that information security is designed and implemented within the development lifecycle of information systems (A.14.2).

Scope

The scope of this document corresponds to Clause 4 Context of the organisation.

Availability

This document is:

• required reading for:

• all employees and contractors of anDREa.

• available for all interested parties as appropriate.

Norm elements

A.14.2 Security in development and support processes

A.14.2.1 Secure development policy

Development within anDREa must meet the following requirements:

• It must be possible to apply sufficient segregation of duties to reduce unauthorised changes or misuse of data.

• It must be possible to separate facilities for testing systems and training users from operational systems.

• The activities of users should be recorded in logs where appropriate. Platform activities are logged, activities within a Workspace (responsibility of the user) are not logged.

• Information contained in log files must be adequately protected from unauthorised alteration or access. Log files are stored in Azure Log analytics Workspaces. New entries can be added, however logs cannot be changed or deleted (immutable).

• System administrator activities must be recorded in log files. These logs must be adequately protected from unauthorised alteration or access.

• It must be possible to give all users a unique user identification.

• Provisions must be made to limit and control the use of special authorisations. Special authorisations are regulated via Azure Privileged Identity Management (PIM). PIM is only issued to trained and mandated personnel. Activation of PIM is only valid for a set time period; activation e-mails are sent to licenseadmin@mydre.org and trained personnel with Security Administrator or Global Administrator roles for logging. PIM activations (activation, assignment and eligibility) are periodically reviewed by the Security Officer.

• Where (highly) sensitive information is concerned, it must be possible to use other technologies besides passwords for user identification and authentication. MFA is enforced and for all privileged authorisations, PIM must be activated.

• The use of strong passwords is enforced.

Security measures

• Quarterly, a back-up of the myDRE source code is deposited to an ESCROW service.

• For SaaS development, the DTAP-approach is used, see A.12.1.1 Documented operating procedures.

• anDREa does not possess any research data. Therefore, data is never used in the development, test and/or acceptance environments.

• The development and test environments are completely separated from acceptance and production environments. The only resources that are shared are:

• Virtual Machine templates, these can be shared between test, acceptance and production environments.

• The acceptance and production environment share the same Entra ID which means that members that exist in the Entra ID, exist in both environments, however access to the acceptance environment is restricted and only accessible on invitation.

• Access to the source code (Github) is limited to authorised personnel. This is done in accordance with A.9 Access control. Registration of access is done in anDREa People.

DTAP starting points

For the development of features, anDREa has the following environments:

• Development environment.

• Access: Developers to their own development environment.

• Hosting: Every developer has a development environment on his/her laptop.

• Testing environment.

• Access: Both testers and developers during the period that tests are carried out.

• Hosting: The test environment is hosted within Microsoft Azure.

• Acceptance environment.

• Access: Developers, Support & Assurance team and invited users for the period they perform acceptance testing.

• Hosting: The acceptance environment is hosted within Microsoft Azure.

• Production environment.

• Access: Researchers. anDREa employees and Research Support Team members do not have access to Workspaces unless specifically invited as a Workspace member. 

• The production environment is hosted within Microsoft Azure.

Working method

anDREa uses the following method to develop features:

• Iterative approach: Agile development process such as Scrum.

anDREa uses the following tools for planning and supporting the development process:

• Zoho: ticketing system, Knowledge Base.

• Azure DevOps Boards for Work Item Tracking and Sprint planning.

• Azure DevOps Pipelines for Continuous Integration and Delivery.

• Azure DevOps Artifacts for sharing binary dependencies internally.
  

• Azure DevOps Wiki for developer documentation.
  

• Azure DevOps Test Plans & Google Workspace for Test plans, decisions and assessments.
  

• Github for source control.
  

• Miro boards for roadmap planning.
  

• Read AI for meeting notes.
  

anDREa develops features in the following environments/frameworks:

• .net Core (C#).

• Javascript (React, Angular).

• PowerShell, Bash.

• Azure ARM, Bicep.

The applied framework supports security of the following OWASP top 10 vulnerabilities:

• Server side request forgery

• OS injection

• LDAP injection

• Broken authentication

• Sensitive data exposure

• XML External Entities (XXE)

• Broken access control

• Cryptographic failures

Depicted below is the Scrum development cycle. All Product Backlog Items (PBIs) are added and documented in Azure DevOps.

Each of the activities is explained in A.12.1.1 Documented operating procedures.

The development of software adheres to A.12.2.5 Secure system engineering principles. 

Hotfixes, resolving bugs

• No exceptions are made, hotfixes and resolution of bugs use normal pipelines.

Responsibilities

anDREa has assigned the following roles:

• CEO

• Employee/contractor:

• Developers

• Testers

• Scrum master

• Product Owner

• Support specialist

• Customer Success specialist

• Support

• anDREa's Support & Assurance team

• Research Support team (tenant)
  

• Service provider

In addition to the roles above, the following roles are also defined:

• Top management

• Security Officer

• Data Protection Officer (anDREa’s CEO functions as DPO for anDREa, anDREa is not required to have a DPO)

• IT administrator

• Internal Auditor
  

• Secretary
  

• Business Manager
  

• Operations Manager
  

• Administrative Assistant
  

• Account Manager
  

Each of the following roles is described in Definition of (Security) Roles and Responsibilities.

Documentation

The developmental processes are described in A.12.1.1 Documented operating procedures. Testing procedures and documentation are described in A.14.2.8 System security testing & A.14.2.9 System acceptance testing.

The developmental process produces the following documentation:

• Technical and functional documentation (architecture, need, solution, implementation) in DevOps Wiki.

• Release notes.

• How-to articles in the Knowledge Base (user manuals).

• Test plans.

• Test scripts.

• WIT documentation for features, PBIs and Bugs.