Free ebook: NIS2 ready using ISO 27001 best practices
Download ebook

Learn more about the connected frameworks

14.2.3
ISO 27001

Sovellusten tekninen katselmointi käyttöalustan muutosten jälkeen

14.2.9
ISO 27001

Järjestelmän hyväksymistestaus

8.29
ISO 27001

Security testing in development and acceptance

Other tasks from the same security theme

Documentation of security metrics related to application security

Critical
High
Normal
Low

The organization must specifically document security metrics that measure the level of application security. Implementation must take into account the organization's own security objectives as well as other security requirements.

No items found.

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.

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

Definition of done and testing principles

Critical
High
Normal
Low

The development unit itself maintains a list of criteria that need to be met before a task can be marked as completed. The criteria may include e.g. review requirements, documentation requirements and testing requirements.

New code will only be implemented after extensive testing that meets pre-defined criteria. Tests should cover usability, security, effects on other systems, and user-friendliness.

14.2.3: Technical review of applications after operating platform changes
ISO 27001
14.2.9: System acceptance testing
ISO 27001
8.29: Security testing in development and acceptance
ISO 27001

Kriittisten ohjelmistojen toteutuksen säännöllinen tarkastaminen

Critical
High
Normal
Low

Kriittiset tietojärjestelmien tai tarjottujen digipalvujen toteutus tarkastatetaan säännöllisesti hyödyntäen ennalta määriteltyä luotettavaa standardia tai turvallisen ohjelmoinnin ohjetta.

Tarkentavia ohjeita ovat mm. VAHTI Sovelluskehityksen tietoturvaohje (VAHTI 1/2013), OWASP Application Security Verification Standard (ASVS) sekä Kyberturvallisuuskeskuksen ohje "Turvallinen tuotekehitys: kohti hyväksyntää".

No items found.

Safe running of unknown code

Critical
High
Normal
Low

All code of unknown origin must be executed in a so-called sandbox environment, i.e. isolated from other devices and networks in the organization. This prevents it from accessing the organization's resources without special permission from the user. This includes:

  • Other software in its own sandboxes
  • Databases that store images or documents, for example
  • Peripheral devices such as cameras, microphones and GPS
  • Access to the local network.
No items found.

Approval from the data owner for using production data for testing purposes

Critical
High
Normal
Low

The organization must obtain approval from the owner of the information, and manage potential risks, before using it for testing purposes.

No items found.

Built in and default data protection in systems development (Privacy by design)

Critical
High
Normal
Low

The organization has to create procedures for having data protection, correct way of processing personal data and compliance with data protection requirements by default in all new systems, digital services or in planning and development of new procedures from the start.

This is called principle of privacy by design. Important part of applying this principle is configuring systems default settings so that they minimize processing of personal data and follow all regional laws and regulations.

No items found.

Built in and default cyber security in system development (Security by design)

Critical
High
Normal
Low

The organization must create procedures that by default cyber security and security requirements are considered from the start when developing and designing new systems, digital services or business processes.

This is called the principle of built-in and default security (security by design). As a result of this approach, the design documentation should clearly indicate what measures are taken to ensure cyber security.

No items found.

Automated secure code deployment and release

Critical
High
Normal
Low

The organization must define the means for a secure software deployment strategy. Means should be automated if possible.

No items found.

Designing Secure Software Development Life Cycle(SSDLC) process

Critical
High
Normal
Low

The organization shall define and implement a Secure Software Development Life Cycle (SSDLC) process in software development.

The first step in the SSDLC process should be to define security requirements that ensure that security considerations become integrated into the services being developed right from the creation phase.

It is recommended that the SSDLC process include at least the following steps:

  • A - Training
  • B - Description of the requirements
  • C - Design
  • D - Development
  • E - Security testing
  • F - Publication
  • G - Responding to issues
PR.IP-2: A System Development Life Cycle
NIST CSF

Protection and minimisation of test data

Critical
High
Normal
Low

The data and other materials used for testing should be carefully selected and protected.

Production information that contains personal or other confidential information should not be used for testing purposes.

14.3: Test data
ISO 27001
14.3.1: Protection of test data
ISO 27001
8.33: Test information
ISO 27001

Encryption of user password information

Critical
High
Normal
Low

We use strong encryption during password transmission and storage in all services we develop.

9.4.2: Secure log-on procedures
ISO 27001
10.1.1: Policy on the use of cryptographic controls
ISO 27001
14.1.3: Protecting application services transactions
ISO 27001
14.2.5: Secure system engineering principles
ISO 27001
8.5: Secure authentication
ISO 27001

Encryption of public network traffic for application services

Critical
High
Normal
Low

Information included in application services transmitted over public networks must be protected against fraudulent and non-contractual activity and against unauthorized disclosure and alteration.

