Welcome to the Acumen Security Blog

Archives for May 2016

Making Real World Impact!

When we started Acumen a little over two years back we wanted our work to have real world impact. Compliance based testing and certification have received bad rap over the years as being checkbox security or even worse having no security impact. In this respect our genesis of starting Acumen might well have been called a pipe dream.

Against such odds, over the last two years I want to believe our work has had real world security impact, from entropy to more secure protocols, to better designed security practices. We have worked with many customers and helped make their products’ security posture better. This has been fulfilling and satisfying experience.

Not every product is purely commercial however. Many government customers have a wish or requirement to pursue the use of Open Source systems, but they still need compliance certifications. For a long time, this has essentially meant the need to use Linux-based systems. We are seeing an increase in interest in BSD-based solutions, however, and Acumen engineers have been conducting some pro-bono research into potential gaps which stand in the way of those potential customers from being able to use operating systems such as FreeBSD and HardenedBSD.

One of the major work products associated with this endeavor was the recent run-down on the “W^X” objective requirement in the OSPP. A lot of attention was paid to this post in the open source community, particularly in the BSD world, including coverage in the BSDNow.tv video pod cast, which really drove a lot of traffic to Acumen’s blog.

As a direct result of this attention, and the discussions which ensued, OpenBSD has sped up their timeline for enabling userland enforcement of W^X, and it will be the default behavior in 6.0, with patches for testing committed by Theo de Raadt last week.

Whether open source projects ultimately choose to pursue certifications, or merely use the guidance to improve their projects, everyone on the Internet who directly or indirectly relies on open source software benefits from a safer, more secure Internet.

This is quite exciting and I am proud of our team and the work they are doing. We hope to continue in this vein and continue making positive impact by driving and deriving value out of certifications rather than just having check box compliance.

The New Wireless Extended Package

There was another move toward more modular Protection Profiles (PPs) with the recent publication of the Extended Package (EP) for WLAN Clients. This EP can be used to extend the Operating System (OS) or Mobile Device Fundamentals (MDF) PPs and replaces the standalone PP for WLAN Clients whose sunset date was at beginning of May. The requirements of the new EP are similar but not identical to many of the wireless requirements currently found in the MDF PP. This will make it easier for MDF PP compliant products to go against this new EP, but it should not be assumed that MDF PP compliance will automatically result in compliance with the WLAN EP.

The first area where the WLAN Client EP adds requirements is audit. This will have a more significant impact on MDF PP TOEs since the current version of the MDF PP does not include FAU_GEN (or any FAU SFRs) as mandatory. The EP adds requirements for cryptography related audit records that are not currently required by the OS PP either. TOEs which meet the MDF PP’s objective requirements for audit generation will be much closer to meeting the WLAN EP’s requirements, although it is currently rare for products to claim conformance to any objective PP requirements. The overlap between those optional requirements and the mandatory requirements of the EP may be something the vendors may wish to take into account when planning their future certification strategy.

In the area of cryptographic support the WLAN Client EP adds requirements for key generation, key distribution and Transport Layer Security (TLS) that are more specifically tailored to wireless encryption. The key generation and distribution requirements are similar to those for WLAN that are already in the MDF PP with some differences. As an example the PP and the EP require different cryptographic key derivation algorithms and different standards for cryptographic key wrap. ST authors will want to take a note of this and be careful not to overlook small differences between the PP and the EP. It’s also interesting that while the OS PP requires supports for TLS 1.2, the WLAN EP only requires TLS 1.0 with 1.1 and 1.2 being optional. An application note in the EP states that this was done because of a current lack of support for TLS 1.2 and it appears very likely that this requirement will be revisited in the near future.

Identification and authentication requirements in the new EP are fairly straightforward with a requirement for 802.1X support and X509 certificate support for EAP-TLS exchanges. Both of these requirements already exist in the MDF PP and neither the SFRs or their associated assurance activities are different in the EP. For security management the EP requires a few wireless network specific management functions and also includes a number of optional wireless related functions. A TOE which meets the MDF PP’s management requirements will also have the mandatory requirements of the new WLAN EP. The EP’s optional capabilities are new and enable ST authors to describe the TOE’s functionality in greater detail than the MDF PP would allow. Protection of the TSF requirements are different from those found in either of the two base PPs but the requirement is a straightforward test of the TOE or platform’s ability to verify the correct function of the TSF.

The WLAN EP’s TOE access requirement is also the same as that found in the MDF PP, although it does add new assurance activities. Finally the EP adds a wireless specific trusted channel requirement which specifies the use of wireless encryption to protect communications between the TOE and an access point. The SFR and its assurance activities are again similar to those from the MDF PP but add tests to detect the modification of trusted channel data and for an appropriate response to the physical interruption of a connection.

In addition to the SFRs described above the WLAN EP has application notes for several cryptographic support SFRs that are specific to one of the two PPs it modifies. No additional SFRs are added, however guidance is provided to ensure that the underlying OS or mobile device provides required cryptographic support.