TNS
VOXPOP
Will JavaScript type annotations kill TypeScript?
The creators of Svelte and Turbo 8 both dropped TS recently saying that "it's not worth it".
Yes: If JavaScript gets type annotations then there's no reason for TypeScript to exist.
0%
No: TypeScript remains the best language for structuring large enterprise applications.
0%
TBD: The existing user base and its corpensource owner means that TypeScript isn’t likely to reach EOL without a putting up a fight.
0%
I hope they both die. I mean, if you really need strong types in the browser then you could leverage WASM and use a real programming language.
0%
I don’t know and I don’t care.
0%
Cloud Native Ecosystem / Containers / Security

The Container Security Maturity Model, a Step-by-Step Approach to Cloud Native Security

What we have come to appreciate is that both the types and extent of security practices that organizations need as they grow in their use of cloud technologies can be plotted along a curve. We call this curve the Container Security Maturity Model.
Jun 9th, 2020 10:37am by
Featued image for: The Container Security Maturity Model, a Step-by-Step Approach to Cloud Native Security

Michelle McLean
As VP of product marketing at StackRox, Michelle is responsible for overseeing all of the company’s product marketing strategy and initiatives. She has more than 20 years of market positioning, GTM, and demand gen experience. Prior to StackRox, she was VP of Marketing at ScaleArc, where she oversaw all outbound marketing activities, and she previously held director of product marketing positions at Silver Spring Networks, ConSentry Networks, Peribit Networks, and Trapeze Networks. She previously served as program director at the research firm META Group, providing technology and strategy direction to global 2000 enterprise clients. She started her career as a technology journalist. Michelle earned her BA in English from the University of California at Berkeley.

Traditional infrastructure came with a robust set of security tooling and best practices. The transition from servers and VMs to cloud native environments with containers and Kubernetes did not end the threat or impact of attacks or shift that responsibility to cloud providers. Instead, it brought a new and different set of security challenges and made the legacy tools obsolete. Learning what the security challenges are as well as the effective mitigation strategies they need, across cloud-based, containerized operations, is essential to protecting your business.

What we have come to appreciate is that both the types and extent of security practices that organizations need as they grow in their use of cloud technologies can be plotted along a curve. The curve defines the various stages an organization passes through on its journey from being a rank beginner to a highly sophisticated developer of containerized applications. We call this curve the Container Security Maturity Model. As you move along your container journey, the security requirements rise steeply.  Use this as a guide to understand what stage you are in, evaluate your current security standing, and prepare to move into the next stage.

Stage 1: Learning about containers. Here, individuals learn the basics about containers using their own individual machines. It typically starts as a side project rather than an officially sanctioned one. Since this work is not destined for production rollout, there’s not much to get wrong in security, so you have no critical need for dedicated security tools.

Stage 2: Officially sanction projects. In this stage, someone’s Stage 1 learning exercise transitions into — or an entirely new effort becomes — an official project destined for production. It is a big step from Stage 1, which often involves just one individual. Stage 2 typically has a whole team working on that project. A private image registry is useful here to enforce policies concerning image scanning and access to images. Pods containing multiple containers come into play here, as does Kubernetes, which orchestrates those pods. Kubernetes brings with it its own vulnerabilities that require their own unique toolkit. As for security at this stage, you will want to revise and codify security policies to suit the needs of containerized applications. Automation tools to control configuration can also be a big plus at this stage. Already, Kubernetes-native security tooling will prove useful, although container-centric security tools could suffice for a time.

Stage 3: Deployment of a single application in production. Now you have an Internet-facing application that creates real-world exposure for your organization. Here, Kubernetes really kicks in, with container scheduling, load balancing, health checks, auto-healing, failovers, and much more. Your team will be on a learning curve to keep up with the complexity of these orchestrated interactions. For security, you need to harden the environment with greater restrictions, become aware of compliance standards, expand your configuration management to span both containers and Kubernetes, provide initial or expanded network segmentation, and add runtime security. At this stage, your teams cannot keep up without Kubernetes-native security, which taps the context and controls of Kubernetes to enable security that is built-in, not bolted on.

Stage 4: Expansion. At this stage, the organization is either containerizing multiple applications or scaling up the initial application. Complexity increases here, in both infrastructure and security. Now security mandates for compliance, incident response, and broader collaboration take center stage.  Organizational governance policies with numerous security guardrails are essential at this stage to ensure a standard workflow. Automation is critical here because you are dealing with multiple clusters, and manual processes are simply inadequate. Kubernetes-native security remains fundamental to keeping up with the complexity, since all policies reside in the infrastructure and inherit Kubernetes’ strengths of automation, scale, and portability.

Stage 5: Organization-wide adoption of containers. This stage represents the culmination of the organization’s growth in the use of containers. At this point, containers account for essentially all new development, and often older applications are migrating into containers. Your infrastructure may take on a new form of complexity with service meshes, which can provide orchestration beyond what is available through Kubernetes. Full automation featuring additional technology layers, sometimes including security-as-code, can also characterize organizations at this stage. Your Kubernetes-native security capabilities will grow with you as you reach this phase of widespread use of containers.

No organization ever achieves perfect security. But you must build on your security capabilities just as you grow your infrastructure knowhow. Security should map tightly to infrastructure across your container journey. And as always, good security extends beyond the tooling and demands the organizational structure and collaborative practices that bring DevOps and Security together for a successful container journey.

Feature image via Pixabay.

Group Created with Sketch.
THE NEW STACK UPDATE A newsletter digest of the week’s most important stories & analyses.