High-level Pathways to Security Visibility
Editor's Note: The F5 Beacon capabilities referenced in this article hosted on F5 Cloud Services are planning a migration to a new SaaS Platform - Check out the latesthere. (10 Minute Read) Introduction In previous articles we identified the elements needed to gain visibility into adaptive application security postures. This entails observing the security configuration (static) and monitoring telemetry (dynamic) coming from different control points (ref. Visibility and Orchestration).We also suggested that security visibility should be integrated in the software development and/or deployment lifecycle as part of a shift-left strategy (ref. Shift-left Security Visibility). Now, we’ll focus on identifying a high-level pathway to achieve application security visibility. First, we need to identify the constraints that frame the effort.We will then identify concrete examples of insertion with F5 technologies. The end-goal is to ensure that you keep close control over the application security by embracing a holistic approach to visibility integrated in the software development/deployment lifecycle. Constraints Inserting security visibility in your enterprise is part of the shift-left strategy (ref. url-to-shift-left-sec-vis.). (https://www.f5.com/company/blog/beyond-visibility-is-operability) In order to be practical, we need to make sure that the pathway adheres to the following guidelines: Friction – The solution should not introduce any friction into the pipeline - For example, the tools used by the DEVOPS and SECOPS teams (e.g. Gitlab, Jenkins) should be the same avoiding gated interdependencies where a change by one group is blocked/delayed by the other. Programmability – The security-centric solutions implemented during the journey need to be highly programmable – This will ensure that the tools adapt to the environment (e.g. services, micro-services), the supporting infrastructure (e.g. cloud, containers), and the application. Automation – Enabling automation is key. This can be achieved by ensuring the tools deployed can be automatically configured without intervention as part of a pipeline.One way to ensure this is to leverage declarative application programing interfaces (API) (link-to-f5-declarative-interface) Scalability – Applications can span across infrastructure that is infinitely scalable like public cloud, across availability zones and geographies.This requires that any solution that is deployed to secure/protect applications and workloads be able to scale.To scale horizontally, the solution can be implemented across multiple workloads in multiple instances.To scale vertically, the solution should be able to handle increasing amounts of traffic in single/few instances. Transparency – From a performance and functionality standpoint, the solutions inserted to gain security visibility cannot impact the application.For example, when a proxy is inserted, it cannot add latency between the client and the workload. It also cannot affect the functionality provided by the workload. Resiliency – Inserting a solution to support your applications security and visibility should be resilient.Any failure of the process providing visibility should be flagged and not affect the application’s/workload’s performance or availability. Visibility Insertion All F5 solutions can be inserted in the application delivery infrastructure to provide security visibility.This comes in the form security-aware proxies.The BIG-IP or NGINX Plus platforms are particularly well-suited for insertion in infrastructure requiring inline low-latency and powerful application security and visibility.Deploying F5 solutions can easily be done observing all the constraints mentioned above. Friction Thanks to the available form factors and programmatic templates provided, implementing BIG-IP or NGINX Plus in the infrastructure is easily achieved using appropriate templates. For example, when working with AWS, a BIG-IP can easily be deployed using a Cloud Formation Template (CFT) found here.From the enterprise git (Gitlab, Github, Bitbucket etc.) repository, BIG-IP can be deployed directly by cloning/forking the F5 repository and integrating with the pipeline (ref. Clouddocs Article). Programmability The BIG-IP Advanced Web Application Firewall (Advanced WAF) configuration is highly programable.The advantage is that the configuration can be stored and or modified easily outside of the BIG-IP. For example, an base policy aimed at protecting against OWASP Top 10 Risks can look like the following: { "policy": { "name": "Complete_OWASP_Top_Ten", "description": "A generic, OWASP Top 10 protection items v1.0", "template": { "name": "POLICY_TEMPLATE_RAPID_DEPLOYMENT" }, "fullPath": "/Common/Complete_OWASP_Top_Ten", "enforcementMode":"transparent", "signature-settings":{ "signatureStaging": false, "minimumAccuracyForAutoAddedSignatures": "high" }, "protocolIndependent": true, "caseInsensitive": true, "general": { "trustXff": true }, "data-guard": { "enabled": true }, "policy-builder-server-technologies": { "enableServerTechnologiesDetection": true }, "blocking-settings": { "violations": [ { "alarm": true, "block": true, "description": "ASM Cookie Hijacking", "learn": false, "name": "VIOL_ASM_COOKIE_HIJACKING" }, { "alarm": true, "block": true, "description": "Access from disallowed User/Session/IP/Device ID", "name": "VIOL_SESSION_AWARENESS" }, { "alarm": true, "block": true, "description": "Modified ASM cookie", "learn": true, "name": "VIOL_ASM_COOKIE_MODIFIED" }, { "alarm": true, "block": true, "description": "XML data does not comply with format settings", "learn": true, "name": "VIOL_XML_FORMAT" }, { "name": "VIOL_FILETYPE", "alarm": true, "block": true, "learn": true } ], "evasions": [ { "description": "Bad unescape", "enabled": true, "learn": true }, { "description": "Apache whitespace", "enabled": true, "learn": true }, { "description": "Bare byte decoding", "enabled": true, "learn": true }, { "description": "IIS Unicode codepoints", "enabled": true, "learn": true }, { "description": "IIS backslashes", "enabled": true, "learn": true }, { "description": "%u decoding", "enabled": true, "learn": true }, { "description": "Multiple decoding", "enabled": true, "learn": true, "maxDecodingPasses": 3 }, { "description": "Directory traversals", "enabled": true, "learn": true } ] }, "xml-profiles": [ { "name": "Default", "defenseAttributes": { "allowDTDs": false, "allowExternalReferences": false } } ], "session-tracking": { "sessionTrackingConfiguration": { "enableTrackingSessionHijackingByDeviceId": true } } } } In the example above, aspects of a security policy like evasion techniques, or cookie consumption settings can easily be programmed in the configuration and handled like any other application code for versioning, editing or storing.The standard JSON format can be managed in a Git repository for use in any environment.Documentation for JSON representations of WAF policies can be found here. This is also true for all F5 security platforms including NGINX App Protect or Essential App Protect (ref.NGINX Configuration Guide and EAP API Users Guide). Similarly, configuring BIG-IP to forward security information telemetry to appropriate facilities can be achieved with the use of the Telemetry Streaming framework.For example, in order to configure BIG-IP to send telemetry data to a centralized visibility tool (F5 Beacon, or ELK for example) it can be configured with a declaration like: "class": "Telemetry", "controls": { "class": "Controls", "logLevel": "debug" }, "TS_Poller": { "class": "Telemetry_System_Poller", "interval": 60 }, "TS_Listener": { "class": "Telemetry_Listener", "port": 6514 }, "TS_Consumer": { "class": "Telemetry_Consumer", "type": "Generic_HTTP", "host": "my.visibility-host.url", "protocol": "http", "port": 8888, "path": "/", "method": "POST", "headers": [ { "name": "content-type", "value": "application/json" } ] } } The above declaration identifies the host where it will send telemetry – in this case debug data Scalability, Transparency and Resiliency F5 provides highly scalable, resilient and transparent solutions that can be inserted in any infrastructure to secure and provide visibility into web applications.Discussing these aspects of BIG-IP, NGINX Plus, or NGINX App Protect is beyond the scope of this article.For more information on scalability and high-availability you can refer to Performance of NGINX and NGINX Plus, NGINX App Protect Application Security Testing or BIG-IP Datasheet. Conclusion This article is meant to offer a path to visibility using F5 technology by inserting BIG-IP and configure it to provide application security and generate telemetry to gain visibility into the application's security posture. The aim is for you build a blueprint to systematically watch over your adaptive valuable applications and workloads across your infrastructure.Shift-left Security Visibility
5 Minute Read 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), ·Integrating web application firewall (WAF) in the CI/CD pipeline as can be seen with BIG-IP Advanced WAF or NGINX App Protect and Kubernetes ·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.Deploying a web application firewall policy with central learning from BIG-IQ
Scope This article is useful for BIG-IP/BIG-IQ users familiar with web application security.This includes, application security professionals, infrastructure management operators. Introduction Centralized Policy Building (CPB) is a feature specific to BIG-IQ.It allows security administrators to create, deploy and manage web application firewall (WAF) policies on BIG-IP devices. The policy building can occur manually or automatically.This feature is comparable to the on-box policy building feature available on BIG-IP and is better suited for distributed environments. This article focuses on the configuration of the central learning feature for web application security policies in BIG-IQ.It will take you through the different steps to create, deploy and manage the WAF policy, as well as the appropriate logging profile. The virtual server and other related elements such as profiles, pools etc. are configured using the Applications framework leveraging AS3. The steps are documented for the operator to use the BIG-IQ web user interface (webUI)to manage the WAF policy.The creation of the virtual server object can be done directly from the BIG-IQwebUIor through a simple REST call (leveraging the Postman™ clienthttps://www.postman.com/product/api-client/). Pre-requisites The following pre-requisites must be met in order to follow the procedures outlined below: BIG-IQ Central Management (CM) and BIG-IQ Data Collection Device (DCD) are deployed provisioned with all appropriate licensing. BIG-IP is deployed licensed and provisioned with both the ASM and AVR modules. A web application is available for securing via BIG-IP. All networking and network security must be in place to allow traffic between the different components. The BIG-IP, BIG-IQ CM, BIG-IQ DCD, application servers etc. all must be reachable as describedhere. The BIG-IP is running TMOS version 14.1 or greater. The BIG-IQ is running version 7.0 or greater. The discovery and import process for the target BIG-IPis completed as documentedhere. The administrator/operator performing the procedure below will have admin-level access to the BIG-IQ CMwebUI. BIG-IQ AS3 Templates are loaded on the BIG-IQ CM as describedhere. Overview The procedure detailed below goes over the following main steps on BIG-IQ: Verify proper BIG-IP/BIG-IQ configuration and reachability Create a web application security (the sample policy used in this example iscreatedwith central policy building enabled for manual learning and manual deployment of policy changes to the BIG-IP) Create a logging profile for application security Deploy the policy and logging profile using the “inactive” inactive virtual server and the profile pinning mechanism Create the application definition using AS3 referencing the policy and logging profile in the declaration. Send test traffic to the virtual server Review logs and learning suggestions on BIG-IQ Procedure For the following steps it is assumed that the operator is logged in the BIG-IQ CMwebUIand has the necessary administrative rights to create,update and delete web application security configuration as well as create applications.BIG-IQ accommodates fine-grained role-based access control (RBAC) toassign different roles to different user, e.g. security administrator role for policy management, and application administrator for other aspects of the configuration.This is beyond the scope of this article,more information is availablehere. BIG-IQ/BIG-IP configuration From theDevicestab, click onBIG-IP DEVICESand select the target BIG-IP (in this case bigip1) and verify that the followingSERVICESare discovered and imported: Local Traffic (LTM) Shared Security (SSM) Web Application Security (ASM) Ensure that the BIG-IQ DCD nodes Web Application Security service is enabled (System >> BIG-IQ DATA COLLECTION >> BIG-IQ Data Collection Devices >> [name of DCD device] >> SERVICES): WAF Policy Creation From theConfigurationtab, expandSECURITYandWeb Application Security Click onPoliciesand theCreatebutton Fill out theNamefield – and configure the policy features as desired (the picture below provides a sample for illustration purposes only and is not to be used in your environment) Click on theSavebutton located at the bottom right of the screen In the policy configuration window, expandPOLICY BUILDING, and selectSettings From thePolicy Building ModeselectCentralfrom the drop down Select thePolicy Building Device(the BIG-IQ DCD configured previously with the BIG-IQ CM) Finish configuring other dimensions in the policy as needed and click on theSave & Closebutton located at the bottom right of the window. Logging Profile Creation In theConfigurationtab, expand theSECURITYand Shared Securitysections and click onLogging Profiles Click on theCreatebutton Enter aNamein the appropriate field and click onSaveat the bottom right of the screen Click onAPPLICATION SECURITY DisableLocal Storagefor the profile Check theRemote Storage, enter the IP address of the BIG-IQ DCD in the Protocol portion of the configuration screen, as shown in the sample below. Click on theAddbutton in theServer Addressesdialog, and then selectSave & Closeon the bottom right of the screen WAF Policy and Logging Profile Deployment Deploy the policy to the BIG-IP using theinactivevirtual server Add the policy to the virtual server on the appropriate BIG-IP Click onSave & Close From theConfiguration >> Security >> Web Application Security >> Virtual Serverswindow select the ‘inactive’ virtual server for the target BIG-IP and click onDeployas shown below: Follow the deployment screen instructions: Name the deployment (e.gdeploy_demo_policy) Select deployment method (e.g. deploy immediately) Select a target device (e.g. the BIG-IP where the policy is deployed) Click onDeploy Pin the logging profile to the BIG-IP (you can also choose to create the logging profile Navigate toConfiguration >> SECURITY >> Shared Security >> Pinning Policies Click on the target BIG-IP(s)and add the logging profileby selecting Logging Profiles from the drop down as shown below: Select the logging profile from the list and click on “Add Selected” Click onSave & Close Navigate toConfiguration >> Shared Security >> Logging Profiles Select the logging profile that was just pinnedand click onDeploy Complete the deployment process as discussed above. You are now ready to deploy the application using AS3. Application Creation (AS3) Go totheApplications tab Click on Create Select the appropriate AS3 Template (in the example belowthis is a template labelled AS3-F5-HTTPS-WAF-existing-template-big-iq-defult-v1– for more information on using AS3 with BIG-IQ,more information can be foundhere) Fill out the required fields including: Application Name (e.g.demo_app) Application Service Name (e.g.demo_app_service) Target (BIG-IP device) Tenant Pool Members (IP & Port) policyWAF(e.g. /Common/demo_policy) Virtual Addresses (VS address) Security Log Profiles (e.g. /Common/demo_log_profile) All the needed Analytics Profileentities required Click onCreate Ensure that the Application Service was created, it shouldlooksomething like: You are now able to send test traffic to the application.Feel free to use the f5-waf-tester tool availablehere. Log and Suggestions Review Now that the traffic is going to the application and, let's take a look at what BIG-IQ provides in terms of visibility. Go to Monitoring, expand DASHBOARDS, select L7 Security: Select the protected virtual server and selectEvent Logsin theView in …drop-down and you should be able to view the application security logs: To look at the suggestions resulting from the traffic being sent to the BIG-IP, go toConfiguration >> SECURITY >> Web Application Security>> Policies Click on the target policy – and selectPOLICY BUILDING >>Suggestions: Select the suggestions you wish to accept, ignore, or delete, and click on the appropriate action button (e.g. Accept) Confirm your choice as appropriate on the pop-up window as needed. Once all the suggestions have been accepted, deploy the policy to the relevant BIG-IP(s) as needed: Deployment >> EVALUATE & DEPLOY >> Web Application Security and click on Create Follow the instructions to complete the deployment process. Conclusion BIG-IQ provides the ideal platform to enable security operations independently from the devops group.The multiple personas can run their tasks independently and effectively gaining granular visibility in the application performance, security, and overall status. Please note that the above steps are also used in an F5 CloudDocs Lab available by following this link.Visibility and Orchestration
Introduction 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. Initial Premise and Challenge 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. Visibility 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: Is the application protected by an advanced web application firewall? What threats are the application and/or the microservices protected from? DoS? Bot? Application vulnerabilities? Is the communication between microservices confidential? 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: How much of the traffic reaching my applications and its components, “good traffic” and how much of it is coming from Bots and Scans? Does the application traffic hitting my servers conform to what I am expecting?Is there any rogue user traffic attempting to exploit possible vulnerabilities to disrupt availability of my application or to gain access to the data it references? Are the protection policies in place appropriate and effective? 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: Orchestration 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. Journey 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: A comprehensive automation toolchain for BIG-IP (link). F5 supported integrations with multiple infrastructure-as-code and automation tools such as Terraform (link)or Ansible (link). Integrations with all major cloud providers including Amazon Web Services (link), Google Cloud Platform (link) or Microsoft Azure (link). Full RESTful API’s to manage all F5 products including Cloud Services, Shape and NGINX Plus instances. 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: Architect the insertion of F5 control points (Cloud Services, BIG-IP, NGINX, Shape etc.) wherever possible. This differs somewhat based on the type of infrastructure (e.g. deployment in on premises datacenter versus cloud deployments) Automate the insertion and configuration of F5 control points leveraging the centralized management platforms, and other F5-provided tools to make the process easy. Automate the configuration of logging and telemetry of different control points in such a manner so that they feed into the centralized management platforms, and other visibility tools such as Beacon, ELK or other 3 rd -party utilities (e.g. SIEM etc). Based on available tools, define logging/telemetry/signaling strategy to collect and build a global view of the infrastructure – this might include the layering of technologies to distill the information as it is interpreted and aggregated, for example, leverage BIG-IQ as the first line of logging and visibility for BIG-IP Leveraging F5 Beacon or other 3 rd party tools, and build custom dashboards offering various insights to appropriate party involved in delivery and security of applications. Enhance the visibility provided through a reporting strategy that will allow the sharing of information among different groups as well as different platforms (e.g. SIEM etc.) Build a centralized solution collecting metrics, logs and telemetry from the different platforms to build meaningful insights. (Optional) Integrate with flexible ops tools such as chatops (Slack, MS Teams etc.) and other visibility tools via webhooks. (Optional) Integrate with ML/AI tools to speed the discovery and creation of insights (Optional) Progressively build SOAR and other capabilities leveraging F5 and/or 3 rd -party tools. 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. Conclusion 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 3 rd 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.
