Skip to Content

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.

Enter Assert4Soa

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.

First steps

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:

To report this post you need to login first.


You must be Logged on to comment or reply to a post.

    1. Antonino SABETTA Post author
      Thanks for your comment, Gabriel. Indeed, there’s quite a lot going on in the project. Initial implementations of the different components that make up the Assert4Soa framework are under development, and in parallel we’re working on the infrastructure that is necessary to produce an integrated prototype of the overall approach. We plan to have something to showcase by the end of 2012, although it’s difficult to commit to a precise schedule yet (and we depend to a large extent on partners’ contributions — as usual in collaborative research projects). Most likely, we will present Assert4Soa applied to a service marketplace scenario, such as the one in the Business Web. Some more details of such an Assert-enabled service marketplace will be presented in another post that I will publish soon.

      Stay tuned!

    2. Antonino SABETTA Post author
      Thanks Gabriel for your comment.

      (I tried to reply earlier to your comment, but for some reason it didn’t get through).

      In the lost comment I tried to mention that we plan to have a demo of an Assert-enabled service marketplace. A precise schedule is difficult to fix (there’s still a lot to do, and there are many interactions and interdependencies with our project partners), but we expect to have something to show by the end of 2012.

      Stay tuned!


Leave a Reply