Transient assets can introduce unique challenges to tracking asset inventory and securing your network, especially in the education sector. Students and faculty rely on a diverse range of personal devices and expect to be able to use them everywhere, resulting in high ratios of transient devices on those networks. The term “transient assets” refers to assets that regularly connect and disconnect from your network or other assets. As defined by Applied Risk, a “transient cyber asset is a portable device, such as an operational laptop, which is capable of processing or transporting executable code.” While laptops are often thought of first, mobile devices, IoT devices, and many other device types can be transient if they aren’t always connected to your network. While the surge of remote work and resultant bring-your-own-device (BYOD) has brought the challenge to the doorstep of many industries, the educational sector has been juggling the security implications of transient assets for years.

What’s the problem?

Transient devices aren’t inherently problematic, but failing to track them as part of your inventory can cause security gaps. While organizations that commonly have short-term visitors can segregate a guest network from the rest of the environment, some organizations that see a lot of transient devices need to allow authenticated access to their internal network and data.

Educational organizations tend to see some of the highest ratios of transient devices as students and faculty come and go. Students and faculty are often provisioned accounts and accesses much like staff or employees. As a result, it is especially important to effectively inventory and track these transient devices so that access to internal assets or data can be monitored.

The core security concern related to transient assets is that they are often unknown and unmanageable. While unmanaged devices are a challenge in their own right, transient devices are sometimes better described as unmanageable. Normal BYOD or device provisioning policies can require enrollment in management platforms, but that isn’t typically an option for handling transient devices. As an example in the education sector, students (and their parents or guardians) are unlikely to agree to have their personal devices monitored at the host-level, so the institution needs to be able to build their inventory from network scanning.

On the radar

Grabbing the list of unique MAC addresses connecting to your network over time is a common first step to understanding the scope of transient devices, but that method won’t tell you much about the asset or give you a complete inventory over time. Network scanning is essential to fill in the gaps, and an effective scanning tool can provide detailed information about the assets discovered. Not only will you have a list of IP:MAC address pairings, but you’ll know about device types, hardware, operating systems, and first and last seen dates. Once you have a sense of the scope of those attributes and network traits like commonly detected ports, protocols, and services, you can start categorizing assets until you have a clear picture of what assets show up where and when. From this baseline, you can better identify anomalies and abnormalities, supplementing your security tools with accurate asset attributes so that you can track down problems or security violations.

Zero unknown assets

Building a complete inventory of assets connecting to your network is easy with runZero. The unique combination of unauthenticated active network scanning with comprehensive asset fingerprinting will help you build and maintain a context-rich asset inventory. From there, you can leverage sites, tags, and rules to categorize assets based on the unique needs of your organization. runZero readily detects when assets get new IP addresses and can even notify you by email or Slack, reducing asset duplication in environments with high numbers of transient devices being assigned IP addresses dynamically. Paired with detailed asset attributes, you can use your runZero inventory to really understand what’s on your network at any given time.

Vulnerability scanning plays a crucial role in any enterprise security program, providing visibility into assets that are unpatched, misconfigured, or vulnerable to known exploits. Customers tell us that they can take action on their vulnerability scan results most effectively when paired with comprehensive asset and network context.

runZero’s vulnerability management integrations let Enterprise users:

• Add asset and network context to their vulnerability data
• Identify gaps in vulnerability scan coverage
• Expedite response to new vulnerabilities

Adding context to your vulnerability data

Just like the other inventory views, the vulnerability inventory supports the use of queries to filter your results. You can craft a query using the supported tags, Boolean operators, and numeric comparison operators. A query like this one will list the critical vulnerability results found on your Cisco hardware: hw:Cisco AND severity:critical. Try this one to identify vulnerabilities with a CVSSv2 score of 6.5 or more on EOL assets: os_eol:<now AND cvss2_base_score:>6.5.

Some organizations find it helpful to prioritize remediating vulnerabilities on public-facing assets. With runZero you can easily find them by querying your vulnerability results using fields related to IP addresses. Not only can you use filters like cidr: to include or exclude particular address ranges, but you can also use has_public:t to find results on assets with public IP addresses. Just like in the other inventories, these query parameters can be combined to find exactly the results you need.

Closing vulnerability scan gaps

