How to survive a Katakri Subdivision I audit


A Katakri audit is a daunting prospect but one that cannot be avoided. Katakri is an information security audit tool for the Finnish authorities that measures organizations' capability to protect national or international classified information. A typical Katakri auditor is a tedious know-it-all who wants to check every piece of minutiae and never seems satisfied with the answers or the level of detail in the documentation. They also seem to have a knack for always finding the one instance where the process artifacts are slightly lacking.
 

The following is a breakdown of some of the current Katakri Subdivision I requirements and what is needed to pass the audit. None of these tips are directly related to DNV Cyber’s products or services; instead, they are actions that organizations can implement in-house. All it takes is time and dedication (i.e., a budget and a mandate). 

None of the following items are absolute requirements, and none of them on their own are enough to pass the Katakri audit. 

Communications Security 

Requirements I-01, I-02 and I-03 

The information processing environment needs to be documented in enough detail to make it possible to visualise its place in the organization’s network as a whole and to separate it from the rest of the architecture. In many instances, the organization has prepared a network diagram of the relevant system but failed to demonstrate to the auditor where the environment sits relative to the organization’s network architecture as a whole.  

The system description needs to clearly explain how and by which mechanisms the environment connects with other areas of the network. If the connection is from a security classification level III or II to a lower classification level, a boundary protection service must be used. 

The network documentation needs to show all traffic to and from the environment and its rationale. In practice, the organization needs a communication matrix that identifies, at least, the source, destination, protocol, ports and reason for the traffic. Ideally, all filtering solutions should also be described in the network documentation. The auditor will examine the communication matrix and select a number of connections, which they will then compare against the implemented filtering rules.  

A process between the communication matrix and filtering should determine how filtering solutions are configured to comply with the communication matrix. This can be, for example, a ticketing system: a ticket is needed to create a filtering rule to allow traffic. If a ticketing system is used, particular attention must be given to ensuring that each request has been authorised and makes sense. All instances where traffic has been allowed and any changes to these rules must be documented in the same way. As part of checking that the filtering rules are aligned with the communication matrix, the auditor will usually also want to see process artifacts of how each rule came to existence. 

It would also be beneficial for the audited entity to establish a process for reviewing the settings of filtering solutions at regular intervals, during maintenance, and in the event of incidents. An annual clock only solves half of this requirement, as separate processes are needed for maintenance and exceptional circumstances. 

Requirement I-04 

Management connections to systems must be documented in enough detail to identify each. The wide variety of connections in a virtual system often causes problems in this respect. Documenting any out-of-band network management solutions is also essential. 

Management connections should be implemented in such a way that they adhere to the principle of least privilege. Although administrators need to have superuser rights to perform their tasks, not all administrators necessarily need all rights to all systems. The natural route for large organizations is to use one of the many Privileged Access Management (PAM) solutions to meet this requirement. 


Systems Security
 

Requirements I-06 and I-07 

User rights management needs to be based on an established process that the organization actually follows in practice, creating a clear audit trail. The auditor typically verifies that the organization is able to answer the following questions: 

a) Which users had access to Z during the period t1?

b) What privileges did user X have during the period t2?

A technical solution (user rights management system) has the benefit of being scalable, but paper-based systems can also be used, as long as the documentation is in order and available for the auditor to review. 

The organization also needs to have processes for ensuring that user rights are always up to date. Typically, terminations are managed properly, but internal job rotation is challenging and often results in the accumulation of user rights. 

At classification level IV, having documented password policies and practices in place is usually enough to satisfy user authentication requirements. However, the authentication requirements also apply to hardware and software, and the practices associated with these, therefore, also need to be documented. Technical authentication of devices and multi-factor authentication of users are required at classification level III. 

Requirement I-08 

Software installation and hardening procedures must be in place for all types of systems. The procedures must be based on a well-known hardening standard. All deviations from the hardening procedures and reasons for the deviations need to be documented. 

