Skip to Content

This post contains content developed in collaboration with Stuart Short.

Please, see bottom of post for additional information and acknowledgements.

In a previous post I presented the key ideas underlying the Assert4SOA project. If you haven’t read that post, you may want to read it now, before proceeding with this one. At the end of that post, I briefly mentioned that an interesting application scenario for Assert4SOA comes from online app store designed after the increasingly popular software marketplace metaphor.

Also an earlier post by Samuel Kaluvuri discussed how digital security certificates could be used to increase the trust of users on digital marketplaces.

In this post, I figured I would not wait for 2013 to try to get a bit more concrete and give you a flavour of what a trustworthy, assert-aware marketplace would look like, and what functionality it would offer to users. In the last few months of the project, we’ve started to sketch a proof of concept and development is ongoing; while it’s a bit too early for a full demo, I can share with you a few mock-ups that should illustrate what we’re trying to achieve.

21-12-2012 14-51-04.png

As you can see, we have dressed the Assert4Soa idea of the assert-aware marketplace with a skin that resembles the SAP Store (well, by now it’s the old skin of the SAP Store). It is just a mock-up to illustrate the idea, please do not confuse this one with the real SAP Store! (Also, do I need to add that all the data shown in these screenshots is made up, and is purely for illustrative purposes?)

Anyways, let’s imagine you are looking for a solution in the Store, say a “time management” solution to manage the schedule of the employees of your company. The picture above shows the result of your search, that is a bunch of candidate solutions that offer such functionality. So far so good. Now the question is: which one would you choose?

Some of you might answer “the cheapest”. If your business is in dire straits or if it can afford disregarding what level of security (and more generally, of quality) the cheapest solution can offer, then go for the cheapest. Those who answered “the most expensive” may have thought “if it costs more, it must be better”. Others may think, I’ll get the solution from  “the vendor with the best reputation”.

NOTE Now, I should say that the SAP Store is not really a great example here, because in reality only a certain number of selected partners can sell applications in the Store; and because of the selection that SAP does and the strict requirements that imposes on the quality of partner solutions, trustworthiness is not questioned. But if we imagine for a second a larger marketplace (say something closer to the model of the Androd market, for example), with thousands of ISVs that come and go and where the ecosystem is much less controlled….well the question “which one would you choose?” is not a trivial one to answer, not only from a security perspective, but more generally from a software quality perspective.

As a matter of fact all of the options above try to find an indirect answer to the question “what security level does this solution offer”? And none of the criteria above is really reliable in aswering that fundamental question.

In Assert4SOA, we’re proposing a radically different approach, which offers a direct answer instead.

In our Certified Store, solutions come with associated Asserts, which represent an explicit statement of what security properties the solutions provide and through which mechanisms. To make this information more useful, Asserts also specify how those security mechanisms have been assessed (testing, static analysis, fuzzing, code inspection, formal methods, etc.). The figure below shown the asserts of the Timekeeping app.

21-12-2012 14-55-53.png

To make the Asserts trustworthy, they signed by the evaluation body (the Assert Issuer) who performed the assessment. This means that even if a solution is from an ISV with whom you do not have a pre-existing trust relationship, you might still want to buy it if the assessment of the solution was performed by a lab of security experts that is in the list of your trusted certification autorities (see picture below).

21-12-2012 14-54-59.png

As a special case, you may want to trust an ISV per se (without relying on a trusted third party) which means you will accept self-signed statements that that ISV has attached to its solutions and treat them purely as machine-readable metadata, without the extra layer of trust on top.

There are two more things our Store has to offer.

The first is an intelligent assistant that supports you in the automatic selection of the solution that best matches your security requirements. These are defined in what we call “security profiles”, stored as part of your user preferences (figure below). You can think of a profile as a container for a set of constraints on the security properties that are applicable to your business. For example, a profile may state that solutions should offer “confidentiality of input data in storage, using encryption at least as strong as AES 256”. You can create different profiles, corresponding for example to different business domains or geographical areas (different data confidentiality regulations may apply in each of them), and activate and deactivate them at will.

21-12-2012 14-47-05.png

When searching for solutions, the system will automatically filter the results for you, discard those that do not offer the required security characteristics. Also, the matching results are sorted based on the degree with which they fit your active profiles, proposing you also solutions that do not match perfectly your requirements, but that may be interesting to you nonetheless (following the example above, you may want to know that a solution guarantees the confidentiality property you’re seeking, but uses an alternative, equally strong, encryption algoritm). That’s cool, isn’t it?

The other interesting feature worth mentioning is comparison; it allows you to visualize, side-by-side the security properties offered by two or more candidates that you selected, which allows you to understand in what they differ and how they compare to your requirements.

The figure below depicts quite a basic realization of this concept, but it should give you the flavour of what I mean.

21-12-2012 14-52-19.png

I guess that’s all for this post; I hope I gave you a sufficiently clear idea of what we’re trying to achieve. As I write, we’re busy developing of a functional proof-of-concept based on the mock-ups shown in this post; in another post I might cover some details on how the whole thing works under the hood, if you are interested. Please, do not hesitate to leave your feedback, questions and requests in the comments below!

Thanks for reading this far!


The storyline described in this post and the content of this video (only available internally) have been developed in collaboration with Stuart Short.

As I write, Midhat Ali is devoting his internship to developing a running prototype based on the ideas presented in this post.

The Assert4SOA project is lead by Michele Bezzi; the team includes Samuel P. Kaluvuri, Francesco Di Cerbo, Stuart Short, Jean-Cristophe Pazzaglia, Antonella Teglia, and myself.

To report this post you need to login first.

Be the first to leave a comment

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

Leave a Reply