ჩაბარების ვადა:

3 ნოემბერი 2025, 18:00

სტატუსი:

მიმდინარე

E
ელ. ტენდერი
T28380 - Tender for purchasing of Web Application Firewall (WAF)

  • გამომცხადებელი: სს ჰეშ ბანკი
  • შესყიდვის ტიპი: ელ. ტენდერი
  • ვაჭრობის ტიპი: ვაჭრობის გარეშე
  • მონაწილეობის დაწყება: 22 ოქტომბერი 2025 დრო 08:00
  • წინადადების მიღება მთავრდება: 3 ნოემბერი 2025 დრო 18:00

დარჩენილია

-

დღე

:

-

სთ

:

-

წთ

:

-

წმ

შეთავაზების ატვირთვისათვის, გთხოვთ გადახვიდეთ "შეთავაზების" ტაბში.

Tender Description:

Hashbank is seeking proposals from qualified vendors for Web Application Firewall

The purpose of this document is to inform the bidders about the purchaser's requirements and conditions for the submission of a complete tender proposal.

Tender Process Timeline:

Tender Announcement:Octomber 21, 2025 

Submission Deadline for Proposals: November 03, 2025

The purchaser reserves the right to suspend, terminate, and/or announce a new tender at any stage of the process, at its sole discretion and without prior notice or agreement with the bidder(s). 

Information regarding the suspension or termination of the tender will be made available on the tender announcement portal.

The purchaser also reserves the right to amend or expand the scope of services/procurement requirements prior to signing the contract with the selected bidder. Any such changes will be published on the tender announcement portal.

1. Vendor Requirements

  • The solution must be cloud-based (SaaS).
  • The vendor must have at least 5 years of presence in the Content Delivery Network (CDN) market.
  • The vendor must be recognized as a Leader in Web Application Firewall (WAF) by the latest Forrester and Gartner reports

2. Solution Architecture Requirements:

  • The solution must operate via a globally distributed Anycast data center architecture.
  • The solution must operate in at least 330 cities worldwide.
  • The vendor must have at least one Point of Presence (PoP) in Georgia
  • All PoPs must have unified functionality.
  • User traffic must be routed via the nearest PoP based on Anycast routing.
  • The system must operate in Reverse Proxy mode.
  • The system must support role-based account access granularity.
  • The vendor must provide the ability to register domain names directly.
  • The system must support configuration backup and recovery. 

3. Security Functionality Requirements:

3.1. General Security

  • The system must provide multiple protection mechanisms: Blocking, Captcha Challenge, JavaScript Challenge.
  • The system must support custom response actions per security event.
  • The system must allow defining access rules based on User-Agent.
  • The system must allow defining access rules for specific zones of a website.
  • The system must allow defining parameters for individual pages/URIs.
  • The system must allow enabling “protection mode” for the entire resource.
  • The solution must be PCI DSS 2.0 and 3.0 compliant.
  • The solution must be able global and private network load balancing 

3.2. DDoS Protection

  • The system must provide protection against network-level (L3/L4) DDoS attacks.
  • The system must provide protection against application-level (L7) DDoS attacks.
  • The solution must mitigate volumetric attacks regardless of size and duration.
  • The system must support Rate Limiting per IP, IP with NAT support, Query, Host, Headers, Cookie, ASN, Country, Path, JA3/JA4 Fingerprint1, JSON field value, Body, Form input value, Custom for specific web pages.
  • The system must support custom rule creation for traffic processing.
  • The provider must have at least 300 Tbps of global DDoS mitigation capacity.
  • The provider must supply a stable list of WAF IP ranges for whitelisting on origin servers, with timely notifications for any changes.
  • The system must provide protection against HTTP/2 rapid reset attacks.
  • The system must support real-time signature generation for new attack patterns.
  • The system must provide adaptive anomaly-based protection, including detection by geolocation, User-Agent, and protocol profile.
  • Available fields in rule expression for rate-limiting : General request fields, request header fields, Verified Bot, Bot Management fields, request body fields

3.3. Web Application Firewall (WAF)

  • The system must protect against all major vulnerability attacks.
  • The system must provide full protection against the latest OWASP Top 10 vulnerabilities.
  • The system must include predefined security templates depending on the platform (e.g., WordPress, SharePoint, Magento).
  • The system must allow tuning response actions per individual signature.
  • The system must provide automatic, real-time signature updates.
  • The system must support request transformation (adding parameters, rewriting requests).
  • The system must allow viewing full HTTP request bodies.
  • The solution must support logging of payloads when managed WAF rules are triggered, with encryption of captured values using the customer’s public key, and ability to decrypt via Dashboard.
  • The system must provide rate limiting to prevent abusive clients, counting requests per IP and also identifying unique users behind NAT.
  • The system must allow configuring rate limiting rules by HTTP method and response code.
  • The system must support custom responses for blocked requests, allowing definition of response type, response code, and response body.
  • The system must provide Sensitive Data Detection

