A.14.2.5 Secure system engineering principles

A.14.2.5 Secure system engineering principles

Version: 3.0

Valid until: 2025-04-10

Classification: Low

Version Management


Version

Author(s)

Change(s)

Date approved

1.0

Stefan van Aalst

Edward Robinson
Sarang Kulkarni

Initiation document

2022-07-07

1.1

Edward Robinson

Additions/changes as part of the periodic review and improvement.


Renamed to A.14.2.5 Secure system engineering principles. 

2022-12-13

2.0Edward RobinsonAdditions/changes as part of the annual review.

No changes were made.
2023-05-19
3.0
Edward Robinson
Additions/changes as part of the annual review.

No changes were made.

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 system engineering principles.


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.5 Secure system engineering principles


“Principles for engineering secure systems shall be established, documented, maintained and applied to any information system implementation efforts.”

Fundamental principles


The fundamental principles are documented and explained in anDREa’s Security Manifesto, Foundation for Audit Recording, and GDPR Compliance Assessment. Ultimately, these principles drive the development of myDRE.


Access principles


This applies but is not limited to the following environments: Development, Test, Acceptance, Production.


  • Least privileged.

  • RBAC.

  • Authorisation always via MFA.

  • Logging according to Assessment Framework for Services.


Design principles


Within the boundaries set in Fundamental principles:


  • Least privileged.

  • RBAC.

  • Design for containment.

  • Authorisation always via MFA.

  • Logging according to Assessment Framework for Services.

  • (Self-service) Workspace changes in configuration are always:

    • Deliberate.

    • Suiting the role following the least-privileged principle.

    • Clearly informative on impact on security, auditability and if applicable what the authorised should/can do to be more compliant and to reduce the risk.

    • Logs the consent.

    • Are much easier to revert to default.

  • Design must be based on user and anti-user stories.

  • Design must have acceptance criteria.

  • Isolate functionalities and design to be switched off without affecting the rest of myDRE.


Development principles


  • Based on designed features.

  • Clean code.

  • Well documented.

  • Peer reviewed.

  • According to naming conventions and code structure set by senior anDREa developers.

  • Isolated from Test, Acceptance and Production environment.

  • No data from Production can be used.


Test principles


  • Based on user and anti-user stories.

  • Based on acceptance criteria.

  • Well-documented.

  • Isolated from Development, Acceptance and Production environment.

  • No data from Production can be used.


Acceptance principles


  • Smoke test.

  • Verify the functionality from user perspective and expectation.

  • Isolated from Development, Test and Production environment.


Deployment (to production) principles


  • Smoke test.

  • On demand access to the Core only.

  • Inform Support Teams

  • Ensure proper documentation can be found by users.

  • In case of an unexpected event during or much later:

    • Switch off functionality, or 

    • Revert back.

Administrations


    • Related Articles

    • A.14 System acquisition, development and maintenance

      Version: 3.0 Valid until: 2024-04-10 Classification: Low Version Management Version Author(s) Change(s) Date approved 1.0 Stefan van Aalst Edward Robinson Sarang Kulkarni Johanna Hakonen Initiation document 2022-07-07 1.1 Edward Robinson Johanna ...
    • A.14.2.1 Secure development policy

      Version: 3.0 Valid until: 2025-04-10 Classification: Low Version Management Version Author(s) Change(s) Date approved 1.0 Stefan van Aalst Edward Robinson Sarang Kulkarni Johanna Hakonen Initiation document 2022-07-07 1.1 Edward Robinson ...
    • A.14.2.8 System security testing & A.14.2.9 System acceptance testing

      Version: 3.0 Valid until: 2025-04-10 Classification: Low Version Management Version Author(s) Change(s) Date approved 1.0 Stefan van Aalst Initiation document 2022-07-07 1.1 Edward Robinson Johanna Hakonen Sayali Shitole Additions/changes as part of ...
    • A.6 Organisation of information security

      Version: 3.0 Valid until: 2025-03-26 Classification: Low Version Management Version Author(s) Change(s) Date approved 1.0 Stefan van Aalst Edward Robinson Initiation document 2022-05-23 1.1 Edward Robinson Additions/changes as part of the periodic ...
    • 20210224 Pentest 2021-Q1 Report & 20210301 White Box Security Audit 2021-Q1 Report

      In accordance with our Pentest Program, anDREa engaged nSEC/Resilience for the anDREa White Box Security and the Pentesting 2021-Q1. The core questions being: Can non-authorized people or services access Workspaces or affect anDREa’s core services? ...