Usage Scenario
Usage Scenario¶
The Vilocify service allows you to monitor a variety of components in your organization for security vulnerabilities. Thus, the first step is to determine which hardware and software products are in use in your organization. This information might be collected in different ways:
- Manually collected information (e.g. collected by a project leader in software development project)
- Automatically generated SBOM (Software Bill of Materials)
- Automatically generated asset lists from network scans
- Export from License Clearing Platforms
- Export from IT Asset Management
Depending on the maturity and area of operation, the information might be derived from different sources.
In our example scenario described here, we are starting out as a small company, which just uses one product:
- Microsoft Windows 11
In Vilocify, we refer to all products as components (no matter, if software, hardware, firmware or microcode).
Querying Vilocify for Relevant Vulnerabilities¶
Now that we created our "list" of components, we have to use this information to query the Vilocify service. Vilocify maintains a vast database of components, as reflected in Vilocify service in figures. There is a high chance, that the components we use are already in the database. To check if a component already exists, we can use the search functionality provided by the API (See the API-Specification for more details):
curl -X 'POST' 'https://api.vilocify.com/v1/searches/component_query'
-d '{
"skip": 0,
"search_term": "Windows 11",
"vendor": "Microsoft",
"eol_reached": false
}' | jq -r
As we can see in the response, there are two components returned by the API, sorted by component_id in ascending order:
{
"components": [
{
"active": true,
"component_id": 138313,
"vendor": "Microsoft",
"component_name": "Windows 11",
"version": "for x64-based Systems",
"url": "https://www.microsoft.com/en-us/windows/windows-11",
"security_url": "https://msrc.microsoft.com/update-guide/vulnerability/",
"eol_reached": false,
"eol_date": null,
"cpe_name": null,
"monitored_since": "2021-10-13",
"deletion_details": null
},
{
"active": true,
"component_id": 138528,
"vendor": "Microsoft",
"component_name": "Windows 11",
"version": "for ARM64-based Systems",
"url": "https://www.microsoft.com/en-us/windows/windows-11",
"security_url": "https://msrc.microsoft.com/update-guide/vulnerability/",
"eol_reached": false,
"eol_date": null,
"cpe_name": null,
"monitored_since": "2021-10-14",
"deletion_details": null
}
],
"total": 2
}
In our example, we use Windows 11 on the x64 version on a Desktop system, thus we choose the first option with component_id 138313 (The other component is for ARM64-based systems). Using this component_id we can now query for security notifications which describe vulnerabilities affecting this component. Let's see what the API can do for us:
curl -X 'GET' 'https://api.vilocify.com/v1/components/138313/notifications' | jq -r
The response contains an array of notification objects, including the notification's ids, the publish_date and the date of the last_update, sorted by id in ascending order:
[
{
"id": 79326,
"publish_date": "2021-11-01T00:00:00Z",
"last_update": "2021-11-12T11:33:49Z"
},
{
"id": 79688,
"publish_date": "2021-11-01T00:00:00Z",
"last_update": "2021-11-17T10:35:01Z"
},
{
"id": 80163,
"publish_date": "2021-11-01T00:00:00Z",
"last_update": null
}
]
Using these notification ids, we can finally get the content of the notifications. Lets query the API:
curl -X 'GET' 'https://api.vilocify.com/v1/notifications/80163' | jq -r
The response is contains a lot of machine readable information:
{
"notification_id": 80163,
"title": "Microsoft Windows Multiple Products - Local Privilege Escalation Vulnerability",
"publish_date": "2021-11-01T00:00:00Z",
"last_update": "2021-11-25T08:10:33Z",
"priority": 2,
"action": 5,
"solution_status": "Unavailable",
"impact": "Exposure of Sensitive Information, Manipulation of Data, Denial of Service (DoS)",
"description": "A security researcher has publicly disclosed an exploit for a new Windows zero-day local privilege elevation vulnerability that gives admin privileges in Windows 10, Windows 11, and Windows Server. Using this vulnerability, threat actors with limited access to a compromised device can easily elevate their privileges to help spread laterally within the network.\r\n\r\nVendor Affected Components:\r\nWindows Server 2008 R2 for x64-based Systems Service Pack 1 (Server Core installation)\nWindows Server 2008 R2 for x64-based Systems Service Pack 1\nWindows Server 2008 for x64-based Systems Service Pack 2 (Server Core installation)\nWindows Server 2008 for x64-based Systems Service Pack 2\nWindows Server 2008 for 32-bit Systems Service Pack 2 (Server Core installation)\nWindows Server 2008 for 32-bit Systems Service Pack 2\nWindows Server 2012 R2 (Server Core installation)\nWindows Server 2012 R2\nWindows Server 2012 (Server Core installation)\nWindows Server 2012\nWindows Server 2016 (Server Core installation)\nWindows Server 2016\nWindows Server, version 20H2 (Server Core Installation)\nWindows Server, version 2004 (Server Core installation)\nWindows Server 2019 (Server Core installation)\nWindows Server 2019\nWindows Server 2022\nWindows Server 2022 (Server Core installation)\nWindows 10 Version 1607 for x64-based Systems\nWindows 10 Version 1607 for 32-bit Systems\nWindows 10 for x64-based Systems\nWindows 10 for 32-bit Systems\nWindows 10 Version 20H2 for ARM64-based Systems\nWindows 10 Version 20H2 for 32-bit Systems\nWindows 10 Version 20H2 for x64-based Systems\nWindows 10 Version 2004 for x64-based Systems\nWindows 10 Version 2004 for ARM64-based Systems\nWindows 10 Version 2004 for 32-bit Systems\nWindows 10 Version 21H1 for 32-bit Systems\nWindows 10 Version 21H1 for ARM64-based Systems\nWindows 10 Version 21H1 for x64-based Systems\nWindows 10 Version 1909 for ARM64-based Systems\nWindows 10 Version 1909 for x64-based Systems\nWindows 10 Version 1909 for 32-bit Systems\nWindows 10 Version 1809 for ARM64-based Systems\nWindows 10 Version 1809 for x64-based Systems\nWindows 10 Version 1809 for 32-bit Systems\nWindows 11 for ARM64-based Systems\nWindows 11 for x64-based Systems\nWindows 8.1 for 32-bit systems\nWindows 8.1 for x64-based systems\nWindows RT 8.1\nWindows 7 for 32-bit Systems Service Pack 1\nWindows 7 for x64-based Systems Service Pack 1",
"vendor_affected_components": "Windows Server 2008 R2 for x64-based Systems Service Pack 1 (Server Core installation)\nWindows Server 2008 R2 for x64-based Systems Service Pack 1\nWindows Server 2008 for x64-based Systems Service Pack 2 (Server Core installation)\nWindows Server 2008 for x64-based Systems Service Pack 2\nWindows Server 2008 for 32-bit Systems Service Pack 2 (Server Core installation)\nWindows Server 2008 for 32-bit Systems Service Pack 2\nWindows Server 2012 R2 (Server Core installation)\nWindows Server 2012 R2\nWindows Server 2012 (Server Core installation)\nWindows Server 2012\nWindows Server 2016 (Server Core installation)\nWindows Server 2016\nWindows Server, version 20H2 (Server Core Installation)\nWindows Server, version 2004 (Server Core installation)\nWindows Server 2019 (Server Core installation)\nWindows Server 2019\nWindows Server 2022\nWindows Server 2022 (Server Core installation)\nWindows 10 Version 1607 for x64-based Systems\nWindows 10 Version 1607 for 32-bit Systems\nWindows 10 for x64-based Systems\nWindows 10 for 32-bit Systems\nWindows 10 Version 20H2 for ARM64-based Systems\nWindows 10 Version 20H2 for 32-bit Systems\nWindows 10 Version 20H2 for x64-based Systems\nWindows 10 Version 2004 for x64-based Systems\nWindows 10 Version 2004 for ARM64-based Systems\nWindows 10 Version 2004 for 32-bit Systems\nWindows 10 Version 21H1 for 32-bit Systems\nWindows 10 Version 21H1 for ARM64-based Systems\nWindows 10 Version 21H1 for x64-based Systems\nWindows 10 Version 1909 for ARM64-based Systems\nWindows 10 Version 1909 for x64-based Systems\nWindows 10 Version 1909 for 32-bit Systems\nWindows 10 Version 1809 for ARM64-based Systems\nWindows 10 Version 1809 for x64-based Systems\nWindows 10 Version 1809 for 32-bit Systems\nWindows 11 for ARM64-based Systems\nWindows 11 for x64-based Systems\nWindows 8.1 for 32-bit systems\nWindows 8.1 for x64-based systems\nWindows RT 8.1\nWindows 7 for 32-bit Systems Service Pack 1\nWindows 7 for x64-based Systems Service Pack 1",
"assigned_components": [
4177,
79255,
80753,
81571,
138313,
138528
],
"vendor_advisories": [],
"solution_details": "Currently, there is no official solution available.",
"legal_notice": "Automatically generated by Siemens ProductCERT (svm.ct@siemens.com), Mon, 17 Jan 2022 14:43:38 UTC. © Siemens AG. Restricted.",
"extended_description": null,
"cve_references": [],
"cvss_v2_metrics": null,
"cvss_v3_metrics": {
"base_score": 8.4,
"temporal_score": 8.1,
"overall_score": 8.1,
"vector": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H/E:H/RL:U/RC:R"
},
"related_notifications": [],
"references": [
"https://github.com/klinix5/InstallerFileTakeOver",
"https://twitter.com/wdormann/status/1462607586272976901",
"https://www.bleepingcomputer.com/news/microsoft/new-windows-zero-day-with-public-exploit-lets-you-become-an-admin/"
],
"nessus_plugin_ids": [],
"vulnerabilities": {
"1": {
"cve": null,
"cwe": null,
"description": "A security researcher has publicly disclosed an exploit for a new Windows zero-day local privilege elevation vulnerability that gives admin privileges in Windows 10, Windows 11, and Windows Server. Using this vulnerability, threat actors with limited access to a compromised device can easily elevate their privileges to help spread laterally within the network.",
"cvss_metrics": {
"base_score": 8.4,
"temporal_score": 8.1,
"overall_score": 8.1,
"vector": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H/E:H/RL:U/RC:R"
},
"deleted": false
}
},
"update_history": [
{
"date": "2021-11-25T08:10:33Z",
"description": "Windows 8.1 and Windows 7 may be affected by this vulnerability.",
"important_update": true
}
]
}
Continuous Monitoring¶
Another use case is to continuously monitor, if any new notifications have been published or if the existing ones have been updated. The GET request to list the notification_ids for a component contains the fields publish_date and last_update. After one day, we might want to check, if a new notification_id appeared, or if any of the dates listed in the response are more recent than the ones returned from our last query. If this is the case, we can get the ids of the notifications with a changed publish_date (that is a new notification) and the ones with a changed last_update field (an updated notification). We then just query the notification details for the new and updated notifications, instead of all of them. Thus we are getting relevant information faster and do not process already known information.
Requesting Components¶
Instead of one software product we now want to monitor also specialized hardware, embedded systems, Open Source Software and Common of the Shelf Software (COTS). One of the products we want to monitor is OpenSSL in version 1.1.1k (and let us assume for the sake of this example, that this is not already in Vilocify's database). Using the search in the API, OpenSSL can be found in various versions, but not the one we need. This result is not unusual, as new software products get released daily and Vilocify only monitors the versions actually used by their customers. If a new product should be monitored by Vilocify, a component request has to be made:
curl -X POST "https://api.vilocify.com/v1/component_requests" \
-d '{
"component_request": {
"vendor": "OpenSSL",
"component_name": "OpenSSL",
"version": "1.1.1 k",
"url": "https://www.openssl.org/",
"comment": null,
"prioritized": false
}
}' | jq -r
The API returns one or more objects containing a request_id in an array:
[
{
"request_id": 185201,
"last_processed": null
}
]
A request_id can be used to check the status of our component request. Lets see:
curl -X 'GET' 'https://api.vilocify.com/v1/component_requests/185201' | jq -r
Since Vilocify's analysts only had about five seconds to process the request, they are not yet done:
{
"component_id": null,
"rejection_reasons": null,
"last_processed": null
}
Rechecking after a few days yields different results: Our component request has been processed successfully, as we provided sufficient information to the Vilocify analysts in our request. Here we can see, that a component_id was assigned to our request:
{
"component_id": 104443,
"rejection_reasons": null,
"last_processed": "2022-01-18T08:55:23Z"
}
Using this new component_id, we can now query again for security notifications in the previous example.
Usually, you have several component requests pending, as your software landscape changes. The API offers an endpoint to query the status of all your component requests:
curl -X 'GET' 'https://api.vilocify.com/v1/component_requests' | jq -r
You can use the last_processed field for each of your requests to determine, if a change occurred (your request has been either processed successfully, was rejected or updated):
[
{
"request_id": 185200,
"last_processed": null
},
{
"request_id": 185201,
"last_processed": "2022-01-18T08:55:23Z"
}
]