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:
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:
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 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:
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:
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:
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.
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.
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.
The organization creates a centralized bill of materials (BOM) repository to manage third-party components, including detailed information, tracking, regular updates, risk assessments, vulnerability monitoring, and facilitate communication with development teams for proactive security management.
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:
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.
Organization ensures that the following aspects are covered in the requirement specifications for new system development:
Newly developed systems are reviewed against the specifications before moving to production use.
In Cyberday, all frameworks’ requirements are mapped into universal tasks, so you achieve multi-framework compliance effortlessly.
.png)
Elevate Your Knowledge with Exclusive Access to Weekly Webinars, Video Courses, Help Articles, and Blogs.
