Can we link cloud security requirements and implementation patterns through executable Model Driven Architecture (MDA) formalisms?

 

Brave new world?

The adoption of cloud services by a target market is directly correlated to a Service Provider’s (SP) ability to prove the security of the service’s architecture.

This blog will examine cloud computing security design pattern specification using SecureUML and ComponentUML leveraging UML’s Object Constraint Language (OCL).  The objective in this discussion is to begin formalizing a generalized WorkFlow-as-a-Service (WFaaS) cloud security design pattern that can be specified through formal property definitions.  I then examine whether the final implementation deployment can be AUTOMATICALLY analyzed against the original formal property specifications.

I can think of no industrial task more financially daunting, technically challenging, or process intensive as the design of a semiconductor component. During my RnD activities as a semiconductor component design & verification engineer, I was an early proponent, advocate, technical evangelist, and inventor of computer-aided automation methodologies for integrated circuit design. As I have described in previous blogs, there is no room for 2nd or 3rd pass manufacturing re-spins in chip design. Similarly, when there is a breach in an information security model, there will be no 2nd or 3rd chance to recover unauthorized data transfers, ala, WikiLeaks.

Because chip design is a high stakes “pay to play” game, accurate system models that represent the chip’s functional behavior are imperative. The same holds true for cloud computing security models. In fact, security breaches in multi-tenant cloud computing architectures represent an even greater risk to service providers (SPs) than traditional proprietary private corporate IT security escapes. The SP’s liability and exposure is multiplied by the number of separate corporate tenants in their respective cloud service. If we are able to execute a system model under stress conditions that exceed operational demands, then our ability to capture architectural design escapes increases, while the quality of the design is optimized.  Any model that we can simulate under a computer executable program with random, observable, and controllable constraints will reveal architectural defects that we could not anticipate through purely deductive reasoning or analysis.  It is for these reasons UML system models that are linked to executable OCL constraints have such high value in analyzing the effectiveness of a cloud computing security architecture.

Service Oriented Architecture (SOA) defines a collaboration network of services that constitute a “workflow”. When multiple organizations are engaged in supply chain activities, an inter-organizational workflow emerges that requires a company to couple its internal workflows to those of its partners. This does not sound all that different than crystallizing a cloud SaaS/PaaS offering into a WorkFlow-as-a-Service (WFaaS). A branch of research that I have been quite heavily engaged in is Model Driven Security Engineering. At the University of Innsbruck in Austria, there is a robust, innovative, and active research group that has defined a model driven security engineering methodology for SOA.

As a chip designer, I spent endless hours creating deterministic and constrained random test benches that would emulate real world behaviors that would be experienced by the chip. Unfortunately, for an SoC of any serious magnitude, it is virtually impossible to create a simulated environment that covers EVERY operational condition. By establishing functional coverage metrics, we can track the discrete simulation events that cross the stateful system paths we have defined in our requirements. We can only hope that our functional coverage metrics accurately define the operational states of the component. What we really seek to leverage is an area of verification that we call “formal verification”. That is the ability to mathematically prove the functional correctness of a design WITHOUT the need for endless cycles of discrete event, software simulation.

Having the ability to specify any requirement, such as an information security policy in a target implementation and then separately in a target independent abstraction, and subsequently test the two specifications for functional equivalence, we can get very close to eliminating human interpretation, manual translations, or gut-check visual inspections of an implementation. This is where the the SECTET model driven security engineering/policy platform can be used to design a cloud computing WFaaS security model that can be formally proven and tested against an architecture’s Web implementation. By leveraging UML’s visual programming model, a more maintainable, understandable, and closed-form architecture can be delivered to the end user. Through target code generation and automated formal model checking, a new security engineering design paradigm can be established.

SECTET Security Engineering Model

This blog entry is based off of work specified in…

• “Automated Analysis of Security-design Models”, D. Basin, M. Clavel, J. Doser, M. Egea, Information and Software Technology, 2009, Vol 51, pages 815-831.
• “Model-Driven Security Engineering for Trust Management in SECTET”, M. Alam, R. Breu, M. Hafner.
• SOA Security, Engineering Security-critical Inter-organizational Applications, M. Hafner, R. Breu, Springer, 2008.

Security requirements for an identity-driven cloud portal

In an earlier blog entry, I expounded upon the disaggregation of the semiconductor supply chain as defined by four (4) distinct stakeholders or identity profiles: (1) Designer, (2) Foundry, (3) IP Provider, and (4) EDA Supplier. Using the SECTET framework, what would a proposed identity profile security architecture look like for a WorkFlow-as-a-Service (WFaaS) cloud computing offering provisioned to service these four identity profiles?

I will outline a non-exhaustive list of identity profile security requirements as applied to semiconductor design-to-release-manufacturing portal.

1. The portal services a plurality of distinct companies.
2. Each company will have multiple portal users.
3. All portal users would necessarily be caste into one of the four (4) identity profiles.
4. Some companies will have users that would be caste into multiple identity profiles, e.g. a foundry may also be an intellectual property supplier.
   • Should co-identity users have a separate sub-classification?
   • At the very minimum, co-identities must create a unique security profile.
5. Inter-company relationships will include:
   • Competitors
     • Users within the same identity profile that belong to different companies, would “most likely” fall into the category of competitors.
     • Regardless of caste, to prevent unauthorized access to products, inter-organizational workflows must be restricted between competitive users.
   • Partnerships
   • Supplier-Customer
     • Design class users represent a primary customer for the other three castes.

More to come on this entry…