CORS with API calls
Hello, Sorry if this is an obvious question -- we're very new to XC. We're using XC with one load balancer with CORS activated. It works fine for web applications but all API calls (to our internal APIs) are blocked because of missing origin header. What is the correct way to handle it? Ask the connecting party to insert origin headers? Dedicate another load balancer (to be used for APIs only) with CORS disabled? Thank you.Forwarding Logs to SIEM Tools via HTTP Proxy for F5 Distributed Cloud Global Log Receiver
Purpose This guide provides a solution for forwarding logs to SIEM tools that support syslog but lack HTTP/HTTPS ingestion capabilities. It covers the deployment and tuning of an HTTP Proxy log receiver configured to work with F5 Distributed Cloud (XC) Global Log Receiver settings. Audience: This guide is intended for technical professionals, including SecOps teams and Solution Architects, who are responsible for integrating SIEM tools with F5 XC Global Log Receiver. Readers should have a solid understanding of HTTP communication (methods, request body, reverse proxy), syslog, and data center network architecture. Familiarity with F5 XC concepts such as namespaces, log types, events, and XC-GLR is also required. Introduction: Problem Statement: SIEM tools often support syslog ingestion but lack HTTP/HTTPS log reception capabilities. Objective: Explain how to deploy and configure an HTTP Proxy to forward logs to F5 Distributed Cloud Global Log Receiver. Solution Overview: Architecture Diagram and workflow: Configuration Steps: Configure Global Log Receiver in F5 Distributed Cloud Console Navigate to: Home → Shared Configuration → Global Log Receiver Create or edit the Global Log Receiver settings for HTTP receiver Ensure the Global Log Receiver batch size is based on the payload size expected from F5 NGINX. Example configuration snap: Set Up NGINX as an HTTP Log Receiver Install NGINX on your designated server. Configure log_format Configure NGINX to accept HTTP POST requests only and forward access logs to syslog Example configuration snippet: log_format custom_log_format_1 escape=json $request_body; # Example: include request body only server { listen 443 ssl; server_name <logreceiver_server_name>; ssl_certificate /etc/ssl/<logreceiver_server_cert>; ssl_certificate_key /etc/ssl/<logreceiver_server_key>; # Other SSL/TLS configurations (e.g., protocols, ciphers) ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers HIGH:!aNULL:!MD5; client_body_in_single_buffer on; # The directive is recommended when using the $request_body variable, to save the number of copy operations involved client_body_in_file_only off; #default client_max_body_size 32M; # based on tuning gzip on; location /log_endpoint { # Allow only POST requests for sending log data limit_except POST { deny all; } # Configure access_log to write incoming data to a file # access_log /var/log/nginx/log_receiver.log custom_log_format_1; access_log syslog:server=127.0.0.1:514,facility=local7,tag=nginx,severity=info custom_log_format_1; proxy_pass http://localhost:8091/; # This dummy Internal server required to collect request_body variable. } } # dummy internal server to respond back 200 ok server { listen 8091; server_name localhost; location / { return 200 "Log received successfully."; } } Set Up rsyslog server Install/configure rsyslog on your designated server. Configure 60-nginx.conf file in /etc/rsyslog.d/ directory Sample 60-nginx.conf file #nginx.* @@127.0.0.1:514 :syslogtag, isequal, "[nginx]" /var/log/nginx-syslog/nginx-access-log.log References: F5 Distributed Cloud Global log receiver supports many log receivers natively: F5 Distributed Cloud Technical Knowledge page on "Configure Global Log receiver" Prerequisites: An external log collection system reachable publicly. The following IP address ranges are required to be added to your firewall's allowlist: 193.16.236.64/29 185.160.8.152/29Advanced WAF v16.0 - Declarative API
Since v15.1 (in draft), F5® BIG-IP® Advanced WAF™ can import Declarative WAF policy in JSON format. The F5® BIG-IP® Advanced Web Application Firewall (Advanced WAF) security policies can be deployed using the declarative JSON format, facilitating easy integration into a CI/CD pipeline. The declarative policies are extracted from a source control system, for example Git, and imported into the BIG-IP. Using the provided declarative policy templates, you can modify the necessary parameters, save the JSON file, and import the updated security policy into your BIG-IP devices. The declarative policy copies the content of the template and adds the adjustments and modifications on to it. The templates therefore allow you to concentrate only on the specific settings that need to be adapted for the specific application that the policy protects. This Declarative WAF JSON policy is similar to NGINX App Protect policy. You can find more information on the Declarative Policy here : NAP : https://docs.nginx.com/nginx-app-protect/policy/ Adv. WAF : https://techdocs.f5.com/en-us/bigip-15-1-0/big-ip-declarative-security-policy.html Audience This guide is written for IT professionals who need to automate their WAF policy and are familiar with Advanced WAF configuration. These IT professionals can fill a variety of roles: SecOps deploying and maintaining WAF policy in Advanced WAF DevOps deploying applications in modern environment and willing to integrate Advanced WAF in their CI/CD pipeline F5 partners who sell technology or create implementation documentation This article covers how to PUSH/PULL a declarative WAF policy in Advanced WAF: With Postman With AS3 Table of contents Upload Policy in BIG-IP Check the import Apply the policy OpenAPI Spec File import AS3 declaration CI/CD integration Find the Policy-ID Update an existing policy Video demonstration First of all, you need a JSON WAF policy, as below : { "policy": { "name": "policy-api-arcadia", "description": "Arcadia API", "template": { "name": "POLICY_TEMPLATE_API_SECURITY" }, "enforcementMode": "blocking", "server-technologies": [ { "serverTechnologyName": "MySQL" }, { "serverTechnologyName": "Unix/Linux" }, { "serverTechnologyName": "MongoDB" } ], "signature-settings": { "signatureStaging": false }, "policy-builder": { "learnOnlyFromNonBotTraffic": false } } } 1. Upload Policy in BIG-IP There are 2 options to upload a JSON file into the BIG-IP: 1.1 Either you PUSH the file into the BIG-IP and you IMPORT IT OR 1.2 the BIG-IP PULL the file from a repository (and the IMPORT is included) <- BEST option 1.1 PUSH JSON file into the BIG-IP The call is below. As you can notice, it requires a 'Content-Range' header. And the value is 0-(filesize-1)/filesize. In the example below, the file size is 662 bytes. This is not easy to integrate in a CICD pipeline, so we created the PULL method instead of the PUSH (in v16.0) curl --location --request POST 'https://10.1.1.12/mgmt/tm/asm/file-transfer/uploads/policy-api.json' \ --header 'Content-Range: 0-661/662' \ --header 'Authorization: Basic YWRtaW46YWRtaW4=' \ --header 'Content-Type: application/json' \ --data-binary '@/C:/Users/user/Desktop/policy-api.json' At this stage, the policy is still a file in the BIG-IP file system. We need to import it into Adv. WAF. To do so, the next call is required. This call import the file "policy-api.json" uploaded previously. An CREATE the policy /Common/policy-api-arcadia curl --location --request POST 'https://10.1.1.12/mgmt/tm/asm/tasks/import-policy/' \ --header 'Content-Type: application/javascript' \ --header 'Authorization: Basic YWRtaW46YWRtaW4=' \ --data-raw '{ "filename":"policy-api.json", "policy": { "fullPath":"/Common/policy-api-arcadia" } }' 1.2 PULL JSON file from a repository Here, the JSON file is hosted somewhere (in Gitlab or Github ...). And the BIG-IP will pull it. The call is below. As you can notice, the call refers to the remote repo and the body is a JSON payload. Just change the link value with your JSON policy URL. With one call, the policy is PULLED and IMPORTED. curl --location --request POST 'https://10.1.1.12/mgmt/tm/asm/tasks/import-policy/' \ --header 'Content-Type: application/json' \ --header 'Authorization: Basic YWRtaW46YWRtaW4=' \ --data-raw '{ "fileReference": { "link": "http://10.1.20.4/root/as3-waf/-/raw/master/policy-api.json" } }' A second version of this call exists, and refer to the fullPath of the policy. This will allow you to update the policy, from a second version of the JSON file, easily. One call for the creation and the update. As you can notice below, we add the "policy":"fullPath" directive. The value of the "fullPath" is the partition and the name of the policy set in the JSON policy file. This method is VERY USEFUL for CI/CD integrations. curl --location --request POST 'https://10.1.1.12/mgmt/tm/asm/tasks/import-policy/' \ --header 'Content-Type: application/json' \ --header 'Authorization: Basic YWRtaW46YWRtaW4=' \ --data-raw '{ "fileReference": { "link": "http://10.1.20.4/root/as3-waf/-/raw/master/policy-api.json" }, "policy": { "fullPath":"/Common/policy-api-arcadia" } }' 2. Check the IMPORT Check if the IMPORT worked. To do so, run the next call. curl --location --request GET 'https://10.1.1.12/mgmt/tm/asm/tasks/import-policy/' \ --header 'Authorization: Basic YWRtaW46YWRtaW4=' \ You should see a 200 OK, with the content below (truncated in this example). Please notice the "status":"COMPLETED". { "kind": "tm:asm:tasks:import-policy:import-policy-taskcollectionstate", "selfLink": "https://localhost/mgmt/tm/asm/tasks/import-policy?ver=16.0.0", "totalItems": 11, "items": [ { "isBase64": false, "executionStartTime": "2020-07-21T15:50:22Z", "status": "COMPLETED", "lastUpdateMicros": 1.595346627e+15, "getPolicyAttributesOnly": false, ... From now, your policy is imported and created in the BIG-IP. You can assign it to a VS as usual (Imperative Call or AS3 Call). But in the next session, I will show you how to create a Service with AS3 including the WAF policy. 3. APPLY the policy As you may know, a WAF policy needs to be applied after each change. This is the call. curl --location --request POST 'https://10.1.1.12/mgmt/tm/asm/tasks/apply-policy/' \ --header 'Content-Type: application/json' \ --header 'Authorization: Basic YWRtaW46YWRtaW4=' \ --data-raw '{"policy":{"fullPath":"/Common/policy-api-arcadia"}}' 4. OpenAPI spec file IMPORT As you know, Adv. WAF supports OpenAPI spec (2.0 and 3.0). Now, with the declarative WAF, we can import the OAS file as well. The BEST solution, is to PULL the OAS file from a repo. And in most of the customer' projects, it will be the case. In the example below, the OAS file is hosted in SwaggerHub (Github for Swagger files). But the file could reside in a private Gitlab repo for instance. The URL of the project is : https://app.swaggerhub.com/apis/F5EMEASSA/Arcadia-OAS3/1.0.0-oas3 The URL of the OAS file is : https://api.swaggerhub.com/apis/F5EMEASSA/Arcadia-OAS3/1.0.0-oas3 This swagger file (OpenAPI 3.0 Spec file) includes all the application URL and parameters. What's more, it includes the documentation (for NGINX APIm Dev Portal). Now, it is pretty easy to create a WAF JSON Policy with API Security template, referring to the OAS file. Below, you can notice the new section "open-api-files" with the link reference to SwaggerHub. And the new template POLICY_TEMPLATE_API_SECURITY. Now, when I upload / import and apply the policy, Adv. WAF will download the OAS file from SwaggerHub and create the policy based on API_Security template. { "policy": { "name": "policy-api-arcadia", "description": "Arcadia API", "template": { "name": "POLICY_TEMPLATE_API_SECURITY" }, "enforcementMode": "blocking", "server-technologies": [ { "serverTechnologyName": "MySQL" }, { "serverTechnologyName": "Unix/Linux" }, { "serverTechnologyName": "MongoDB" } ], "signature-settings": { "signatureStaging": false }, "policy-builder": { "learnOnlyFromNonBotTraffic": false }, "open-api-files": [ { "link": "https://api.swaggerhub.com/apis/F5EMEASSA/Arcadia-OAS3/1.0.0-oas3" } ] } } 5. AS3 declaration Now, it is time to learn how we can do all of these steps in one call with AS3 (3.18 minimum). The documentation is here : https://clouddocs.f5.com/products/extensions/f5-appsvcs-extension/latest/declarations/application-security.html?highlight=waf_policy#virtual-service-referencing-an-external-security-policy With this AS3 declaration, we: Import the WAF policy from a external repo Import the Swagger file (if the WAF policy refers to an OAS file) from an external repo Create the service { "class": "AS3", "action": "deploy", "persist": true, "declaration": { "class": "ADC", "schemaVersion": "3.2.0", "id": "Prod_API_AS3", "API-Prod": { "class": "Tenant", "defaultRouteDomain": 0, "API": { "class": "Application", "template": "generic", "VS_API": { "class": "Service_HTTPS", "remark": "Accepts HTTPS/TLS connections on port 443", "virtualAddresses": ["10.1.10.27"], "redirect80": false, "pool": "pool_NGINX_API_AS3", "policyWAF": { "use": "Arcadia_WAF_API_policy" }, "securityLogProfiles": [{ "bigip": "/Common/Log all requests" }], "profileTCP": { "egress": "wan", "ingress": { "use": "TCP_Profile" } }, "profileHTTP": { "use": "custom_http_profile" }, "serverTLS": { "bigip": "/Common/arcadia_client_ssl" } }, "Arcadia_WAF_API_policy": { "class": "WAF_Policy", "url": "http://10.1.20.4/root/as3-waf-api/-/raw/master/policy-api.json", "ignoreChanges": true }, "pool_NGINX_API_AS3": { "class": "Pool", "monitors": ["http"], "members": [{ "servicePort": 8080, "serverAddresses": ["10.1.20.9"] }] }, "custom_http_profile": { "class": "HTTP_Profile", "xForwardedFor": true }, "TCP_Profile": { "class": "TCP_Profile", "idleTimeout": 60 } } } } } 6. CI/CID integration As you can notice, it is very easy to create a service with a WAF policy pulled from an external repo. So, it is easy to integrate these calls (or the AS3 call) into a CI/CD pipeline. Below, an Ansible playbook example. This playbook run the AS3 call above. That's it :) --- - hosts: bigip connection: local gather_facts: false vars: my_admin: "admin" my_password: "admin" bigip: "10.1.1.12" tasks: - name: Deploy AS3 WebApp uri: url: "https://{{ bigip }}/mgmt/shared/appsvcs/declare" method: POST headers: "Content-Type": "application/json" "Authorization": "Basic YWRtaW46YWRtaW4=" body: "{{ lookup('file','as3.json') }}" body_format: json validate_certs: no status_code: 200 7. FIND the Policy-ID When the policy is created, a Policy-ID is assigned. By default, this ID doesn't appear anywhere. Neither in the GUI, nor in the response after the creation. You have to calculate it or ask for it. This ID is required for several actions in a CI/CD pipeline. 7.1 Calculate the Policy-ID We created this python script to calculate the Policy-ID. It is an hash from the Policy name (including the partition). For the previous created policy named "/Common/policy-api-arcadia", the policy ID is "Ar5wrwmFRroUYsMA6DuxlQ" Paste this python code in a new waf-policy-id.py file, and run the command python waf-policy-id.py "/Common/policy-api-arcadia" Outcome will be The Policy-ID for /Common/policy-api-arcadia is: Ar5wrwmFRroUYsMA6DuxlQ #!/usr/bin/python from hashlib import md5 import base64 import sys pname = sys.argv[1] print 'The Policy-ID for', sys.argv[1], 'is:', base64.b64encode(md5(pname.encode()).digest()).replace("=", "") 7.2 Retrieve the Policy-ID and fullPath with a REST API call Make this call below, and you will see in the response, all the policy creations. Find yours and collect the PolicyReference directive. The Policy-ID is in the link value "link": "https://localhost/mgmt/tm/asm/policies/Ar5wrwmFRroUYsMA6DuxlQ?ver=16.0.0" You can see as well, at the end of the definition, the "fileReference" referring to the JSON file pulled by the BIG-IP. And please notice the "fullPath", required if you want to update your policy curl --location --request GET 'https://10.1.1.12/mgmt/tm/asm/tasks/import-policy/' \ --header 'Content-Range: 0-601/601' \ --header 'Authorization: Basic YWRtaW46YWRtaW4=' \ { "isBase64": false, "executionStartTime": "2020-07-22T11:23:42Z", "status": "COMPLETED", "lastUpdateMicros": 1.595417027e+15, "getPolicyAttributesOnly": false, "kind": "tm:asm:tasks:import-policy:import-policy-taskstate", "selfLink": "https://localhost/mgmt/tm/asm/tasks/import-policy/B45J0ySjSJ9y9fsPZ2JNvA?ver=16.0.0", "filename": "", "policyReference": { "link": "https://localhost/mgmt/tm/asm/policies/Ar5wrwmFRroUYsMA6DuxlQ?ver=16.0.0", "fullPath": "/Common/policy-api-arcadia" }, "endTime": "2020-07-22T11:23:47Z", "startTime": "2020-07-22T11:23:42Z", "id": "B45J0ySjSJ9y9fsPZ2JNvA", "retainInheritanceSettings": false, "result": { "policyReference": { "link": "https://localhost/mgmt/tm/asm/policies/Ar5wrwmFRroUYsMA6DuxlQ?ver=16.0.0", "fullPath": "/Common/policy-api-arcadia" }, "message": "The operation was completed successfully. The security policy name is '/Common/policy-api-arcadia'. " }, "fileReference": { "link": "http://10.1.20.4/root/as3-waf/-/raw/master/policy-api.json" } }, 8 UPDATE an existing policy It is pretty easy to update the WAF policy from a new JSON file version. To do so, collect from the previous call 7.2 Retrieve the Policy-ID and fullPath with a REST API call the "Policy" and "fullPath" directive. This is the path of the Policy in the BIG-IP. Then run the call below, same as 1.2 PULL JSON file from a repository, but add the Policy and fullPath directives Don't forget to APPLY this new version of the policy 3. APPLY the policy curl --location --request POST 'https://10.1.1.12/mgmt/tm/asm/tasks/import-policy/' \ --header 'Content-Type: application/json' \ --header 'Authorization: Basic YWRtaW46YWRtaW4=' \ --data-raw '{ "fileReference": { "link": "http://10.1.20.4/root/as3-waf/-/raw/master/policy-api.json" }, "policy": { "fullPath":"/Common/policy-api-arcadia" } }' TIP : this call, above, can be used in place of the FIRST call when we created the policy "1.2 PULL JSON file from a repository". But be careful, the fullPath is the name set in the JSON policy file. The 2 values need to match: "name": "policy-api-arcadia" in the JSON Policy file pulled by the BIG-IP "policy":"fullPath" in the POST call 9 Video demonstration In order to help you to understand how it looks with the BIG-IP, I created this video covering 4 topics explained in this article : The JSON WAF policy Pull the policy from a remote repository Update the WAF policy with a new version of the declarative JSON file Deploy a full service with AS3 and Declarative WAF policy At the end of this video, you will be able to adapt the REST Declarative API calls to your infrastructure, in order to deploy protected services with your CI/CD pipelines. Direct link to the video on DevCentral YouTube channel : https://youtu.be/EDvVwlwEFRwF5 Roles required for Catalog Items
Having difficulty mapping required roles for a group to have proper access to catalog items. If I create a group call Security-Team and I want them to manage the security like WAF (Web App * API Protection) and Bot Defense, Web App Scanning and whatever else the Security Team should be monitoring to keep our environment safe. What Roles are required for management? They don't need access to everything, just what is required for the application security. Then we have a group called Support-Teams that need ReadOnly access to everything so they can log into F5 XC and just view everything with no ability to make changes. Not sure what Roles would get assigned to this group. Both scenarios let's assume all namespaces. Any help or direction is most appreciated.Introducing F5 Distributed Cloud Web App Scanning
F5 Distributed Cloud Web App Scanning is a powerful and proactive solution for discovering security vulnerabilities in web applications and APIs across distributed and dynamic environments. With its automation, scalability, detailed reporting, and seamless integration into the broader F5 security ecosystem, it’s a valuable tool for safeguarding modern applications from vulnerabilities and ensuring compliance with regulatory standards.
Introducing AI Assistant for F5 Distributed Cloud, F5 NGINX One and BIG-IP
This article is an introduction to AI Assistant and shows how it improves SecOps and NetOps speed across all F5 platforms (Distributed Cloud, NGINX One and BIG-IP) , by solving the complexities around configuration, analytics, log interpretation and scripting.
Can I use XC as a TCP proxy and DDoS Protection?
Hello, experts! I’m a longtime BIG-IP user but a complete newbie to XC. I have a task and would love some guidance on the best way to approach it. The goal is to use XC as a TCP proxy and for DDoS protection. The scenario: A client has a distributed network of ATMs that connect to a server. XC should sit in front of the server as a TCP proxy. The requests come in via IP. A few questions: Which XC product should I use for this? TCP Load Balancer requires requests to come via a domain name, correct? Would I need a dedicated IP from XC in this case? Can DDoS protection be applied in this setup? Am I thinking about this correctly? Any insights or recommendations would be greatly appreciated!Acronyms
Acronyms, are used all the time and the author /presentor is usually convinced that everyone in the audience understands what they mean, but every once in a while you hear or read something that you are not sure of the meaning. We are all professionals, that do not want to look like we are the only one in the room who does not know. So after hearing a talk or reading an article we often find ourselves looking it up; this can become confusing because acronyms mean different things when we search outside our field. For example CE what does it mean? The letters "CE" are the abbreviation of French phrase "Conformité Européene" which literally means "European Conformity". In the dictionary you will probably find CE meaning Common Era or Christian Era. When looking for a more modern meaning, we will find it may mean Consumer Electronics. But here in our community, when someone writes CE, they mean Customer Edge. Here, you have, at your fingertips a list of acronyms, unconfused with other fields. Please let me know if I missed any acronyms so I can add them to our list. A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z | A ACL - Access Control List ADC - Application Delivery Controller ADN - Application delivery network ADO - Application Delivery Optimization ALG - Application Layer Gateway AI - Artificial Intelligence AJAX - Asynchronous JavaScript and XML API - Application Programming Interface APM - Access Policy Manager ASM - Application Security Manager (F5’s Application Security Manager™ ASM is also known as BD) AWAF - Advanced Web Application Firewall AWS - Amazon Web Services B BaDos - Behaviour AniDDoS (Behaviour AniDDoS, an F5 product that is used against DDoS) BDM -- Business Decision Maker BGP - Border Gateway Protocol BOO - Build Once Only C CDN - Content Delivery Network CE - Customer Edge CGNAT - Carrier Grade NAT CIA triad - Confidentiality, Integrity,Availability (triad Security model) CIFS - Common Internet file system CRS - Core RuleSet CRUD - Create , Read, Update, Delete CSRF - Cross-Site Request Forgery, also known as XSRF CUPS - Control Plane and User Plane Separation CVE - Common Vulnerabilities and exposures CVSS - Common Vulnerability Scoring System D DAP - Digital Adoption Plateform DAST - Dynamic testing. (Examples of such tools Qualys and Nessus) DB - Database DC - Direct Communication / Direct Connect DDoS - Distributed Denial-of-Service DGW - Default Gateway Weight Settings Protocol (DGW) DHCP - Dynamic Host Configuration Protocol DIO - Distribution Initiated Opportunity DLP - Data Loss Protection DMZ - Demilitarized Zone [Demilitarized Zone DNS - Domain Name System DoH - DNS over HTTP DoT - DNS over TLS DPIAs - Data Protection Impact Assessment DRP - Disaster Recovery Plan DSR - Data Subject Rights E ELA - Enterprise License Agreement EDPB - European Data Protection Board EDR - Endpoint Detection and Response EPP - Endpoint Protection Platforms EUSA - End User Software Agreement F FIPS - Federal Information Processing Standards FPGA - field-programmable gate array FQDN - Fully Qualified Domain Name FRR - FRRouting G GDPR - General Data Protection Regulations GKE - Google Kubernetes Engine GPU - Graphic Processing Unit GSLB - Volterra’s Global Load Balancing gRPC - Google Remote Procedure Call H HIPAA - Health Insurance Portability & Accountability Act HMAC -Hash-based message authentication HSL - High-Speed Logging HTTP - Hypertext Transfer HTTPS - Hypertext Transfer Protocol I IANA - Internet Assigned Numbers Authority IBD - Integrated Bot Defense ICO - Information Commission Office IDS - Intrusion Detection System IIoT - Industrial Internet of Things ILM - Information Lifecycle Management IoT - Internet of Things IPAM - IP Address Management IPSec - Internet Protocol Security IR - Incidence Response ISO - Standardization Organization ISP - Internet Service Provider J JS - Javascript K KMS - Key Management Service / Key Management System KPI - Key Performance Indicator KV - Key Value k8s - Kubernetics L L7 - Layer 7 - The application layer LB - Load Balancer LBaaS - Load Balancing as a Service LDAP -Lightweight Directory Access Protocol LFI - Local File Exclusion attack LTM - Local Traffic Manager M MAM - Mobile Application Management MDM - Mobile Device Management MFA - Multi-Factor Authentication MitM - Man in the Middle ML - Machine Learning MSA - Master Service Agreement MSP - Managed Service Provider MT - Managed Tenant mTLS - Mutual Transport Layer Security MUD - Malicious User Detection MUM - Malicious User Mitigation N NAP - Network access point NAS - Network-Attached Storage NAT - Network Address Translation NIC - NetworkInterface Cards NFV - Network functions NFVI - Network functions virtualization NPU - Network Processing Units O OAS - OpenAPI Specification (Swagger) OPA - Open Policy Agent OT - Original Tenant OWASP - Open Web Application Security Project P PAAS - Platform as a service (PaaS PBD - Proactive Bot Defence. PCI DSS - Payment Card Industry Data Security Standard. PBD - Privacy by Design PE - Portable executable PFS - Perfect Forward Secrecy PIA - Privacy Impact Assessments PII - Personally identifiable information POP - Point of Presence Q QoS - Quality of Service R RBAC - Role based Access control RCE - Remote Code Execution RDP - Remote Desktop Protocol RE - Routing Engine, Regional Edges REST - Representational State Transfer *[[Rest API -Representational State Transfer]]* RFI - Request For Information OR Remote File Inclusion vulnerability attack RFP - Request for Proposal RPC - Remote Procedure Call RSA – (Rivest–Shamir–Adleman) is a public-key cryptosystem RTT - Round Trip Time S SAM - Security Accounts Manager SAML - Security Assertion Markup Language SCIM - System for Cross-domain Identity Management SCP - Secure Copy Protocol SCP - Server Communication Proxy SDC - F5 Security and Distributed Cloud SDK - Software Development Kit SDN - Software Defined Network SE - Solutions Engineer SIEM - Security Information & Event Management SLA - Service Level Availability SLED -State,Local Government and Education SLI - Service Level Indicator SNAT - Source Network Address Translation SOC - Security Operations Center SP - Service Provider SPK - Service Proxy for Kubernetes SRE - Site reliability engineering SRT - Security Research Team at F5 SSD - Solid State Drive SSL - Secure Sockets Layer SSO - Single Sign On SSRF - Server-side request forgery STRIDE - Spoofing, Tampering,Repudiation,Information Leakage, Denial of Service, Elevation of Privilege (a TMA Model) T TCL - Tool Command Language TCP - [Transmission Control Protocol TDM - Technical Decision Maker TLS - Transport layer Security TMA - Threat Model Assessment TO - Tenant Owner TOCTOU - Time of Check vs Time of Use TOI - Transfer of Information TTFB - Time to First Bit TTL - Time to Live U UAM - User Access Management UI - User Interface URI - Uniform Resource URL - Uniform Resource Locator UX - User Experience V VER - Volterra Edge Router VES - Volterra Edge Services VIF - virtual interface VIP - Virtual IP address VM - Virtual Machine Vnet - Virtual network VPC - Virtual Private Cloud VPN - Virtual Private Network VRS - Volterra Rules Set W WAAP - Web Application& API Protection WAF - Web application firewall WPA3 - Wi-Fi Alliance Access 3 X XML - Extensible Markup Language [XML - Wikipedia](https://en.wikipedia.org/wiki/XML) XSS - Cross Site Scripting XSRF - Cross-Site Request Forgery, also known as CSRF Y Z ZTNA -Zero Trust Network Access ZTP - Zero-Touch Provisioning ZTS - Zero Trust Security
F5 XC articles published in the Technical Article section lately March 7 , 2023
Here is a list of the F5 XC articles that were published lately on DevCentral in the Technical Articles section. If you find them useful, please give a Kudo. We appreciate it and we know the author would as well. F5 Hybrid Security Architectures (Part 1 - F5's Distributed Cloud WAF and BIG-IP Advanced WAF) F5 Hybrid Security Architectures (Part 2 - F5's Distributed Cloud WAF and NGINX App Protect WAF) End-to-End Fraud and Risk Detection with F5 Distributed Cloud Silverline DDoS capabilities are now available in F5 Distributed Cloud Using F5 Distributed Cloud AppStack & CE Site Survivability Easily Protect Your Applications from DDoS with F5 Distributed Cloud DDoS Auto-Mitigation Mitigation of OWASP API6: 2019 Mass Assignment vulnerability using F5 Distributed Cloud Platform Overview of Trusted Client IP Headers in F5 Distributed Cloud Platform Demo Guide & Video Series for F5 Distributed Cloud Network Connect (Multi-Cloud Networking) Prevention of OWASP API Security API2:2019 Broken Authentication using F5 Distributed Cloud Platform Mitigating OWASP Web App Top 10 2021 : A08-Software and Data Integrity Failures using F5 XC Platform Egress control for Kubernetes using F5 Distributed Cloud Services Comprehensive solution for OWASP Web App A09:2021 Security Logging & Monitoring Failures from F5 XC How To Protect Your Applications from Cross Site Request Forgery (CSRF) with F5 Distributed Cloud Bot Defense for Mobile Apps in XC WAAP Part 1: The Bot Defense Mobile SDK Deploy High-Availability and Latency-sensitive workloads with F5 Distributed Cloud Mitigation of OWASP Web Application Top 10 2021 A04:2021-Insecure Design using F5 XC platform
