Andreas SteffenThe open source strongSwan VPN solution combined with the strongTNC security automation framework and the swidGenerator tool allow to do fully automated software inventory control and software vulnerability detection on an unlimited number of endpoints.
strongSwan implements the complete IETF Network Endpoint Assessment (RFC 5209 NEA) protocol stack consisting of the three posture layers:
- Measurement or Attribute Layer (RFC 5792 PA-TNC equivalent to TCG TNC IF-M)
- Management or Broker Layer (RFC 5793 PB-TNC equivalent to TCG TNC IF-TNCCS)
- Transport Layer (RFC 6876 PT-TLS / RFC 7171 PT-EAP equivalent to TCG TNC IF-T)
On an Endpoint any number of Integrity Measurement Collectors (IMCs) can be dynamically attached to the TNC Client via the TCG TNC IF-IMC interface whereas on a Policy Server any number of Integrity Measurement Verifiers (IMVs) can be dynamically loaded and controlled by the TNC Server through the TCG TNC IF-IMV interface.
The strongSwan log below shows the typical use of the three TNC layers when an OS IMC sends operating system information to a corresponding OS IMV when a strongSwan Android IPsec client is connecting to a strongSwan VPN gateway. Transport is via IKEv2 EAP:
The Software Inventory Message and Attribute (SWIMA) for PA-TNC (RFC 8412) standard is an extension of RFC 5792 and defines in the IETF namespace a new SWIMA Attributes PA-TNC message subtype and the following new PA-TNC attributes
- SWIMA Request
- Software Inventory
- Software Identifier Inventory
- Software Events
- Software Identifier Events
- Subscription Status Request
- Subscription Status Response
- Source Metadata Request
- Source Metadata Response
By sending a SWIMA Request attribute, a SWIMA IMV can request from a SWIMA IMC either a Software [Identifier] Inventory or alternatively Software [Identifier] Events. It is also possible to establish Subscriptions which force a SWIMA IMC to immediately send changes in the Software Inventory or new Software Events to the SWIMA IMV as soon as they occur.
A Software Inventory consists of all software packages currently installed on an endpoint and is usually described using ISO/IEC 19770-2:2015 SWID Tags of the form:
The Software Identification Tag above describes version 2.48.0-1+deb8u2 of the libsoup2.4-1 HTTP library as installed on a Debian 8.0 ARM platform. Its tagId Debian_8.0-armhf-libsoup2.4-1-2.48.0-1~deb8u2 is unique for a given tagCreator which for this tag is the strongSwan Project with regid strongswan.org.
Since a typical Linux system has more than 2000 installed software packages, the Software Inventory would comprise about 20 Mbytes of SWID tags. When a Linux package manager like dpkg (Debian, Ubuntu, etc.) or rpm (RedHat, Fedora, etc.) is used to deploy software packages then system files installed on endpoints with the same hardware architecture (x86_64, i686, armhf, etc) and running the same Linux distribution are identical so that a SWID tag must be stored only once in the central Configuration Management Database (CMDB) by the Policy Server.
Therefore a SWIMA IMV usually requests a more concise Software Identifier Inventory which consists of the unique Software Identifiers of all installed software packages. According to RFC 8412, Software Identifiers are constructed by concatenating the regid of the tagCreator by means of two underscore characters with the tagId resulting in strongswan.org__Debian_8.0-armhf-libsoup2.4-1-2.48.0-1~deb8u2 in the above SWID tag example. With this Software Identifier a policy server can easily reference the corresponding SWID tag stored in the CMDB.
A Software [Identifier] Inventory is usually requested only when an endpoint is assessed for the first time, especially if no previous software history is available. When installation logs are maintained on the endpoint then Software [Identifier] Events can give much more detailed information on the software version history including the exact time when a software package was installed, updated or removed from the endpoint.
Let’s assume the following Security Automation and Configuration Management (SACM) scenario. A vulnerability in the Soup 2.4 HTTP library has been detected and published under CVE-2018-12910. The Debian security tracker then publishes a security advisory pointing to software updates fixing this vulnerability:
The strongTNC policy server hourly checks for security updates on the Debian and Ubuntu security trackers and automatically downloads the libsoup2.4.1 security update in the form of a deb package from the URL
http://security.debian.org/pool/updates/main/libs/libsoup2.4/libsoup2.4-1_2.48.0-1+deb8u2_armhf.deb
The SWID tag displayed earlier in this text can be extracted from the deb package using the swidGenerator tool
swid_generator swid --package-file libsoup2.4-1_2.48.0-1+deb8u2_armhf.deb --full --pretty
and stored in the CMDB. Based on the Debian security information the strongTNC policy server can now automatically generate a list of all endpoints that are vulnerable to CVE-2018-12910. Among them is raspi5, a RaspberryPi IoT device running the Raspbian 8.0 armv7l OS based on Debian 8.0 armhf. After installing all currently available Raspbian security updates the strongSwan pt-tls-client on raspi5 reports the following Software Identifier Events to the SWIMA IMV:
Using the strongSwan sw-collector tool the endpoint maintains an Events Database by analysing the history.log generated by the local apt system command. A monotonically increasing Event ID (EID) is assigned to each update event. The strongTNC policy server knows that it has received from raspi5 all Software Identifier Events up to EID 92 and therefor requests newer events only which in the above case are all bound to the next EID 93. Each Software Identifier Event contains a Timestamp and and Action field where the possible actions are 1 = CREATION, 2 = DELETION or 3 = ALTERATION. We see that raspi5 reports three deleted software packages and three created packages as replacements.
Since the Raspbian 8.0 armv7l binaries are different from the Debian 8.0 armhf ones, no matching SWID tags are found in the CMDB. Therefore the SWIMA IMV generates a so called targeted SWIMA Request requesting the missing Raspbian SWID tags:
The SWIMA IMC replies with a Software Inventory attribute containing the missing SWID tags:
The Configuration Management Database (CMDB) can be browsed and managed using the graphical user interface of the strongTNC policy server. The Software Identifier Events from endpoint raspi5 associated with EID 93 are shown below:
Clicking on the tagID Debian_8.0-armv7l-libsoup2.4-1-2.48.0-1~deb8u1 of the replaced vulnerable software package shows the following information:
The vulnerable package version 2.48.0-1+deb8u1 has been in use on raspi5 only, from Aug 13 2017 until July 9 2018 when it was replaced by the security update.
The strongSwan SWIMA implementation has been in successful use since it was first demonstrated at the IETF Prague Hackathon 99 in July 2017, helping to move forward RFC 8412 on its IETF standards track and in the meantime the Configuration Management Database (CMDB) of our demo policy server tnc.strongswan.org (user: Readonly, password: strongSwan) has grown to 1832 Software Identifier Events acquired during 784 PT-TLS or PT-EAP sessions on 13 endpoints. More than 17’000 SWID tags have been collected containing more than 2 million SHA-256 file hashes which are regularly used for TPM-based remote attestation of IoT devices.
Silviu Vlasceanu
David Challener