Assurance through Product Security Certification

Security assurance of software products has always been an important aspect [28], especially in critical domains such as defence, military, avi-ation, healthcare and finance. Since the software consumers in these do-mains are not security experts, nor can they relyonlyon the statements and assurances of the software vendor - there was a need for an independent, trusted third party to evaluate the software and certify that it meets certain security features.

Governmental bodies were [124] , and still are (seen collectively), one of the biggest consumers of software products and since data that is pro-cessed within those departments can be extremely sensitive (such as in the case of military), governments drafted guidelines for software prod-ucts that are used within their departments. However, in order to verify that software vendors were meeting those guidelines the products had to be evaluated. Thus, these guidelines evolved into “criteria” against which products were evaluated. Software procurement policies in governmental organizations required the products to have passed the evaluation based on these criteria [173].

However, with an ever increasing number of software vendors and prod-ucts, governments needed to find a scalable approach. Hence they created 19

centralized “certification” bodies that were dedicated to evaluate products and consequently certify whether they meet the criteria. The certification bodies were responsible for designing and managing the overall certifica-tion scheme. The certificacertifica-tion bodies authorized several laboratories (ac-credited evaluation labs) to perform the actual evaluation of products. Soft-ware vendors who wanted to provide their products to governmental orga-nizations had to pay these evaluation labs to get their products certified [8].

This model was successful when software products were custom built for specific use.

With the advent of generic software products especially in categories such as Operating systems, Databases, productivity software, this approach was no longer a viable solution for product vendors as: a)It was not pos-sible to build products that meet the criteria of every country;b)The costs of getting a product certified in each country was impractical for product vendors.

In order to resolve this issue, certification bodies across various coun-tries spent significant efforts to harmonize the certification criteria. One of the first significant results in this direction was the Information Tech-nology Security Evaluation Criteria (ITSEC) [52] which harmonized [144]

the security evaluation criteria from United Kingdom, Germany, France and Netherlands.

The United States and Canada still had their own criteria namely the Trusted Computing Security Evaluation Criteria(TCSEC also known as “Or-ange Book”) [171] andCanadian Trusted Computer Product Evaluation Cri-teria(CTCPEC) [107] respectively which were considerably different from ITSEC [30] in terms of specification of security functionalities and the as-surance levels provided by these schemes.

Moreover, the application of these schemes was still limited to gov-ernmental organizations with limited success [111], however, as software adoption was increasing in non-governmental sector and consumers re-quired to gain security assurance of the software products, the existing certification schemes could not be applied as they proved to be too restric-tive. Hence, there was a need for a generic software certification scheme.

In order to provide a unified criteria for security evaluation, the ISO brought the various certification bodies together to combine and harmonize the evaluation criteria which resulted in the “Common Criteria for Infor-mation Technology Security Evaluation” (referred as CC henceforth) [45].

CC is an international standard (ISO/IEC 15408) and is recognized in 26 countries [50]. It is the most popular, used and recognized IT security certification in the world.

Though CC is widely applicable and recognized, it is also expensive

2.2. ASSURANCE OF SECURE SOFTWARE

and time consuming, hence there were several specialized domain-specific, lightweight certification schemes that have been developed over the years.

In addition, there have been country specific variations of the CC scheme.

But CC scheme can be seen as the most broadest of all product based security certification schemes. The various certification schemes and ap-proaches are discussed in detail in Section 2.3.

Vetting Processes in Software Marketplaces

Recently, we have seen software marketplaces emerging, primarily driven by the explosive growth in mobile devices, as a facilitator between software consumers and providers. Given that most marketplaces are operated by organizations that also provide the operating system on which the software is executed, marketplace operators have a stake in the security of the soft-ware admitted to their marketplaces.

In this regard, marketplace operators can adopt different approaches to deal with security while delivering applications to end users: in particular, Barrera and Van Oorschot [19] propose three categories, “Walled garden”,

“Guardian” and “User control”; they range from a rigorous assessment of any applications on the market, to a completely open model, where security checks are upon user’s responsibility. They also propose a classification of vetting tests, which can also be seen as “Lightweight certification”, for applications to be advertised on a (mobile software) marketplace. The seven categories are: “smoke tests”, “hidden-API checks”, “functionality checks”, “intellectual property, liability and terms-of-service checks”, “UI checks”, “bandwidth checks”, and “security checks”.

We present in Table 2.1 a number of relevant marketplaces, together with their publicly disclosed security assessment criteria.

Market name Code

Salesforce AppExchange No Yes Yes Yes Yes

Google AppsMarket No No No No Maybe

Windows Azure Marketplace No* No* No* No* Maybe

Apple App Store No* No* No* No* Yes

Android Market (Play) No No No No Yes

Windows Store No Yes No Yes Yes

Nokia Store No No No No Yes

BlackBerry App World No* No* No* No* Yes

Table 2.1: Security Features Of Existing Software Markets. Information marked with ‘*’ are not completely publicly disclosed by providers

Salesforce releases a customer relationship management (CRM) system on the cloud that has a number of companion tools. It permits third-parties to publish and advertise their applications (or extensions to existing 21

Salesforce applications) that can operate on customers’ data and informa-tion, on a specific marketplace with defined security review policies [148].

Google Apps Market is a store where third-parties can advertise comple-mentary services for Google Apps services. Google explicitly informs its customers that no security checks are conducted on advertised applications [75]. Windows Azure Market is the official marketplace for Windows Azure (Platform-as-a-Service). Third parties can advertise their services, that ap-parently are not verified by Microsoft [113]. Existing marketplaces adopt the previously-described “User Control” approach.

Apple’s App Store, instead, can be seen as an example of the “Walled Garden” approach, meaning that anything that runs on the mobile de-vices(iPhone & iPads) must be explicitly approved by Apple. The app review process is not publicly disclosed; in a response to a FCC request in 2009, Apple disclosed some information[12], that are contained in Ta-ble 2.1. Microsoft offers Windows Store [114] to users of its Windows Phone OS. Application publishing and review process is documented in MSDN [112], the reference guide for any development effort with Mi-crosoft technologies. Also Nokia has a specific certification process for publishing applications on its market [125], the Nokia Store [126]; nev-ertheless, newer Nokia’s Windows mobile phones should follow Microsoft guidelines. RIM’s App World is the reference software market for Black-Berry devices. Almost no public information on security assessment could be found, except those contained in [145].

In summary, where applicable, none of the above marketplaces dis-closes:

• the details of its security assessments, or

• the results of the vetting process for each applications.

This means that users have to cope with a “one-size-fits-all” definition of security, like in the majority of cases, having no option but to trust blindly marketplaces’ procedures; or they have to face the absence of security as-sessments, having no option but to trust third-parties. Moreover, market-place operators, who assume the role of Certification Authorities, control the execution environment of the services or mobile applications, which may not be the case for generic security certification schemes. However, the vetting processes adopted by the various marketplace operators can be seen as a lightweight, scalable, custom certification schemes.