How can we reduce the complexity of cloud standards - A call to action

 

The IT security standards landscape is particularly complex compared to other areas of standardisation - the EC’s ambition to “cut through the jungle of standards” has never been more true anywhere else than in this problem space. However, whilst the sheer amount of stndards may have a paralysing effect at first glance, in reality this problem becomes much less complext since there are a number of aspects to be considered when choosing a set of standards to implement as follows:

 

However, in reality the problem is less complex as there are a number of aspects to be considered when choosing a set of standards to implement as follows:

National standards.

Examples of national security standards selection are the NIST series of standards in the US, GCHQ Top 10, BSI (German government institute for security in information technology) and other national bodies. These are the prime source of security standards and best practices industry is tapping for guidance.

International standards.

Although not explicitly mentioned, the differentiation between national and international standards selection seem to follow the lifelines of differentiation between national and international business and trade relationships.

Technical maturity.

Of course, standards need to be technically mature before one even considers implementing it so as to lower the cost of implementation and adjustment over draft publication versions.

Industry support vs. consumer demand.

The dynamics and mechanics of industry support and consumer demand are frequently reciprocal, and confusingly, also corollary. While usually strong industry support is a driver for further uptake in a positively self-enforcing manner, it can also be reciprocal, depending on consumer demand. If consumer demand is satisfied by current supply, it may be *adverse* to also implement a standard. On the other hand, if consumer demand out-paces supply, or if supply is yet low, it may be a very attractive opportunity to implement a standard as a competitive advantage over other supply-side market participants.

Reputation of the SDO and SSO.

Standards Development Organisations (such as OASIS, DMTF, SNIA, OGF, and many others) and Standards Setting Organisations both need to maintain their reputation for quality of delivery: In that sense, there does indeed exist competition between SDOs even though this may be unexpected by those outside the community. For example, the very controversial process of ECMA standardising MS Office's XML document format (in the OOSXML structure) was perceived as very damaging to its reputation.

Complexity & re-use.

Complexity of standards plays an important role in selection and eventually in adoption. Increasing scope of a specification intrinsically adds to its complexity, if not complicatedness, which is very reduces the possibility of its re-use in other domains.

Policy declaration & regulation.

Particularly in dysfunctional markets or segments, or where sovereign topics are at hand (e.g. data protection, and privacy), national and international policy and regulation replaces selection.

 

It is clear that the cloud security landscape is staggeringly complicated and ridden with obstacles and hindrances. To get a grasp of the most pressing needs we compiled a list of the top 10 issues developers have with the current cloud (security) landscape:

Equivalence of policy-level standards

There are many standards out there which try to address the same issue. However, it is unclear whether at all these are equivalent, or at least partially equivalent (and with which overlap?). Do they overlap in their formal requirements? Or do they diverge in terminology, and semantics?

Too many standards.

Clearly, the sheer demand for standards is too much. Standards therefore should be consolidated. The question remains how to do this?

Cost of implementation.

The cost of implementation must not be underestimated, and the ROI on this is a key differentiator of the success of one standard over the other.

Limit the scope!

Naturally, a tightly scoped standard will cause a lower cost of implementation, and vice versa, hence software frequently includes only partial implementations of standards.

Modularity and levels of conformance/compliance.

Frequently, standard specifications are designed and written as large monolithic behemoths. Instead, the "architecture" of standards should change into small cores and optional modules that may or may not be implemented based on the actual need at hand.

Such an approach, however, has a direct impact on traditional assessment and certification of conformance to a standard which are more often than not still binary decisions.

Standardisation process and timing.

This problem is as old as standards are. This leads many market participants to believe that standardisation is at best irrelevant, market stifling or at worst killing the market. Timing is an issue, in that one must find the right point in time, not too early, not too late, when to begin formal standardisation - and then it needs to finish in time to be still relevant. The exact mechanisms are still unclear. Yet, the overwhelming perception is that of standardisation from start to finish, takes too long.

Stability and backwards compatibility.

There are clearly antagonist forces at play in the lifecycle of standards. From the viewpoint of implementers, stable standards have a zero cost of update. Yet, standards need amendments to stay relevant and reflect market conditions. The worst possible scenario for implementers are entirely new standards that have nothing to do with the previous version, maximising cost of update to the cost of a completely new implementation. Therefore, backwards compatibility between intermediate versions of standards are a necessity so as to not invalidate conformance or compliance of existing implementations without reason.

Reference implementations and case studies/white papers.

Often, standards specifications are difficult to read and understand; they frequently use a specific language and taxonomy alien to the "uninitiated". Also, the intellectual leapfrog from formal language on paper to live code producing data, or procedures implementing policy level standards, represents a steep learning curve. Reference implementations and primers/guidelines for technical standards, and white papers and case studies for policy-level standards lower the barrier of implementation significantly.

Certification.

The world of certification for conformance/compliance is endlessly fragmented. In an attempt to make sense of it, participants identified for archetypical modes of certification/adherence to standards on a whole spectrum of variations:

  1. Voluntary adherence / code of conduct (weakest)
  2. Self certification / self assessment
  3. 3rd party external certification
  4. Legislative regulation (strongest)

Particularly (c) rises and falls with the certification auditor's qualification and conduct of the actual audit - after all, external certification presents a significant cost for businesses, and thus should be reputable, fair, independent, comparable and repeatable.

 

A succinct list of actions that should be tackled in the short term. While some of these are already well-known, others are quite novel and almost guarantee a controversial discussion:

Align mandatory breach notification with SDO/SSO for continuous improvements of standards

This action aims at opening up, or improving, the communication channel between Standards Development Organisation and implementing bodies. While it is fairly obvious that no organisation likes to admit to having experienced security breaches, outputs and results from post mortems need to be fed back to SDOs for further improvement of the relevant existing standards. Such a feedback channel would require a secure, save and trusting foundation (likely including NDAs). On the other hand, similar structures already exist for technical aspects of services (covered by Problem Management, Configuration Management, Release Management and other service management procedures), which might be adopted and adapted according to the needs.

Reference implementations & White Papers.

There is a dire need for reference implementations for technical standards which should::

  • Come free of capital expenditure,
  • Be available in source code format (however, which language?)
  • Carry an industry-friendly open source license (e.g. Apache 2, BSD style)

Transposed to process-level standards, white papers and case studies can provide implementers with the necessary jumpstart in their strategy on how to implement process-level standards.

Free standards.

Standards are frequently developed with the support of government expenditure. Aligned with the EC's new Open Data policy for the H2020 programme, standards developed with the financial support of governments should be freely accessible at no cost, just as reference implementations should be (see above)

Involve academia.

Academia has been long underestimated in their value and drive of standards. In order to maintain relevant education of future capacities and leaders in the IT industry, academia needs a constant influx of requirements, ideas and technologies that it can transform into education of future generations. As such, academic involvement in the standardisation process needs to be re-evaluated and adjusted as the prime candidate for development and maintenance of reference implementations as a means and vehicle for higher education on various topics of computer science.