hi this is Andy and Denny we're members of the customer outcomes group here at servicenow where we focus on implementing our security operations products we've put together some content here today into our series called the more you know specifically we're going to cover the interactions between servicenow secops vulnerability response configuration compliance and the servicenow cmdb we've put this content together for a number of reasons the vulnerability response product in particular has evolved significantly since its initial Inception there are certain components especially with the interactions with cmdb that have paint there are also some common misconceptions that we hear in the field with regards to the interactions between vulnerability response configuration compliance and the servicenow cmdb along with where the seem to be ire component fits in we're also looking to clarify some of the dependencies and moving Parts within secops and the cmdb interactions we'd also like to show you the interactions between secops and cmdb in a step-by-step walkthrough to kick things off let's go over some key terms cmdb that is our configuration management database think of that as your central area where you store you track and you manage assets devices right ownership relationship details a configuration item or what we call ACI that's a representation of a single entity environment that may be something physical such as a server it might be something logical such as a instance of a database server or it might be something conceptual such as a relationship or a service seem to be ire stands for identification and Reconciliation engine this is one of the ways we maintain the Integrity of the cmdb the ire is what is used to Control Data inserts and updates within the same DB discovered item that is a secops component think of the discovered item as a representation of a host from a third-party security tool such as a vulnerability scanner like qualis rapid 7 tenable and the discovered item points to a corresponding CI in the cmdb that might be an existing CI that we did a successful lookup on or that might be a CI that we've created because a representative CI did not exist in the cndp and really think of the discovered item as the glue between our security tool and the cndb it's what Stitches the two together let's move into some key Concepts so as you can see on the diagram here we have on the left are external tools our asset inventories these are what feed into the servicenow cmdb as this information is brought into the cmdb the ire think of the ires or interface that is what controls the inserts or the updates so that controls creating new CI records and updating attributes on existing CR records on the right side we've got our security tools that could represent things like our vulnerability scanners if you look here the third party scanner is what creates the discovered item and the discovered item is what is used to consume data from the cmdb as we mentioned before this is the the glue or stitching together right the discovered item is what puts these two together your cmdb and your security tool as we bring in security data into servicenow we initially start by ingesting that information that information may contain simply the hosts from a third-party security tool like a vulnerability scanner that information may also contain the host and the identified vulnerabilities on those hosts but we we start at the same point we we ingest that information the next step is to determine have we seen that host before do we know what corresponding CI and the cmdb we should use for that host if we haven't seen that host before we move into our lookup or cndbci lookup process here is where we actually say based on the host that came into servicenow how do we find a matching CI in the cmtb we may use certain identifying attributes like the DNS name or fully qualified domain name or an IP address if we're unable to successfully look up a CI in the same DB we then move into what we call our unknown scenario and that is where we we would actually create a new CI in the cmdb to track that host there are some common misconceptions that we hear in the field with regards to the secops and cmdb interactions the first one is Stack Up ca lookup rules are the only way to match a host from a third-party security scanner to a corresponding CI in the cmdb and actually there are really two ways yes the first one is the second rules however we also have the ire identification rules the next is when we can't find a CI in the cmdb with the lookup rules we simply just create a new CI in the unmatched CI class this was true in early generations of the VR product where we tried to look at look for a CI in the cmdb we couldn't find a matching CI and we would create one however in the new and the current generation of the secops applications we no longer use the unmatched CI as the primary home for the unknown scenario we still use the unmatched CI class that is for if we try to create a CI with the ire feature and there's an error condition that we run into but primarily there are two new classes that we create CIS in the first is the unclosed hardware and the second is the incomplete IP the next is reclassification of CIS created by secops has to be performed by hand in other words if we load a host in from vulnerability response and there's no matching CI we'll create a CI at some point in the future when the real CI comes into the cmdb there is a way that that can be automated to reclassify the CI that was created by our security tools the last is secops will not update attributes on existing CIS in the cmdb in other words we're not going to step on the toes of scene DB it's actually not quite true there there is a notable Edge case where secops May in fact update a particular attribute such as an IP address attributes the operating system attribute on an existing CI we'll dive deeper into these misconceptions as we get into our scenario walkthroughs let's break down the scenarios that we're going to step through here the first is a host brought in from a third party security tool and we successfully matched to ACI and the cmdb with the secops see I look at pearls in this case we never interact with the ire the second scenario is going to be we bring in a house from a third party security tool and unfortunately we don't match to a CI in the cmdb so we have to create a new CI in the cmdb in this case the winning interaction is actually ire as ire will create that new CI the third scenario is where we bring in a host from a third-party scanner and we don't match to the CI with the secops say look up rules so we pass pass it on to ire before it creates a CI will actually do its own lookup and in this third scenario though it is an edge case that is possible that the ire will match to a CI in this situation will prevent the creation of a duplicate CI the fourth scenario is where we bring in a host from a security tool and there is no corresponding CI so we create that CI in other words vulnerable response is first in the door now at a future date your cmdb Discovery tool brings in a corresponding host what will happen here is ire will prevent the creation of a duplicate CI and in fact what it will do is reclassify the host that was created by our security tool to the right place Denny's going to walk us through each of these four scenarios in a step-by-step sequence over to you Denny thanks Andy in scenario one I will be going over when a host brought in from a third-party scanner is successfully matched to a CI in the cmdb using the secapp cmdbci lookup roles step one involves a discovered item lookup which is used to help us determine whether secops has seen this asset before the lookup tries to find an existing discovered item with a source ID matching to the host ID provided by the scanner for this asset in this scenario a match is not found because this is the first time we are ingesting this new asset in step two a lookup occurs using the secops CI lookup rules each active rule is evaluated based on the attributes of the host they find a matching CI in the cdb the rules are executed in a specified order and when a rule returns a single CI the CI is identified as the matching CI and other rules are skipped in step 3 a CI record was found in the seem to be for the corresponding host now after a successful lookup a new discover item is created using the host ID from the asset as the source ID for the discovered item the discovered item will also contain various attributes of the hosts that were available from the scanner because the Discover item record has now been created for this host and Associated to a CI in the cdb subsequent ingestions of this host will complete here at step one with a discovered item lookup and no longer require the second rules to run for this host scenario two covers when a host is brought in from a third-party scanner without matching to a CI in the cdb in this scenario a new CI will be created Step One is similar to scenario one where the host ID is being looked up against the discovered items table and again since this is the first time the asset has been adjusted there's no matching disabled item step two second option CI lookup rules are invoked and each rule is being evaluated based on the attributes of the host as we move on to step three all the psychopsy I look up rules have been evaluated and no matching CI was found in the cdb in step four the host dot is now passed over to seem to be ire and the ire identifier rules are invoked against the hardware class steps five and six shows ire performing a lookup against the cmdb using the name of the host and no matching host was found now as we move on to step seven at this point ire creates a new CI record the target tables for creating Ci's from ire are the unclassed hardware incomplete IP and unmatched CI in this scenario the CI was created in the unclass hardware table the CI is created in this table if I P address plus additional information in the host information that is received from the scanner contains data such as the hostname DNS net bios or the MAC address the CI is created in incomplete IP address class if only the IP address is available there's also the unmatched CI class in earlier releases of vulnerability response prior to version 12.1 unmatched Ci's were created in this class this class is still used now in cases where ire ran into an error while trying to create the CI after the CI is created a new discover item record is created associating the host from the scanner with the newly created CI scenario 3 covers when a host is brought in from a third-party scanner and matched to a CI in the cdb Via ire identification rules this is a less commonly seen scenario because in most cases they've been matching CI exist in your cmdb your CI lookup rules should ideally find that first before the ire lookup is invoked however there are some edge cases where this may occur depending on how your CI lookup rules are configured and your cmdb data so it is still important to understand how the scenario may impact or seem to be in case it occurs in Step One discover item lookup occurs where no matching discover item was found step two the stack up CI lookup rules are invoked and in step three all psychopsy lookup rules have been evaluated and no matching CI was found in the CME in Step 4 host data is passed over to seem to be ire and the ire identification rules are invoked step 5 ire performs a lookup against their cmdb using the name of the host and a matching CI was found that is a Windows server in Step six once it matches found by ire ire will update the cmdbci attributes using the available attributes for that host that were provided by the scanner some examples of CI attributes that may be updated are the OS IP address and the ftdn this example shows how the CI looked before ire updated some of the attributes with the data from the scanner and we can see here attributes that were changed highlighted in red there are cases where you may not want the scanner to update the attributes on the CIS and in order to prevent that from occurring reconciliation rules can be created for the Discover sources that create or update CIS in the cdb and that will allow you to configure the Precedence for which source has the ability to update this data details of these steps are available in this knowledgebase article listed here as with other scenarios after this lookup process that occurs a new discover item is created and Associated to the CI is the host from the scanner in this case the discovered item state will reflect the state of matched however the discovered item CI lookup rule will be empty because the match was done using ire identifier rules rather than the second Seattle couples in scenario 4 we will be assuming that an unclass Hardware CI has already been created this is a CI that has already gone through the lookup process and was created by ire as an unclass Hardware this often happens when a CI was first brought into servicenow via a third-party scanner before your discount resource so in this case secops is first in the door we will be going over how the CI can be automatically reclassified in the future preventing the creation of a duplicate CI in step one we have a host that comes in from Discovery or another ire source since this is not a secops VR Source or a configuration compliance Source it doesn't have to go through this setcaps lookup process Instead This host payload gets passed to the cmdb ire and starts here steps two ire performs a lookup on the cmdb to find a CI using ire identifier rules and doesn't find a match in existing CI classes such as Windows server and Linux server but in step 3 ire continues searching it seem to be and does find a match for the incoming host in the unclass hardware table this match is based on the name field in Step 4 ire reclassifies a CI that was originally brought in by the scanner and moves the CI out of the unclass hardware and into the Windows Server class this is done through leveraging the ire identifier rules where in this case the name of the unclass hardware CI matched the incoming name from ire then finally in step five ire enriches the CI where incoming details from the discovery data source you can see here how the CI looked when it was first created from the standard source and how it looks after the array was reclassified and updated by the discovery source the OS is now populated and the class has changed from unclassed Hardware to Windows server the discovery Source has also changed from VR Dash qualis to Discovery that was great insight into the four scenarios that we called out here with the interactions between secops and cmdb to bring us home let's summarize what we've discussed number one there are multiple lookups involved in the interactions between secops and cmdb and those those lookups operate in a sequence the first is we have our discovered item lookup right which works with the source ID from the Upstream tool we also have our secops CI lookup rules which have their own ordered logic and we also have the cmdb ire identification roles in particular the hardware role the next is secops can update attributes on existing CI records it is an edge case but it is possible and there are two components to that so the first is the seem to be ire identification rules again on the hardware table and there's also the the knowledge article that we're going to share that covers the ire data source rules which allows you to configure the Precedence of which a particular sort can update an attribute on a CI for example you might want to have a discovery Source you know favored over qualis for updating the operating system on a Windows server and lastly in scenarios where we have hosts coming into the cmdb from a security tool or application like vulnerability response and we in fact create those CIS because we couldn't find a matching CI on day one it is possible that at a future date when your cndb Discovery tool comes in those CIS can be reclassified appropriately in other words they may start out as unclassed Hardware CIS and then they may move to the Windows Server CI class that works with the seem to be ire identification rules in particular the hardware rule where we focus on the name attribute thank you everyone for your time we'll be sharing some of the links that we've been discussing here as part of the content bye-bye