Penetration testing should have clearly defined goals and scope. The goals may include, e.g., testing continuity plans and capabilities, assessing security controls or identifying security weaknesses. The scope can be defined as follows:
Vital systems or components that could be excluded, e.g., include those essential for maintaining critical organizational services or those unable to withstand the stress of a penetration test.
During the planning phase, it is important to involve relevant stakeholders in advance. This often means informing external system monitoring providers prior to testing, though it may not be necessary to inform users or system management personnel.
Penetration testing should be conducted regularly, at least annually. It should be performed both from outside the organization's network perimeter and from within. Testing from the outside simulates an external attack (black box and white box), while testing from the inside simulates potential threats from compromised clients/servers or malicious insiders (grey box).
The results of penetration tests should always be documented.
Organization has a process for regulalry conducting threat-led penetration testing (TLPT).
TLPT process fills the following requirements:
The organization has defined a process for addressing identified technical vulnerabilities.
Some vulnerabilities can be fixed directly, but vulnerabilities that have a significant impact should also be documented as security incidents. Once a vulnerability with significant impacts has been identified:
Organization carries out threat intelligence by gathering information about information security threats related to its operations and how to protect against them. The goal is to increase awareness of the threat environment, so that own security level can be better evaluated and adequate control measures implemented.
When collecting threat intelligence, all three levels must be taken into account:
Principles related to threat intelligence should include:
The organization has a process for handling vulnerabilities disclosed by other parties, such as regular users or white-hat hackers.
Typically, this is managed through Vulnerability Disclosure Programs (VDPs) or formal bug bounty programs. These programs allow users to submit vulnerabilities to the organization.
The organization should after a penetration test:
The organization develops a detailed severity rating system for vulnerabilities, defining criteria for severity levels, integrating these ratings into development workflows, setting security standards, using automated assessment tools, establishing a triage process, and reviewing the system annually to ensure effective vulnerability management.
The organization establishes a dedicated team and standardized process for root cause analysis of security vulnerabilities, ensuring thorough data gathering, cause identification, collaboration with development teams for solutions, training to prevent recurrence, and continuous improvement of security practices.
The organization conducts monthly automated vulnerability scans on all externally-exposed assets, utilizing advanced tools for thorough analysis and prompt response to findings, while regularly updating scanning protocols to address emerging threats and maintain security vigilance.
The organization has implemented a comprehensive strategy for automated vulnerability scans of internal assets, conducting both authenticated and unauthenticated scans with thorough coverage and regular analysis of results, and continuously enhancing tools and techniques based on findings to address security risks.
The organization should have documented processes and templates for reporting detected vulnerabilities.
The vulnerability detection reports should be submitted immediately to the competent cyber incident prevention institution, and no longer than five days after detecting the vulnerability.
The detection report should include the following information:
The organization has defined processes for addressing identified vulnerabilities.
These processes should include at least the following:
The organization performs the actions necessary to prevent the vulnerability within the time limit set by the competent cyber incident prevention institution, but no later than 90 days after receiving the information, and informs the competent cyber incident prevention institution about the progress of the vulnerability prevention.
If, due to objective reasons, it is not possible to eliminate the vulnerability within the time limit specified, at the request of the organization, the cyber incident prevention institution may extend the deadline for the elimination of the vulnerability, but not more than 180 days from the moment of submitting the vulnerability detection report, by informing about it in the vulnerability detection report the submitter.
The organization should used vulnerability scanning tools as the main tool for regular vulnerability scanning process.
In addition organization should use attack tools to test those vulnerabilities found with the scanning tool.
The results and reports of penetration tests should be communicated to relevant stakeholders. These tests should be documented with at least a summary, a list of findings, and suggested improvements.
Penetration testing should have clearly defined goals and scope. The goals may include, e.g., testing continuity plans and capabilities, assessing security controls or identifying security weaknesses. The scope can be defined as follows:
Vital systems or components that could be excluded, e.g., include those essential for maintaining critical organizational services or those unable to withstand the stress of a penetration test.
During the planning phase, it is important to involve relevant stakeholders in advance. This often means informing external system monitoring providers prior to testing, though it may not be necessary to inform users or system management personnel.
Penetration testing should be conducted regularly, at least annually. It should be performed both from outside the organization's network perimeter and from within. Testing from the outside simulates an external attack (black box and white box), while testing from the inside simulates potential threats from compromised clients/servers or malicious insiders (grey box).
The results of penetration tests should always be documented.
Penetration testing should have clearly defined goals and scope. The goals may include, e.g., testing continuity plans and capabilities, assessing security controls or identifying security weaknesses. The scope can be defined as follows:
Vital systems or components that could be excluded, e.g., include those essential for maintaining critical organizational services or those unable to withstand the stress of a penetration test.
During the planning phase, it is important to involve relevant stakeholders in advance. This often means informing external system monitoring providers prior to testing, though it may not be necessary to inform users or system management personnel.
Penetration testing should be conducted regularly, at least annually. It should be performed both from outside the organization's network perimeter and from within. Testing from the outside simulates an external attack (black box and white box), while testing from the inside simulates potential threats from compromised clients/servers or malicious insiders (grey box).
The results of penetration tests should always be documented.
The organisation should have an adequate patch management procedure defined and implemented. This should include the testing and installation of patches.
There should measures to minimize the risk related to patch management and verification of successful installation of patches.
The patch management should be automated when possible (for example operating system updates).
The patch management process should take into account the requirements set by frameworks or other requiremetns they need to comply with.
Organization carries out threat-led penetration testing. Each test needs to cover multiple critical or important functions of the related financial entity.
To properly define the proportionate scope for TLPT:
The result of this assessment shall determine the precise scope of TLPT and shall be validated by the competent authorities.
The testing organization used for threat-led penetration testing should meet at least the following requirements:
In the case of using internal testers along with the list above they should be:
In contracts with the tester management of results and any data processing do not create risks to the organization.
Organization's resilience testing programme is prepared for providing all the necessary supporting expert work for the chosen resilience testing operations. This may include e.g. performance testing, end-to-end testing, penetration testing or source code reviews.
Related resilience testing operations can e.g. include vulnerability scans, other scanning software use, network security assements, physical security reviews or other kinds of gap analyses.
Isolate technical environments where the consequences can be very damaging.
Unmanaged installations of software on computers can lead to vulnerabilities and security breaches.
The organization should determine what types of software or updates each user can install. The instructions may include e.g. the following guidelines:
The operation of information systems may depend on certain key resources, such as server capacity, file storage capacity, data processing capacity, monitoring capacity or certain key persons.
In particular, some of these resources may have long delivery times or high costs in certain situations, in which case special attention must be paid to future capacity problems with them.
We monitor the use of key system resources and identify trends, potential security bottlenecks and dependencies on important people.
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.
We have defined the rules for responding to identified vulnerabilities. The rules may include e.g. the following things:
Vulnerabilities related to high-risk data systems are always of high severity and are addressed first.
Information sources for software and other technologies have been consciously identified to identify and maintain information about technical vulnerabilities that are relevant to us (e.g. authorities or hardware and software manufacturers). Data sources are evaluated and updated as new useful sources are found.
Vulnerabilities can be found directly in the vendor systems we exploit or in the open source components exploited by many of our systems. It’s important to keep track of multiple sources to get the essential information obtained.
Ohjelmistohaavoittuvuuksien hallitsemiseksi suojaustasolla IV toteutetaan seuraavat toimenpiteet:
Merkittäviä muutoksia ovat mm. verkkotopologian muutokset, uusien järjestelmien käyttöönotot, vanhojen järjestelmien merkittävät päivitykset sekä palomuurien ja vastaavien suodatussääntöjen merkittävät muutokset.
Ohjelmistohaavoittuvuuksien hallitsemiseksi suojaustasoilla III-II toteutetaan seuraavat toimenpiteet:
Merkittäviä muutoksia ovat mm. verkkotopologian muutokset, uusien järjestelmien käyttöönotot, vanhojen järjestelmien merkittävät päivitykset sekä palomuurien ja vastaavien suodatussääntöjen merkittävät muutokset.
Static scans on code are the first step in detecting risky vulnerabilities. However, once a service has been deployed, it is vulnerable to new types of attacks (e.g., cross-site scripting or authentication issues). These can be identified by penetration testing.
The organization must develop a process to automate the treatment of technical vulnerabilities.
The organization must have a clear model for prioritizing identified technical vulnerabilities. The operating model should not be entirely new invention, but should be based on generally accepted practices.
Vulnerabilities should be prioritized based on the risk they pose, the importance of the assets involved, the potential organizational impact, and the urgency (taking into account the CVSS value).
The organization needs to define Monitored Metrics for identifying and correcting vulnerabilities. Meters must be monitored at specified intervals.
Hardening is the practice of reducing system vulnerability by reducing its attack surface.
When configuring virtual machines the organization has to make sure the machines are hardened by, for example, only using ports, protocols and services that are needed. There must also be technical security measures like anti-malware and logging enabled for all virtual machines.
The vulnerability management process is regularly tested at intervals specified by the organization to ensure that it is up-to-date, functional, and effective.
Tietojenkäsittely-ympäristön laitteet tarkastetaan kattavasti ohjelmistohaavoittuvuuksien varalta vähintään vuosittain ja merkittävien muutosten yhteydessä. Prosessissa on huomioitu seuraavat seikat:
"Merkittäviin muutoksiin" voidaan laskea esim. verkkotopologian muutokset, uusien järjestelmien käyttöönotot ja/tai vanhojen service pack -tason päivitykset sekä palomuurien ja vastaavien suodatussääntöjen merkittävät muutokset.
Tietojenkäsittely-ympäristön laitteet tarkastetaan kattavasti ohjelmistohaavoittuvuuksien varalta vähintään puolivuosittain ja merkittävien muutosten yhteydessä. Prosessissa on huomioitu seuraavat seikat:
"Merkittäviin muutoksiin" voidaan laskea esim. verkkotopologian muutokset, uusien järjestelmien käyttöönotot ja/tai vanhojen service pack -tason päivitykset sekä palomuurien ja vastaavien suodatussääntöjen merkittävät muutokset.
The validity and effectiveness of used hardening is maintained throughout the whole life cycle of the data system.
Organization carries out threat intelligence by analyzing and utilizing collected information about relevant cyber security threats related and corresponding protections.
When analyzing and utilizing the collected threat intelligence information, the following points must be taken into account:
The organization monitors information about technical vulnerabilities of the information systems in use. When relevant technical vulnerabilities are detected, the organization takes action according to the planned operating model.
The technical vulnerability management process is regularly monitored and evaluated to ensure its effectiveness and efficiency.
Organization must consider the threat intelligence process findings in the information security risk management process. Threat intelligence can detect, for example, the proliferation of certain types of attacks or the development of new technologies, based on which assessments of certain information security risks must be updated, which may lead to the need to reduce risks through treatment plans.
Organization should share threat intelligence information actively with other organizations to improve its own threat awareness.
The operation of information systems may depend on certain key resources, such as server capacity,storage space, data processing capacity,monitoring capacity or certain< em>key people.
The organization has defined key resources and methods for monitoring the use of these key resources. A normal level is also determined for the resources, which is used when assessing the risk of jeopardizing availability due to capacity problems.
.png)
