More info on the vulnerability here and manufacturer links on how they're going to deal with it here.
I wanted to use CMS to collect which in our fleet need firmware and/or BIOS updates to address the vulnerability, and I haven't used custom inventory fields much, so I thought if I share the process it may help some others.
My first step was to create 2 new custom data classes because I wanted to collect 2 registry fields in different subkeys. I thought this could be done with 1 new class, but I couldn't get it to work and support directed me to use 2. To do this, I went to settings, all settings, Settings, Discovery and Inventory, Inventory Solution, Manage Custom Data classes and selected New data class.
I created 2 new data classes, one called IntelSA00086 (attribute SystemRisk) and one called IntelSA00086MEVersion (attribute MEVersion). For both I selected No for required. See screenshots below.
The Intel vulnerability tool writes these fields to the registry, so the next step was writing scripts to tell the client once they ran the Intel tool, to send the appropriate keys to the CMS inventory.
Here's my vbscript task to Add System Risk to Inventory. You should make sure the output is what you'd expect by running this vbscript locally on your machine removing the ' from the the last line (so MsgBox nse.xml is not commented out). You should be presented with a pop up box showing the output, what you're looking for is towards the end "<row c0=....." This is what will get stored in the CMS inventory for that object. If it says "This system is vulnerable" or "This system is not vulnerable" then it's working as expected. Make sure when you put the script into your CMS task you comment out that last line again.
'Pick the appropriate WMI registry hive code and comment the line you don’t use
Const HKEY_LOCAL_MACHINE = &H80000002
'Another example: Const HKEY_LOCAL_MACHINE = &H80000002
Set wshShell = WScript.CreateObject( "WScript.Shell" )
ComputerName = wshShell.ExpandEnvironmentStrings( "%COMPUTERNAME%" )
set nse = WScript.CreateObject ("Altiris.AeXNSEvent")
nse.To = "{1592B913-72F3-4C36-91D2-D4EDA21D2F96}" 'Do not modify this GUID
nse.Priority = 1
dim objDCInstance
set objDCInstance = nse.AddDataClass ("IntelSA00086") 'Your Data Class Here
set objDataClass = nse.AddDataBlock (objDCInstance)
KeyPath = "SOFTWARE\Intel\Setup and Configuration Software\INTEL-SA-00086 Discovery Tool\System Status" 'Your Registry Key Path Here
ValueName = "System Risk" 'Your Registy Entry Here
Set oReg=GetObject("winmgmts:{impersonationLevel=impersonate}!\\.\root\default:StdRegProv")
'Use the HKEY constant defined earlier and use the oReg function appropriate to the type of data in the registry entry
error_returned = oReg.GetStringValue(HKEY_LOCAL_MACHINE,KeyPath,ValueName,Value)
'Another example: error_returned = oReg.GetStringValue(HKEY_LOCAL_MACHINE,KeyPath,ValueName,Value)
if error_returned <> 0 then Value = "Does Not Exist" end if
set objDataRow = objDataClass.AddRow
objDataRow.SetField 0, Value
'If your data class has more than one attribute add a line for each
'objDataRow.SetField 1, Value2
nse.Send
'Uncomment the line below for testing purposes
'MsgBox nse.Xml
Here's my script for "Add MEVersion to Inventory." Similarly to above, testing can be done locally on your machine to make sure your script is collecting ME version from the registry.
'Pick the appropriate WMI registry hive code and comment the line you don’t use
Const HKEY_LOCAL_MACHINE = &H80000002
Set wshShell = WScript.CreateObject( "WScript.Shell" )
ComputerName = wshShell.ExpandEnvironmentStrings( "%COMPUTERNAME%" )
set nse = WScript.CreateObject ("Altiris.AeXNSEvent")
nse.To = "{1592B913-72F3-4C36-91D2-D4EDA21D2F96}" 'Do not modify this GUID
nse.Priority = 1
dim objDCInstance
set objDCInstance = nse.AddDataClass ("IntelSA00086MEVersion") 'Your Data Class Here
set objDataClass = nse.AddDataBlock (objDCInstance)
KeyPath = "SOFTWARE\Intel\Setup and Configuration Software\INTEL-SA-00086 Discovery Tool\ME Firmware Information" 'Your Registry Key Path Here
ValueName = "ME Version" 'Your Registy Entry Here
Set oReg=GetObject("winmgmts:{impersonationLevel=impersonate}!\\.\root\default:StdRegProv")
'Use the HKEY constant defined earlier and use the oReg function appropriate to the type of data in the registry entry
error_returned = oReg.GetStringValue(HKEY_LOCAL_MACHINE,KeyPath,ValueName,Value)
'Another example: error_returned = oReg.GetStringValue(HKEY_LOCAL_MACHINE,KeyPath,ValueName,Value)
if error_returned <> 0 then Value = "Does Not Exist" end if
set objDataRow = objDataClass.AddRow
objDataRow.SetField 0, Value
'If your data class has more than one attribute add a line for each
'objDataRow.SetField 1, Value2
nse.Send
'Uncomment the line below for testing purposes
'MsgBox nse.Xml
Before moving forward, once those scripts are in your CMS instance, I would run them against a test client to make sure the inventory is uploaded as you'd expect. You can check the client inventory by navigating to the client in CMS - Computers - right click on client - resource manager - view inventory - Inventory - custom - 2 keys should be there and on the right you should see the values you'd expect as shown below.
Next, you'll want to download the detection tool (as of 11/27/2017 version is 1.0.0.135). I decided I'm going to roll this out as a Managed Software policy, and I don't need to install it to Program Files, so I'm just going to run it from where CMS drops the files. My next step was to upload it to the Software Catalog by going to Manage - Software Catalog - select import and then the plus/add button and pointing it to the downloaded files
Note: This .exe is weird and requires it to be ran in the same folder as where it's being launched from. For this reason, I only am uploading the contents of the command line tool (not bothering with the GUI folder). You'll need to highlight Intel-SA-00086-console.exe and select "Set Installation File" & then select next.
Here's the command line I'm using with success/failure codes from their documentation
I set up 3 filters to use with the detection tool under Manage - Filters.
Intel SA 00086 Vulnerable
select _resourceguid from Inv_IntelSA00086
Where SystemRisk = 'This system is vulnerable.'
Intel SA 00086 Not Vulnerable
select _resourceguid from Inv_IntelSA00086
Where SystemRisk = 'This system is not vulnerable.'
Needs Intel SA 00086 Tool
This filter is just set up manually via Filters included in this filter - Windows computers and under exclusions I listed the 2 filters I created above and VMWare Clients. This is the filter that the managed software policy to deliver the tool will be scoped to.
Next, I set up the managed software delivery policy under Managed Policies and created a new policy adding the Software task and the 2 scripts to add the 2 registry keys to the inventory database. The scope is set to the "Needs Intel SA 00086 Tool" filter, and for schedule I have it set to a scheduled 24 hour window checking every 70 minutes. Once the task runs, the registry keys get populated, and CMS pulls those keys into the database, and the computers fall out of the scope and the software delivery task goes away for them.
This managed police worked fine for all of my existing computers, but for win7 freshly imaged, it was failing with exit code 11. You'll see exit code 11 if you're not running from the same directory, but I knew I was doing that. Reading Intels documentation, in my case, this appeared to be a root trust certificate issue as the newly imaged computers didn't trust commandline.dll's root cert. To fix this, I right clicked on the commandline.dll in the installer folder, went to digital signatures and navigated up to the root cert and exported it (AddTrust External CA Root). I navigated back to my software catalog, searched for the Intel Detection tool, and modified it to also include this IntelAddTrustExternalCARoot.cer file. I created a new command line job in the Intel detection tool in the catalog in order to import that root cert before the job runs. The 2nd command line would be
certutil -addstore root "C:\Program Files\Altiris\Altiris Agent\Agents\SoftwareManagement\Software Delivery\{yourguidhere}\cache\IntelAddTrustExternalCARoot.cer"
So, my final software delivery task looks like this, where the first software entry is just running the cert import, the 2nd software entry is running the .exe, and then the 2 tasks upload the data to CMS.
Finally, support helpd me create a report that outputs the Computer name/User/SystemRisk/MEVersion/Bios version/Model. Here's the SQL we used for that.
SELECT vc.guid [_itemguid],vc.name [Computer],vc.[user],int1.SystemRisk,int2.MEVersion,swb.name [Bios version] ,invmm.[Model]
From vcomputer vc
join Inv_IntelSA00086 int1
on int1._resourceguid = vc.guid
join Inv_IntelSA00086MEVersion int2
on int2._resourceguid = vc.guid
join inv_SW_BIOS_Element swb
on swb._resourceguid = vc.guid
JOIN
(SELECT ihld._ResourceGuid, ihld.Manufacturer, ihld.Model
FROM Inv_HW_Logical_Device ihld
JOIN Inv_HW_Computer_System iid
ON ihld.[Device ID] = iid.[Device ID]
) invmm
on invmm._resourceguid = vc.guid
The next step for me will be updating the vulnerable computers, which I need to wait on Dell for. Be sure to check the manufaturer response link in the first line of the article to see how your hardware manufacturers are addressing it.