Adding German BSI-IT-Grundschutz

[ab-smith]

Discussed in https://github.com/intuitem/ciso-assistant-community/discussions/240

^{Originally posted by 42mst April 11, 2024}
To expand even further I think it would be a good idea to include this as well.

[ab-smith]

Let's focus on this one as a starting point, and I guess we will focus on the 2023 version:

help me please understand the skeleton of the Excel sheet and how you use it:

• column A, the layer - depth 1
• B, building block - depth 2
• H, requirement, depth 3
• M, partial requirement (the actual requirement details) depth 4

and the rest are meta attributes, that can be used as annotations later on.

Is that it or have I missed something?

[42mst]

@ab-smith

Sorry, I should have give you a bit of explanation:

• The Grundschutz is divided in different layers. These are represented in column A - depth 1
  • Each Layer is divided in separate modules, called bausteine. They are the heart of the IT-Grundschutz; column B - depth 2
  • Each module is part of either ISMS, System, Process, DER (Detection); column C - module-attribute A
  • For each module there are responsibilities; column F - module-attribute B
  • Each module consist of multiple requirements; column H - depth 3
  • Each requirement has a specific criticality (Basis, Standard, Hoch (High)); column I - requirement-attribute A
  • Each requirement can be separated into sub-requirements; column M - depth 4

Overall the important columns that need to be imported are:

• A - Layer - depth 1
• B - module - depth 2
• C - module Type - Attribute (module)
• F - responsibilities - Attribute (module)
• H - requirements - depth 3
• I - criticality - Attribute (requirement)
• L - sub-requirement ID - Attribute (sub-requirement)
• M - sub-requirements - depth 4

[ab-smith]

thanks for the feedback @42mst 👍
One more thing: column I can be considered as a level (equivalent to implementation group of CIS ) ?

[42mst]

@ab-smith
Kind of like the CIS groups but not a 1:1 mapping.

In the BSI IT-Grundschutz framework, criticality levels (Schutzbedarfsfeststellung) are used to assess and categorize the need for information security measures based on the potential impact of a security incident on business processes.
The criticality levels help determine the appropriate level of security controls required to protect their assets.

They correlate more depending on the asset (CIAA). The higher the criticality the stronger/complex and usually more expensive the controls that need to be implemented.

Depending on the asset even a small sized company with 2 employees needs to implement the highest controls and vice versa. I´m not that deep into the CIS controls but I think they also depend more on the size of the company.

Does this makes it a bit more clear?

[42mst]

@ab-smith
To make it very short and to answer your question. Sorry for the details.
Sure, you can consider them as a level :)

[ab-smith]

It’s ok thank you @42mst ; since we added support for multi level ( implementation groups ) I will use that for the BSI

[ab-smith]

prioritized for next week @42mst , will send you a first video before merging :)

I'm stating the obvious but I guess we should take out requirements like APP.1.1.A1.1 where it's mentioned as "Diese Anforderung ist entfallen" or req with "ENTFALLEN" mention ? there are so many lines like this

Also for consistency, I suggest that we drop the mention between () that refer to previous editions or that the requirement is new; this can be covered with the mapping feature afterwards

[ab-smith]

I've managed to free a couple of hours over this weekend @42mst ,
check the cleaned up excel file here that got digested to CISO Assistant format: https://github.com/intuitem/ciso-assistant-community/pull/414/files
I've included the criticality as implementation groups which should be more flexible for incremental auditing.

It seems as a very intense framework, we might need to improve our serialization to make it snappier here

[ab-smith]

Also, after peer review, the file seems to have about 7359 sub-requirements. Does this sound reasonable? can it be auditable with this volume?

[lfrancke]

The IT-Grundschutz is a bit different than most other frameworks I am aware of (and I'm not an expert so this might not be too uncommon).

See this extract which I brought up as a question on Discord:

The "controls" or "requirements" here are much more detailed than in other frameworks as the IT-Grundschutz also does a risk assessment for common scenarios and then suggests concrete steps to take - at the technical level - for each and every one of those scenarios.
But you have to chose which make sense for you.
If, for example, you don't run a Samba server then the whole section APP.3.4 does not apply to you.
No one will have to follow all of these.

In addition there are three different levels of requirements: Basic, Standard and High.
What you do is, you look at an asset e.g. your Samba server and check the "protection requirements" on the CIA triad.
Example: Samba requires Normal Availability and High Confidentiality and High Integrity. This would lead (it's a bit more complicated than that) to Samba being classified as "High".

• Basic checks are - as the name implies - rudimentary checks that everyone should do but if you only follow those you can't get a certification
• Standard is what you'd use with "Normal" and "High" protection requirements and if you follow all of these you can get an ISO 27001 certification
• "High" requirements are what you only need to implement if the protection level required is "Very High", otherwise they are not needed.

So: Yes, there are a lot of sub-requirements but in reality it is narrowed down by a lot.
I do understand that CISO Assistant currently will not help at all in selecting which requirements are useful for a company.
For that an asset register and an assessment on the protection levels would be needed. This is probably a process that needs to happen outside of CISO Assistant and/or as a preparation for it.

My explanation is a) a bit simplified as a lot of the above can be customized if needed and b) might also be slightly wrong as I'm not an expert either. I still hope it helps a bit.

