Adoption of the cloud and cloud-native application architectures has become increasingly popular among developers because it enables them to keep — even enhance — their competitive edge through innovation and ability to meet ever-changing business demands. These tools and methods provide substantial improvements for the DevOps team but for the security practitioner, they introduce concern and headaches regarding the overall security program.
Often times, for DevOps teams, security measures and procedures become a tradeoff for convenience and capability. As DevOps professionals embrace the cloud, it breaks down the traditional security perimeter structure. This structure is the makeup of preexisting security practices and initiatives lead by security professionals versus modern methods being implemented by DevOps teams which disaggregate the neatly packaged n-tier, VM-bound application into distributed architectures.
From the Developer’s Perspective:
The developer is focused on access control and encryption requirements which are caused by security and data privacy mandates introduced by the security practitioner. While the developer is focused on building their business logic, they are faced with a few common challenges to meet these requirements. These common challenges include:
- Encryption enablement: When enabling across all microservice components, there are changes required for applications while maintaining the associated public key infrastructure (PKI). As a result, any patches associated with encryption libraries will require re-deployment of these applications.
- Distributed application programming interface (API) authorization: Authorization is key to ensuring all API requests within an Enterprise and any access to APIs from outside the Enterprise are sanctioned. By authorizing them in a distributed manner, it ensures this is properly done.
- Increased overhead: For distributed applications, particularly those governed by strict compliance such as the payment card industry (PCI), secrets management and key distribution introduce overhead for the developer.
From the Security Practitioner’s Perspective:
The security practitioner’s primary goal is maintaining visibility, compliance, and control while embracing this architectural transformation towards microservices. In doing so, the security team runs into a few common challenges that hinder them from achieving this goal. These common challenges include:
- Application deployment velocity: The dynamic nature of microservices invalidates existing network security approaches. The common security practice of ticket-driven security requires a corporate security team to create new firewall rules that with each release greatly hampers the application deployment velocity.
- Threat monitoring: Challenges are created for monitoring the threat landscape at both the network and host layer when control is lost over the network and compute infrastructure.
- Compliance: For both new application architectures driven by APIs and containers, it becomes increasingly difficult to assess compliance.
As both the developer and security practitioner play vital roles in the successful enablement of a microservice, it is crucial to align on an effective security solution prior to implementation. For an organization looking for end-to-end security for their microservices and containers, there are three core tenants of an effective microservice security solution:
- Comprehensive: Does the solution address the entire microservices stack? With a comprehensive microservice stack, there are three layers. These include the container runtime (the interactions of the container with the host), network access (the network traffic between microservices), and the API layers (the unit of consumption for microservices). When you only address a single layer, it will result in a myopic protection and detection solutions for two key reasons:
- Protection: A much more robust solution is created when exercising both zero trust and least privilege access control across all three layers, greatly reducing the probability of a complete attack. For example, a code injection attack followed by an attempted remote shell and data exfiltration encompass multiple layers of the security stack.
- Detection: Anomalies across all three layers can be better correlated greatly improving the signal-noise ratio for detecting attacks. Signals from all three layers provide a better view of the potential kill chain an attack will use versus a single layer. For example, one is able to correlate a runtime violation with running port scans or brute force attempts to determine open API’s on a microservice.
- Identity-drivers: Is the solution based on the Zero Trust principles of authentication and authorization for all transactions? Identity paves the path for scalable encryption across all microservices. A popular encryption technique – Mutual TLS (transport layer security) – is part of the TLS negotiation process used to authenticate and authorize both microservice ends. When an identity is assigned to a microservice, it may now be an integral part of the authorization process during the TLS session. Authentication and authorization policies are strengthened when they are identity-driven because the more context available to identify a microservice, the strong it makes it. Identity enhancement considerations include:
- Leverage vulnerability data from container image scans.
- Use metadata from containers to become a multi-attribute identity. Containers are most often auto-generated as part of a CI/CD pipeline and possess a significant amount of metadata. This metadata can include a type of container, type of image it is running or even a reference identifier back to the code commit that triggered the creation of this container.
- Heterogeneous: Can it be deployed across heterogeneous environments? Typically stared as a small initiative, most microservice and cloud-native adoption projects have specific scopes — there is always a brownfield deployment where microservices have dependencies on monoliths. A microservice security solution needs to be capable of operating in multiple environments, which services can be hosted in both public and private environments. Additionally, they can use a variety of orchestration capabilities such as Kubernetes, VMWare or EC2 Container Services.
In general, within a microservice environment, it is vital to address all aspects of core protection and visibility use cases of a distributed application. With challenges facing both, the developer and the security practitioner, the rapidly growing need for security teams to understand the full set of requirements is crucial for a successful implementation. Proper hygiene, monitoring, logging and compliance are required for a comprehensive microservice security solution. At all layers of a security stack, it is important to keep these three principles top of mind to ensure success: is it comprehensive, identity-driven and heterogeneous.
About the author:
Amir Sharif has 20 years of experience building data center products integrating OS, virtualization, networking, storage, low-latency I/O, and orchestration. His executive experience includes running product management, engineering, and business development. Amir holds patents in RFID and distributed storage and received his MBA from UC Berkeley, where he was a Gloria Appel Entrepreneurial Fellow, a Hitachi Mu Chip Fellow, and Mayfield Fellow. He started his career as a mathematician and software engineer.
