Introduction to BIG-IP SSL Orchestrator
Demo Video What is SSL Orchestrator? F5 BIG-IP SSL Orchestrator is designed and purpose-built to enhance SSL/TLS infrastructure, provide security solutions with visibility into SSL/TLS encrypted traffic, and optimize and maximize your existing security investments. BIG-IP SSL Orchestrator delivers dynamic service chaining and policy-based traffic steering, applying context-based intelligence to encrypted traffic handling to allow you to intelligently manage the flow of encrypted traffic across your entire security stack, ensuring optimal availability. Designed to easily integrate with existing architectures and to centrally manage the SSL/TLS decrypt/re-encrypt function, BIG-IP SSL Orchestrator delivers the latest SSL/ TLS encryption technologies across your entire security infrastructure. With BIG-IP SSL Orchestrator’s high-performance encryption and decryption capabilities, your organization can quickly discover hidden threats and prevent attacks at multiple stages, leveraging your existing security solutions. BIG-IP SSL Orchestrator ensures encrypted traffic can be decrypted, inspected by security controls, then re-encrypted—delivering enhanced visibility to mitigate threats traversing the network. As a result, you can maximize your security services investment for malware, data loss prevention (DLP), ransomware, and NGFWs, thereby preventing inbound and outbound threats, including exploitation, callback, and data exfiltration. Why is this important? Offload your SSL decryption compute resources to F5. Let F5 handle all the decrypt/encrypt functions so your security tools don’t have to. This will increase the performance capabilities of your existing security solutions. Easily create policy to bypass decryption of sensitive traffic like Banking, Finance and Healthcare related websites. Improve high availability by leveraging SSL Orchestrator to distribute load among a group of security devices, like Next Generation Firewalls. A comprehensive SSL decryption solution gives you much-needed visibility into encrypted traffic, which enables you to block encrypted threats. SSL Orchestrator integrates with your existing infrastructure An SSL Orchestrator “Service” is defined as a device that SSL Orchestrator passes decrypted traffic to. A Service can be Layer 2 or 3. It can be unidirectional (TAP). It can be an ICAP server. It can be an Explicit or Transparent HTTP proxy. A Layer 2 device (bridging/bump-in-wire) refers to connectivity without IP Address configuration. Layer 2 devices pass all traffic from one interface to another interface. A Layer 3 device (typical NAT) refers to IP Address to IP Address connectivity. Layer 3 devices must be specifically configured to work on a network. An Explicit Proxy device also utilizes IP Address to IP Address connectivity. However, in this case, web applications have to be specifically configured to use an Explicit Proxy. A Transparent Proxy device also utilizes IP Address to IP Address connectivity. In this case, web applications DO NOT need to be configured to use a Proxy. Other type of devices are supported, like an ICAP server or TAP device. An ICAP server is often used for Data Loss Prevention (DLP). A TAP device is often used for passive visibility as it receives an exact copy of decrypted traffic. Service Chains Service Chains are user-defined groupings of one or more Services. Multiple Service Chains are supported by Policy (see next section). There are no restrictions on the type of Services that can be in a Service Chain. For example: a Service Chain can consist of one or more Layer 2 devices, and one or more Layer 3 devices, and so on. Policy SSL Orchestrator supports a flexible policy editor that is used to determines what type of traffic to send or not to send to a Service Chain. For example: in the case of an Outbound (see next section) configuration, certain content can bypass SSL Decryption based on URL Categories like Banking, Finance and Healthcare. Topologies A Topology defines how SSL Orchestrator will be interested into your traffic flow. It is defined as either Incoming or Outgoing. High-level parameters for how/what to intercept are defined here. In an Inbound Topology, traffic comes from users on the internet to access an application like mobile banking or shopping. This may also be referred to as a reverse proxy. In an Outbound Topology, traffic comes from users on your network to access sites/applications on the internet. For example: a person who works at Apple HQ who is accessing the internet using the company’s network. This may also be referred to as a forward proxy. Conclusion F5 BIG-IP SSL Orchestrator simplifies and accelerates the deployment of SSL visibility and orchestration services. Whether for modern, custom, or classic apps, and regardless of their location—be it on premises, in the cloud, or at the edge—BIG-IP SSL Orchestrator is built to handle today’s dynamic app landscape. Related Articles Integrating Security Solutions with F5 BIG-IP SSL Orchestrator
Integrating Security Solutions with F5 BIG-IP SSL Orchestrator
What are Security Services? SSL Orchestrator supports a wide variety of Security Services. A “Service” is defined as a device that SSL Orchestrator passes decrypted traffic to. A Service can be Layer 2 or 3. It can be unidirectional (TAP). It can be an ICAP server. It can be an Explicit or Transparent HTTP proxy. Security Services need to inspect content that is not encrypted. SSL Orchestrator handles the decryption so the Service can inspect it for threats, enforce certain policies, prevent sensitive data from leaving the network and much more. A Next Generation Firewall, or NGFW, is a common Service type. A NGFW is a network security device that extends traditional firewall capabilities by incorporating features like deep packet inspection, intrusion prevention, and application control to protect against advanced cyber threats. A NGFW is commonly deployed as a Layer 2 or 3 device. A sandbox is another common Service type. Sandboxes look for malware and other threats by analyzing potentially malicious content in a controlled environment. A sandbox is a secure, isolated environment where suspicious code or applications can be executed and observed without the risk of infecting the host or network. A Sandbox is commonly deployed as a Layer 2 device. A Secure Web Gateway (SWG) is a network security solution that acts as a central point of control for all web traffic, filtering and inspecting it to protect against malware, phishing, and other web-based threats, while enforcing security policies. This solution has evolved over the years and may also be referred to as a Secure Access Service Edge (SASE) or Security Service Edge (SSE). A SWG is often deployed as an HTTP Proxy. Data Loss Prevention (DLP) is a cybersecurity solution designed to prevent the unauthorized access, use, or transmission of sensitive data. DLP is often deployed as an ICAP server. A network TAP device is a passive component that allows non-intrusive access to data flowing across a network, enabling monitoring and analysis of network traffic without disruption. A TAP receives a copy of the decrypted traffic so it can analyze it in the background. An HTTP proxy is commonly used as a SWG solution but is flexible and can be used for other purposes. An HTTP proxy may be used to cache web content, authenticate users and log all connections. An HTTP proxy may also be used for what is called “Web Isolation” or “Browser Isolation”. This security solution acts as an intermediary between users and web content. Offering a virtualized “view” of web content that is completely safe to users and the network itself. Which vendors or products? SSL Orchestrator supports all leading NGFW vendors and has generic support for any NGFW that is not specifically supported. Vendors/products supported include Palo Alto Networks NGFW, Check Point Security, Cisco Firepower, Fortinet FortiGate, McAfee/Trellix, Trend Micro and more. SSL Orchestrator also supports all leading Sandbox vendors and has generic support for any Sandbox that is not specifically supported. Vendors/products supported include FireEye/Trellix, Symantec and more. Most Secure Web Gateway (SWG) solutions are supported by SSL Orchestrator. Vendors/products supported include Cisco WSA, Forcepoint, Fortinet, McAfee/Trellix, Symantec/Broadcom ProxySG and many more. SSL Orchestrator supports all leading Data Loss Prevention (DLP) vendors and has generic support for any DLP solution that is not specifically supported. Vendors/products supported include Digital Guardian, McAfee/Trellix, Opswat, Symantec/Broadcom and more. Some of the TAP vendors supported by SSL Orchestrator are Palo Alto, McAfee/Trellix, RSA Netwitness, Trend Micro and Netscout. SSL Orchestrator supports HTTP proxies from the following vendors: Cisco, Forcepoint, Fortinet, McAfee/Trellix, Symantec/Broadcom and Squid. Service Deployment type Services can be deployed in a variety of different ways. SSL Orchestrator supports most, if not all of these deployment types. The common deployments are listed and described below: A Layer 2 device (bridging/bump-in-wire) refers to connectivity without IP Address configuration. Layer 2 devices pass all traffic from one interface to another interface. A Layer 3 device (typical NAT) refers to IP Address to IP Address connectivity. Layer 3 devices must be specifically configured to work in a network. An Explicit Proxy device also utilizes IP Address to IP Address connectivity. However, in this case, web applications have to be specifically configured to use an Explicit Proxy. A Transparent Proxy device also utilizes IP Address to IP Address connectivity. In this case, web applications DO NOT need to be configured to use a Proxy. Other type of devices are supported, like an ICAP server or TAP device. An ICAP server is often used for Data Loss Prevention (DLP). A TAP device is often used for passive visibility as it receives an exact copy of the decrypted traffic. Service Creation Services can be added, removed or edited from the Services tab of the SSL Orchestrator configuration utility. Services are divided into the different Service deployment types. Layer 2 The following Layer 2 Services are available: Layer 3 The following Layer 3 Services are available: Inline HTTP The following Inline HTTP Services are available: ICAP The following ICAP Services are available: TAP The following TAP Services are available: F5 SSL Orchestrator also supports F5 Solutions as Services. The following F5 Services are available: Examples Here’s an example of a Cisco Firepower Service deployed in Layer 3 mode: An IP Address and VLAN are selected for connectivity to the Service. The IP Address of the Cisco Firepower is specified. An IP Address and VLAN are selected for connectivity from the Service. Here’s an example of a Palo Alto NGFW Service deployed in Layer 2 mode: A From and To VLAN is specified for connectivity from/to the Service. Note: IP addressing is not used with a Layer 2 Service Here’s an example of an Opswat MetaDefender ICAP Service: An IP Address and port are specified for connectivity To/From the ICAP server. Some ICAP server specific settings are also needed. Here’s an example of a Netscout TAP Service: The mac address of the Netscout is specified. The VLAN and interface for connectivity to the Netscout is also specified. Creating a Service Chain Service Chains are user-defined groupings of one or more Services. Multiple Service Chains are supported. There are no restrictions on the type of Services that can be in a Service Chain. For example: a Service Chain can consist of one or more Layer 2 devices, and one or more Layer 3 devices, and so on. Service Chains can be added, removed or edited from the Service Chains tab of the SSL Orchestrator configuration utility. Available Services will be listed on the left. One or more Services can be moved into the Service Chain. The Service Chain Order is easily configurable. Demo Video Conclusion F5 BIG-IP SSL Orchestrator makes it easy to simplify and deploy your security stack. SSL Orchestrator supports virtually all available security and visibility solutions. It is able to seamlessly integrate security solutions whether they are deployed as Layer 2, Layer 3, Inline HTTP, ICAP or TAP. Related Articles Introduction to BIG-IP SSL Orchestrator
DNS Request to VS?
Hello, we found on our Firewall lots of DNS-Requests from the floating IP to some VS (with ASM-Policy). Now we want the Firewall to only allow DNS-Requests to the known DNS-Servers. Question: is this normal behaviour? The BIGIP has DNS-Resolver configured. Where can I check the Config-Utility? Thanks for any hint. KarlGuide for exam 402 F5 Certified Solution Expert
I passed exam 402 F5 Certified Solution Expert, I would like to share guide for prepare to exam this certificate, First you have to review blueprint about exam topic from F5: https://techdocs.f5.com/dam/f5/kb/global/solutions/k29900360/402_-_Cloud_Solutions.pdf 1. Information about license https://my.f5.com/manage/s/article/K14810 https://clouddocs.f5.com/cloud/public/v1/matrix.html https://clouddocs.f5.com/cloud/public/v1/licensing/licensing.html https://wtit.com/f5-good-better-best-licenses/ 2. F5 instance type on microsoft azure and AWS 3. Strategy migration application to cloud https://aws.amazon.com/blogs/enterprise-strategy/6-strategies-for-migrating-applications-to-the-cloud/ 4. Learning about HTTP method for API and API concept https://community.f5.com/kb/technicalarticles/wils-the-data-center-api-compass-rose/283999 5. About cloud provide object https://clouddocs.f5.com/cloud/public/v1/aws_index.html https://clouddocs.f5.com/cloud/public/v1/azure_index.html 6. Cloud concept and automation
Mutual TSL Between Two BigIPs
Hello, I am trying to determine how Mutual TLS (mTLS) can be implemented between 2 Big IPs for API calls. The certificates will reside on the two BigIPs where the authentication will occur. The objective is to isolate the applications such that no changes are required to the applications or certs need to be loaded exchanged between the apps and the Big IP. Based a several AI searches, this is possible but haven't been able to find explicit documentation on if it is supported and how it can be implemented. Any help is appreciated. Client App --> BigIP 1 -mTLS- Big IP 2 --> Server AppModern Applications-Demystifying Ingress solutions flavors
In this article, we explore the different ingress services provided by F5 and how those solutions fit within our environment. With different ingress services flavors, you gain the ability to interact with your microservices at different points, allowing for flexible, secure deployment. The ingress services tools can be summarized into two main categories, Management plane: NGINX One BIG-IP CIS Traffic plane: NGINX Ingress Controller / Plus / App Protect / Service Mesh BIG-IP Next for Kubernetes Cloud Native Functions (CNFs) Ingress controller F5 Distributed Cloud Customer Edge (CE) Ingress solutions definitions In this section we go quickly through the Ingress services to understand the concept for each service, and then later move to the use cases’ comparison. BIG-IP Next for Kubernetes Kubernetes' native networking architecture does not inherently support multi-network integration or non-HTTP/HTTPS protocols, creating operational and security challenges for complex deployments. BIG-IP Next for Kubernetes addresses these limitations by centralizing ingress and egress traffic control, aligning with Kubernetes design principles to integrate with existing security frameworks and broader network infrastructure. This reduces operational overhead by consolidating cross-network traffic management into a unified ingress/egress point, eliminating the need for multiple external firewalls that traditionally require isolated configuration. The solution enables zero-trust security models through granular policy enforcement and provides robust threat mitigation, including DDoS protection, by replacing fragmented security measures with a centralized architecture. Additionally, BIG-IP Next supports 5G Core deployments by managing North/South traffic flows in containerized environments, facilitating use cases such as network slicing and multi-access edge computing (MEC). These capabilities enable dynamic resource allocation aligned with application-specific or customer-driven requirements, ensuring scalable, secure connectivity for next-generation 5G consumer and enterprise solutions while maintaining compatibility with existing network and security ecosystems. Cloud Native Functions (CNFs) BIG-IP Next for Kubernetes enables the advanced networking, traffic management and security functionalities; CNFs enables additional advanced services. VNFs and CNFs can be consolidated in the S/Gi-LAN or the N6 LAN in 5G networks. A consolidated approach results in simpler management and operation, reduced operational costs up to reduced TCO by 60% and more opportunities to monetize functions and services. Functions can include DNS, Edge Firewall, DDoS, Policy Enforcer, and more. BIG-IP Next CNFs provide scalable, automated, resilient, manageable, and observable cloud-native functions and applications. Support dynamic elasticity, occupy a smaller footprint with fast restart, and use continuous deployment and automation principles. NGINX for Kubernetes NGINX is known for its great performance in microservices environments; NGINX takes care of service-level functionalities at the application level. The differentiator in case we need to deploy CNFs or NGINX for Kubernetes is the bandwidth and required internal service flows. While BIG-IP Next for Kubernetes/CNF make use of F5 own TMM to perform application delivery and security, NGINX rely on Kernel to perform some network level functions like NAT, IP tables and routing. So it’s a matter of the architecture of your environment to go with one or both options to enhance your application delivery and security experience. BIG-IP Container Ingress Services (CIS) BIG-IP CIS works on management flow. The CIS service is deployed at Kubernetes cluster, sending information on created Pods to an integrated BIG-IP external to Kubernetes environment. This allows to automatically create LTM pools and forwarding traffic based on pool members health. This service allows for application teams to focus on microservice development and automatically update BIG-IP, allowing for easier configuration management. Use cases categorization Let’s talk in use cases terms to make it more related to the field and our day-to-day work, NGINX One Access to NGINX commercial products, support for open-source, and the option to add WAF. Unified dashboard and APIs to discover and manage your NGINX instances. Identify and fix configuration errors quickly and easily with the NGINX One configuration recommendation engine. Quickly diagnose bottlenecks and act immediately with real-time performance monitoring across all NGINX instances. Enforce global security polices across diverse environments. Real-time vulnerability management identifies and addresses CVEs in NGINX instances. Visibility into compliance issues across diverse app ecosystems. Update groups of NGINX systems simultaneously with a single configuration file change. Unified view of your NGINX fleet for collaboration, performance tuning, and troubleshooting. NGINX One to automate manual configuration and updating tasks for security and platform teams. BIG-IP CIS Enable self-service Ingress HTTP routing and app services selection by subscribing to events to automatically configure performance, routing, and security services on BIG-IP. Integrate with the BIG-IP platform to scale apps for availability and enable app services insertion. In addition, integrate with the BIG-IP system and NGINX for Ingress load balancing. BIG-IP Next for Kubernetes Supports ingress and egress traffic management and routing for seamless integration to multiple networks. Enables support for 4G and 5G protocols that are not supported by Kubernetes—such as Diameter, SIP, GTP, SCTP, and more. BIG-IP Next for Kubernetes enables security services applied at ingress and egress, such as firewalling and DDoS. Topology hiding at ingress obscures the internal structure within the cluster. As a central point of control, per-subscriber traffic visibility at ingress and egress allows traceability for compliance tracking and billing. Support for multi-tenancy and network isolation for AI applications, enabling efficient deployment of multiple users and workloads on a single AI infrastructure. F5 Cloud Native Functions (CNFs) Add containerized services for example Firewall, DDoS, and Intrusion Prevention System (IPS) technology Based on F5 BIG-IP AFM. Ease IPv6 migration and improve network scalability and security with IPv4 address management. Deploy as part of a security strategy. Support DNS Caching, DNS over HTTPS (DoH). Supports advanced policy and traffic management use cases. Improve QoE and ARPU with tools like traffic classification, video management and subscriber awareness. NGINX Ingress Controller Provide L4-L7 NGINX services within Kubernetes cluster. Manage user and service identities and authorize access and actions with HTTP Basic authentication, JSON Web Tokens (JWTs), OpenID Connect (OIDC), and role-based access control (RBAC). Secure incoming and outgoing communications through end-to-end encryption (SSL/TLS passthrough, TLS termination). Collect, monitor, and analyze data through prebuilt integrations with leading ecosystem tools, including OpenTelemetry, Grafana, Prometheus, and Jaeger. Ingress controller F5 Distributed Cloud Customer Edge (CE) The F5 Ingress Controller is supported only for Sites running Managed Kubernetes, also known as Physical K8s (PK8s). Deployment of the ingress controller is supported only using Helm. The Ingress Controller manages external access to HTTP services in a Kubernetes cluster using the F5 Distributed Cloud Services Platform. The ingress controller is a K8s deployment that configures the HTTP Load Balancer using the K8s ingress manifest file. The Ingress Controller automates the creation of load balancer and other required objects such as VIP, Layer 7 routes (path-based routing), advertise policy, certificate creation (k8s secrets or automatic custom certificate) Conclusion As you can see, the diverse Ingress controllers tools give you more flexibility, tailoring your architecture based on organization requirements and maintain application delivery and security practices across your applications ecosystem. Related Content and Technical demos BIG-IP Next SPK: a Kubernetes native ingress and egress gateway for Telco workloads F5 BIG-IP Next CNF solutions suite of Kubernetes native 5G Network Functions Announcing F5 NGINX Ingress Controller v4.0.0 | DevCentral JWT authorization with NGINX Ingress Controller My first CRD deployment with CIS | DevCentral BIG-IP Next for Kubernetes BIG-IP Next for Kubernetes (LA) BIG-IP Next Cloud-Native Network Functions (CNFs) CNF Home F5 NGINX Ingress Controller Overview of F5 BIG-IP Container Ingress Services NGINX OneVulnCon 2025, EU CRA, CVE funding, Smishing Kit
Notable security news for the week of April 13th through April 20th. Your editor this week is Chris from the F5 Security Incident Response Team. A bit of a different format this week as I was in Raleigh for VulnCon 2025 the previous week. I will discuss highlights from that as well as notable events from the past week. VulnCon 2025 The 2025 Vulnerability Management Ecosystem Collaboration, Ideation, and Action Conference (aka “VulnCon”), which was sponsored by FIRST and the CVE Program, was held from April 7th through April 10th this year. The aim of this conference is to promote collaboration between various vulnerability management and cybersecurity professionals to better help the whole cybersecurity ecosystem. Key topics that were highlighted this year were the EU's Cyber Resilience Act (CRA), Vulnerability Exploitability eXchange (VEX), Cybersecurity Assurance Framework (CSAF), and publishing more complete CVE records or Vulnrichment. I will discuss the CRA in the next paragraph. VEX facilitates the exchange of vulnerability information, fostering collaboration to swiftly address emerging threats. Concurrently, CSAF ensures a standardized approach to cybersecurity practices. One of the pushes that was discussed was to get security scanners to start ingesting VEX to help decrease the amount of false positives and focus more on vulnerabilities that are exploitable. As for Vulnrichment, it is alarming that a large number of CVEs that are disclosed every year do not include Common Weakness Enumerations (CWE) or Common Vulnerability Scoring System (CVSS) scores. I agree that adding this information at a minimum would be very beneficial to both the consumers as well as the vendor. The vendor is in the best position to assign these in a more accurate manner since they are most familiar with the products. https://www.first.org/conference/vulncon2025/ https://openssf.org/blog/2023/09/07/vdr-vex-openvex-and-csaf/ EU Cyber Resilience Act (CRA) The Cyber Resilience Act introduces mandatory cybersecurity requirements for hardware and software products, throughout their whole lifecycle. The main goals of this act are to ensure that products with digital elements placed on the EU market have fewer vulnerabilities that Manufacturers remain responsible for cybersecurity throughout a product’s life cycle, improve transparency on security of hardware and software products and bring benefits to business users and consumers from better protection. Products will bear the CE marking as is common with many other products sold, which means they have been assessed to meet high safety, health, and environmental protection requirements. The three main roles that are laid out are: Manufacturers: If you develop or manufacture products with "digital elements" for sale in the EU. Open-Source Software (OSS) Stewards: Entity other than a manufacturer that provides support on a sustained basis for the development of specific products with digital elements, qualifying as free and open-source software and intended for commercial activities, and that ensures the viability of those products. Examples of this would be the Linux Foundation, Apache Foundation, etc.... OSS Developers: Upstream maintainer or developer of open-source software that is used by the manufacturer. The key point to note in this distinction of these three roles is that if there is a vulnerability exploited in open-source software, the manufacturer is the one held liable. The OSS Steward and the OSS Developers are not being held liable. This makes it a good idea to develop working relationships with the OSS upstream developers for when emergencies do arise. Now to focus on the manufacturer requirements. I will not touch all of them as the CRA is a large document but will point out some of the key topics. Secure-By-Default and Secure-By-Design principles will now be a requirement and not just a pledge. Products with digital elements shall be delivered without any known exploitable vulnerabilities. Manufacturers will need to provide evidence that the product was checked before release. A risk assessment will need to be provided with the product and the contents of that assessment are laid out in Annex I of the document. Manufactures must be able to provide SBOMS in either SPDX or CycloneDX format at the request of authorities. Manufacturers must , address and remediate vulnerabilities without delay, which includes providing security updates. Manufacturers must provide support for a minimum of 5 years, including security updates and that each security update remains available after it has been issued for a minimum of 10 years or for the remainder of the support period, whichever is longer. There are also reporting requirements. Highlight a couple of them; they pertain to actively exploited vulnerabilities and severe incidents having an impact on the security of the product. An early warning notification of an actively exploited vulnerability or severe incident, without undue delay and in any event within 24 hours of the manufacturer becoming aware of it. Then "an incident notification, without undue delay and in any event within 72 hours of the manufacturer becoming aware of the incident, which shall provide general information, where available, about the nature of the incident, an initial assessment of the incident, as well as any corrective or mitigating measures taken, and corrective or mitigating measures that users can take, and which shall also indicate, where applicable, how sensitive the manufacturer considers the notified information to be". That was taken from the document and you can see how thorough they are being when detailing what to report. The final report will need to be submitted by 14 days for active exploits and one month for severe incidents. Then to explain where to report: "The notification shall be submitted using the electronic notification end-point of the CSIRT designated as coordinator of the Member State where the manufacturers have their main establishment in the Union and shall be simultaneously accessible to ENISA". This means that the manufacturer will need to choose one of the European country's CSIRT teams to be the point of contact. As for the consequences of non-compliance, the EU is not playing around with that either: Non-compliance with the essential cybersecurity requirements set out in Annex I and the obligations set out in Articles 13 and 14 shall be subject to administrative fines of up to EUR 15,000,000 or, if the offender is an undertaking, up to 2.5% of its total worldwide annual turnover for the preceding financial year, whichever is higher. Non-compliance with the obligations set out in Articles 18 to 23, Article 28, Article 30(1) to (4), Article 31(1) to (4), Article 32(1), (2) and (3), Article 33(5), and Articles 39, 41, 47, 49 and 53 shall be subject to administrative fines of up to EUR 10,000,000 or, if the offender is an undertaking, up to 2% of its total worldwide annual turnover for the preceding financial year, whichever is higher. The supply of incorrect, incomplete or misleading information to notified bodies and market surveillance authorities in reply to a request shall be subject to administrative fines of up to EUR 5,000,000 or, if the offender is an undertaking, up to 1% of its total worldwide annual turnover for the preceding financial year, whichever is higher. To explain those bullet points more simply, everything I mentioned above about manufacturer requirements and reporting all fall under Annex I or Articles 13 and 14 so would be subject to the most severe penalties per incident. As for the timelines of this act, the CRA was officially adopted on October 10, 2024, and entered into force on December 10, 2024. However, the CRA's main obligations will apply starting from December 11, 2027. Some earlier obligations will apply, such as the reporting of vulnerabilities and severe incidents, starting from September 11, 2026. Additionally, the rules on conformity assessment bodies will be applicable from June 11, 2026. https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act https://github.com/SecurityCRob/presentations/blob/main/CRA%20PSIRT%20TL_DR.pdf CVE Program Funding The Common Vulnerabilities and Exposures (CVE) program, managed by MITRE, was facing funding expiration on April 16, 2025. The program is essential for identifying and tracking security vulnerabilities in software and hardware. Without funding, the CVE program would stop adding new vulnerabilities, which could lead to significant impacts on national vulnerability databases, cybersecurity tools, incident response operations, and critical infrastructure. MITRE's Vice President Yosry Barsoum expressed hope that the government is making efforts to continue supporting the program. Luckily, the Department of Homeland Security's (DHS) Cybersecurity & Infrastructure Security Agency (CISA) was able to secure funding at the last moment, to fund the program for 11 more months. This is despite ongoing budget and staffing cuts to CISA by the current administration. The cybersecurity community has expressed concern over the potential loss of the CVE program, emphasizing its importance in standardizing vulnerability information and aiding in the timely patching of security flaws. On April 16, MITRE announced the creation of a non-profit entity called "The CVE Foundation" to continue the program's work under a new funding mechanism. https://krebsonsecurity.com/2025/04/funding-expires-for-key-cyber-vulnerability-database/ The CVE Foundation The CVE Foundation was launched to secure the future of the CVE Program. The CVE Foundation was formally established on April 16, 2025, to ensure the long-term viability, stability, and independence of the Common Vulnerabilities and Exposures (CVE) Program. The CVE Program has been a U.S. government-funded initiative for 25 years, raising concerns about sustainability and neutrality due to its reliance on a single government sponsor. MITRE notified the CVE Board on April 15, 2025, that the U.S. government would not renew its contract for managing the program. In response, a coalition of CVE Board members developed a strategy to transition CVE to a dedicated, non-profit foundation to continue delivering high-quality vulnerability identification. CVE identifiers and data are crucial for cybersecurity professionals worldwide, aiding in security tools, advisories, threat intelligence, and response. Going forward, the CVE Foundation aims to eliminate a single point of failure in the vulnerability management ecosystem and ensure the CVE Program remains globally trusted and community-driven. https://www.thecvefoundation.org/home Pay Your Tolls!! About 3 and a half years ago, I was driving into Denver on Interstate 70 coming from the East. I had no need to drive through Denver as I was heading north through Wyoming anyway. Well, a few miles before the city there was an offramp for E-470, a toll highway that would bypass Denver and connect to I-25 a few miles north of the city. I had never used a toll highway before since I live in Eastern Washington where they are unheard of. I was picturing a scene out of a movie where you pull up to a booth and pay an attendant. I was surprised as I merged onto the highway and everyone was driving at 60+ MPH. I saw a sign that stated the system used E-ZPass and would scan the license plate. Fast forward a few months and I receive a bill in the mail from E-ZPass, a pretty nice way to bypass driving through the middle of a large city, I thought. Now, unfortunately, a smishing campaign is targeting that same system to trick victims into giving them their payment information. Since mid-October 2024, multiple financially motivated threat actors have been using a smishing kit developed by "Wang Duo Yu" to target toll road users in eight U.S. states. The campaign impersonates U.S. electronic toll collection systems like E-ZPass, sending SMS messages and Apple iMessages about unpaid tolls, urging recipients to click on fake links. Victims are prompted to solve a fake CAPTCHA challenge and enter personal and financial information on fraudulent pages, which is then siphoned off to the threat actors. Wang Duo Yu, a computer science student in China, is alleged to be the creator of the phishing kits used by the Smishing Triad, a Chinese organized cybercrime group. The Smishing Triad has conducted large-scale smishing attacks targeting postal services in 121 countries, using failed package delivery lures to harvest personal and financial information. Services like Oak Tel facilitate smishing on a global scale, allowing cybercriminals to send bulk SMS and manage campaigns efficiently. I have personally received 2 or 3 of these over the past few months. Luckily, I know the one time I drove on a toll road, so it was obvious to me that this was fake. I worry about people that are using these systems more regularly that may fall victim. https://thehackernews.com/2025/04/chinese-smishing-kit-behind-widespread.htmlDriving Down Cost & Complexity: App Migration in the Cloud
Introduction The digital transformation journey for many organizations involves migrating applications to the cloud. This process, while beneficial, can be fraught with challenges related to cost, complexity, and security. This white paper aims to provide a comprehensive overview of how organizations can drive down costs and simplify the complexity of app migrations to the cloud, leveraging solutions from F5. The Pain of App Migrations App migrations are often driven by the need for cost optimization, meeting business requirements, and responding to external factors and market pressures. However, the process can be painful due to delays in internal processes, budget constraints, and the need for secure migrations without publicly advertising the app or its API endpoints. The app migration process can be divided into the following phases: Plan: Determine if a lift and shift or refactor is needed and estimate the time required 3 Prepare: Assess infrastructure, ensure compliance and security requirements 4 Build: Begin migrating the application or refactoring the process Pre-Production Testing: Test in staging environments and check for vulnerabilities Production Testing: Run new and legacy environments in production and test for resilience Go Live: Deploy the application to the production environment Decommission Legacy App: Proceed with the decommissioning of the legacy app Individuals within organizations can identify app migration opportunities by listening for key pain points such as the need to consolidate cloud applications; changes in VMware's contract terms, challenges in ongoing migrations, plans for datacenter consolidation, and timelines for new application cutovers. Key persons looking to migrate apps are… VP of IT: Manages IT operations and ensures systems run smoothly Cloud Architect: Designs and implements cloud infrastructure SecOps: Ensures the security posture of apps, focusing on threat detection, incident response, and compliance DevOps: Ensures smooth integration between development and operations, optimizing the deployment pipeline and managing CI/CD workflows Whether your migration is between cloud providers or on-prem, F5’s solution seamlessly ties together all the ends. The Process: Migrating Apps with F5 Comprised of three integrated components to accelerate time to market and reduce redundancies, an F5 solution provides: Deployable Software (CE): Abstracts multi-environment complexity Distributed Cloud App Connect: Provides app connectivity and secure network overlay SaaS-Console: Offers universal visibility and consistent policy enforcement F5 Distributed Cloud Services simplify app migrations by ensuring observability, security, and compliance. End-to-end visibility is maintained throughout the migration, traffic is balanced across both environments, and consistent security policies are enforced. CE’s, deployable to most hypervisors, virtual platforms, and most public cloud providers, deliver many L3 and L7 services and capabilities, some of which include the following: Single dashboard view Multi-site support Multi-tenancy Native service discovery L7 load balancing L3 firewall L3 routing, including with BGP Network segmentation L3 VPN SNAT DHCP Server For migrations that include RedHat OpenShift Virtualization or Nutanix AH-V, free tools are available from each to move virtual machines between environments. For OpenShift, use the Migration toolkit for virtualization (MTV), and for Nutanix, use Nutanix Move. Regardless of the provider or platform, with an F5 XC CE at each location, re-connect the workloads on your VM’s without making any changes. Using F5 XC App Connect or Network Connect, extend L7 or L3 network services with any combination of L7 HTTP load balancing or L3 routing (and use SNAT policies only as needed). Demo The following video shows two migration scenarios and how using F5 XC simplifies the task. The first part covers how to migrate app VMs from a VMWare environment to one powered by RedHat OpenShift Virtualization. In the second part, I show how to use Nutanix Move to migrate VM’s between Nutanix clusters from one cloud provider to another. In both scenarios, F5 XC CE’s are configured to use App Connect to seamlessly deliver connectivity and security. This allows both migrations to happen without downtime to applications. Video: https://youtu.be/SEuSvcyxWDU Conclusion Migrating applications to the cloud can be a time consuming and costly process, but with the right strategies and solutions, organizations can overcome these challenges. F5's integrated components and services provide the necessary tools to simplify migrations, ensure security, and optimize cost. Additional Resources Scale Your DMZ with F5 Distributed Cloud Services Seamless Application Migration to OpenShift Virtualization with F5 Distributed Cloud Deploying F5 Distributed Cloud Customer Edge in Red Hat OpenShift Virtualization VMware NSX to Red Hat OpenShift Virtualization Migration with F5 Distributed Cloud How I Did it - Migrating Applications to Nutanix NC2 with F5 Distributed Cloud Secure Multicloud Networking
Which encyrtion algorithm is used when making Kerberos ticket encyrtion.
Which algorithm is used when making Kerberos ticket encyrtion. Hello, we have created and installed all encyrption methods as all in the keytab file. Now how can I see which encyrption method is used by the application that does kerberos authentication on F5? We will detect applications that use old encyption methods and force them to use the new methods. It would be great if anyone has any experience, suggestions or knowledge on how to solve this issue.Introducing the New F5 Bot Defense Self-Service UI
Bot Defense Advanced protects your web and mobile application endpoints from automated attacks by identifying and mitigating malicious or bad bots. For more information about Bot Defense Advanced features, see Bot Defense Overview Important: Bot Defense Advanced Self-Service Policy Management is an Early Access feature. Step 1: Sign Up for Bot Defense Advanced To enable Bot Defense Advanced, contact your F5 Technical Account Manager (TAM). Once enabled, your TAM and the F5 Services team help you quickly get your Bot Defense Advanced infrastructure and policies configured to protect your applications from automated attacks, such as credential stuffing, denial of service, web scraping and so on. As your applications change and you add new endpoints to your environment, you can use Bot Defense Advanced Self-Service Policy Management to make changes to your policies, or you can contact your TAM for assistance. To make changes to your Bot infrastructure, contact your TAM. Bot Defense Advanced Self-Service Policy Management is available from the Distributed Cloud Console. You must have one or more of the following permissions: f5xc-bot-defense-admin role: Provides advanced administrative access, including service activation. f5xc-bot-defense-user role: Provides read and write access to bot policies and read access to bot infrastructure. This role also grants permission to deploy new bot policy versions. f5xc-bot-defense-monitor role: Provides read-only access to bot infrastructure, bot policies and dashboards. f5xc-bot-defense-report role: Provides permissions to create and manage monthly Bot Defense reports. If you do not have any of these roles, contact your Bot Defense administrator or your TAM. Step 2: Decide What You Want to Protect You must decide which endpoints you want to protect with Bot Defense. For information about what to consider when you configure web and mobile endpoints, see the following information: Protect Web-Based Endpoints Protect Mobile Endpoints Step 3: Configure Your Bot Policies Bot Defense Advanced provides three system policies that allow you to control system configuration settings: Bot Endpoint Policy Bot Allowlist Policy Bot Network Policy The F5 Operations team performs a site analysis and creates the initial version of each policy and then works with you to deploy the policies in your Bot Infrastructure. Bot Defense Advanced Self-Service Policy Management allows you to make and deploy any necessary changes to your policies, for example, to protect new endpoints, update mitigation actions, add new clients to the allowlist or to add new network routes. If you prefer, you can also work with your F5 Operations Team to make these changes. Use the Distributed Cloud Console to view and manage your policies, including details of current and past policy versions. Step 4: Test Your Configuration Use the Test cluster provided to you by F5 to test your Bot Defense deployment and help ensure that Bot Defense policies are properly configured, that JavaScript tags are injected in your application pages correctly, or that you have correctly integrated the mobile SDK. For information, see Test Your Bot Defense Advanced Configuration. Step 5: Deploy Policies in Your Production Environment After you verify in your test environment that Bot Defense is configured correctly and correctly identifying automated traffic, work with your F5 Operations team to deploy your policies in a production environment. Bot Defense Advanced Self-Service Policy Management Demo: Related Resources: Deploy Bot Defense on any Edge with F5 Distributed Cloud (SaaS Console, Automation) Protecting Your Web Applications Against Critical OWASP Automated Threats Making Mobile SDK Integration Ridiculously Easy with F5 XC Mobile SDK Integrator JavaScript Supply Chains, Magecart, and F5 XC Client-Side Defense (Demo) Bots, Fraud, and the OWASP Automated Threats Project (Overview) Protecting Your Native Mobile Apps with F5 XC Mobile App Shield Enabling F5 Distributed Cloud Client-Side Defense in BIG-IP 17.1 Bot Defense for Mobile Apps in XC WAAP Part 1: The Bot Defense Mobile SDK F5 Distributed Cloud WAAP Distributed Cloud Services Overview Enable and Configure Bot Defense - F5 Distributed Cloud Service
