How does CSDM complement Vulnerability response

[Dharshini Rohit]

Hi,

In all VR documents, it is mentioned that a CI should possess an Assignment group info for the Remediation tasks to be assigned to. However, this contradicts the fact of introducing CSDM. As in CSDM, we group CI's either to a Technical Service offering via Application service. The support group info for ITSM triaging is obtained (based on category of the Incident) from either Application Service or from the Technical Service offering.  But for VR, we are required to populate this info on the CI. My question is, where and how does CSDM provide value to Security operations/ vulnerability response.

Thanks

Dharshini

[Mark Bodman]

The main issue with CI's belonging to multiple TSO's is that ownership, reporting etc. becomes ambiguous.  It also compounds difficulty in who to assign a ticket, calculating SLA / OLA & Commitments based on outage records, keeping all the right teams involved for a change approval etc. 

The data synch process results will be arbitrary if a CI is part of multiple TSO groups. All the assignments will happen.  The last one that is processed will be the result you see, this is completely arbitrary.

Scott Lemm and I discuss this situation with TSO's in this video deep-dive discussion on Technical Services to explain the nuances in detail. Hope this helps explain it in more detail. 

[CMDB Whisperer]

Does it need to be arbitrary though?  It would seem to me there are ways around this including:

• Allow the support group to be overridden on the CI so that synchronization occurs only if it is empty (or currently matching so that it will pick up changes)
• Use the "Teams" list to show that there are multiple support groups.  (As I understand it that was one of the original intentions of that list but the last time I checked there were business rules preventing the addition of multiple groups with the same role.)

In any case I just wonder how realistic it is to assert a one-to-one relationship.  I think you called out in one of your videos that there are gray areas, so I'm just calling it out as well.  I think there is a difference between designing only for the scenario where there are one-to-one relationships versus defining the business logic that occurs in those cases where there is not a one-to-one relationship.  I agree there should be ideally, I just wonder if this unnecessarily limits the capabilities.

[Mark Bodman]

It is actually 1 TSO to many CI's, but from a CI perspective, yet one TSO. Enforcing this in the future is the main strategy to become product-centric.  Properly managing product design, decomposition, and dependancies.  Today's situation makes this impossible, so most organizations will not be able to transition to a product-centric model.

Teams is not to support "many owners".  It's meant to address the various product team responsibilities for a CI's. Teams will also extend more into the Dev and planning aspects, and be defined more from a product-centric model in the future.  This is currently done in DevOps teams, we are supporting this concept more thoroughly in the future, to include the technical teams who own various components of the tech stack. The TSO model is a big step in that direction, where product-centricity is severely lacking in practice because of this ambiguity we are discussing here: multiple ownership = no ownership in reality...

[CMDB Whisperer]

Thanks for clarifying (and for correcting the relationship cardinality phrase I used mistakenly).  I think I did see/hear a comment about Teams that indicated that multiple values could be specified for the same role, such as multiple levels of support perhaps?  Not sure where I saw that so I'll have to go check my notes.  In any case, as you point out I think once we have the Teams piece more fully in place this will go a long way to solving my dilemma and skepticism, since the use case I keep coming to in my mind is what if one CMDB group is "all Windows Servers" which is supported and another group is "all Windows Servers that run a SQL Server instance".  While I completely agree that it is mistaken to say there are multiple owners of these Servers, I do think it is valid to consider this as a shared support model.  The Windows team may be responsible for provisioning the server to begin with, as well as performing patching activities and handling outage, but the DBA team may be authorized to perform updates to the server as well, including applications and even rebooting the server if needed.  So it may be a legitimate need to use CMDB groups to show a list of the Servers that have the specific DBMS platform installed on them.  Any thoughts on this use case, and how it could flow into the use of Teams or some other feature?

[Barry Kant]

My thoughts:
In my opinion those could be contextual. 

Can a TSO contain context like:

• ownership
• primary support
• disaster recovery
• ...

It might also be an option that the Business Service (Offering) includes context:

• This is modern solution (support vertical)
• This is traditional solution (support horizontal)

Context kind of logic makes is possible to support a hybrid landscape (it offers flexibility where needed).