Security Analytics: Tracking Software Updates

To put network operations in context, analysts need to track the software running on the organization’s network. This tracking involves not only keeping tabs on which applications are running, but whether those applications are being regularly updated in versions and patches. Many security checklists recommend keeping software current on applicable recent versions and patches. Such recommendations, including RFC 2196, under “ongoing activities,” have been in place for decades. DHS/CISA recommendations on defending against current ransomware threats emphasize keeping your computer patches up to date. Some organizations push updates onto internal clients and servers, but others use vendor-supported update services. This blog post presents an analytic for tracking software updates from official vendor locations.

There are a number of ways that tracking updates helps to inform network security efforts. Using vendor-supported update services may require clients and servers to poll designated download sites for the most current updates. By knowing which hosts are receiving updates, analysts can track compliance with the organization’s update policies. Tracking which updates the clients and servers are receiving also helps confirm the software configuration on those devices, which in turn may feed into the network vulnerability management process. Finally, tracking the dates at which updates occur helps to identify how current the configured software is on the organization’s clients and servers, which may give a sense for which vulnerabilities may be of concern in protecting the network.

After we know why to track updates, analysts can determine what information is desired from the tracking. This blog post assumes analysts want to track expected updates to software, as part of managing and security the network. Knowing the update server, whether it was polled or downloaded to which client or server, and at what time the contact was made to the update server all provide a useful basis for this network management effort. For other purposes, alternate information may be required (e.g., if analysts need to track the bandwidth consumed by the update process, then knowing duration and byte volume of the contacts with the update server would be important). The analytic discussed below is specifically to identify which internal hosts are receiving updates from which source and over what time period.

Overview of the Analytic for Tracking Software Updates

The analytic covered in this blog posting assumes that the update locations are known by the analysts. Common URLs for update locations include:

Analysts may build a more site-specific list through discussion with the network administrators as to which update locations are allowed through firewalls and other defenses.

The approach taken in this analytic is to use the list of update locations and identify transfers of data into the internal network associated with those locations. The list of URLs may require conversion by isolating the host portion of it and resolving the IP addresses involved. These addresses can then be encapsulated as a text file, an IP set file, or as an SQL table, depending on the tooling involved. The output of this analytic is a list of internal addresses and a summary of the contacts by the update sites.

Several different tools can be used to track software updates. Packet capture and analysis could be used, but often the volume of data and the focus on packet detail make it time consuming to aggregate and extract the information to produce the summary. Intrusion detection system (IDS) rules, either for host or network-based IDS, could be established to issue an alert each time an update is made, but such alerts are often hard to federate across a medium or large-size network infrastructure and require filtering and post-processing to provide the summary information.

Logs, either from clients, servers, or security devices, such as firewalls, could contain records of update contacts. Again, however, a time-consuming process would be needed to filter, federate, and aggregate the logs before processing them to identify the summary information. This blog describes use of network flow records (which summarize network connections) and applying them in a retrospective analysis (via the SiLK tool suite), streaming analysis (via Analysis Pipeline), and through an SQL database.

Implementing the Analytic via SiLK

Figure 1 presents a series of SiLK commands (SEI’s suite of tools that retrospectively analyze traffic expressed as network flow records) to implement an analytic that tracks software updates. The rwfilter call isolates traffic inbound on known web ports (80, 8080, or 443) to the monitored network from one of the identified update IP addresses, considering only flows representing more than a protocol handshake (i.e., those with three packets or more: two for the protocol handshake and at least one to transfer data). The rwuniq call produces a summary for each destination (internal) address showing the timing of the traffic. The call to head abbreviates the output for this blog and would not be included for production use.

</section