Being able to track down assets impacted by newly disclosed vulnerabilities is great, but how can you be sure you’re scanning everything by addressing gaps in your scan policies? As a starting point, you can evaluate the assets that have been identified by runZero but are not included in your vulnerability results. You can leverage the source column to identify assets that are known by runZero but are not included in your vulnerability scan results. Try out this query in your asset inventory to see which IP addresses you may not be vulnerability scanning (if you changed the minimum severity setting in your integration configuration, this may not be as accurate for you): source:runZero AND NOT source:[VM vendor]. Swap [VM vendor] with the name of your integrated vulnerability management vendor in any query to find the right results:

• Qualys: source:runZero AND NOT source:qualys
• Rapid7: source:runZero AND NOT source:rapid7
• Tenable: source:runZero AND NOT source:tenable

The same logic can be used to find high-value assets or subnets that are not covered by your vulnerability scanning. If you’ve been using sites or tags to organize your assets, you could use the site: or tag: query fields with AND NOT source:[VM vendor] to find matching assets that have not been vulnerability scanned. You can also search for services or protocols that might be a cause for concern, such as protocol:smb AND NOT source:[VM vendor] to find SMB services on assets that haven’t been vulnerability scanned. The query logic also supports filtering by IP address ranges or subnets, meaning you could use cidr:192.168.30.0/24 AND NOT source:[VM vendor] to find unscanned assets in that subnet.

Since many vulnerability management solutions support importing a line-delimited list of IP addresses into a scan policy, you could use the results of these queries as a scan range. Simply export them to a CSV from the runZero Console then copy the address column into a text file. Or, if you’d prefer to use the export API, the following command will pull the results into JSONL format, filter for the address field, and clean up the extra characters. Just switch [VM vendor] in the URL to the right value and you’ll be left with a line-delimited text file of all the addresses that you might not be vulnerability scanning.

curl --location --request GET 'https://console.runzero.com/api/v1.0/export/org/assets.jsonl?search=source%3A%22runzero%22%20AND%20NOT%20source%3A%22[VM vendor]%22&fields=addresses' \
 --header 'Authorization: Bearer <EXPORT API TOKEN>' \
 |  jq -r ".addresses[]?" | sort | uniq > IPsNotVulnScanned.txt

Expediting your response

When the latest vulnerability hits the news, you can use runZero in many cases to quickly check for impacted assets. runZero’s Rapid Response series is a great way for readers to stay on top of breaking security news and track down affected assets. The ability to query across vulnerability and asset details can help you find impacted assets while you’re getting your vulnerability scanner ready for a full analysis. This is just one example of how a comprehensive asset inventory can work in tandem with your vulnerability management tools.

runZero’s rich datasets of devices, manufacturers, and operating systems, coupled with our highly-tuned scanning and processing logic, provides high quality and high confidence asset and service fingerprints. Pulling your vulnerability data into runZero lets you leverage our extensive fingerprinting capabilities to enrich your vulnerability scan results with the asset and network data being gathered by your runZero Explorers, letting you find vulnerabilities impacting specific operating systems, hardware, or services.

With the data already collected by your runZero Explorers, you can quickly identify vulnerable or exploitable assets based on various datapoints, like vendor name and service version. For example, you can use the following query to find BIG-IP assets that might be vulnerable to authentication bypass without having to run a new scan.

_asset.protocol:http AND protocol:http AND (service.vendor:F5 OR html.title:"=BIG-IP%" OR html.copyright:"F5 Networks, Inc" OR http.body:"/tmui/" OR favicon.ico.image.md5:04d9541338e525258daf47cc844d59f3)

When updated vulnerability scan data is available, you can use queries to find results that match a specific CVE or scan plugin ID to better prioritize your remediation efforts. For example, this query can help you find external-facing assets with vulnerable Log4Shell installations: has_public:t AND cve:CVE-2021-44228.

A bug that could cause offline self-hosted platform updates to fail has been resolved.
The timeout for Qualys connection tasks has been increased from 60 seconds to 5 minutes.
Fingerprint updates.

A notice was added to the MFA page to inform users that they can continue to use the old rumble.run domain until they re-enroll their authenticators for the new runzero.com domain.
Font rendering in Safari browsers now matches Firefox and Chrome.
UI improvements were made to the queries table.
A bug that could prevent exporting selected assets and asset search results has been resolved.
A bug that could prevent starter accounts from setting up recurring tasks has been resolved.
A bug affecting organization selection when a default organization is set has been resolved.
A bug that could cause SSH probes to occasionally deadlock has been resolved.