After discussing the scope and contents of an IT documentation in the first part of this article, I would now like to take a closer look at the safeguards.
Which contents are stipulated by IT-Grundschutz?
Safeguard “S 2.25 Documentation of the system configuration” lists some contents and topics relevant to IT documentation. Thus, the physical network structure and the logical network configuration of a network environment need to be documented. This means that your IT documentation should cover all IT systems operating in your network. For each IT system, create a datasheet that documents the entire configuration and all system settings. It goes without saying that this also includes the installed software base and the passwords in use. Documenting the logical network structure is no less time-consuming: Here, the existing data connections, the network services in use, and the applied protocols should be considered. Once you have analysed and documented all these points, tasks such as monitoring your IT network will become a lot easier as only the documented types of data traffic may exist. Anything else is not permitted and should be reported immediately, enabling you to detect unwanted IT systems and applications in your network.
The safeguard mentioned above also stipulates the documentation of access rights and file structures. Even in smaller networks, it has meanwhile become virtually impossible to document them manually as file structures in general are just too complex. It is hardly possible to analyse and break down nested file structures or inherited rights without the help of a software tool. In Docusnap, you can use the Permission Analysis module for this purpose and automate the documentation of this data. For more information, read our “Inventorying File Servers and Access Rights” blog post.
IT documentation does not stop here: You need to add a data backup description as well. We recommend that you define a logical structure for your documentation: First, create your data backup concept which will also be required by the data protection officer for auditing purposes. Set up your data backup on the basis of this concept. Your data backup software will already contain most of the information required for documenting this process. However, how can you provide this information is a suitable way? You surely want to avoid that everybody has access to the data backup software. Depending on the backup software product, Docusnap can help you here again by automating the documentation of completed backup jobs.
Docusnap also allows you to document the order in which IT systems are switched on and off during start-up or power-down. In the IT Relations module, you can graphically relate the recovery plan elements with each other, create the actual recovery plan in the IT Concept module and document it by adding descriptive texts. This way, IT staff can rely on detailed instructions when needed and are not lost in the event of an emergency case while the responsible administrator is not available.
Collecting directory services data and roles concepts in use
Documenting all users and groups that have been set up as well as their current access permissions is another very tedious task. For this purpose, we recommend that you first create a so-called roles concept. It describes which members of staff or which teams have by default access to which folders and files. Granting access to the file server or creating shares should always be based on roles, not on individual persons. This makes it easier to keep track of the shares.
This rights concept will most probably be mapped using a directory service. For roles documentation, you can for example use the Permission Analysis module of the Docusnap documentation tool. Aspiring to document them manually is as ambitious as trying to document directory shares on the file server. In addition, the roles should be reviewed (and revised, if necessary) continuously, at least for the folders and files requiring appropriate protection.
A special challenge: documenting daily changes
Safeguard “S 2.34 Documentation on changes made to an existing IT system“ stipulates that you document all changes made to IT systems. This is a special challenge for every IT department because strict discipline is required here. Any change made to a system must be documented in a traceable manner. This is not trivial because immediately after making a change, you are often called for something else. So unfortunately, there is hardly any time and occasion to document the changes. A way out of this dilemma is the automatic inventory of all IT systems. Another option would be to create a change request or ticket for every change, as suggested by ITIL. This requires a certain overhead but would be worthwhile.
Again, you could use Docusnap to create an automated documentation. Provided that you perform inventory scans frequently, you can compare them in order to determine any changes that have been made in-between.
Read the third and last part of this article to learn more about the safeguards stipulated in the IT-Grundschutz catalogue.
