Entity framework granularity - How deep we should go?

Marek Remi_ · 3 hours ago

Hello Everyone,

I would like to know your opinion or get help with Entities and which ones to generate to make Risk and Compliance manageable.

The thing is that some of the customers have not used Entities in the past, and their risks were "in the wind," not really specifying what may be impacted. Most of their risks sound like a risk to the company itself, and that’s it. They see the benefit of having entities to specify the risks, BUT they also have a huge problem defining the entities so they don’t end up from 500 risks to a few thousand by applying statements to everything that may be affected.

Some cases are really easy since we don’t have that many entities, for example, departments. They know that this statement describes the risk that all departments should assess. That way, we will have entities per department, and then the risks and controls on each department. Still manageable, I guess. There are not thousands of departments.

BUT if we start talking about IT CIs like servers, now we are elsewhere. Some of the companies are managing thousands of these, and it’s not really manageable to have a few risks and controls for each server, right? So I was thinking that we should not generate an entity per each server, but instead go up in the CMDB hierarchy and say we have Linux Servers and Windows Servers, or even just Servers.

Example:

I have 1,000 servers.
It’s nonsense to create an entity for each of them, attaching control objectives and statements, and generating thousands of risks and controls. I don’t think it’s necessary to be so granular anywhere. That is, I would go one level higher in the CMDB and say that I will have two entities: Windows Servers and Linux Servers.
In my opinion, this level of granularity is enough for the customer and is definitely better.

My question are

Is my approach and understanding how to properly design entities correct ?
if an entity is meant to represent an entire table and not specific records in the CMDB, then I cannot use the source record because the "Windows server" is not a record; it’s just a cmdb class that contains records. Does this mean that I create an entity without a record and name it the same as it is in the CMDB? Do you think this is a good approach? Or how else could this be solved?

I understand that some entities can be managed in the standard way if there aren’t hundreds or thousands of them, like departments, etc. However, with these IT CIs, I’m concerned that it might not be manageable.

I would appreciate any input or if anyone has dealt with this before. Thanks a lot!

Matthias Ferstl · 2 hours ago

Basically: Yes there has to be some cooperation, but it should be okay, if Risk/Compliance/ Audit Teams define own CMDB groups (and filter). The rest is part of the GRC Application.

Before I help customers define their entities is taking a look on the controls and risks.

A very baseline example: If I see Control Objectives like "activate windows defender" i know that i have to define Windows Clients and separate them from other clients (makes no sense to have that on a linux client).

And your customer should definitely share these information, as this is in his own interest to avoid: - Gaps

- unneccessary granularity that slows down security relevant processes

Please mark answers (not only mine) as helpful if they were
and "accepted solutions"This motivates others to take part, post solutions and find answers. Thanks! - Mat

View solution in original post

Marek Remi_ · 2 hours ago

I had similar questions. BUT then I realized they managed without having any entities, with a single risk saying something like this:

Risk of Server Configuration Management
If server configuration changes are not tracked and controlled, then .... may occur, leading to ......

This somehow worked for them. So, I don’t want all the servers to have this risk, but I want to connect it to an entity and make someone responsible for the other risks and controls

SohamTipnis · 2 hours ago

That's a great approach and technique. I would like to know more about this. Once your approach meets with a real-life situation, do let us know. This will help us to learn more from actual real-life approaches and methods in GRC. Thanks, Marek Remi. 😊

@Matthias Ferstl, your approach for groups of entities is excellent; I will apply this with difficulty in my work as well.👍

Marek Remi_ · 2 hours ago

Yeah, having something at the CI level that distinguishes CIs into groups, e.g., by criticality, would require the CMDB to maintain it correctly. But then, we can group them by criticality and treat them differently if needed.

Yeah, a lot of documents and information won’t give you these real-life scenarios, and knowing how to approach this is the power of the community, I’d say.

Glad to help, and glad for the help!

SohamTipnis · an hour ago

@Marek Remi_

If you find my answer useful, please mark it as Correct ‌😊

Regards,
Soham Tipnis
ServiceNow Developer || Technical Consultant
LinkedIn: www.linkedin.com/in/sohamtipnis10