The organization needs to have a process for managing installation and hardening procedures, according to which the documentation is regularly reviewed and updated whenever the operating environment or the applicable hardening standards change. A common pitfall is failing to upgrade existing systems to meet new requirements. 

Requirement I-09 

The easiest way to achieve adequate malware protection is to use centrally managed antivirus software from a well-known brand and to ensure that the software is always running the latest version and up-to-date malware signatures. However, antivirus software alone is not enough, as the organization also needs to have a documented process of how alerts are monitored and responded to. My top tip in this respect is to train the organization’s malware monitoring and response team to treat the EICAR test virus like they would a major threat, meaning that detection should trigger a response. The EICAR test file is not just a tool that the auditor uses to see whether the organization’s antivirus software is capable of detecting attacks but to test the entire process chain. 

Requirements I-10 and I-11 

In practice, compliance with these requirements necessitates a centralised log management system and a security operations centre (SOC) to monitor the logs that the system produces. The logs need to be comprehensive enough to enable both detecting information security incidents in real-time and analysing them afterwards. The logging solution needs to be documented, and the documentation must justify the choice of logs. The SOC should be provided with a description of what to monitor in the logs, what the baseline looks like and and how to respond to various anomalies. Typically, an auditor will ‘infect’ the system with a harmless security anomaly to see how the organization’s process for dealing with the incident works in practice. 

Requirements I-12 and I-15 

According to the Katakri requirements, traffic must be encrypted both inside and outside the physically protected area. Traffic leaving the physically protected area needs to be encrypted using crypto solutions approved by the competent authority (often the Finnish Transport and Communications Agency Traficom) and sufficiently long keys. Unencrypted transmission or weaker encryption can be used inside the physically protected area, as long as the solutions are based on a risk assessment and have been specifically approved by the competent authority. The criteria for crypto solutions are laid down in requirements I-01 and I-04. 

Requirement I-13 

This requirement is rather complex and multi-faceted. The wording makes it clear that the security requirements of a system need to be known before the system is purchased and that the procurement documentation must explain why and how the system satisfies the relevant requirements. In addition, the organization must have a process for deploying new systems, which ensures that all installations and updates are checked to test that the security features work as intended. The auditor will also want to see proof that the system is protected against network attacks – this is usually a document that explains the types of potential network attacks that have been identified and the measures taken to protect against them. 


Operations Security 
 

Requirement I-16 

Having a change management system aligned with the Information Technology Infrastructure Library (ITIL) is a good starting point for satisfying this requirement. In addition to the standard ITIL process, however, the organization needs a process for regular security reviews to ensure that the associated documentation is also updated whenever changes are made. Typically, the auditor will review a sample of a few changes for all process artifacts, including documentation updates. 

Satisfying this requirement with a system that was initially built more informally as a project for one purpose and later declared fit for processing classified information is very difficult (if not impossible).  This kind of practice is akin to presenting an untouched toothpaste tube to an auditor, where the squeezed-out toothpaste has been put back in. 

Requirement I-19 

Effective vulnerability management requires knowledge of every component within the system, including the lowest-level open-source libraries. Vulnerability tracking should cover all components. Whenever a vulnerability is detected in any component, the associated risks must be assessed, and a plan must be created to either eliminate or mitigate the identified risks. A checklist must be used to ensure that every step of the plan is implemented. Additionally, regular technical vulnerability scanning is also recommended. The technical solution that most organizations use for compliance with this requirement is a CMDB (configuration management database) of some kind. 

Requirement I-20 

In respect of backup arrangements, it is advisable to determine recovery time objective (RTO) and recovery point objective (RPO) values and test the system to make sure these objectives are met. 

Requirement I-21 

For the disposal of classified information in electronic format, the organization needs a documented process and evidence that the process is being followed in practice. Most organizations satisfy this requirement by having a secure interim storage facility, from which a certified service provider collects the materials and destroys them.  

If you need help preparing your organization for a Katakri audit or have any other questions, please get in touch 

2/20/2025 11:05:00 AM