In a previous post I presented the key ideas underlying the Assert4SOA project, and here a description of how an assert-aware software marketplace (AESM) would look like and what functionality it would offer to users. The demo promised in the previous post has been realized in the meantime, and I had the pleasure to presented it at DKOM in Paris earlier this year (March 2013).
Afterwards, we conducted a set of interviews with a panel of potential users, to gether their feedback about that demo and validate our work. In this post I will quickly summarize what we found. A questionnaire was used to guide the respondents as to what aspects we intended to cover, but we encouraged free feedback, either in oral or written form. We wanted to evaluate the business relevance, the usability, and the technical maturity of our prototype, as well as the potential for adoption of the underlying concept. We got a remarkable amount of useful comments, which we analyzed to draw some conclusions.
While these conclusions cannot be generalized, given the nature of our study, they provide qualified feedback on our prototyping activity and indicate promising directions for improvement and further investigation.
According to our respondents, the AESM represent an important means to empower end-users (buyers) and to expedite the procurement of software: using the automated matching and comparison features, buyers can take decisions more quickly, while ensuring the compliance with relevant regulations and corporate policies.
Obviously, the increase of transparency and trustworthiness achieved by making security certificates available to end-users is valuable, however the assumptions on the security knowledge of end-users should be considered with care. In particular, since the implicit goal of the AESM is to bring security assurance to a general audience of non-security-experts, it is not reasonable to expect that users understand technical terms, such as those used to describe advanced security properties (related, e.g., to encryption algorithms and key lengths).
Two important consequences follow from this observation. Firstly, although in the simplification of our proof-of-concept the distinction is not clear-cut, in a real-world implementation of our concept, the actor who is responsible for buying products and the actor defining policies should be distinct. The former need not be knowledgeable of security: they should be able to select products that respect the applicable requirements (imposed, e.g., by his/her organization) just by selecting the corresponding policies from a menu, and by looking at the intuitive "compliance score" presented in the comparison view (as shown in the picture below).
The latter instead is responsible for translating the constraints and the requirements of their organization into policies that end-users can easily apply. In this way, policies represent a simple, yet effective usability device and their proper definition is key for the success of the AESM model. This approach however, increases the responsibility of the role creating policies, and as remarked by the respondents, liability attribution can be problematic and would need to be examined in more depth.
The idea of monetizing investments in security with the increase of trustworthiness brought by security certificates was deemed appealing by our respondents. Evaluating the volume of such return on investment is difficult though, as it depends on a number of factors including the structure and dynamics of the marketplace ecosystem, on the type of products and the target industries and business areas. Consistently with our belief, the interviews also indicate that self-signed certificates could be the first step to obtain a initial set of low-cost certificates that would at least increase transparency while providing the basis for employing automated matchmaking based on security policies and certified properties.
Finally, we always assumed that exposing detailed security information about the software sold on the marketplace would represent an advantage for the software vendor and for the marketplace owner, besides the buyer. The discussions we had in our focus groups indicated that this point deserves more investigation: several respondents suggested that "customers take quality (such as security) for granted", which is the reason why marketing people would probably be reluctant to (proactively) offer more information about security than asked by the buyer. We are convinced that while this might well be the case in many of today's marketplaces, the situation might gradually change as a result of growing users' awareness and increasing regulatory pressure.
- SAP Managed Tags:
