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 latest here.

(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.