Applications evolve rapidly whether your organization runs off-the-shelf applications or builds its own applications and frameworks. Increasingly, workloads are developed in a matter of hours, packaged, instantiated and torn down in timespans measured in minutes. This is the nature of continuous deployment pipelines.
Securing applications and workloads that are highly dynamic possibly living across different colocation facilities (Colos) and cloud infrastructures (public and private), can only be achieved following continuous integration and continuous deployment (CI/CD) methodologies.
In practice, this has resulted in integrating security in the software development and deployment lifecycles with the automation of:
· Code scanning when checked in to software versioning management tools (Git repository) using static application security testing (SAST),
· Verifying artifacts used for application instantiation such as packages and containers during creation, before they are stored to ensure that they are free of malware
· Scanning applications/workloads at runtime as part of the pipeline before deployment in production leveraging dynamic application security testing (DAST) tools
· Securing runtime environments enforcing admission control, use of least-privilege during spin-up, and implementing monitoring
· Building in compliance at every stage of the development and deployment process as needed (HIPAA, PCI etc.)
Building automated and orchestrated
· Monitoring Kubernetes clusters and other cloud and physical infrastructure where workloads run, however ephemerally, tracking things like container health, container orchestration and ownership across the cluster
· Monitoring workloads and cloud services following site reliability engineering (SRE) guidelines – following the “Golden Signals” (Source: SRE Book)
· Performing regular vulnerability scanning of applications in production
Building security in the early stages of the software development lifecycle is part of a “shift-left” strategy, and is discussed here or here.
In order to support specific service level objectives (SLO), monitoring at the application and infrastructure level is built into the infrastructure from the perspective of latency, traffic, errors and saturation. More information on adopting SRE with F5 can be found here.
What about security visibility?
The fundamental need to have a holistic view of the application and its components is essential to be able to mitigate threats. You need to visualize your applications and possible threats in order to assess risk, identify threat vectors before attackers do, and possibly investigate in the event of an issue.
In a previous article, we focused on the posture assessment (static view) and monitoring (dynamic view) axis as fundamentals of security visibility. Implementing this visibility entails building and deploying security and security visibility within the pipeline along-side the application, workload or infrastructure.
The above figure shows the insertion of WAF policy and logging the software building pipeline. In a shift-left effort the logging, telemetry and security policy configuration is integrated alongside the application’s SDLC. The intent is to leverage the same pipeline infrastructure and have the security and visibility aspects integrated in the project with the workload code. WAF only provides one aspect of the application security suite and is the focus of this exercise. Other infrastructure-centric security configurations, such as mTLS use within a Kubernetes Service Mesh or authentication/authorization framework configurations, can also be inserted in the pipeline.
In order to simplify testing and deployment, the security infrastructure needs to be defined as code for consistent deployment for testing and production environments. Within an infrastructure-as-code and security-as-code framework, this article is meant to outline the need for visibility-as-code, and more precisely security-visibility-as-code. All F5 WAF products and their associated logging, monitoring and telemetry capabilities are easily automated and defined as-code. They can be inserted anywhere programmatically in all environment for testing as well as production.