The phrase process-procedural security might be misunderstood or confusing to the layman, as it happens to be associated with chemical technology rather than the world of cybersecurity. Nothing of the sort.
It is a term associated with security science and is applicable to both security in the broad sense, infotmation security or, more specifically, cybersecurity.
Process-procedural security is a process, like infotmation security, of which it is a component, a sub-process. It can be said, by oversimplification that any kind of security, regardless of its type, is based on two fundamentals:
- technical security (generally tools, equipment, systems, software, etc.),
- process-procedural security (the processes in the organization and the procedures describing them, based on functioning standards, so-called good practices, norms, etc.).
One can consider these two bases to be like two sets of building blocks from which the security designer draws components to build the system, depending on the functionality that the designed system is to have. The possible results:
- security system,
- infotmation system security,
- cybersecurity of the organization, state, etc.
Each of the systems built can be a little different depending on the external context, the expectations, the requirements it has to meet.
In the area of IT-like security, it is worth considering the approach defined by recently fashionable terms like security by default and security by design.
Unfortunately, usually such a model approach to security design is an idea that is nowhere near the reality.
Often, especially in the world of cybersecurity, one can hear that real security is provided only by the hard core, i.e. technical security, and process-procedural security is some kind of ‘whim’, an unnecessary nonsense, because it practically does not give anything to anyone, it generates costs, alternatively (this is sometimes the only reason to tolerate it) it can protect from paying a fine for failure to meet the requirements of the legal provisions.
There is a bit of truth in this because all ISO or process-like systems are designed to manage safety, monitor it, correct it, improve it, force certain actions, but they are not designed for real actions. They are inherently soft; unlike the hard ones that technical security offers.
On the other hand, basing systems security solely on technical security is a mistake because systems built and maintained without a foundation based on solid risk analysis are poorly tailored to the organization, do not take into account the risks arising from the organization’s context (internal and external), and are not properly managed, because no one remembers to provide adequate resources, periodical maintenance, and supervision. System updates, backups are done from time to time, when someone suddenly remembers about them or when a minor malfunction brings attention to the need to recover a copy. Authorisations are granted during conversations on the corridor, and administrators work with privileged accounts. The examples multiply. It’s full of chaos and laid-back attitude. People say that the systems work that way and nothing happens. Yes they work, but they will do so to the sad end when something happens to someone’s resources, there is a data leak, a data theft, or a hardware failure that causes damage. Then customer claims will arise, external auditors will show up with uncomfortable questions, and the relaxed life of chaotic administrators will become very complicated. The question arises, is this the direction we want to go?
It seems to not be an optimal direction, and many system administrators, system owners are slowly realizing that a middle ground must be found, that there must be a way devised for a sensibly built ICT system that will be operated by administrators who are aware of their tasks, who receive ongoing training, and who know that the combination of the two basics described earlier, i.e. technical security and process-procedural security, is essential, because it simply benefits everyone.
Based on various completed projects, it can be concluded that the percentage of administrators or system owners described in the previous paragraph is still not large, and there are still a lot of systems that have process-procedural security issues incorrectly implemented and regulated.
The process-procedural irregularities encountered can be systematized according to the following problems:
1. Lack of procedures related to systems management. Many organizations lack any documentation related to process-procedural safety. Administrators explain this with the amount of their workload, numerous duties that do not allow them to take care of the so-called ‘paperwork’. Sometimes, after a sudden inspection, audit, the documentation is created, completed just so it’s there, without any deeper meaning. Administrators often say they use standards, the so-called ‘good practices’, in their work. Unfortunately, in no way are they able to recall what those standards, recommendations, etc. they used were called.
2. If the documents on the management of systems, IT security exist, they are related to the security policy within the meaning of the old regulation to the Law on Personal Data Protection, i.e. the Regulation of the Minister of Internal Affairs and Administration of April 29, 2004 on the documentation of personal data processing and the technical and organizational conditions that should be met by devices and IT systems used to process personal data.
It’s also interesting that they don’t go to the benchmark, which could be Appendix A of ISO 27001, where a catalog of procedures required in an Information Security Management System is listed. An exemplary catalog of procedures that a system compliant with the ISO 27000 standard should implement.
If the administrators had used the Regulation of the Council of Ministers of April 12, 2012, on the National Interoperability Frameworks, minimum requirements for public registries and the exchange of infotmation in electronic form, and minimum requirements for ICT systems, they too would have found a reference to the standards they should apply in their work.
3. Some organizations claim to have an Information Security Management System (ISMS), but they are not built on the basis of standards such as the ISO 27000. They are mostly based on the outdated Regulation of the Minister of Internal Affairs and Administration of 29 April 2004 on documentation of personal data processing and technical and organizational conditions to be met by devices and IT systems used for personal data processing. Written in accordance with the regulation, the security policy based on the personal data security policy listed in the regulation and the management instruction for the information system used to process personal data is introduced by the regulation and treated as documentation of the ISMS. It should be noted that the system, built on the basis of such a policy, does not exhaust the characteristics of an ISMS, because it is not periodically updated, managed, maintained, nor does it address the other issues described in the standard.
If the organizations don’t want to use paid ISO standards, they can use free NIST documents, and if they have trouble translating these documents into Polish, they can turn to the National Cyber Security Standards based on NIST documents translated into Polish.
4. Lack of documentation related to the risk estimation process, risk analysis, etc.
Organizations generally don’t keep risk analysis documentation. If there is any documentation, it is done for data protection purposes. At this point, it must be added that deficiencies related to the lack of risk analysis documentation should be added to the scope of deficiencies related to the inventory of IT resources. Of course, this is not about the accounting inventory. It’s difficult to manage something you have no knowledge about or aren’t aware that something like this exists in the managed infrastructure. Very often, administrators are unable to indicate on what basis they made their purchasing decision. It was an exception for an administrator to say that certain things are not done as a result of the risk analysis.
Unfortunately, it can be said that risk analysis is treated as something completely unnecessary, and if it would have to be done, it is only because of an obligation imposed by law. Administrators see no benefit in this (with very few exceptions).
5. Lack of business continuity plans
In organizations, the issue of business continuity is treated with great nonchalance. There are no dedicated documents on these issues. Sometimes there is a paragraph or two about it in the security policy (understood as in the previous paragraphs, especially in paragraph 3).
6. Lack of systemic identity and authorisation management.
In the organizations inspected, assignment of rights is sometimes done in a very loose way, without evidence of resource assignment. Even if it is done in a compliant manner, there are no documented procedures.
7. Lack of systemic incidents and vulnerabilities management.
If something is implemented in this regard from the process-procedural side, it is written, again as part of the security policy understood as in the previous paragraphs, especially in paragraph 3. The incidents are described only in terms of data protection, while others are mostly downplayed. Sometimes the UTM (device registers and logs) or security system logs are treated as incident, event logs.
8. Lack of a service approach to IT systems management (ISO 20000, ITIL)
One can observe a gentle development of interest in such issues, but it is mostly out of curiosity, or receiving training in this direction, etc. Practical knowledge and experience in this area is marginal, and mostly in the ITIL library scope rather than ISO 20000.
9. Lack of documentation on development planning for managed systems.
Implemented investments, equipment purchases are not justified by development plans. If such planning is done, it is perhaps at other, higher organizational levels. At the executive level, if there are funds in the IT field, they are momentarily dispersed, as there are many needs and few resources. The consequence is a lack of planning because it’s hard to plan for the long term when you have to meet current, immediate needs. Therefore, it is difficult to find such elements in the analyzed documents presented for review.
The same is true of the aforementioned risk (point 4). In general, one does not encounter an organization (one stated exception) where any activities related to cybersecurity, systems management were based on or linked to risk analysis. There is no perception of a link between the identified risks and their mitigation through appropriate investments – other safeguards. This indicates either a poorly run risk analysis process in the organization, or silo structure, poor information flow, and a lack of linkages between organizational processes.
Summary
As can be seen from the remarks, there is much to be done in the area of process-procedural security. It seems to be a good idea to start by pointing out that data security, or cybersecurity, is a permanent process, never finished, requiring continuous work.
It is important to maintain the periodical nature of the process, continuous updates not only to documentation, but also to systems, implementation of patches, planned improvements, investments, training, etc.
The procedures are meant to be a tool to control the parameters of security systems and are meant to help and remind administrators of what to do. On the other hand, the system documentation is also intended to be a memory of the changes and improvements the administrators have made to the system. It is supposed to secure evidence of work done, traces of incidents, etc.
Documentation is not only supposed to be ‘God’s punishment’ for administrators, but also their salvation, since it is on the basis of the documentation and event logs collected in accordance with it, that it can be proven that the administrator has done his job, properly configured, secured the system, secured the traces of the intrusion and that the fault does not lie with him, but somewhere else, elsewhere in the organization.
