Secure development

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.

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.

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.

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

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.

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

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.

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.

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

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

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.

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

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.

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.

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

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.

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.

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

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

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

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

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.

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

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