We use strong encryption and security protocols (eg TLS, IPSEC, SSH) to protect confidential information when it is transmitted over public networks in connection with the IT services we develop.

13.2.3: Electronic messaging
ISO 27001
14.1.2: Securing application services on public networks
ISO 27001
14.1.3: Protecting application services transactions
ISO 27001
14.2.5: Secure system engineering principles
ISO 27001
PR.DS-2: Data-in-transit
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.

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

Listing authorized users for publishing code changes

Critical
High
Normal
Low

Only pre-defined, authorized users are allowed to post changes to the code.

12.5: Control of operational software
ISO 27001
12.5.1: Installation of software on operational systems
ISO 27001
14.2.2: System change control procedures
ISO 27001
14.2.7: Outsourced development
ISO 27001
8.19: Installation of software on operational systems
ISO 27001

Source code management

Critical
High
Normal
Low

Access to source code and other related plans is controlled to prevent e.g. adding unauthorized code and avoiding unintentional changes. Access rights are allocated on a need-to-know basis and, for example, support staff are not granted unlimited access rights.

Source code control can be implemented, for example, by storing all code centrally in a dedicated source code management system.

9.4.5: Access control to program source code
ISO 27001
14.2.6: Secure development environment
ISO 27001
8.4: Access to source code
ISO 27001
8.31: Separation of development, test and production environments
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.

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

Restoration strategy

Critical
High
Normal
Low

We have agreed and recorded policies to restore an earlier version of the software before implementing the releases.

12.3: Backup
ISO 27001
12.5: Control of operational software
ISO 27001
12.3.1: Information backup
ISO 27001
12.5.1: Installation of software on operational systems
ISO 27001
14.2.2: System change control procedures
ISO 27001

Change management procedure for significant changes to data processing services

Critical
High
Normal
Low

Inadequate change management is a common cause of incidents for digital services.

An organization shall document the change management process that must be followed whenever significant changes are made to developed digital services or other computing services that affect cyber security. The process includes requirements e.g. for the following:

  • Defining and documenting the change
  • Assessing the risks and defining the necessary control measures
  • Other impact assessment of the change
  • Testing and quality assurance
  • Managed implementation of the change
  • Updating a change log
14.2.2: System change control procedures
ISO 27001
14.2.4: Restrictions on changes to software packages
ISO 27001
PR.DS-6: Integrity checking
NIST CSF
8.32: Change management
ISO 27001

Using data system risk assessments to determine separation needs

Critical
High
Normal
Low

The organisation's IT systems go through a risk assesment that's used for determining the necessity for the seperation into development, testing and operational systems.

The segmentation is then implemented based on the results of the risk assesment.

No items found.

Specific safeguards for production data used for testing

Critical
High
Normal
Low

The use of production data for testing purposes should be avoided. If confidential information is used in testing, the following security measures should be used:

  • all sensitive details should be either deleted or made secure (e.g. anonymisation of personal data)
  • testing environments are subject to the same strict access control as production
  • copying production data to the test environment is done only with a separate authorization
  • production data is removed from the test environment immediately upon completion of testing
14.3: Test data
ISO 27001
14.3.1: Protection of test data
ISO 27001
8.33: Test information
ISO 27001

Regular critical code identification and verification

Critical
High
Normal
Low

The definition of security-critical code for the various services is maintained. New parts of the critical code are constantly being identified and new updates are being checked particularly closely for changes to the critical code. The aim is to keep the likelihood of security vulnerabilities to a minimum.

14.2.3: Technical review of applications after operating platform changes
ISO 27001
14.2.5: Secure system engineering principles
ISO 27001
14.2.9: System acceptance testing
ISO 27001
8.27: Secure system architecture and engineering principles
ISO 27001

Secure setting and distribution of temporary login information

Critical
High
Normal
Low

Temporary credentials should be unique and should not be quessable, for example, by inferring from user data.

9.2.4: Management of secret authentication information of users
ISO 27001
5.17: Authentication information
ISO 27001

Maintaining a release log

Critical
High
Normal
Low

An event log should be kept for all updates to production or customer software or in-house IT services.

12.5: Control of operational software
ISO 27001
12.5.1: Installation of software on operational systems
ISO 27001
8.19: Installation of software on operational systems
ISO 27001

Ensuring the coverage of new IT system development requirements

Critical
High
Normal
Low

Organization ensures that the following aspects are covered in the requirement specifications for new system development:

  • Information security requirements
  • Vendor recommendations and best practices for secure configuration and implementation
  • General best practices and security guidelines
  • Fail-safe mechanisms (designed to return to a safe state in case of failure or malfunction)

Newly developed systems are reviewed against the specifications before moving to production use.

No items found.