Misconfiguration remains a haunting and treacherous security challenge, despite the industry’s heroic efforts to overcome it. Record-level investment, rapid controls innovation, advances in analytics, intensive sharing of guidance/content, increasing automation — none of these measures alone or in sum have proven to be an adequate answer.
The problems continue to compound as complexity increases. Applications grow in scale and become more dynamic, more distributed, and more decoupled. Attackers have become faster, more sophisticated, and more elusive. The regulatory environment regarding monitoring and control of people, processes, and technologies becomes ever-more restrictive. Even the security portfolios that we employ are increasingly complex, regularly comprising 60+ security technologies, each with different policy languages, operating in a different topological context, and often managed by different understandings of the identity, significance, and behavior of the assets we are trying to protect.
This evolving landscape has produced a number of relevant innovations, such as the intrinsic security potential of cloud-native applications, Zero Trust security architecture/policy, and DevSecOps. While none of these has proven to be a silver bullet in isolation, it is increasingly clear that they can work together to improve the efficiency and effectiveness of the entire security portfolio, augmenting the protection they afford in toto.
This blog post begins an exploration of the ways that these individual innovations can interact and influence each other at their confluence on the hosting platform.
Cloud-native applications
The development of cloud-native applications (CNAs) and their underlying architectures has resulted in the realization of more scalable, more granularly evolvable, and more operationally resilient applications, portfolios, and ecosystems. In contrast to conventional applications, CNAs are composed of smaller, more decoupled, and often independently developed/built/tested microservices and functions.
In cloud-native design, there are no massive monoliths of procedural code. Each of the constituent components of a service exposes an API that explicitly describes the intended interactions between components. There are far fewer implicit couplings and dependencies to resolve when making changes. These components are comparatively small, regularly exhibiting sizes between 250 and 500 source lines of code (SLOC) (such as with linguistic microservices). As such, they are easier to understand, to maintain, to evolve, and to describe behaviorally.
The resulting mutual decoupling of microservices allows natural isolation at the logical boundary of each service. Container technologies convey namespace and process isolation. Micro-virtualization enables more comprehensive isolation between container memory, network, and storage address spaces, while also interposing isolation between the application components and the underlying platform. Clearly, perfectly isolated components wouldn’t be very useful, so CNAs generally leverage some mechanism for enabling communication between components, moderated by an API policy that can restrict those interactions.
The operational benefits of the cloud-native approach have led to extraordinary growth in its operational footprint, comprising over 50% of all workloads hosted in multiple public-cloud platforms today.
To leverage the cloud-native approach’s obvious potential for security, we need to answer the question: where does the policy for all those granular components and their respective policy enforcement points come from?
DevSecOps
Following on the DevOps intention to reduce the time between committing a change to a system and the change being placed into normal production, DevSecOps aims to enhance and leverage the security-relevant context cultivated during the development process, in order to provide better, more efficient, and more sustainable security in operation.
It is necessary to establish some level of design intention for the functionality of each application, service, and component before coding. As development proceeds, tests can be formulated to independently verify that the resultant code produces the intended behavior under intended usage scenarios. As development moves toward completion, automated testing and scanning can also contribute to improving compliance, as well as quality and performance.
With all of the promise inherent in DevSecOps’ cultivation of contextual understanding of the intended and expected behavior of applications, prior to release into production, the lingering question is: how do we capture, maintain, and communicate this context in ways that the security portfolio can leverage, without creating more complexity, more work, or more brittleness? With CNAs, this ambition is demonstrably possible and need not require additional development effort or complexity beyond that already regularly used to drive comprehensive automated testing and integration technologies.
The contextual information can include:
- The intended interactions between components from API description
- The expected interactions between components from test results
- The expected interactions between the component and the underlying platform
- The observed security portfolio indications from instrumentation of test environments/platforms
The DevSecOps approach has been so successful in reducing the complexity (and cost) of effective security in the defense department that it has been codified into the concept and product category “DevSecOps as a Service,” which is now offered on multiple platforms. Moreover, the processes are mature enough that we are seeing growing standardization of how the security context is moved between development and operations and standardization of how the security portfolio components cooperatively communicate.
This addresses the question of reigning in security complexity and misconfiguration at the component level. But we are also concerned about the complexity of controlling and monitoring the behavior of the systems constructed from these components. Component development is generally not the right perspective from which to consider system governance, intra/intersystem interactions, and system compliance. Enter Zero Trust and other security/compliance reference architectures focused on capturing policy closer to business intention, and on bringing business context into technical security management.
Zero Trust and reference architectures
Modern exploits and the recognition of the complexity limits to visibility and control have given rise to the concept of Zero Trust and the fundamental assumption that compromise already exists in the components, infrastructure, processes, and people that constitute our information systems. For example, at a systems level, organizations do not build every component that they use, such as their underlying devices, servers, or network equipment. They do not develop their own operating systems, frameworks, or compilers. They don’t own or operate their own telecommunications fabrics or the cloud they connect. There is a supply chain for most resources, into which the organization has little lifecycle visibility and upon which the organization’s security posture and information integrity rely.
Zero Trust acknowledges the need for ongoing, continuous independent verification of evidence-based trust policy for all transactions. Zero Trust Architectures (ZTAs) are intended to make it practical and sustainable to do so.
The formalization of the NIST definition of Zero Trust Architecture in 2020 and the realization of such architectures as compliant, automated reference models on public-cloud platforms has accelerated the engagement of security teams in the effort to determine both where Zero Trust applies and how to implement it sustainably. Although NIST’s National Cybersecurity Center of Excellence is in the first iterations of implementing standardized Zero Trust efforts, international standards bodies, auditor certification organizations, and emerging regulatory agencies are embracing Zero Trust in their training, content, and prospective certification guidance.
Putting it all together
The development of CNAs, DevSecOps, and Zero Trust is leading to new lifecycle instrumentation, integrations, and reference architectures. But what concepts do they have in common and how can we put these disparate pieces together to form more impervious, resilient, and manageably secure systems?
The hosting platform resides at the intersection of all of these security-relevant innovation dimensions. The platform is where the clusters, resources, and infrastructure are orchestrated to support the cloud-native framework. The platform is where the artifacts from the DevSecOps lifecycle transition from development and testing to production. The platform is where the isolation, access, and logical colocation of security instrumentation act to support the Zero Trust policy model for customer consumption.
At this nexus lies the opportunity for both operational integration and embrasure key standardization efforts, including Open API, Open DXL, Open SCAP, C4, and the MITRE SAF. Some of the foundational work is currently underway at NIST, MITRE, and in the OASIS Open Cybersecurity Alliance.
Follow-on posts in this series will articulate the implications of this approach in greater detail and explore the opportunity to lead the promising transformation with the VMware platform, portfolio, and customer base.
