Everyday new security threats emerge – from software and hardware vendors diligently testing their products, to customers reporting issues and hackers exploiting vulnerabilities. In response to these threats, vendors are constantly developing patches and fixes to their products to protect you (their customers) from security threats. How effective you respond to these threats and close the back doors that put your company at risk is up to you.
Responding to IT security alerts is a race between your company and those who would do you harm. In order to win the race, you need to identify and fix the vulnerabilities in your systems before someone ese can identify and exploit them. Fortunately, you have an advantage in this race in the form of your ITSM system and the asset data in your CMDB.
The way it (hopefully) works goes something like this… the software or hardware vender issues a security threat alert which you receive because you register your products. When you receive the alert, you look up the impacted supplier part numbers and versions in your CMDB, which should tell you where and how many instances of the product you have in your environment. You then use the dependency relationships (also recorded in the CMDB) to identify what business functions are impacted and the risk to your company’s operations. This information is then used to determine if the recommended fix should be applied immediately or scheduled into the next release window. In either case, you then deploy and test the fix, resolving the vulnerability before a would-be hacker finds an entry point to exploit.
That scenario sounds great, but what happens if the data in your CMDB is incomplete, incorrect, has conflicts or is out of date? Perhaps you run through the assessment steps, and identify some vulnerabilities and fix them… but not all of them. Some security vulnerabilities remain in your environment (but you don’t know about them). Management thinks the issue is resolved and becomes overly confident about being protected from risk. Meanwhile, professional hackers (or maybe just some teenager bored in his basement bedroom in the middle of the night) finds one of the vulnerable components that you missed and decides to exploit it. The story continues from there and as you can probably imagine, it doesn’t have quite the same happy ending.
So what can we learn from this situation? The obvious answer is that CMDB data quality is important. But equally important are: having a realistic understanding of the data quality you have available (to avoid the over-confidence trap); having an effective and timely process for using the information to initiate action (as soon as you learn of threats from suppliers); and, if you find your security response is still not adequate – do something about it.
Most companies who use only basic import functions and discovery tools to populate their CMDB (unknowingly) have about 30% of the data being in-accurate, out of date, missing, duplicated or otherwise lacking in necessary data quality. This happens because the different data sources don’t cleanly align to each other. There are gaps, overlaps, conflicts and timing differences that become problematic when combined in the CMDB.
The solution to this problem is to apply a set of data quality management capabilities to help clean, verify, validate and combine the data as it is going into the CMDB to ensure that when it comes time to use the data for activities like threat assessments, the quality you expect is present. Blazent is the industry leader in data quality management capabilities for IT Asset management and understands this and other critical scenarios that your IT team face when trying to keep your company’s operations running smoothly and securely. To learn more about current offerings or to contact one of our sales staff, visit www.blazent.com