Today, I want to take a different tack, and instead of attacking the technical aspects try to explain the higher-level challenges for management. To do this we are going to approach this from two different angles.
- Actionable Data
In February 2019, I ran a poll asking what we should call “something” with a Windows operating system installed on it. That poll received 730 votes, with mixed results.
If you are a medium to large business you likely have more than one employee responsible for securing your enterprise. This means there will be a disparity in terminology and understanding as illustrated above. This disparity grows when trying to link a vulnerability definition to a remediation. For example: CVE-2017-0144. This is how a security expert would refer to and communicate about the WannaCry vulnerability. Unfortunately, the CVE identifier is not tracked in WSUS or ConfigMgr. This makes it challenging when different teams are now trying to report compliance, for a vulnerability that has two different metrics.
Fortunately there is a way to correlate a CVE to the associated KB articles when it comes to Microsoft by browsing:
While this does provide a good starting point it’s difficult to search it properly. If you load the CVE in, you’ll get a number of recent reports because the current cumulative rollup address’s this CVE.
As a result, it makes understanding what you are seeing challenging. This is just one example of Terminology challenges there are more.
Additional Terminology Challenges Include:
- KB Article ID
- Bulletin ID
All of these terms may be referenced depending on your staff’s background in the industry and time involved in the industry. This makes peer-to-peer communication difficult.
As a leader it’s important to ensure your team understands and agrees upon common terms to ensure they are providing accurate information and not just the current “buzz word”.
Developing actionable data from uncertain terminology, in a shifting environment is incredibly complicated and messy. Especially if that data is expected to be provided in any type of “pretty” format.
I promised earlier I wouldn’t go to deep into the technology side of things, yet this merits some explanation. Configuration Manager is an absolute treasure trove of knowledge. The database contains a truly astonishing amount of information. However, as a result the sheer volume of information means the information has to be broken up and then assembled as needed.
As an example, if you asked for a report on every machine considered not compliant with CVE-2017-0144 from the ConfigMgr team they would need to assemble information from several different SQL views. Here is an example of a data connection model.
Note we are pulling data from three different sources here and then filtering that data based on CVE. Unfortunately, none of these views (or any other view) contains the CVE information. Additionally, some of these views have multiple versions.
Since none of our views have the CVE data it means we have to access the portal to find all patches that CAN resolve the issue and then build the query on that.
Then we have to find a way to reasonably present this data in a timely manner which means putting into SSRS. This means your staff member who is responsible for CM, now needs to either have the following skills themselves, or access to people with these skills.
- SSRS – (Or PowerBI)
- SQL Query Language (TSQL)
- ConfigMgr Knowledge.
However, just knowing the data sources doesn’t do us any good if we don’t understand how and more importantly WHEN the data is updated.
Patching is complicated and reporting on it is no less so. There is confusing and often misleading terminology between different IT disciplines. Combined with shifting parts that mean different things. This sets us up for failure when we ask “general” questions. Instead focus on asking more specific questions, asking for the right compliance information from the right team. Vulnerability compliance from the security team and their tools, article ID compliance from the Windows Management team.