As you will know, IT-Grundschutz covers information security issues. This concept provides methods to identify and implement security measures using state-of-the-art procedures. The name “Grundschutz”, the German word for “basic protection”, is a little misleading because the measures described in the corresponding catalogues go far beyond just “basic” protection. If you are busying yourself with the IT-Grundschutz catalogues issued by the German Federal Office for Information Security (BSI), you are probably about to introduce an ISMS (information security management system) – be it by choice or by force. Security needs management, that much is clear.
Everybody must find their own way when dealing with security, i.e. to define its meaning and significance. While this applies to individuals, it is even more important on the company level. Since security is just a concept and nothing tangible, you might ask yourself: What does IT security mean? I find the following statement quite neat:
“Safe = orderly + clean”
With respect to an IT landscape, this means for me that it is necessary to create and maintain a traceable IT documentation that must contain all relevant contents and always be up-to-date. Every member of the IT department must be aware of it, know where it is filed and of course be able to use it.
The IT-Grundschutz catalogues includes numerous references to the necessity of a comprehensive and clear IT documentation. The following safeguard is particularly important: S 2.219 Continuous documentation of information processing. This is a central safeguard which, in turn, is subdivided into several individual topics.
- The scope and contents of an IT documentation are described in safeguard “S 2.25 Documentation of the system configuration”.
This safeguard stipulates that the IT documentation must describe the physical network structure and the logical network configuration, the data backup, the applications used, and the file structures in the IT systems. The safeguard also details the creation of a recovery plan and the necessity of documenting the reporting chains.
- Safeguard “S 2.31 Documentation of authorised users and rights profiles” defines the requirements with respect to a roles concept and the documentation of a directory service such as Microsoft Active Directory.
- Safeguard “S 2.34 Documentation on changes made to an existing IT system” presents a special challenge because the documentation of the daily changes made to IT systems is no trivial task for any IT department.
- Safeguard “S 2.4 Maintenance / repair regulations” describes the documentation required for maintenance procedures and the interaction with external service providers. This safeguard also mentions the activities to be carried out before and after repair.
- Safeguard “S 2.215 Error handling” describes the IT documentation requirements with respect to errors or malfunctions that occur in IT systems.
- The procedures covered by “S 2.26 Appointment of an administrator and his deputy” are a little easier to implement. This safeguard mainly discusses how to take organisational measures and brief all members of staff.
- Safeguard “S 6.37 Documentation of the data backup” should be part of your data protection concept. If this concept already exists, you can directly link to it in your IT documentation.
- Safeguard “S 6.59 Specification of responsibilities for dealing with security incidents” documents the reporting chains for the different levels of security incidents. It states the user groups to be defined beforehand and the rights and duties to be assigned to them in case of a security incident.
There is a lot to do…
The above-mentioned safeguard S 2.219 is classified as qualification level A, meaning that it must be implemented as a basic safeguard and not only if you go for a certification. This safeguard is grouped under module M 1.14 – “Patch and change management”. Most certainly, your data protection officer will request an IT documentation, for instance when auditing the technical and organisational safeguards. It is also required when it comes to ensure the availability of the IT system. How is it possible to restore a system if nobody knows about its configuration before the crash? Very often, an up-to-date backup of the configuration is not available, but only an earlier version. In this case, the most recent changes need to be reproduced manually. Or take the case where a new configuration proves to be unsuitable and you would like to restore the old settings. Unfortunately, nobody remembered to back up the configuration prior to the update. Where can you look up the previous state?
A never-ending story
Be aware of the following: IT documentation is a constant process that never ends. At best, your IT documentation always reflects the current situation. This is an obvious result of the requirement to document all changes made to an existing system. But if you succeed in keeping your IT documentation up-to-date, it will provide an invaluable benefit. Of course, there are dedicated software tools that will help you with this task. Some activities, however, cannot be automated. I recommend that you add them to your process descriptions so that you will not forget them.
An example of a software tool for automated IT documentation is the Docusnap documentation tool. In the next parts of my post, I will refer to this software whenever appropriate and point out how you can use it to implement safeguards properly.
The second part of this article will give you more details on the safeguards stipulated by the IT-Grundschutz catalogue.
