The Microservices Architecture Pattern: Expanding Security Assurance Ideas in Containers and Microservices

After 137 rolling discussions on Circle and growing a library of input material to 42 unique documents, 2 co-chairs and 343 Application Containers and Microservices (ACM) working group members spanning 5 continents created a third installment further expanding the ideas of CSA security assurance in the microservices architecture and computing container context.

In the first paper, the focus was establishing key viewpoints and fleshing out concerns of architects, developers, and operators dealing with container infrastructure. The effort committed by dedicated participants yielded a product that fostered openings to explore additional opportunities and provide guidance targeting securing application, container, and microservices installations.

In the latest installment, the working group dug down to the software layer and took advantage of openings and opportunities created by DevOps, DevSecOps, and Shift-Left culture. They leapt into security overlays, which up until this time reflected program level assemblages of security control programming applied at a macro-organization scale in the form of work plans and control checklists.

Applying Security Overlays

The working group devised a method to apply the security overlay concept to specific software patterns. The premise at work was that if a developer assembled an application's architecture on a whiteboard using software patterns, what would happen when each software pattern possessed its own unique security overlay?

What happened was that a door to the adjacent pattern opened where not only could a microservices application architecture declare its pattern assemblies before software development began, but carefully curated security controls overlays on individual patterns could create logical modeling building blocks. These blocks were capable of revealing the security architecture for a microservices application at the earliest point in the software development life cycle. It was the last mile that DevSecOps could not cover - it was a means to appreciate control inheritance and defense in depth very early in the software design process far ahead of policy as code.

Rethinking Secure Software Design

As an iterative process, this novel approach is not the final say on the last mile in DevSecOps - all the groundwork (control plans, policy enforcement points, education, awareness, training, and policy as code) that came before still matters. The paper and its methods look backwards for inspiration, as well as forwards to the next generation thinking about securing software. We ask readers to appreciate this paper for its attempt to bridge a gap that many security organizations are hard pressed to span - the last (or in this case, first) mile of secure software development. The paper's theories and methods do not make it right, or wrong - just different and lateral in its thinking about secure software design in the microservices architectural style. CSA hopes this work provokes thought and conversation - and perhaps reveals the next adjacent possibility to explore in secure software design and assurance.

Download the Microservices Architecture Pattern.