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

Learn more about the connected frameworks

2.1.5
NSM ICT-SP

Use a secure software development method

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
ISO27 Full
12.1.4: Separation of development, testing and operational environments
ISO27 Full
12.5.1: Installation of software on operational systems
ISO27 Full
14.2.6: Secure development environment
ISO27 Full
PR.DS-7: The development and testing environments
NIST

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
ISO27 Full
14.2.9: System acceptance testing
ISO27 Full
8.29: Security testing in development and acceptance
ISO27k1 Full
CC8.1: Change management procedures
SOC 2
PR.IP-2: A System Development Life Cycle to manage systems is implemented.
CyFun

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ää".

TEK-14: Ohjelmistojen turvallisuuden varmistaminen
Julkri

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.
MWP-06: Safe running of unknown code
Cyber Essentials
MWP: Application sandboxing
Cyber Essentials

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.

2.1.5: Use a secure software development method
NSM ICT-SP

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.

2.1.5: Use a secure software development method
NSM ICT-SP
2.1.8: Maintain the software code developed/used by the organisation
NSM ICT-SP

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
PR.IP-2: A System Development Life Cycle to manage systems is implemented.
CyFun
2.1.5: Use a secure software development method
NSM ICT-SP

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
ISO27 Full
14.3.1: Protection of test data
ISO27 Full
8.33: Test information
ISO27k1 Full
21.2.e: Secure system acquisition and development
NIS2
5.3.1: Information Security in new systems
TISAX

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
ISO27 Full
10.1.1: Policy on the use of cryptographic controls
ISO27 Full
14.1.3: Protecting application services transactions
ISO27 Full
14.2.5: Secure system engineering principles
ISO27 Full
8.5: Secure authentication
ISO27k1 Full

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
ISO27 Full
14.1.2: Securing application services on public networks
ISO27 Full
14.1.3: Protecting application services transactions
ISO27 Full
14.2.5: Secure system engineering principles
ISO27 Full
PR.DS-2: Data-in-transit
NIST

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
ISO27 Full
14.2.3: Technical review of applications after operating platform changes
ISO27 Full
TEK-14: Ohjelmistojen turvallisuuden varmistaminen
Julkri
8.28: Secure coding
ISO27k1 Full
8.32: Change management
ISO27k1 Full

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
ISO27 Full
12.5.1: Installation of software on operational systems
ISO27 Full
14.2.2: System change control procedures
ISO27 Full
14.2.7: Outsourced development
ISO27 Full
8.19: Installation of software on operational systems
ISO27k1 Full

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
ISO27 Full
14.2.6: Secure development environment
ISO27 Full
8.4: Access to source code
ISO27k1 Full
8.31: Separation of development, test and production environments
ISO27k1 Full
CC8.1: Change management procedures
SOC 2

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
ISO27 Full
14.2.5: Secure system engineering principles
ISO27 Full
TEK-14: Ohjelmistojen turvallisuuden varmistaminen
Julkri
8.25: Secure development life cycle
ISO27k1 Full
8.27: Secure system architecture and engineering principles
ISO27k1 Full

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
ISO27 Full
DE.CM-6: External service provider activity monitoring
NIST
8.28: Secure coding
ISO27k1 Full
8.30: Outsourced development
ISO27k1 Full
21.2.e: Secure system acquisition and development
NIS2

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
ISO27 Full
12.5: Control of operational software
ISO27 Full
12.3.1: Information backup
ISO27 Full
12.5.1: Installation of software on operational systems
ISO27 Full
14.2.2: System change control procedures
ISO27 Full

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
ISO27 Full
14.2.4: Restrictions on changes to software packages
ISO27 Full
PR.DS-6: Integrity checking
NIST
TEK-17: Muutoshallintamenettelyt
Julkri
8.32: Change management
ISO27k1 Full

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.

5.2.2: Seperation of testing and development environments
TISAX

Testing security functions that are affected by the changes to ICT systems

Critical
High
Normal
Low

Test security functions that are affected by changes to ICT systems both before and after deployment in order to maintain secure state. It is important to ensure that security functions are tested because changes to ICT systems can often create new vulnerabilities.

2.10.3: Test affected security functions
NSM ICT-SP

Integrating security into the organization's urgent change processes

Critical
High
Normal
Low

The organization must integrate security aspects into its urgent change processes, even in time-sensitive or emergency situations. Minimum requirements for staff involvement, testing, and documentation should be stipulated both before and after deployment. This ensures clear documentation of the minimum steps that must be taken in urgent cases.

2.10.4: Integrate security into the organisation’s urgent change processes
NSM ICT-SP

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
ISO27 Full
14.3.1: Protection of test data
ISO27 Full
8.33: Test information
ISO27k1 Full
21.2.e: Secure system acquisition and development
NIS2
2.1.6: Use separate environments for development, test and production
NSM ICT-SP

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
ISO27 Full
14.2.5: Secure system engineering principles
ISO27 Full
14.2.9: System acceptance testing
ISO27 Full
8.27: Secure system architecture and engineering principles
ISO27k1 Full
21.2.e: Secure system acquisition and development
NIS2

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
ISO27 Full
5.17: Authentication information
ISO27k1 Full

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
ISO27 Full
12.5.1: Installation of software on operational systems
ISO27 Full
8.19: Installation of software on operational systems
ISO27k1 Full

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.

5.3.1: Information Security in new systems
TISAX