Service-orientation is an emerging paradigm for building complex systems based on loosely coupled components, deployed and consumed over the network. By allowing customers to just consume a piece of functionality without having to deal with the complexity of the underlying IT infrastructure and its management, service orientation brings economy of scale, scalability, cost-effectiveness, and flexibility to accommodate changes in the business volume. Especially to SMEs – strong adopters of SOA, especially in the form of cloud applications – this sort of outsourcing is key to keeping the focus on what’s really core to their business. SOA and the Cloud offer a winning recipe using the two key ingredients: 1) simplifying access to what’s valuable (the functionality), and 2) hiding what is just overhead (the setup and management of the underlying infrastructure).
However, despite the original intent of the service-oriented paradigm, its current instantiations are mostly limited to a single trust domain, e.g., within the borders of the IT infrastructures of individual organizations.
A matter of trust
The main reason for this limitation is a lack of trust. Even when users do trust a given application provider, they might be concerned about the security of any additional third-party services that are not under the control of the application provider, and about the communications between the service-based application and those external services. Unfortunately, this lack of centralized control is a typical characteristic of cloud-based applications.
Ironically, one of the very two key ingredients (‘hiding’) of the successful recipe of service-orientation is also hindering the adoption of service-based software products in contexts where trust on a service cannot be granted without specific assurance being provided, i.e., without un-hiding some of the (otherwise hidden) details of how the service-based application is made inside and how its infrastructure is setup and managed.
Certified security properties
Certification is a well–known approach to establish assurance about security properties of products, processes, systems, and services. A consumer of certified entities can rely on the asserted properties, provided that the process of certification is known to produce sufficient evidence for the validity of the property for the certified entity.
Today’s certification processes typically include a thorough examination by experts following pre–defined and publicly accepted criteria. However, the evidence itself is not typically part of the awarded certificate. Thus, the relying party needs to trust the certificate, the experts, and the certification scheme itself. This trust is established by making sure that the scheme is run by accredited authorities, by the accreditation of the experts themselves, and by the certificate being officially approved.
While this applies to product and system certification (as, for instance, with the Common Criteria), if the scope of the examination is the system itself, we need an even higher level of trust in the case of process certification (as, for instance, with ISO 9001).
When the certification targets the properties of the process used to make a product, the consumer of the certification needs to understand and accept that the properties of the process (which is certified) will have a certain effect on the properties of the resulting product (which he/she is buying). In other words, the consumer is actually accepting to consume an indirect certification.
Shortcomings of current certification approaches
Clearly, although well established and successful for the assessment of individual and static systems and components, this approach of providing certificate–based assurance of security does not scale well to service–based systems. These are characterized by high dynamicity, through mechanisms such as service discovery and binding, are typically highly distributed, and operate in ever–changing environments whose timescale is much faster paced that the typical certification process of other types of products or even of traditional software.
Indeed, current schemes produce certificates heavily rely on human effort, and their results are intended for human consumption, expressed in natural language, at a high level of abstraction. Today’s certificates refer to a particular version of the product or system. In general, changes in the system structure require re–certification (Common Criteria does contain an assurance class on flaw remediation, but it is rarely used and does not provide methodological support for analyzing the security impact of system changes). Finally, the system that is subject of certification is generally considered to be monolithic, and the support for deriving the security properties of composite systems imposes too strict requirements (e.g., in CC it requires a perfect match between assumptions and component guarantees).
The way current certification schemes are conceived and run makes them very expensive and time-consuming. The high cost makes them unsuitable for a large number of applications, and justifies recurring to certification only to address the specific demand of players from particular industries (e.g., the public sector or other highly regulated industries).
While the cost of a SAS 70 II certification exceeds $100,000 USD, a 2006 report of the US Government Accountability Office estimated that an evaluation based on the Common Criteria framework would cost up to $170,000 USD for the Evaluation Assurance Level 2 (the minimum level of assurance!) and would take, on average, four to six months. On the other hand, an evaluation at a higher level of assurance (EAL 4) would cost between $300,000 and $750,000, requiring one to two years.
Obviously, as a consequence of the high cost and of the technical limitations of security certification, its adoption today is not as widespread as it could be, which makes it inaccessible to a huge number of application providers, and therefore to a huge number of consumers.
The Assert4Soa project aims at filling the gap between the need for lighter-weight, automatically processable security certificates and the current state of the practice. In order to do so, the Assert4Soa consortium is committed to producing novel techniques and tools for expressing, assessing and certifying security properties for service-oriented applications, composed of distributed software services that may dynamically be selected, assembled and replaced, and running within complex and continuously evolving software ecosystems.
At the core of the Assert4Soa approach is a language, designed to express machine-readable, digitally signed statements (Asserts), that certify the security properties owned by a service. Similarly to current security certification schemes, the assessment of the security properties of a service is delegated to an independent third party (certification authority), who issues a corresponding Assert, bound to the service. The certification of a security property in an Assert is based on either a formal proof or on service testing that has been carried out before the certificate is issued. These formal proofs and tests must have been carried by the entity who has issued the certificate (e.g., a certification authority).
Differently to existing security certificates (e.g., Common Criteria), Asserts are represented in a form that is suited for automated reasoningand processing. Also, Asserts not only include the specification of the security property that they guarantee for the service, but also information about the certification authority that has issued the certificate and a description of the evidence that underpins it (e.g., the testing process or the formal methods that were applied). Hence, Asserts provide comprehensive descriptions of security properties that can be queried and analyzed at run-time by an Assert-enabled discovery platform without (or with limited) human intervention. As a result, the content of security certifications can be successfully exploited for service discovery and selection; based on the information encoded into Asserts, it is possible to query for services that satisfy certain security properties, filtering out those that do not. Also, by reasoning on the content of Asserts, it is possible to rank the matching candidate services, enabling automatic service selection.
Now in its first year of activity, the Assert4Soa consortium has started to deliver some initial results.
Draft models and languages. We produced an initial version of the Assert models, particularly of Assert-M to represent Asserts about properties with a model-based formal proof, and Assert-E to represent properties supported by test-based evidence. Additionally, an Assert4Soa ontology is being de to provide the semantic basis for the description of security properties to be captured in Asserts, as well as to support automatic comparison of different types of Asserts.
High-level architecture design. An initial architecture of the complete Assert4Soa framework has been drafted, where we identified the main functional components, interfaces, and the key interaction mechanisms. A core element of Assert4Soa framework is the discovery engine, equipped with its Assert-aware service query language.
As part of the requirement elicitation activity, we identified some promising use cases, including a scenario based on an Assert-enabled service marketplace. The marketplace metaphor, which is becoming more and more common across the software industry, is a very good example of a large community of consumers of software (services) who would enormously benefit from certification of security properties, but whose needs are not met by the current generation of certification approaches. But this will be the topic of a dedicated post, so please, stay tuned! In the meantime, you may want to check out the project web-site: www.assert4soa.eu.