The Setup
In our previous installment (https://number40.medium.com/services-runtime-security-part-1-7be71d3fa5e5) we outlined some fundamental issues that many businesses and security teams face when modernizing their systems. We are going to explore these using our fictional company, BlueMyst BioLabs. At BlueMyst we have been transitioning our systems from monolithic applications to a Service Oriented Architecture for years. We are on a journey to allow partners both internal and external the ability to interact with our systems via RESTful APIs. This new openness has made us a target. Our systems are especially attractive to threat actors because they contain both PII and PHI.
During internal discussions we discovered that a new architectural guideline has been established. Any new services, should be architected and developed as microservices. This means we will have a mix of larger SOA style services and a diverse microservices architecture. If that was not enough, our company has decided to go to the cloud. Select systems are being re-platformed to be more cloud native. Easy, right!
Requirements
We have established some requirements for our security solution.
- Architect a security solution that can help us move forward into the this future state.
- Decouple security controls from the individual applications.
- Ensure only authenticated users and services can access the API.
- Ensure proper authorization levels for accessing specific data.
- Record detailed logs of all API requests and responses without logging sensitive PII or PHI data.
- Validate and sanitize all inputs to prevent common attacks.
- Define and implement Kubernetes network policies to control the communication between pods.
- Implement identity verification between services.
- Implement encryption for data-in-transit.
Our Basic Technology Stack
Our chosen stack, which hinges upon the synergy of an API Gateway and the robust capabilities of Kubernetes, is becoming emblematic of a new era in software design. It’s a setup that is not very unique and is gaining traction as a typical configuration among startups and enterprises alike, aiming for streamlined operations and agile development cycles.
Services/Microservices
Responsibility: Each microservice is responsible for a specific piece of functionality, and a service may be responsible for a set of functionalities. A characteristic of microservices is that they can be developed, deployed, and scaled independently.
Communication: Services usually communicate over HTTP/HTTPS using REST or gRPC, although other protocols might be used.
API Gateway
Responsibility: Handles request routing, composition, rate limiting, security (like authentication & authorization), and other cross-cutting concerns.
Popular Solutions: Azure API Manager, Kong, Apigee
Kubernetes (K8s)
Responsibility: Manages the lifecycle of containerized services and microservices, handles service discovery, load balancing, secret management, and provides self-healing capabilities.
Popular Solutions: Azure Kubernetes Service, Amazon Elastic Kubernetes Service.
Note: The diagrams in this series will generally depict Azure resources. This is just preference.
Problems (Uh, oh!)
If the technology challenges were not enough. Our architectural team identified two fundamental problems, a lack of services security standardization and a reluctance by development and operational teams to adopt cloud-native security technologies.
The lack of a unified approach to services security practices has led to tangential issues such as longer development cycles, as developers must navigate a complex and varied set of tools and methodologies. These inconsistencies not only slow down our ability to deliver innovative products and services but also hinders our response to ever-changing market demands. The absence of standardized practices reduces the overall quality of our efforts, making it more challenging to maintain and debug applications, ultimately increasing operational costs.
Inefficient resource allocation is another significant issue stemming from our current practices. Without standardization, developers often spend valuable time and effort recreating code, components, and libraries that could be reused across projects. This redundancy not only increases development costs but also diverts our resources from focusing on delivering unique value and innovation to the organization.
Inconsistent services security practices impede cross-functional collaboration and knowledge sharing among team members. When developers work with disparate tools, frameworks, and methodologies, it becomes more challenging to share knowledge and solve problems efficiently. This can lead to slower learning, reduced team performance, and ultimately, hinder our organization’s ability to innovate and stay ahead of the competition.
From a security standpoint, our organization’s inconsistent approach to securing services exposes us to potential vulnerabilities and data breaches. As cyber threats continue to evolve, maintaining a fragmented security posture puts our sensitive data and business reputation at risk. Additionally, the absence of consistent security practices complicates our ability to comply with industry-specific regulations and data protection standards, potentially resulting in costly penalties and legal consequences.
The second problem was the reluctance to use cloud-native technologies and the fear associated with changing how teams perform their responsibilities. One of the primary reasons developers are hesitant to adopt cloud-native technologies is the steep learning curve associated with these tools. The shift from traditional monolithic architectures to microservices, containers, and orchestration platforms can be challenging, requiring developers to learn new skills and adapt to unfamiliar paradigms. Moreover, the ever-evolving landscape of cloud-native technologies, with new tools and best practices emerging regularly, can be overwhelming and daunting for developers.
Adopting cloud-native technologies often requires significant investments in time and resources, which may not always be feasible for small development teams or organizations with limited budgets. Additionally, the cost of managing and maintaining these technologies can be a deterrent for some, as they weigh the potential benefits against the financial implications. Some developers may be uncertain about the tangible benefits of adopting cloud-native technologies, particularly if their applications are already functioning well on traditional architectures. This skepticism can lead to a reluctance to invest in new tools and paradigms, even when the potential advantages are well-documented and widely recognized.
From a security perspective this is an issue because cloud-native technologies often include built-in security features, such as container isolation, automated vulnerability scanning, and encryption. By avoiding these technologies, developers may miss out on opportunities to enhance their applications’ security posture, increasing the risk of data breaches, unauthorized access, and other security incidents.
Questions (beyond technical)
As an architectural group we mainly think about the technical side of security solutions. I think this is shortsighted and often misses the point. The security solutions exist for a reason…to protect something. I think all good architectural teams should be prepared to answer questions from management. It’s essential to consider the primary responsibilities of management, which revolve around protecting organizational information, ensuring compliance, managing risk, and staying ahead of security threats. Given this context, This will also help inform your architecture. The BlueMyst architects were asked to take some time and think about this project from management’s point of view, ask themselves questions about Services Runtime Security.
Threat Landscape
- What are the current and emerging threats specific to services runtime?
- How are attackers exploiting runtime vulnerabilities?
Protection Mechanisms
- How can anomalies or malicious activities be detected during runtime?
- What measures are in place to mitigate a threat once detected?
Performance Impact
- What is the performance overhead of the security measures on the service?
Compliance and Regulation
- How does the runtime security solution help in meeting industry regulations and standards?
- Are there audit capabilities to demonstrate compliance?
Integration
- How well does the runtime security solution integrate with existing infrastructure, tools, and platforms?
- How challenging is it to deploy and manage the solution across varied environments?
Incident Response
- Does the runtime security solution offer actionable insights for incident response?
- How quickly can a team respond to a detected threat, and what tools are available to them?
Forensics and Analysis
- Does the solution provide tools or logs that can help in post-incident analysis?
Automation and Orchestration
- Can the runtime security measures be automated?
Cost and ROI
- What are the costs associated with the solution, and how do they compare with the potential risks mitigated?
- How does the solution impact the total cost of ownership (TCO) of the services or applications it protects?
By addressing these concerns and topics, you can provide management (and yourself) with a comprehensive understanding of the runtime security solution’s value and its potential impact on their organization’s security posture. This will help inform your later decisions.
Goals for the BlueMyst Security Architects
Our goals need to align to the requirements and solve our challenges.
Standardization of Services Security
- Develop and implement a unified approach to services security practices.
- Monitor and update this solution as needed, ensuring its effectiveness in the long term.
Reduce Development Cycle Time
- Minimize inconsistencies in tools and methodologies to streamline the development process.
- Promote the reuse of common components and libraries across projects.
Address Current Security Vulnerabilities
- Conduct a comprehensive security audit to identify existing vulnerabilities in the system.
- Prioritize and address the vulnerabilities found, ensuring data protection and compliance with industry-specific regulations.
Cloud-Native Security Technologies Adoption
- Identify key cloud-native security technologies relevant to our industry and business needs.
- Showcase the built-in security features of cloud-native technologies like container isolation, automated vulnerability scanning, and encryption.
- Continuously update and refine the training material based on the latest security best practices in cloud-native technologies.
So…how do we do it and what do we consider? In our next series installment we will examine some common solutions!
https://number40.medium.com/services-runtime-security-part-3-8b9641753e31
