Separation of production, testing and development environments

Critical
High
Normal
Low

Software under development, testing and production is run in differentiated technical environments in order to ensure the quality of development work in an environment that adapts to the production environment and, on the other hand, the production environment is not disturbed by unfinished development.

Sensitive or personal data of users is not copied and used in a development environment.

Connected other frameworks and requirements:
14.2.6: Secure development environment
ISO 27001
12.1.4: Separation of development, testing and operational environments
ISO 27001
12.5: Control of operational software
ISO 27001
12.5.1: Installation of software on operational systems
ISO 27001
PR.DS-7: The development and testing environments
NIST CSF

General rules for reviewing and publishing code

Critical
High
Normal
Low

General rules for reviewing, approving and publishing the code have been defined and enforced.

The rules may include e.g. the following things:

  • the generated code has been validated against the general safe development guidelines of the OWASP Framework
  • the code has been reviewed by at least two people
  • the changes have been approved by a designated, authorized user prior to publication
  • the system documentation has been updated before release
  • the time of publication of the changes has been chosen in accordance with the given instructions in order to minimize disruption to business processes
  • the instructions needed by users have been updated before the code is released

The rules are intended to manage the risks associated with the release of new program code.

Connected other frameworks and requirements:
14.2.2: System change control procedures
ISO 27001
14.2.3: Technical review of applications after operating platform changes
ISO 27001
8.28: Secure coding
ISO 27001
8.32: Change management
ISO 27001

Guidelines for secure development

Critical
High
Normal
Low

The general rules for secure development work have been drawn up and approved by the development managers. The implementation of the rules is monitored in software development in the organization and the rules are reviewed at least yearly.

The safe development policy may include e.g. the following things:

  • safety requirements of the development environment
  • instructions for secure coding of the programming languages used
  • safety requirements at the design stage of properties or projects
  • secure software repositories
  • version control security requirements
  • the skills required from developers to avoid, discover and fix vulnerabilities
  • compliance with secure coding standards

Compliance with the rules of secure development may also be required of key partners.

Connected other frameworks and requirements:
14.2.1: Secure development policy
ISO 27001
14.2.5: Secure system engineering principles
ISO 27001
8.25: Secure development life cycle
ISO 27001
8.27: Secure system architecture and engineering principles
ISO 27001
8.28: Secure coding
ISO 27001

Process for monitoring and tracking outsourced development work

Critical
High
Normal
Low

Even when development is outsourced, we remain responsible for complying with appropriate laws and verifying the effectiveness of security controls.

We have defined the procedures that we monitor and follow throughout the outsourcing chain.Practices may include e.g. the following things:

  • policies for reviewing and approving generated code
  • evidence of testing activities performed by the partner
  • communication practices
  • contractual rights to audit the development process and management tools
  • documentation requirements for code generation
Connected other frameworks and requirements:
14.2.7: Outsourced development
ISO 27001
DE.CM-6: External service provider activity monitoring
NIST CSF
8.28: Secure coding
ISO 27001
8.30: Outsourced development
ISO 27001

Regular vulnerability scanning

Critical
High
Normal
Low

The organization regularly conducts a vulnerability scan, which searches for vulnerabilities found on computers, workstations, mobile devices, networks or applications. It is important to scan even after significant changes.

It should be noted that vulnerable source code can be from operating system software, server applications, user applications, as well as from the firmware application as well as from drivers, BIOS and separate management interfaces (e.g. iLo , iDrac). In addition to software errors, vulnerabilities occur from configuration errors and old practices, such as the use of outdated encryption algorithms.

Connected other frameworks and requirements:
12.6.1: Management of technical vulnerabilities
ISO 27001
18.2.3: Technical compliance review
ISO 27001
14.2.8: System security testing
ISO 27001
ID.RA-1: Asset vulnerabilities
NIST CSF
PR.IP-12: Vulnerability management plan
NIST CSF

Vulnerability monitoring in used third-party or open source libraries

Critical
High
Normal
Low

Vulnerabilities in third-party or open source libraries must be monitored, scanned, and reported in the same style as other vulnerabilities.

The organization must define policies to identify required updates in applications that use external libraries. Surveillance scans can be automated with specialized tools.

It also makes sense for an organization to monitor overall communication about vulnerabilities.

Connected other frameworks and requirements:
8.28: Secure coding
ISO 27001
No items found.