In 2011, computer and network security news stories, which were previously the preserve of specialist journals and blogs, have become commonplace in the mainstream media. There are now many different types of threat, which are sometimes categorised into hacktivist, e-crime and most recently, advanced persistent threats (APT). Whilst some of these attacks have exploited zero day vulnerabilities, many of these attacks have simply taken advantage of the fact that systems have not been configured securely for their deployment environment.
To use an easy–to-understand analogy, consider a wireless router. This device will generally be shipped from the factory in the most flexible, open communication configuration, which will have many or all of the security options disabled. This will be fine if the wireless router is intended to be used as a free public Wi-Fi access point (e.g., cyber cafe), but not for a private business or home office if you want to prevent drive-by wireless hacks). In these cases, wireless encryption such as WPA2 will need to be enabled for the router and clients, and access may even need to be restricted to specific clients via MAC addresses, etc.
For the developer wanting to create a secure product using embedded Linux, the wealth of configurable functionality and security packages can seem overwhelming. In the critical device space, the key question is, "How can one create a Linux configuration for their product which can be secure and meet the security requirements of the product's targeted international markets?" The answer is straightforward and well defined – use standards-based approaches to both configure and prove security robustness.
For IT security, there is one globally-recognised standard, Common Criteria, that a product can be evaluated against, and this evaluation ensures that connected IT products are performed to high and consistent standards. Because Common Criteria is now recognized by 26 countries, product security evaluation using this standard eliminates the burden of duplicating security evaluations in multiple countries by providing international mutual recognition of evaluated products.
To accelerate the Common Criteria evaluation, the product can be developed according to the approved Protection Profile (PP) to ensure that it meets the accepted security requirements for that class of product. A Protection Profile is a document that defines the combination of threats, security objectives, assumptions, security functional requirements (SFRs), security assurance requirements (SARs) and rationales for a specific security target (ST). The PP is used to substantiate vendors' claims of a given family of information system products. The PP for a particular device typically specifies the Evaluation Assurance Level (EAL), a number 1 through 7, indicating the depth and rigour of the security evaluation, usually in the form of supporting documentation and testing, that a product meets the security requirements specified in the PP. In the United Kingdom, CESG supports Common Criteria evaluation and the use of PPs; in the United States, the National Institute of Standards and Technology (NIST) and the National Security Agency (NSA) have agreed to cooperate on the development of validated US government PPs.
Common Criteria testing and evaluation can be quite expensive, and adds significant risk to any programme. To help eliminate much of this risk, Wind River has taken this approach for the development of Wind River Linux Secure, a commercial-off-the-shelf (COTS) product which has been certified by NIAP under the US Common Criteria Evaluation Scheme to Evaluation Assurance Level (EAL) 4+ (EAL4 being the highest level which is mutually recognised internationally under the Common Criteria Recognition Arrangement, and "+" referring to the evaluation being augmented with the Security Assurance Requirement ALC_FLR.3, the highest level of systematic flaw remediation).
Wind River Linux Secure was evaluated against the US Government Protection Profile for General Purpose Operating Systems in a Networked Environment (US GP-OSPP). This is a new protection profile which was published by the US National Security Agency's Information Assurance Directorate in August 2010, and supersedes the earlier Role-Based Access Control Protection Profile (RBAC) which was 'sunsetted' from 1st September 2011.
With this COTS GP-OSPP foundation, we expect that evaluating Linux products under similar PPs, like the German Federal Office for Information Security (Bundesamt für Sicherheit in der Informationstechnik, BSI) General Purpose Operating System Protection Profile (BSI GP-OSPP) can also be undertaken. The BSI OSPP is also published on the Common Criteria portal, and defines the specific requirements for the German security market. Although there are two separate general-purpose operating system protection profiles, with some specific differences in Security Functional Requirements, there is a lot of commonality, and Wind River’s experience in evaluating a full-featured Linux distribution from kernel.org removes considerable risk from other programmes requiring Common Criteria certification using the US GP-OSPP, BSI GP-OSPP, or other evaluation scheme.