on 27-Aug-2020 08:45
Applications living in public clouds such as AWS, Azure, GCP, Alibaba Cloud, delivered via CI/CD pipelines and deployed using Kubernetes or Docker, introduce significant challenges from a security visibility and orchestration perspective.
This article is the first of series, and aims at defining the tenets of effective security visibility and explore a journey to achieving end-to-end visibility into the application construct. The consideration of visibility from the inception of service or application is crucial for a successful implementation of security. Comprehensive visibility enables ‘security and performance’ oriented insights, generation of alerts and orchestration of action based on pertinent events.
The end-goal of integrating visibility and orchestration in application management is to provide a complete framework for the operation of adaptive applications with appropriate level of security.
For the purposes of this article, an application is defined as a collection of loosely coupled microservices (ref. https://en.wikipedia.org/wiki/Microservices) that communicate over the back and/or front-end network to support the frontend. Microservices are standalone services that provide one or more capabilities of the application. They are deployed across multiple clouds and application management infrastructures. The following shows a sample application built on microservices (ref. https://github.com/GoogleCloudPlatform/microservices-demo).
The challenge posed by the infrastructure above lies in providing comprehensive visibility for this application.
From a confidentiality, integrity and availability standpoint, it is essential to have this visibility to ensure that the application is running optimally and that the users are guaranteed a reasonable level of reliability.
In this article we consider two distinct aspects of security: posture assessment and monitoring. The first is based on the review and assessment of the configuration of the security measures protecting the application. For example, the analysis aims to answer questions such as:
The second aspect of security visibility is dynamic in nature. It relies on the collection of logs and intelligence from the infrastructure and control points. The information collected is then processed and presented in an intelligible fashion to the administrator. For example, log gathering aims to answer questions such as:
The figure below gives a graphical representation on possible feeds into the visibility infrastructure.
Once the data is ingested and available from the assessment and monitoring, we can use the data to produce reports, trigger alerts and extract insights.
Strategies for reporting, alerting and insights will vary depending on requirements, infrastructure and organizational/operational imperatives. In following articles, we will offer different possibilities to generate and distribute reports, strategies for alerting and providing insights (dashboards, chatops etc.)
From an F5-centric perspective, the figure below shows the components that can contribute to the assessment and monitoring of the infrastructure:
In order to be able to consume security visibility with an adaptive application, it needs to be implemented as part of the CI/CD pipeline. The aim is to deploy it alongside the application. Any dev modification will trigger the inclusion and testing of the security visibility.
Also, any change in the security posture (new rules, modified policy etc.) will trigger the pipeline and hence testing of deployment and validation of security efficacy.
From an application deployment point of view, inserting F5 solutions in the application through the pipeline would look something like the picture below.
In the picture above, BIG-IP, NGINX Plus / NGINX App Protect, F5 Cloud Services, Silverline/Shape are inserted at key points in the infrastructure and provide control points for the traffic traversing the application. Each element in the chain also provides a point that will generate telemetry and other information regarding the component protected by the F5 element.
In conjunction with the control points, security can also be provided through the implementation of an F5 AspenMesh service mesh for Kubernetes environments.
The implementation of security is integrated into the CI/CD pipeline so as to tightly integrate, testing and deployment of security with the application. An illustration of such a process is provided as an example in the figure below.
In the figure above, changes in the security of the application is tightly coupled with the CI/CD pipeline. It is understood that this might not always be practical for different reasons, however, it is a desirable goal that simplifies the security and overall operations considerably.
The figure shows that any change in the service or workload code, its security or the API endpoints it serves triggers the pipeline for validation and deployment in the different environments (prod, pre-prod/staging, testing). The figure does not show different integration points, testing tools (unit and integration testing) or static code analysis tools, as those tools are beyond the scope of this discussion.
Eventually, the integration of artificial AI/ML, and other tooling should enable security orchestration, automation and response (SOAR). With greater integration and automation with other network and infrastructure security tools (DoS prevention, firewall, CDN, DNS protection, intrusion prevention) and the automated framework, it is conceivable to offer important SOAR capabilities. The insertion and management of the visibility, inference, and automation in the infrastructure enables coordinated and automated action on any element of the cyber kill-chain thus providing enhanced security and end-to-end remediation.
It is understood that the implementation of security frameworks cannot occur overnight. This is true for both existing and net-new infrastructure. The journey to integration will be fraught with resistance from both the Security or secdevops group and the Application or devops organization. The former needs to adapt to tools that seem foreign but are incredibly accessible and powerful. The latter category feels that security is a hindrance and delays implementation of the application and is anything but agile. Neither sentiment is based on more than anecdotal evidence.
F5 offers a set of possible integrations for automated pipelines, this includes:
These integrations are supported and maintained by F5 and available across all products.
The following are possible steps in the journey to achieve complete visibility with the use of F5 products – the following steps as well as recommendations will be discussed in greater detail in follow-up articles:
Keep in mind that applications are fluid and adaptive. This raises important challenges with regards, to maintaining and adjusting the visibility so that it remains relevant and efficient. This justifies the integration of security in the CI/CD pipeline to remain nimble and adapt at the speed of business.
This article aims at helping you define a journey to building a comprehensive resilient and scalable application security visibility framework. The context for this journey is that of adaptive applications that evolve constantly. Do note that the same principles apply to common off-the-shelf applications as well as they are extended and communicate with third-party applications.
The journey may begin by defining the goals for implementing security visibility and then a strategy to get to the goals. To be successful, the security strategy should include a “shift-left” plan to integrate into the CI/CD pipeline, removing friction and complexity from an implementation standpoint. Operational efficiency and usability should remain the guiding principles at the forefront of the strategy to ensure continued use, evolution and rapid change.
The next articles in this series will help you along this journey, leveraging F5 technologies such as BIG-IP, BIG-IQ, NGINX Plus, NGINX App Protect, Essential App Protect and other F5 Cloud Services to gather telemetry and configuration information. Other articles will discuss avenues for visibility and alerting services leveraging F5 services such as Beacon, as well as 3rd party utilities and infrastructure.
At the heart of this article is the implementation of proxies and control-points throughout the networked infrastructure to gather data and assess the application’s security posture. As a continuation of this discussion, the reader is encouraged to consider other infrastructure aspects such as static code analysis, infrastructure isolation (what process/container/hypervisor connects to which peer etc.) and monitoring.