3.4 API Security: 

  • The solution must support secure client authentication using OAuth 2.0, OpenID Connect, and mTLS.
  • The system must implement granular authorization policies based on RBAC or ABAC models.
  • The API gateway must enforce rate limiting and adaptive throttling to prevent abuse and DoS attacks.
  • The platform must include built-in DDoS and bot protection with behavioral traffic analysis.
  • The API must support schema-based request validation using OpenAPI or JSON Schema.
  • The system must sanitize and validate all input and output data to prevent injection and XSS attacks.
  • The solution must support encrypted communication over TLS 1.3 
  • The system must provide full audit logging for all authentication, authorization, and API transactions.
  • The platform must integrate with SIEM systems for real-time monitoring and alerting on anomalies.
  • The API must support discovering to prevent Shadow API
  • The solution must provide protection against OWASP API Security Top-10 vulnerabilities.
  • The vendor must offer continuous signature updates and machine-learning-based anomaly detection.

3.6 Protection against bots

  • Functionality of blocking malicious bots and allowing access for search engine bots
  • Availability of protection mechanisms: Blocking, Captcha Challenge, JS Challenge
  • Protection against password brute force attacks
  • Check the user's browser
  • Using machine learning, behavioral analysis, and white lists mechanisms to determine bot access to resources
  • Ability to use detailed query parameters to determine access
  • Ability to use JA3/JA4 fingerprint for control traffic (allow/block)

3.7 RASP functionality (SDK module)

  • The system must detect and report runtime threats, including tampering, instrumentation, and debugging attempts within the mobile application.
  • The system must verify and definitively attests to the authenticity of your app and the device on which it is running. (App attestation)
  • The system must detect and prevent the execution of repackaged or modified versions of the mobile application. 
  • The system must identify rooted or jailbroken devices and enforce configurable security policies (e.g., access restriction, blocking).
  • The system must detect blocks Man-in-the-Middle (MitM) attacks and enables secure over-the-air instant pin updates without service disruptions with dynamic certification pinning.
  • The system must prevent unauthorized code injection, dynamic hooking, and modification of application logic or sensitive APIs.
  • The system must support automated responses to detected threats, including token revocation, session termination, or alert generation.
  • The system must integrate with API security and bot management to ensure that only verified and untampered mobile applications can access protected APIs.
  • The system must support cross-platform operation, including iOS and Android mobile environments.
  • The system must ensure minimal performance overhead and maintain optimal user experience during runtime protection operations.
  • The system must use a patented challenge-response protocol to protect attestation from replay attacks
  • The system must issue short-lived cryptographic tokens after successful attestation to prove authenticity to backend APIs
  • The system must prevent the app itself from making its own integrity decisions or signing its own tokens—integrity decisions must be made by the attestation server
  • The system must integrate with platform attestation services (iOS App Attest / DeviceCheck, Google Play Integrity) to strengthen attestation signals
  • The system must dynamically pin the server certificate(s), ensuring the mobile app only communicates with a server whose certificate matches the pinned set
  • The system must support over-the-air dynamic updates of pin sets, allowing certificate rotations or changes without requiring an app update
  • The system must protect against “Man-in-the-App” attacks, such as function-hooking frameworks (e.g. Frida), that attempt to nullify pinning implementations
  • The system must ensure that valid attestation tokens or runtime secrets are never issued when pinning is compromised or hooking is detected

4. Encryption Requirements:

  • The system must support TLS 1.3 encryption.
  • The system must allow defining a minimum TLS version.
  • The system must allow encryption only for the client session.
  • The system must allow end-to-end encryption (client + origin).
  • The system must support Bring Your Own Certificate (BYOC).
  • The vendor must operate its own Certificate Authority (CA).
  • The system must support SSL certificates using ECDSA, and removal of non-secure cipher suites.
  • The system must support Certificate Transparency Monitoring with alerts in case of unauthorized certificate issuance.
  • The system must support automatic SSL renewal management.
  • The solution must support solution-generated certificates with automated renewal.