[lfrancke]

Because I just saw your multi-level demo video on LinkedIn: This cannot be used like it is for IT-Grundschutz as the levels ("implementation groups") are per asset and not global.

As in: One mail server can have the level "very high" while another one only has "basic".

But again: I just watched the video and might mis understand.

[ab-smith]

Thank you @lfrancke that is very helpful indeed,

As a matter of fact, I get the approach of having a global registry for everything and then just mark what doesn't make sense as Not Applicable, we we do support, just thinking about the user experience on this one.

BTW, the approach of having presets for risk analysis is shared also with ANSSI standards, the French authority or the NIST with their 800-53 containing +1100 controls,

So the Implementation groups can be actually combined like this:

so you can pick one or two out of the levels as you wish.

and can be a good starting point I believe:

[ab-smith]

The annoying parts that I'm concerned about are about performances and the fact that we don't have yet a feature to batch actions on a full node

[42mst]

@ab-smith wow a lot happened. Thanks a lot guys. I will go through it:

• Regarding the "ENTFALLEN" ones, I agree they can be dropped.

• The amount of sub-requirements seems good. This is just a huge framework.

• The file you provided looks good to me.

• @lfrancke Thanks for your detailed answer. I agree with you. The only thing to be aware of is the comparison between ISO27001 and the Grundschutz. As an ISO27001 certification can also tell you nothing at all. I´ve seen ISO27001 certifications and if you would translate it into IT-Grundschutz requirements they did not even fulfill the BASIC requirements. You´ll always need to know the scope of audit. The IT-Grundschutz is by its nature is telling precisely what and also how you must do certain things. The ISO27001 just tells you what with a lot of room for imagination :).

• The possibility to choose the implementation group is awesome but as @lfrancke said in this case it would only make sense if you can map it with a corresponding asset.

• Now probably the trickiest part; performance. My suggestion would be to be able to load only the BAUSTEINE (modules) you need for the assessment you are performing. As @lfrancke already mentioned, you often only need 10% of the requirements in there. It is more important to be able to work with the BAUSTEINE.

• By that I guess that the performance will increase significantly.

[42mst]

For example if you are performing a cloud related assessment, it just might be enough to use a couple of 2 to 5 BAUSTEINE and not the whole framework. This would cut the ~8000 requirements down to ~60.

[ab-smith]

Ok good idea, so in this case you are suggesting to switch to having BAUSTEINE as Implementation groups instead?

[42mst]

@ab-smith Thats tricky. The current filtering to select the criticality is actually good. It would be better (because otherwise you´ll lose information) to have another layer for the selection:

1. Select the framework (IT-Grundschutz)
2. Select the Baustein(e) (Cloud-Outsourcing, Server, etc.)
3. Select the criticality (Basis, Standard, High)

The advantage of doing this could be also a new feature in the future. Consider the Bausteine more as a tag for a specific topic. If you would add those tags to other frameworks (on a control level) as well you would be able to gain more information (and also have an implicit kind of mapping.) For example as @lfrancke already mentioned some frameworks are more or less useful for implementation as they often don´t tell you how. If you are then able to filter (on control level) for a specific topic you would be able to use more precise controls (from other frameworks as well) for you implementation. Does that make sense?

[ab-smith]

yes the tagging system is something that we have in mind indeed but won't be available right now it's tracked on #413
since you guys are practitioners of this framework, is it worth it to merge it without the Baustein, or it won't be usable?

[42mst]

@ab-smith To be honest I don´t think this is going to be user friendly. It will create to much effort to select the controls you need to have in place.

It would then make more sense to use your first suggestion and treat the Bausteine as Implementation groups instead. In the long run when focusing on #413, we could then switch to an optimized solution and use the tags to represent the Bausteine.

[42mst]

I would also like to free up some capacity from my site for your #413 efforts as I think this will change the data model. Please reach out to me, if I can assist you!

[ab-smith]

@eric-intuitem food for thoughts on this topic, #413 and #185

[eric-intuitem]

Very interesting discussion! We will address the performance issue, but what's more important is indeed the UX for selecting relevant controls. I think about a tailoring feature as suggested by @42mst to select with a top-down flexible approach the requirements to consider, and only create the relevant RequirementAssessment objects (with a capacity to change one"s mind), thus having excellent performance and frugality. And we could let users create selection templates to facilitate the process.

[ab-smith]

Ok great, let's compromise then and I'll split using Baustein to have 10 different files that can be imported separately, this will give us what @lfrancke mentioned, and I'll combine these with Schutzniveau as implementation group so that we don't lose this advantage as @42mst mentioned initially

[ab-smith]

Correction: split by Schicht to get the 10 I've mentioned above

[ab-smith]

ok then I'm doing the split this weekend and should be released shortly after 😉

[lfrancke]

Thank you! I'll take a look after the next release.