Entity framework granularity - How deep we should go?

[Marek Remi_]

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

1. Is my approach and understanding how to properly design entities correct ? 
2. 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]

Hi @Marek Remi_ 

if you implement GRC this Entity Scoping part is vital, but there is no "one standard to rule them all".

But i think your approach is correct. I've been implementing it in a similar way.

You can leverage dynamic CMDB Groups to "collect" CIs, in a quite flexible way, so you dont have to create "artificial" entities.

I use those groups as an entity (e.g. 50 Server in Group A, 50 in Group B, in GRC 2 Entities, one for group A one for B). The filter condition for those CMDB Groups can be adjusted to your customers likings. This grouping can be "all servers that are linked to process X" or "all applications that are used by department Y".

The grouping itself depends also on the Control Objectives and finding correct filters for those groups is considered the most important part. 

Using those groups avoids assessing single CIs as single entities. 

Hope this helps, if you have more questions, let me know

[Marek Remi_]

This looks even better than my approach, offering more granularity, and you can group the servers by importance or criticality, for example. Really nice idea.

Unfortunately, this solution would require the customer’s maturity to be higher than usual, and also a huge cooperation between data management and the Risk/Compliance/Audit teams, if I’m not mistaken.

So, it may be something helpful in the future.

What I guess I really need to do is dive deeper into what is truly important and necessary for them to meet all the regulatory criteria, right? Some companies need more granularity at the business process level, others on the CIs — it depends. But the customer has to share this information so we can properly define the entities, right?

[Matthias Ferstl · Accepted solution]

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

[SohamTipnis]

Hi @Marek Remi_ ,

This is a really good approach, as I am new to GRC, and I find it very interesting, but I have some doubts about this approach. There are a few questions for which I need answers from you, like:

• Are patching risks different?

• Are vulnerabilities different?

• Are compliance requirements different?

• Are control procedures different?

If controls are identical, then even this might be too granular,

I think there will be few difficulties in this approach; let me know if my questions are valid to you 😊

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

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