5. DNS Requirements

  • The system must allow hosting of domain zones on vendor-managed DNS servers.
  • The system must support CNAME usage.
  • The vendor’s DNS must support DNSSEC with algorithm 13.

6. Access Control Requirements:

  • The system must allow defining access rules for employees.
  • The system must allow defining access rules for groups of users.
  • The system must support audit and change logging.
  • The management console must support Single Sign-On (SSO).
  • The management console must support Multi-Factor Authentication (MFA).

7. Content Caching Requirements:

  • The system must allow caching of static content.
  • The system must allow granular cache levels.
  • The system must allow defining cache lifetime in the browser.
  • The system must support forced cache purging by host, URI, or tag.
  • The system must support tiered caching.
  • Providers must support smart tiered caching, using upper/lower-tier PoPs to reduce origin load and cost.

8. Optimization Requirements:

  • The system must support image optimization mechanisms.
  • The system must provide a built-in wizard for analyzing and optimizing security settings.
  • The system must provide Automatically detect network congestion in real time and route traffic across the most efficient path over the Internet for optimal content delivery and user experience.

9. Analytics Requirements:

  • The system must support real-time logging.
  • The system must allow detailed filtering in reports.
  • The system must provide raw logs via REST API.
  • The system must support log compression for export to third-party systems.
  • The system must allow customization of log fields before export.
  • The system must support forwarding of original client IP addresses to protected servers.
  • Dashboards must provide at least 30 days of historical data.

10. Support Requirements:

  • The vendor must provide 24/7/365 support via email and phone.
  • The vendor must guarantee 100% service uptime.
  • The vendor must ensure availability English speaking engineers.

Supplier Requirements and List of Documents to be Submitted

  • Annex #1 – Company Details (Requisites);
  • At least two (2) recommendation letters related to the requested type of service;
  • The bidder must submit a detailed financial offer in accordance with the technical specifications, in PDF format signed by an authorized person, as well as in Excel format. The tender offer must include all costs related to the provision of services, including applicable taxes and other charges incumbent upon the bidder;
  • An updated extract from the Register of Entrepreneurs and Non-Entrepreneurial (Non-Commercial) Legal Entities; 
  • MAF (Manufacturer Authorization Form) for the proposed product;
  • The supplier must submit a valid certificate issued by the manufacturer’s engineer for the proposed product;
  • The implementation/installation of the supplied product must be carried out by the engineer whose certificate is submitted by the bidder;
  • By submitting a tender proposal, the bidder confirms that: (a) they have reviewed the sample Purchase Agreement provided as Annex #2, which will be signed with the winning bidder. The contract is a template and will be individually adjusted with the selected supplier; and (b) they are aware that during the contract period, they are not entitled to increase the contractual prices or otherwise worsen the buyer’s position.

Grounds for Disqualification:

The purchaser is authorized to disqualify a bidder if:

  • The bidder is listed in the register of debtors;
  • The bidder’s property is subject to a registered tax lien, mortgage, or other encumbrance/restriction;
  • The bidder is undergoing reorganization, liquidation, or insolvency proceedings;
  • The documentation/information required by the tender application is:
    - Not fully submitted;
    - Not in compliance with the specified requirements;
    - Inaccurate or inconsistent with actual facts;
    - Falsified.
  • There are other objective circumstances that make the bidder's further participation in the tender impossible.

Confidentiality

The bidder shall be responsible for maintaining the confidentiality of any information provided by the purchaser, both during the selection process and after its completion, regardless of the outcome of the tender.

Tender Submission Terms:

  • Offers should be submitted on procurement web-page: www.tenders.ge
  • Submission Deadline is: 03/11/2025 ; 18:00 PM 
  • Bid currency: N.A
  • Auction type: Without auction
  • Instructions to Apply for E-Tender can be found in the attached file
  • Any question during the electronic tender process shall be made in writing and communicated through the Q&A platform of www.tenders.ge website

Additional Information:

For any questions or clarifications, vendors may contact Diana Kadaria at [diana.kadaria@hashbank.ge] Tel: +995 551 67 74 67, [Irakli Dalakishvili] at [irakli.dalakishvili@hashbank.ge] Tel: +995 557 71 33 52

ტენდერის კატეგორია:

  • 48900000 სხვადასხვა სახის პროგრამული პაკეტები და კომპიუტერული სისტემები
  • 48700000 პროგრამული პაკეტების მომსახურე პროგრამები
  • 48800000 საინფორმაციო სისტემები და სერვერები
შეკითხვები