Lot-1: Core Firewall, Lot-2: DMZ Firewall and Lot-3: Web … · 2017-05-21 · Prepared By NCC Bank...

Request for Proposal of Core Firewall, DMZ Firewall and WAF

Prepared By NCC Bank IT Division Page 1 of 48

REQUEST FOR PROPOSAL

“Lot-1: Core Firewall, Lot-2: DMZ Firewall and Lot-3: Web Application Firewall” for National Credit & Commerce Bank Limited (NCCBL) at NCC Bank Bhaban, Motijheel C/A, Dhaka

NATIONAL CREDIT & COMMERCE BANK LIMITED 13/1 & 13/2 Toyenbee Circular Road, Motijheel Commercial Area, Dhaka-1000,

Bangladesh, Phone: PABX (02) 9561902-4, 9566283, Fax: 880-2-9566290, Telex: 642821 NCL BJ

Cable NATCREDIT DHAKA, E-mail: [email protected], web: www.nccbank.com.bd

http://www.nccbank/



Contents

PART- A: BACKGROUND………………………………………………………………...….............................4

PART- B: INSTRUCTIONS TO BIDDERS and TERMS & CONDITIONS……………........................…….5

PART- C: Specification of Core Firewall, DMZ Firewall and Web Application Firewall……………....16

C.1 Core Firewall ............................................................................................................................... 16

C.2 DMZ Firewall…......................................................................................................... .................. 24

C.3 Web Application Firewall………………………………………………………………………………..33 PART-D: APPENDIXES ............................................................................................................................. 43

D.1 Schedule of Technical proposal .................................................................................................. 43

D.2 Schedule of Price Proposal ......................................................................................................... 44

D.3 Form of Technical Proposal ........................................................................................................ 45

D.4 Form of Price Proposal ............................................................................................................... 46

D.5 Form of Performance Security (Bank Guarantee) ...................................................................... 47



IMPORTANT NOTICE

This tender document is not transferable. Bidders are advised to study the tender document carefully. Submission of bid shall be deemed to have

been done after careful study and examination of the tender document with full understanding of its

implications.

The response to this tender must be full and complete in all respects. Incomplete or partial bids shall be

rejected. The bidder must quote for all the items asked for in this tender.

The bidder shall bear all costs associated with the preparation and submission of the bid, including cost of

presentation for the purpose of clarification of the bid, if so desired by purchaser. Purchaser will in no

case be responsible or liable for those costs, regardless of the conduct or outcome of the bidding

process.



PART- A: Background

Background NCCBL has constructed its own 22 storied Building and aiming to enhance technology based Banking services from its new location. NCC Bank wants to introduce full-fledged Internet based Banking Services to its customers by implementing robust security system through Core Firewall, DMZ firewall and Web Application Firewall. Project Overview

(i) NCCBL having 106 branches are spread all over the country with centrally located Head Office in Dhaka. This document lays specifications of Core Firewall, DMZ Firewall and Web Application Firewall with an aim to modernize the Enterprise IT security systems of the Bank.

(ii) The RFP specifies indicative requirements of Core Firewall, DMZ Firewall and Web Application Firewall; detailed functional specifications of the solution are desired for the project. The technical specifications specified are the minimum suggestive specifications and these must be taken as guidelines for design and implementation of the project. It is the bidders’ responsibility to offer suggestions in the design as well as indicate missing components if any (separately), that may be considered necessary in his bid to implement and operate the facility to meet the required objectives of the project as has been laid down in this document. Suggestions, modifications, if any, in this regard, must be communicated in written explanation (before the pre-bid meeting) with the purchaser so that any essential components must not be missing.



PART-B: INSTRUCTIONS TO BIDDERS and TERMS & CONDITIONS

B.1 Instructions to Bidders

1. Bidder’s qualification

i. Bidders are expected to examine the attached specifications and all instructions contained

in this Request for Proposal. Failure to do so will be at the Bidder’s risk.

ii. All Documents mentioned in this document must be submitted.

iii. All correspondence in connection with the proposal and the purchase order is to be in

English.

2. General description of the IT infrastructure

a) Following sites to be considered for the project scope:

Data Center SARA TOWER 11/A, Toyenbee Circular Road, Motijheel C/A Dhaka - 1000

b) Systems under project scope: (Major Services running at Core Network and DMZ)

NCC Bank Limited is planning to implement Virtualization Technology for its most of the services except some of the core services. So, the solution must support of the virtualization technology and work smoothly in this virtual environment.

3. Cost of bidding

The bidder shall bear all costs associated with the preparation and submission of its bid and the Bank

will in no case be responsible or liable for those costs.

SL Name of the Services 1 SMS Banking 2 Internet Banking 3 Bank’s Website (Internal & External) 4 SWIFT 5 Sanction Screening for SWIFT 6 Email 7 Anti-Virus 8 Core Banking Service 9 CIB Services 10 BACH, RTGS, BFTN



4. Content of bidding documents

The bidding documents are those stated below, and must be read in conjunction with any addenda

issued in accordance with clause 6:

(a) PART A : Background & Project overview

(b) PART B : Instruction to bidders and Terms & Conditions

(c) PART C : Specification of Core Firewall, DMZ Firewall and Web Application Firewall

(d) PART D : Appendixes

(i) Schedule of Technical proposal (D1).

(ii) Schedule of Price proposal (D2).

(iii) Bid form for technical proposal (Appendix D.3).

(iv) Bid form for price proposal (Appendix D.4).

(v) Form of Performance Security (Appendix D.5)

The bidder is expected to examine carefully the contents of the bidding documents. Failure to

comply with the requirements of bid submission will be at bidder’s own risk. Pursuant to clause 20,

bids which are not substantially responsive to the requirements of the bidding documents will be

rejected.

5. Clarification of bidding documents:

A prospective bidder requiring any clarification of the bidding documents may notify the Bank

([email protected]) through their registered company email (mail from Gmail/Yahoo/Hotmail etc.

will not be accepted) and the Bank will respond to clarification request through email which it receives

earlier than 7 days prior to the deadline for submission of bids. Copies of the Bank’s response,

including a description of the enquiry, will be forwarded to all purchasers of the bidding documents by

email.

6. Amendment of bidding documents:

At any time prior to the deadline for submission of bids, the Bank may, for any reason, whether at its

own initiatives or in response to a clarification requested by a prospective bidder, modify the bidding

documents by issuing addenda.

Any addenda thus issued shall be part of the bidding document pursuant to clause 5, and shall be communicated to all purchasers of the bidding documents through their supplied registered email. Prospective bidders shall acknowledge receipt of each addendum by sending a return email to the Bank ([email protected]) within 2 days from the date of receiving the addenda. 7. Language of the bid:

The bid and all correspondence and documents, related to the bid, exchanged between the bidder and the Bank shall be written in English language. Supporting documents and printed literature furnished by the bidder may be in another language provided they are accompanied by an accurate translation of the relevant passages in the English language, in which case, for purposes of interpretation of the bid the English translation shall prevail.



8. Documents comprising the bid:

The bid submitted by the bidder shall comprise two envelopes submitted simultaneously, one containing only the technical proposal and the other the price proposal.

The technical proposal shall contain the following:

Bid document that has been obtained from National Credit & Commerce Bank Limited.

Power of attorney (authorizing the person to sign and initial the bid document on behalf of the company).

Bid security pursuant to clause 14 (Photocopy).

Proposal of Technical & Functional Specification of the Tools (PART-C).

Bid form of Technical proposal (APPENDIX D.3).

Schedule for Technical proposal (APPENDIX D.1);

Vendor’s agreement with an expert organization having required qualification for the implementation of security tools in case the vendor does not have the required experience.

CV of the proposed project Manager including photocopy of relevant certificates.

Any other things required to implement the software or tools.

The price proposal shall contain the following:

(i) Bid security pursuant to clause 14 (Original).

(ii) Bid form for Price proposal (APPENDIX D.4).

(iii) Schedule for price proposal (APPENDIX D.2).

(iv) Any other things required to implement the software or tools.

9. Bid form and price schedule:

The bidder shall complete the bid forms and schedules furnished in the bidding documents in the manner and detail indicated therein, following the requirements of clauses 10 and 11. 10. Bid prices:

Unless specified otherwise in Bank’s requirements, bidders shall quote for the 3 Lots separately.

The bidder shall give a breakdown of the prices in the manner and detailed for in the schedule of prices. In the schedules, bidders shall give details and a breakdown of their prices, including all taxes, duties, levies and charges.

11. Bid currency: Price must be quoted in Bangladeshi currency (BDT).



12. Bid validity:

Bid shall remain valid for a period of 120 days after the date of opening of Technical proposals. In

exceptional circumstances, prior to expiry of the original bid validity period, the Bank may request the

bidder to extend the period of validity for a specified additional period. The request and the responses

thereto shall be made in writing. A bidder agreeing to the request will not be permitted to modify its

bid.

13. Format and signing of bid:

The bidder shall prepare one original and two copies of the technical proposal and the financial

proposal, clearly marking each one as: “ORIGINAL-TECHNICAL”,”ORIGINAL-PRICE PROPOSAL”,

“COPY NO. I – TECHNICAL PROPOSAL”, “COPY NO. II- PRICE PROPOSAL” etc. as appropriate.

In the event of discrepancy between the original and any copy, the original shall prevail.

The original and all copies shall be signed by a person or persons duly authorized to sign on behalf of

the bidder. All pages of the bid where entries or amendments have been made shall be initialed by

the person or persons signing the bid.

The bid shall contain no alterations, omissions or additions, excepts those to comply with the instructions issued by the Bank, or as necessary to correct errors made by the bidder, in which case such corrections shall be initialed by the person or persons signing the bid.

14. Bid security:

The bidder shall furnish, as part of its bid with the price proposal, a bid security in the amount of Tk. 5

(Five) lacs in the form of Bank Guarantee in the name of “National Credit & Commerce Bank

Limited”. The bid security will be forfeited:

(a) If the bidder withdraws its bid, except as provided in clause 21.

(b) If the bidder does not accept the correction of its bid price pursuant to clause 21.

(c) As per clause 35, if the successful bidder fails within the specified time limit to

(i) Sign the contract agreement, or

(ii) Furnish the required performance security.

A photocopy of the bid security must be included in the Technical proposal and the original one must

be include with the price proposal.

15. Sealing and marking of bid:

The bidders shall seal the original bids and each copy of the bid in an inner and outer envelope, duly marking the envelopes as “ORIGINAL” and “COPY”. Bidders will prepare 3 separate outer envelopes for 3 Lots Lot-1: Core Firewall, Lot-2: DMZ Firewall and Lot-3: Web Application Firewall.

The inner and outer envelopes shall

1. Be addressed to the Bank at the following address: National Credit & Commerce Bank Limited, 13/ & 13/2, Toyenbee Circular Road, Motijheel C/A, Dhaka-1000.



2. Bear the following identification:

Bid for Core Firewall, DMZ Firewall and Web Application Firewall

DO NOT OPEN BEFORE 3.30 p.m. on 30th May, 2017.

3. In addition to the above requirements, the inner envelope shall indicate the name and address of the bidder to enable the bid to be returned unopened in case it is declared “late” pursuant to clause 17.

4. If the outer envelope is not sealed and marked as above, the Bank will assume no responsibility for the misplacement or premature opening of the bid.

16. Deadline of bid:

Bids must be received by the Bank at the address specified above no later than 3.15 p.m. on 30th May, 2017.

17. Late Bids: Any bid received by the Bank after the deadline for submission of bid prescribed in clause 16 will be rejected and returned unopened to the bidder. 18. Opening of technical bid: The Bank will open the technical proposals in presence of the bidder’s representative who chooses to attend at 3.30 p.m. on 30th May, 2017 at the following location: National Credit & Commerce Bank Limited, NCC Bank Bhaban, 13/1 & 13/2, Toyenbee Circular Road, Motijheel C/A, Dhaka-1000. The price proposals will remain unopened and will be held in the custody of the Bank until the time of bid opening of the price proposals. The time and date and location of the bid opening of the price proposals will be communicated in writing. The Bank shall prepare minutes of the bid opening including the information disclosed to those present.

19. Preliminary examination of technical bid:

The Bank will examine the bids to determine whether they are complete, whether the bid document officially obtained from National Credit & Commerce Bank Limited by the bidder is included, whether the documents have been properly signed, whether the photocopy of required bid security is included, and whether the bids are generally in order. Any bid found not to comply with these requirements must be treated as non-responsive. 20. Evaluation and comparison of technical proposals: The Bank will carry out a detailed evaluation of the bids according to the information supplied by the bidder in PART–C of functional proposals. The Bank may want to see the demonstration of the software or tools to assess the functional features mentioned by the bidder in the format of technical proposal. In such a case, the Bank must send an email requesting the bidder to arrange the demonstration and the bidder must arrange it within two weeks from the date of receiving the request. If the bidder refuses to arrange the demonstration, his/her bid will be treated as non-responsive. If the criteria as mentioned in PART-B.1, clause 1 are met, the technical proposal will be evaluated as



responsive and the price proposal of such bid will be opened. The price offer of the non-responsive bidder will be returned unopened. 21. Clarification of technical proposal:

The Bank may conduct clarification meetings with each or any Bidder to discuss any matter, technical or otherwise, where the Bank requires amendments or changes to be made to the Technical and functional Proposal. Where amendments or changes are required by the Bank, bidders will be requested in writing to adjust their proposals accordingly and submit a supplementary price proposal within 3 days. The supplementary price proposal must only contain the changes in price resulting from the changes in the technical proposals. Bidders must note that, if the Bank, during the evaluation of the price proposals, considers that the changes in price are unrealistic in comparison with the original price proposal, the bid is liable to be rejected. Bidders not wishing to change their technical proposals may withdraw from the bidding process and their price proposals will be returned unopened.

The Bidder shall seal the original supplementary price proposals and each copy (number of copies to be the same as the number required in the bid submission) in an inner and outer envelope clearly marking each one as “ORIGINAL –SUPPLEMENTARY PRICE PROPOSAL”, “COPY NO. 1 SUPPLEMENTARY PRICE PROPOSAL”, etc. as appropriate.

The inner and outer envelope shall be addressed and bear the name of contract.

Supplementary price proposals which are not received in the time required by the Bank will result in

the rejection of the bid.

22. Information about opening of Price Proposals: As per Bank’s policy, bidders are not invited while opening the technically responsive bids. Bank has an internal committee to open the price proposal. However, after opening of these bids, a statement showing the position of the technically responsive bids may be circulated to all the responsive bidders.

Bank will notify Bidders that have been rejected on the grounds of being substantially non-responsive to the requirements of the bidding documents in writing and return the unopened price proposal.

23. Opening of the Price Proposals: The Bank internal committee will open the price proposals and, if provided, the supplementary price proposals of all bidders who submitted substantially responsive technical proposals. The bidder’s names, the Bid Prices including Supplementary Price Proposals, the total amount of each bid, any discounts, the presence or absence of bid security and such other details will be recorded by the Bank at the opening. 24. Process to be confidential:

Information relating to the examination, clarification, evaluation and comparison of bids and recommendations for the award of a contract shall not be disclosed to bidders or any other persons not officially concerned with such process until the award to the successful bidder has been announced. Any effort by a bidder to influence the Bank’s processing of bids or award decisions may result in the rejection of the bidder’s bid.



25. Clarification of Price Proposals: To assist in the examination, evaluation and comparison of price proposals, the Bank may, at its discretion, ask any bidder for clarification of its bid. The request for clarification and the response shall be on writing, but no change in the price or substance of the bid shall be sought, offered or permitted except as required to confirm the correction of arithmetic errors discovered by the Bank in evaluation of the bids in accordance with clause 27. 26. Preliminary Examination of Price Proposals and determination of Responsiveness: The Bank will examine the bids to determine whether they are complete, whether the documents have been properly signed, whether the required security is included, whether the bids are substantially responsive to the requirements of the bidding documents; and whether the bids provide any clarification and or substantiation that the Bank may require pursuant to Clause 25. A substantially responsive bid is one which conforms to all the terms, conditions and requirements of bidding documents, and includes the amendments and changes, if any, requested by the Bank during the evaluation of the bidder’s technical proposal. If a price proposal is not substantially responsive, it will be rejected by the Bank, and may not subsequently be made responsive by correction or withdrawal of the nonconforming deviation or reservation. 27. Correction of Errors: Price proposals determined to be substantially responsive will be checked by the Bank for any arithmetic errors. Arithmetic errors will be rectified on the following basis. If there is a discrepancy between the unit rate and the total cost that is obtained by multiplying the unit rate and quantity, the unit rate shall prevail and the total cost will be corrected unless in the opinion of the Bank there is an obvious misplacement of the decimal point in the unit rate, in which case the total cost as quoted will govern and the unit rate corrected. If there is a discrepancy between the total bid amount and the sum of total costs, the sum of total costs shall prevail and the total bid amount will be corrected.

28. Evaluation and Comparison of Price Proposals: The figure that will be mentioned in “Schedule of price Proposal” will enter into the comparison table of the bidders to be prepared by the Bank. 29. Consolidated evaluation:

There will no score of technical evaluation of the bids that will be technically qualified. As a result,

financial evaluation of the technically qualified proposals will be treated as a consolidated evaluation.

30. Price Negotiation:

The Bank may request any of the bidders who have been technically qualified for price negotiation. Representative of the Bidders must have authorization for price negotiation. 31. Award of Contract: Subject to Clause 30, the Bank will award the Contract to the successful bidder.



32. Bank’s right to accept any bid and to reject any or all bids:

Notwithstanding Clause 31, the Bank reserves the right to accept or reject any bid, and to annul the

bidding process and reject all bids at any time prior to award of Contract, without thereby incurring

any liability to the affected bidder or bidders or any obligation to inform the affected bidder or bidders

of the grounds for the Bank’s action.

33. Notification of award:

Prior to expiration of the period of bid validity prescribed by the Bank and after successful

negotiations, the Bank will notify the successful bidder by registered letter, that its bid has been

accepted. This letter (hereinafter called the “Letter of Acceptance”) shall name the sum, which the

Bank will pay the Vendor in consideration of the execution of the said project as prescribed by the

Contract (hereinafter called “the Contract Price”).

The notification of award will constitute the formation of the Contract.

Upon the furnishing by the successful bidder of a performance security the Bank will promptly notify other bidders that their bids have been unsuccessful.

34. Signing of contract: At the same time that the Bank will notify the successful bidder that its bid has been accepted, the Bank will send the bidder the Form of Contract Agreement. Within 7 days of receipt of the Form of Agreement, the successful bidder shall sign the Form and return it to the Bank.

35. Performance Security:

Within 7 days of receipt of award from the Bank, the successful bidder shall furnish to the Bank a performance security in the form of Bank guarantee in an amount of 5% of Contract price in accordance with the Conditions of Contract. This performance security will be kept up to completion of the project. The bid security will be returned after receiving the performance security. Failure of the successful bidder to comply with the requirements of Clauses 34 or 35 shall constitute sufficient grounds for the annulment of the award and forfeiture of the bid security.



B.2 Terms and Conditions

1. The bidder must follow the guidelines as described in B.1 (Instruction to bidder). Failing to comply with these guidelines will disqualify the proposal.

2. The successful bidder must arrange their activities to supply, install, configure, commissioning, testing the tools (PART-C: Specification of Core Firewall, DMZ Firewall and Web Application Firewall) along with the relevant training of the officers of NCCBL within 270 days from the date of appointment.

3. They will submit a detail project plan, project methodology, plan of action and milestones with their offer.

4. They will appoint a Project Manager (PM) immediately after getting the work order. PM must have adequate relevant job experience.

5. They must submit original technical and user manuals of the tools at the time of delivery of the items to the Bank.

6. The terms of payment will be as under:

For PART-C: Specification of Core Firewall, DMZ Firewall and Web Application Firewall, 80% of the price will be paid after delivery of hardware/appliance/software against equal amount of Bank Guarantee and rest amount will be paid after final UAT. The Bank Guarantee will be released after successful installation, configuration and commissioning of the tools.

Deployment and configuration price will be paid after successful demonstration of installation and configuration.

AMC charge of the tools may be paid at the beginning of the year after expiry of warranty period.

Other charges (if any) may be paid on a suitable time after negotiation with the successful bidder.

7. The tools supplied by the bidder must coherently work together by themselves as well as with the existing security devices of NCCBL and the information of all these devices must be displayed in a common dashboard.

8. Bank reserves the right to award single or multiple bidders for this project.



ANNEXURES A. Personnel Capability Statement (in Similar Project Implementation) NAME OF THE BIDDER:

Sl No Name Educational qualifications

Experience relevant to the present work

Clients already served



ANNEXURES B. Client List NAME OF THE BIDDER:

Sl No

Client Name Contract Sign Date Project Ending

Date Contact Person Details

1

2

3

4

5



PART-C: Specification of Core Firewall, DMZ Firewall and Web Application Firewall

National Credit and Commerce Bank intends to enhance Internet based Banking Services through the deployment of the following tools/products. Details of specific products are mentioned below:

C.1 Core Firewall: In order to secure our Core Banking System we require to setup Next Generation

Firewall in our Core zone

SL Technical Specification Compliance

(Y/N) Remarks

Type Next Generation Firewall

Quality Certification ISO, FCC, UL, CE or To be mentioned by the bidder

Brand To be mentioned by the bidder Model To be mentioned by the bidder Country of Origin USA or EU Country of Assemble / Manufacture

USA or EU

Enclosure Type Rack-mountable

Industry Evaluation

Firewall solution offered from OEM must be rated as ‘Leaders’ or 'Challengers' in the latest Magic Quadrant for Firewall published by Gartner

C.1.1 Hardware Architecture

C.1.1.1

The appliance must be capable of providing Firewall, IPS/Threat prevention, Application visibility, Anti-Virus/Malware, Advance Malware protection Services (Anti-APT) and must be capable of VPN (IPSec/SSL) in a single appliance. Firewall which have Anti-virus facility get preference.

C.1.1.2

The appliance hardware must be a multicore CPU architecture with a hardened 64 bit operating system to support higher memory ( Bidder must mention no of cores)

C.1.1.3 Proposed Firewall must work on flow mode with all the content inspection features enable

C.1.1.4 Proposed appliance must have minimum 32GB RAM for higher performance

C.1.1.5 Proposed firewall must have Next generation firewall architecture and must not have proxy or unified threat management architecture

C.1.1.6

Proposed Firewall must not be proprietary ASIC based in nature & must be open architecture based on multi-core CPUs to protect & scale against dynamic latest security threats.



C.1.1.7 The appliance must have at least 8 * 10G enable ports from Day one and must be scalable to 4 * 40G ports in future

Storage Minimum storage capacity must be 200 GB. In addition it is also mandatory to mention storage capacity provisioning in detail.

C.1.2 Performance & Scalability

C.1.2.1 Firewall Throughput: Must be 12 Gbps however above throughput will get preference

C.1.2.2 Threat Prevention Throughput: Must be 09 Gbps however above throughput will get preference

C.1.2.3 IPSec VPN Throughput: Must be 05 Gbps however above throughput will get preference

C.1.2.4 Max Session: Must not be less than 4,000,000

C.1.2.5 New Connection per second: Must not be less than 60,000

C.1.2.6 Firewall must support at least 1000 VLANs C.1.3 High-Availability Features C.1.3.1 Firewall must support Active/Standby failover

C.1.3.2

Firewall must support ether-channel functionality for the failover control & date interfaces for provide additional level of redundancy

C.1.3.3 Firewall must support redundant interfaces to provide interface level redundancy before device failover

C.1.3.4 Firewall must support 802.3ad Ether-channel functionality to increase the bandwidth for a segment.

C.1.3.5 Firewall must have integrated redundant power supply

C.1.3.6 Firewall must have redundant hot-swappable FANs

C.1.4 NGFW Firewall Features

C.1.4.1

The solution must be capable of gathering information about network hosts & their activities, such as operating system, services, open ports, client applications & vulnerabilities, to assist with multiple activities, such as intrusion event data correlation, elimination of false positives & policy compliance when traffic passes through it

C.1.4.2 Firewall must support creating access-rules with IPv4 & IPv6 objects simultaneously

C.1.4.3 Firewall must support operating in Layer 2, Layer 3 & transparent mode

C.1.4.4 Must support Static, RIP, OSPF, OSPFv3 and BGP



C.1.4.5 Firewall must support manual NAT and Auto-NAT, static NAT, dynamic NAT, dynamic PAT

C.1.4.6 Firewall must support NAT66 (IPv6-to-IPv6), NAT 64 (IPv6-to-IPv4) & NAT46 (IPv4-to-IPv6) functionality

C.1.4.7 Firewall must support Multicast protocols like IGMP, PIM, etc

C.1.4.8 Must support security policies based on security group names in source or destination fields or both

C.1.4.9 Must support capability to limit bandwidth on basis of apps / groups, Networks / Geo, Ports, etc

C.1.4.10

Must be capable of dynamically tuning IDS/IPS sensors (e.g., selecting rules, configuring policies, updating policies, etc.) with minimal human intervention.

C.1.4.11

The solution must be capable of gathering information about session flows for all monitored hosts, including start/end time, ports, services, and amount of data when traffic passes through it

C.1.4.12

Must be capable of automatically providing the appropriate inspections and protections for traffic sent over non-standard communications ports.

C.1.4.13 Must be able to link Active Directory and/or LDAP usernames to IP addresses related to suspected security events.

C.1.4.14 Must be capable of detecting and blocking IPv6 attacks.

C.1.4.15

Solution must have the ability to analyze activities to detect threats emerging from inside the network. This includes the ability to establish “normal” traffic baselines through flow analysis techniques and the ability to detect deviations from normal baselines. If the vendor does not support this feature on the Firewall they can propose separate solution.

C.1.4.16

The solution must provide IP reputation feed that comprised of several regularly updated collections of poor reputation of IP addresses determined by the proposed security vendor

C.1.4.17 Solution must support IP reputation intelligence feeds from third party and custom lists of IP addresses including a global blacklist.

C.1.4.18 Must must support URL and DNS threat intelligence feeds to protect against threats



C.1.4.19

Solution must be capable of passively gathering details unique to mobile devices traffic to identify a wide variety of mobile operating systems, mobile applications and associated mobile device hardware.

C.1.4.20

Must support more than 4000 application layer and risk-based controls that can invoke tailored intrusion prevention system (IPS) threat detection policies to optimize security effectiveness.

C.1.4.21

Must be capable of providing network-based detection of malware by checking the disposition of known files in the cloud using the SHA-256 file-hash as they transit the network and capability to do dynamic analysis on-premise on purpose built-appliance (if required in future)

C.1.4.22

NGFW OEM must have its own threat intelligence analysis center and must use the global footprint of security deployments for more comprehensive network protection.

C.1.4.23

The detection engine must support capability of detecting and preventing a wide variety of threats (e.g., malware, network probes/reconnaissance, VoIP attacks, buffer overflows, P2P attacks, etc.).

C.1.4.24 Must be able to identify attacks based on Geo-location and define policy to block on the basis of Geo-location

C.1.4.25 The detection engine must support the capability of detecting variants of known/unknown threats, as well as new threats

C.1.4.26

The detection engine must incorporate multiple approaches for detecting threats, including at a minimum exploit-based signatures, vulnerability-based rules, protocol anomaly detection, and behavioral anomaly detection techniques. Identify and explain each type of detection mechanism supported.

C.1.4.27

The detection engine must inspect not only Network Layer details and information resident in packet headers, but a broad range of protocols across all layers of the computing stack and packet payloads as well.

C.1.4.28

The proposed firewall shall support network traffic classification which identifies applications across all ports irrespective of port/protocol/evasive tactic.



C.1.4.29

Must support Open based Application ID for access to community resources. However must have accuracy and ensure accountability of the application identification and protection. In addition, proposed solution must be easily customizable to address new and specific threats and applications quickly

C.1.4.30

Must support protocol decoder-based analysis state fully decodes the protocol and then intelligently applies signatures to detect network and application exploits

C.1.4.31

The proposed firewall should have on box Anti-Virus/Malware/Spyware signatures and must have minimum signatures update window of every one hour

C.1.4.32

Intrusion prevention signatures shall be built based on the vulnerability itself, A single signature must stop multiple exploit attempts on a known system or application vulnerability.

C.1.4.33 The firewall shall mask the internal network from the external world.

C.1.4.34

The firewall shall provide robust access control capability and be fast in making access control decisions. Access Control shall be done based on criteria such as source, destination IPs, port number, protocol, traffic type, application, date information (day of week, time of day), etc.

C.1.4.35 Multi-layer, Stateful, application-based filtering shall be done

C.1.4.36

It shall provide network segmentation features with powerful capabilities that facilitate deploying security for various internal, external and DMZ (Demilitarized Zone) sub- groups on the network, to prevent unauthorized access.

C.1.4.37 Ingress/egress filtering capability shall be provided.

C.1.4.38 There shall be support for detection of reconnaissance attempts such as IP address sweep, port scanning etc.

C.1.4.39 Firewall itself shall be resistant to attack and shall have protection against firewall evasion techniques.



C.1.4.40

Some basic attack protection features listed below but not limited to: a. Maximum number of protections against attacks that exploit weaknesses in the TCP/IP protocol suite b. It shall enable rapid detection of network attacks c. TCP reassembly for fragmented packet protection d. Brute force attack mitigation e. SYN cookie protection , SYN Flood, Half Open Connections and NUL Packets f. Protection against IP spoofing g. Malformed packet protection h. Java blocking, and real-time alerts

C.1.5 Management

C.1.5.1 The management platform must be accessible via a web-based interface and ideally with no need for additional client software

C.1.5.2 The management platform must provide a highly customizable dashboard.

C.1.5.3

The management platform must be capable of integrating third party vulnerability information into threat policy adjustment routines and automated tuning workflows

C.1.5.4

The management platform must be capable of role-based administration, enabling different sets of views and configuration capabilities for different administrators subsequent to their authentication.

C.1.5.5 Must support REST API for monitoring and config programmability

C.1.5.6 The management platform must provide multiple report output types or formats, such as PDF, HTML, and CSV.

C.1.5.7 The management platform must support multiple mechanisms for issuing alerts (e.g., SNMP, e-mail, SYSLOG).

C.1.5.8

The management platform must provide robust reporting capabilities, including a selection of pre-defined reports and the ability for complete customization and generation of new reports.

C.1.5.9 The management platform must risk reports like advanced malware, attacks and network



C.1.5.10

The management platform must include an integration mechanism, preferably in the form of open APIs and/or standard interfaces, to enable events and log data to be shared with external network and security management applications, such as Security Information and Event Managers (SIEMs), and log management tools.

C.1.6 Application control

C.1.6.1

The solution must integrate application control to reduce risks associated with applications usage and client-side attacks. It must provide a means of enforcing acceptable use policies of up to minimum 2000 application detectors.

C.1.6.2 The solution must support creation of user-defined application protocol detectors.

C.1.6.3

The solution must have content awareness with comprehensive file detection policies and blocking of files by types, protocols and directions.

C.1.6.4 The solution must provide capabilities for establishing and enforcing host compliance policies and alerting on violations.

C.1.6.5 The solution must be capable of easily identifying all hosts that exhibit a specific attribute or non-compliance condition.

C.1.7 Anti-Malware /APT Protection

C.1.7.1

The NGFW must have the capability to capture the suspected files and be able to check the reputation of the file through a cloud based sand-boxing infrastructure ( Bidder must mention response time)

C.1.7.2 The NGFW must be able to block the files if the file disposition from Cloud Sandbox or Local sandbox is found to be negative / suspicious.

C.1.7.3 The NGFW must be able to track the files movement within the network if the initial file disposition is unknown

C.1.7.4 The Anti-APT feature on NGFW must be able to seamlessly integrate with end-point Anti-APT solution

C.1.7.5

The proposed Threat (APT) protection platform shall support static and dynamic cloud based threat emulation and on premise threat emulation with protection of unknown threats

C.1.7.6 The proposed firewall shall block known network and application-layer vulnerability exploits



C.1.7.7 The proposed firewall must have Built‐in Signature and Anomaly based NG-IPS engine.

C.1.7.8

Identifies unknown malwares / signature less malwares, analyzes it based on malicious behaviors, and then automatically creates signature and then block it.

C.1.7.9

Blocks a range of known threats, including exploits, malware and spyware, across all ports, regardless of common threat-evasion tactics employed.

C.1.7.10 Limits the unauthorized transfer of files and sensitive data, and safely enables non-work-related web surfing.

C.1.7.11 Support for BOTNET protection, isolating malware communication to the command & control center

C.1.8 VPN Features

C.1.8.1

The firewall shall support Internet Protocol Security (IPSec) & SSL VPN from the same appliance. Key exchange with latest Internet Key Exchange (IKE), IKEv2. Site-to-site VPN tunnels: full-mesh / Star topology shall be supported.

C.1.8.2 AES, 3DES, SHA-1, SHA-2. IPSec Nat traversal Shall be supported

C.1.8.3 Bidder must mention the number of supporting IPSec/SSL VPN

C.1.9 SSL/SSH Decryption

C.1.9.1 The proposed firewall shall be able to identify, decrypt and evaluate SSL traffic in an inbound connection

C.1.9.2 The proposed firewall shall be able to identify, decrypt and evaluate SSH Tunnel traffic in an inbound and outbound connections

C.1.9.3

The NGFW shall support the ability to have a SSL inspection policy differentiate between personal SSL connections i.e. banking, shopping, health and non-personal traffic

C.1.9.4 SSL decryption must be supported on any port used for SSL i.e. SSL decryption must be supported on non-standard SSL port as well

Authorization Original Manufacturer Authorization Certificate with offered product/model must be submitted along with the bid

C.1.10 Manufacturer part number

C.1.10.1 Bidder must submit BOQ of proposed device including the details part numbers and Manufacturer warranty.



C.1.10.2 Bidder must submit the required performance document for the proposed device.

Warranty

Must have 03 years OEM Warranty including subscription (IPS, Malware/Spyware/AV prevention, APT) & Support and bidder Must quote the manufacturer support part code.

Training OEM Technical Training must have to provide

for two (2) personnel of the NCC Bank for the supplied products and features

C.2. DMZ Firewall: In order to secure our Internet based services like Internet Banking, SMS Banking, E-

mail etc. we require to setup Next Generation Firewall in our DMZ zone.

SL Technical Specification Compliance Y/N Remarks

Type Next Generation Firewall

Quality Certification ISO, FCC, UL, CE or To be mentioned by the bidder

Brand To be mentioned by the bidder

Model To be mentioned by the bidder

Country of Origin USA or EU Country of Assemble / Manufacture

USA or EU

Enclosure Type Rack-mountable Industry Evaluations Firewall solution offered from OEM must be

rated as ‘leaders’ or 'Challengers' in the latest Magic Quadrant for Firewall published by Gartner

C.2.1 Hardware Architecture

C.2.1.1

The appliance must be capable of providing Firewall, IPS/Threat prevention, Application visibility, URL filtering, Anti-Malware, Anti-Virus, Advance Malware protection Services (Anti-APT) and VPN (IPSec/SSL) in a single appliance.

C.2.1.2

The appliance hardware must be a multicore CPU architecture with a hardened 64 bit operating system to support higher memory ( Bidder must mention no of cores)

C.2.1.3 Proposed Firewall must work on flow mode with all the content inspection features enable

C.2.1.4 Proposed appliance must have minimum 8GB RAM for higher performance



C.2.1.5

Proposed firewall must have Next generation firewall architecture and must not have proxy or unified threat management architecture

C.2.1.6

Proposed Firewall must not be proprietary ASIC based in nature & must be open architecture based on multi-core cpu's to protect & scale against dynamic latest security threats.

C.2.1.7 The appliance must have at least 8 * 1G and 2 * 10G enable ports from Day one


C.2.2 Performance & Scalability

C.2.2.1

Firewall Throughput: Must be 4 Gbps however above throughput will get preference

C.2.2.2

Threat Prevention Throughput: Must be 2 Gbps however above throughput will get preference

C.2.2.3

IPSec VPN Throughput: Must be 500 Mbps however above throughput will get preference

C.2.2.4 Max Session: Must not be less than 500,000

C.2.2.5 New Connection per second: Must not be less than 40,000

C.2.2.6 Firewall must support atleast 1000 VLANs C.2.3 High-Availability Features

C.2.3.1 Firewall must support Active/Standby failover

C.2.3.2

Firewall must support ether-channel functionality for the failover control & date interfaces for provide additional level of redundancy

C.2.3.3

Firewall must support redundant interfaces to provide interface level redundancy before device failover

C.2.3.4

Firewall must support 802.3ad Ether-channel functionality to increase the bandwidth for a segment.

C.2.3.5

Firewall must have integrated redundant power supply

C.2.3.6 Firewall must have redundant hot-swappable FANs

C.2.4 NGFW Firewall Features



C.2.4.1 The solution must be capable of gathering information about network hosts & their activities, such as operating system, services, open ports, client applications & vulnerabilities, to assist with multiple activities, such as intrusion event data correlation, elimination of false positives & policy compliance when traffic passes through it

C.2.4.2 Firewall must support creating access-rules with IPv4 & IPv6 objects simultaneously

C.2.4.3 Firewall must support operating in Layer2, Layer3 & transparent mode

C.2.4.4 Must support Static, RIP, OSPF, OSPFv3 and BGP

C.2.4.5 Firewall must support manual NAT and Auto-NAT, static NAT, dynamic NAT, dynamic PAT

C.2.4.6 Firewall must support NAT 66 (IPv6-to-IPv6), NAT 64 (IPv6-to-IPv4) & NAT 46 (IPv4-to-IPv6) functionality

C.2.4.7 Firewall must support Multicast protocols like IGMP, PIM, etc

C.2.4.8 Must support security policies based on security group names in source or destination fields or both

C.2.4.9 Must support capability to limit bandwidth on basis of apps / groups, Networks / Geo, Ports, etc

C.2.4.10 Must be capable of dynamically tuning IDS/IPS sensors (e.g., selecting rules, configuring policies, updating policies, etc.) with minimal human intervention.

C.2.4.11 Must support Reputation- and category-based URL filtering offering comprehensive alerting and control over suspect web traffic and enforces policies on more than 280 million of URLs in more than 80 categories.

C.2.4.12 Must be capable of automatically providing the appropriate inspections and protections for traffic sent over non-standard communications ports.

C.2.4.13 Must be able to link Active Directory and/or LDAP usernames to IP addresses related to suspected security events.

C.2.4.14 Must support DNS sink holing for malicious DNS request from inside hosts to outside bad domains and must be able to integrate and query third party external threat intelligence data bases to block or sinkhole bad IP address, Domain and URLs



C.2.4.15 Must be able to call 3rd party threat intelligence data on malicious IPs, URLs and Domains to the same firewall policy to block those malicious attributes and list must get updated dynamically with latest data

C.2.4.16 Vendor must automatically push dynamic block list with latest threat intelligence data base on malicious IPs, URLs and Domains to the firewall policy as an additional protection service

C.2.4.17 Must be capable of detecting and blocking IPv6 attacks.

C.2.4.18 Solution must have the ability to analyze activities to detect threats emerging from inside the network. This includes the ability to establish “normal” traffic baselines through flow analysis techniques and the ability to detect deviations from normal baselines. If the vendor does not support this feature on the Firewall they can propose separate solution.

C.2.4.19 The proposed firewall shall delineate specific

instances of Proxies (ultrasurf, ghostsurf, freegate, etc.)

C.2.4.20 The solution must provide IP reputation feed that comprised of several regularly updated collections of poor reputation of IP addresses determined by the proposed security vendor

C.2.4.21 The proposed firewall must be able to implement Zones, IP address, Port numbers, User id, Application id and threat protection profile under the same firewall rule or the policy configuration.

C.2.4.22 The proposed firewall shall be able to protect the user from the malicious content upload or download by application such as Facebook chat or file sharing by enforcing the total threat protection for known and unknown malicious content such as virus, malware or a bad URLs.

C.2.4.23 Solution must support IP reputation intelligence feeds from third party and custom lists of IP addresses including a global blacklist.

C.2.4.24 Must support URL and DNS threat intelligence feeds to protect against threats

C.2.4.25 Solution must be capable of passively gathering details unique to mobile devices traffic to identify a wide variety of mobile operating systems, mobile applications and associated mobile device hardware.



C.2.4.26 Must support more than 4000 application layer and risk-based controls that can invoke tailored intrusion prevention system (IPS) threat detection policies to optimize security effectiveness.

C.2.4.27 Must be capable of providing network-based detection of malware by checking the disposition of known files in the cloud using the SHA-256 file-hash as they transit the network and capability to do dynamic analysis on-premise on purpose built-appliance (if required in future)

C.2.4.28 NGFW OEM must have its own threat intelligence analysis center and must use the global footprint of security deployments for more comprehensive network protection.

C.2.4.29 The detection engine must support capability of detecting and preventing a wide variety of threats (e.g., malware, network probes/reconnaissance, VoIP attacks, buffer overflows, P2P attacks, etc.).

C.2.4.30 Must be able to identify attacks based on Geo-location and define policy to block on the basis of Geo-location

C.2.4.31 The detection engine must support the capability of detecting variants of known threats, as well as new threats

C.2.4.32 The detection engine must incorporate multiple approaches for detecting threats, including at a minimum exploit-based signatures, vulnerability-based rules, protocol anomaly detection, and behavioral anomaly detection techniques. Identify and explain each type of detection mechanism supported.

C.2.4.33 The detection engine must inspect not only Network Layer details and information resident in packet headers, but a broad range of protocols across all layers of the computing stack and packet payloads as well.

C.2.4.34 The proposed firewall shall support network traffic classification which identifies applications across all ports irrespective of port/protocol/evasive tactic.

C.2.4.35 The detection engine must incorporate multiple approaches for detecting threats, including at a minimum exploit-based signatures, vulnerability-based rules, protocol anomaly detection, and behavioral anomaly detection techniques. Identify and explain each type of detection mechanism supported.



C.2.4.36 Must support Open based Application ID for access to community resources. However must have accuracy and ensure accountability of the application identification and protection. In addition, proposed solution must be easily customizable to address new and specific threats and applications quickly

C.2.4.37 The proposed firewall shall support network

traffic classification which identifies applications across all ports irrespective of port/protocol/evasive tactic.

C.2.4.38 Must support protocol decoder-based analysis state fully decodes the protocol and then intelligently applies signatures to detect network and application exploits

C.2.4.39 The proposed firewall should have on box Anti-Virus/Malware/Spyware signatures and must have minimum signatures update window of every one hour

C.2.4.40 Intrusion prevention signatures must be built based on the vulnerability itself, A single signature must stop multiple exploit attempts on a known system or application vulnerability.

C.2.4.41 The firewall shall mask the internal network from the external world.

C.2.4.42 The firewall shall provide robust access control capability and be fast in making access control decisions. Access Control shall be done based on criteria such as source, destination IPs, port number, protocol, traffic type, application, date information (day of week, time of day), etc.

C.2.4.43 The proposed firewall shall perform content based signature matching beyond the traditional hash base signatures

C.2.4.44 Multi-layer, Stateful, application-based filtering shall be done

C.2.4.45 It shall provide network segmentation features with powerful capabilities that facilitate deploying security for various internal, external and DMZ (Demilitarized Zone) sub- groups on the network, to prevent unauthorized access.

C.2.4.46 Ingress/egress filtering capability shall be provided.

C.2.4.47 There shall be support for detection of reconnaissance attempts such as IP address sweep, port scanning etc.



C.2.4.48 Firewall itself shall be resistant to attack and shall have protection against firewall evasion techniques.

C.2.4.49 Some basic attack protection features listed below but not limited to: a. Maximum number of protections against attacks that exploit weaknesses in the TCP/IP protocol suite b. It shall enable rapid detection of network attacks c. TCP reassembly for fragmented packet protection d. Brute force attack mitigation e. SYN cookie protection , SYN Flood, Half Open Connections and NUL Packets f. Protection against IP spoofing g. Malformed packet protection h. Java blocking, and real-time alerts

C.2.5 Management

C.2.5.1 The management platform must be accessible via a web-based interface and ideally with no need for additional client software

C.2.5.2 The management platform must provide a highly customizable dashboard.

C.2.5.3 The management platform must be capable of integrating third party vulnerability information into threat policy adjustment routines and automated tuning workflows

C.2.5.4 The management platform must be capable of role-based administration, enabling different sets of views and configuration capabilities for different administrators subsequent to their authentication.

C.2.5.5 Must support REST API for monitoring and config programmability

C.2.5.6 The management platform must provide multiple report output types or formats, such as PDF, HTML, and CSV.

C.2.5.7 The management platform must support multiple mechanisms for issuing alerts (e.g., SNMP, e-mail, SYSLOG).

C.2.5.8 The management platform must provide robust reporting capabilities, including a selection of pre-defined reports and the ability for complete customization and generation of new reports.

C.2.5.9 The management platform must risk reports like advanced malware, attacks and network



C.2.5.10 The management platform must include an integration mechanism, preferably in the form of open APIs and/or standard interfaces, to enable events and log data to be shared with external network and security management applications, such as Security Information and Event Managers (SIEMs), and log management tools.

C.2.6 Application control

C.2.6.1 The solution must integrate application control to reduce risks associated with applications usage and client-side attacks. It must provide a means of enforcing acceptable use policies of up to minimum 2000 application detectors.

C.2.6.2 The solution must support creation of user-defined application protocol detectors.

C.2.6.3 The solution must have content awareness with comprehensive file detection policies and blocking of files by types, protocols and directions.

C.2.6.4 The solution must provide capabilities for establishing and enforcing host compliance policies and alerting on violations.

C.2.6.5 The solution must be capable of easily identifying all hosts that exhibit a specific attribute or non-compliance condition.

C.2.7 Anti-Malware /APT Protection

C.2.7.1 The NGFW must have the capability to capture the suspected files and be able to check the reputation of the file through a cloud based sand-boxing infrastructure ( Bidder must mention response time)

C.2.7.2 The NGFW must be able to block the files if the file disposition from Cloud Sandbox or Local sandbox is found to be negative / suspicious.

C.2.7.3 The NGFW must be able to track the files movement within the network if the initial file disposition is unknown

C.2.7.4 The Anti-APT feature on NGFW must be able to seamlessly integrate with end-point Anti-APT solution

C.2.7.5 The proposed Threat (APT) protection platform shall support static and dynamic cloud based threat emulation and on premise threat emulation with protection of unknown threats

C.2.7.6 The proposed firewall shall block known network and application-layer vulnerability exploits



C.2.7.7 The proposed firewall must have Built‐in Signature and Anomaly based NG-IPS engine.

C.2.7.8 Identifies unknown malwares / signature less malwares, analyzes it based on malicious behaviors, and then automatically creates signature and then block it.

C.2.7.9 Blocks a range of known threats, including exploits, malware and spyware, across all ports, regardless of common threat-evasion tactics employed.

C.2.7.10 Limits the unauthorized transfer of files and sensitive data, and safely enables non-work-related web surfing.

C.2.7.11 Support for BOTNET protection, isolating malware communication to the command & control center

C.2.8 VPN Features

C.2.8.1 The firewall shall support Internet Protocol Security (IPSec) & SSL VPN from the same appliance. Key exchange with latest Internet Key Exchange (IKE), IKEv2. Site-to-site VPN tunnels: full-mesh / Star topology shall be supported.

C.2.8.2 AES, 3DES, SHA-1, SHA-2. IPSec Nat traversal Shall be supported

C.2.8.3 Bidder must mention the number of supporting IPSec/SSL VPN (Minimum 10)

C.2.9 SSL/SSH Decryption

C.2.9.1 The proposed firewall shall be able to identify, decrypt and evaluate SSL traffic in an inbound connection

C.2.9.2 The proposed firewall shall be able to identify, decrypt and evaluate SSH Tunnel traffic in an inbound and outbound connections

C.2.9.3 The NGFW shall support the ability to have a SSL inspection policy differentiate between personal SSL connections i.e. banking, shopping, health and non-personal traffic

C.2.9.4 SSL decryption must be supported on any port used for SSL i.e. SSL decryption must be supported on non-standard SSL port as well

Authorization Original Manufacturer Authorization Certificate with offered product/model must be submitted along with the bid

C.2.10 Manufacturer part number



C.2.10.1 Bidder must submit BOQ of proposed device including the details part numbers and Manufacturer warranty.

C.2.10.2 Bidder must submit the required performance document for the proposed device.

Warranty

Must have 03 years OEM Warranty including subscription (IPS, Malware /Spyware/AV prevention, URL, APT) & Support and bidder Must quote the manufacturer support part code.

Training OEM Technical Training must have to provide

for two (2) personnel of the NCC Bank for the supplied products and features

C.3 Web Application Firewall (WAF): Performs deep packet inspection of incoming traffic to detect threats by creating a security layer in front of the web server application. Total 2 (two) numbers of Web Application Firewall.

SL Technical Specifications Compliance

Y/N Remarks

Brand Must be mentioned by bidders

Model Must be mentioned by bidders

Country of Origin USA or EU

Country of Manufacture

USA or EU

Certification

1. The WAF must be qualified in the ICSA, NSA Lab Report 2. WAF solution offered from OEM must be rated as ‘Leaders’ or 'Challengers' in the latest Magic Quadrant for Firewall published by Gartner

C.2.1 Architecture

C.3.1.1 Solution must be appliance based with hardened OS.

C.3.1.2 Must have WAN/LAN/MGMT ports

C.3.1.3 Must have minimum 4 x 1Gbps + 1Gbps Management ports (Copper or Fiber)

C.3.1.4 Minimum throughput is 2 Gbps





Y/N Remarks

C.3.1.5 The solution must support minimum 15K HTTP, 4K HTTPS Transactions / Sec & 150K Concurrent connections

C.3.1.6 Must support Ipv4 and Ipv6 traffic

C.3.1.7

The WAF must be deploy-able in full reverse proxy mode as well as transparent bridge mode, where all traffic is re-directed to flow through the WAF.

C.3.1.8 Must support Ethernet Bypass

C.3.2 Features

C.3.2.1 The solution must be able to terminate and offload SSL traffic to the WAF itself.

C.3.2.2

a. The WAF must decrypt the encrypted traffic to get access to the HTTP data. b. Client Authentication based on client (SSL) certificated must be available c. OCSP and CRL support must be available for client certificate validation d. It must be possible to send the content from client certificates to the application using some alternative transport method (e.g. request headers). e. It must be possible to encrypt the back-end traffic (i.e. the traffic from the WAF to the web server) f. Must be able to select SSL cipher suites

C.3.2.3

The solution must provide a mode whereby it can encrypt plain-text HTTP on behalf of the web applications, redirecting incoming HTTP requests to the HTTPS service and rewriting HTTP hyperlinks in the response to HTTPS. No change will be required to the back-end servers or application code.

C.3.2.4 The solution must support LLCF in bridge mode operation.

C.3.2.5 The solution must be able to employ connection pooling technology to optimize back-end network operations and server resources

C.3.2.6

The solution must have High Availability (HA) for avoiding single points of failures. Active-Active HA must be supported with automatic configuration synchronization, fail-over and fail-back.

C.3.2.7

The solution must support multi-tenancy, i.e. have advanced, multiple routing capabilities: it must support assigning protected web applications to virtual networking containers with independent routing tables and network ACLS.




Y/N Remarks

C.3.2.8 The solution must support multiple routing tables for network virtualization.

C.3.2.9

WAF must be able to learn from both successful requests/responses (200 Ok) as well as partially successful requests/responses (302 and 301 responses)

C.3.2.10 WAF must Link Loss Carry Forward function for physical interfaces in a Bridge Mode Deployment

C.3.3 Security Capabilities

C.3.3.1

The solution must support a session recording feature to save the complete transaction between the client and server that includes the request URL, headers request data and response data.

C.3.3.2

Solution must offer a log-only (detection) mode that applies the security policies exactly as if it were in prevention mode. The mode setting must be specifiable on a granular level to application security constructs like URL, query/FORM parameters, cookies and header related security rules on an individual basis.

C.3.3.3

The solution must provide a mode whereby it can rewrite HTTP applications to HTTPS on-the-fly, e.g. by modifying all outbound content, and redirect incoming HTTP requests to the HTTPS No changes must be required to the back-end servers or application code. Must be able to support this function natively – without any additional scripting

C.3.3.4

The solution must support the following blocking capabilities – connection reset, custom error response page, redirect the request or block the offending client IP(s) for a time period.

C.3.3.5 WAF must support URL and Header rewrite functions and must support translation rules for HTML, JS, and CSS response bodies.

C.3.3.6

The solution must allow the administrator to restrict access to various HTTP and WEBDAV methods, including HEAD, CONNECT, TRACE, etc. on a per URL basis.

C.3.3.7

The solution must be able to apply different restriction policies to different parts of the request. Restriction must be applicable at the following levels – applications, URLs, query/FORM parameters, headers, cookies, and request rates.




Y/N Remarks

C.3.3.8

The solution must allow enforcing the following protocol related restrictions on the requests and these must be specifiable on an individual URL basis:

a) HTTP method length b) Request line length c) URI length d) Query string length e) Protocol length f) Header name, value, and number g) Request body length h) Cookie name, value and number. i) Parameter name, value and number j) Max length (per file) and number for

uploaded files (via POST).

C.3.3.9

The solution must be able to “cloak” error responses to hide sensitive server related information in the response body and response headers.

C.3.3.10

The solution must be capable of analyzing the response body, irrespective of the response code, to completely block the response or cloak sensitive data patterns, if the later are found in it. Credit card patterns must be searched by default. Other patterns must be specifiable in a regular expression format, preferably assisted by a regex builder utility.

C.3.3.11 The solution must support the ability to operate a signature/pattern in passive mode even if the overall security policy is active.

C.3.3.12

The solution must support the following normalization methods: URL Decoding including hex encoding, (e.g. %xx), Null bytes string termination, self-referring paths (/./), path back-references (/../) and decode ampersand encoding (e.g. &# 99;, & quot;, &#xAA) a. It must detect overlong UTF-8 encoding of ascii characters (which is a technique used for obfuscation of ascii range meta characters like “<” etc.)




Y/N Remarks

C.3.3.13

The solution must support a negative security model where attacks are detected by performing a regular expression match against incoming URL requests.

a) It must be possible to specify granular

regex based matching on all parts of the

request – URI, parameters, headers,

cookies to select the URL space to which

the corresponding rules must apply. For

example: (i) Applying rules to only those

requests where parameter user is

present in the URI, (ii) Parameter xyz =

xxx, or Host Header =

login.example.com or User Agent

contains Mozilla etc.

b) The solution must allow configuring rules

with complex logic with operators such

as logical AND and logical OR, exists,

contains, equals, etc. For example, rules

like (i) Header User-Agent contains

Mozilla OR URI contains /abc*html OR

HTTP-Version = 1.0 && Client-IP is in

192.168.1.0/24

C.3.3.14

The solution must support a positive security model that allows specification of legal “white-listed” values in various security policy elements, while all other values are denied. E.g.: (a) List of allowed values for FORM/query parameters (allowed data types, list, etc), (b) List of Allowed meta-characters /keywords in URL, parameters (c) Valid application profile – allowed URLs, and the parameters for each URL with individual security profiles for both, (d) Allowed HTTP methods for each URL (e) Allowed Content Types per URL, (f) File Upload Extensions allowed

C.3.3.15 The solution must have the ability to mark fields as read-only to protect against form tampering.

C.3.3.16

The solution must include protection for the common attacks mentioned in the OWASP top ten e.g. SQL Injection, Cross Site Scripting, CSRF, RFI, OS Command Injection etc.

C.3.3.17 The WAF must support URL encryption and must allow the administrator to set URL encryption




Y/N Remarks

rules for specific parts of the application.

C.3.3.18 The product must be able to analyze and secure traffic where a parameter is split across multiple instances.

C.3.3.19

The solution must provide for rate based attack protection – a. Protection from Brute Force attacks against access controls. b. Detect brute force attacks (repeated requests for the same resource) against any part of the application. c. React by either slowing or blocking the attacker down. d. Detect brute force attacks against session management (too many sessions given out to a single IP address or range).

C.3.3.20

The solution must protect session tokens, i.e. cookies: a. Sign cookies, to prevent clients from changing them b. Encrypt cookies, to hide contents. c. Prevent Cookie Replay attacks d. Allow for exempting certain cookies from security checks

C.3.3.21 The solution must allow for specification (and detection) of hidden FORM fields and prevent such fields from modification by the clients.

C.3.3.22

The solution must employ adequate security measures against CSRF attacks like generating unique URLs by making links session specific and using referrer checks.

C.3.3.23 The solution must provide Ant-Virus or anti-malware protection on the file uploads.

C.3.3.24 WAF must support bulk fix for exception policies/recommended policies.

C.3.3.25 Solution must be able to allow deny traffic based on IP address

C.3.3.26 The solution must provide Geo-IP detection of clients and blocking based on Geographical region on the clients

C.3.3.27

The solution must support the ability to save the search criteria of the filters set by the administrator for future repeated use to reduce administrative overhead

C.3.3.28 The solution must provide protection from application layer DDOS attacks such as Slowloris, RUDY and slow read attacks

C.3.3.29 The solution must be able to detect an block requests coming from anonymous proxies




Y/N Remarks

C.3.3.30 The solution must be able to detect an block requests coming from satellite ISPs

C.3.3.31 The solution must be able to identify and block requests coming from TOR networks

C.3.3.32 The solution must integrate with a tier 1 IP Reputation intelligence service to detect infected clients that are part of bot-nets

C.3.3.33

The solution must provide passive challenge-response mechanisms to distinguish malicious bots from human browsers, e.g. transparent client fingerprinting via script injection.

C.3.3.34

The solution must support evasion techniques for WAF fingerprinting itself. For example, it must support modification of the names of the system generated parameters and cookies by the administrators.

C.3.3.35

The solution must have the ability to generate and issue CAPTCHA queries to challenge suspicious requests, such as those coming from bots.

C.3.3.36 Solution must be able to protect against SSL based attacks like SSL renegotiation, BEAST, CRIME, padding oracle, etc. c)

C.3.4 Management Capabilities

C.3.4.1

The product must come with a signature database and it must be possible for the WAF to automatically retrieve the latest signatures for the rule database periodically, without manual intervention.

C.3.4.2

The solution must provide comprehensive logging of web attacks, access traffic and admin audit trails. (a) Commonly-used log formats must be supported e.g. Common, W3C extended, NCSA extended etc. (b) Logs must be exportable via syslog and SFTP. (c) It must be possible to turn off logging for select security policy violations. (d) Log information must include session and login identifiers. (e) It must be possible to suppress/mask sensitive parameters from getting logged.

C.3.4.3

The solution must provide an easy way to include legitimate requests originally considered as attacks by the current security policy (false positives). This task mustn’t be harder than clicking on a log entry and pushing changes to the WAF.




Y/N Remarks

C.3.4.4

The solution must automatically employ intelligent heuristics to learn false positives from request or response traffic and recommend/effect reduction of false positives by modifying the security policies.

C.3.4.5

The solution must provide the ability to define different policies for different applications and provide canned policies for common applications like Outlook Web Access, SharePoint and Oracle.

C.3.4.6

The management components must include facilities to develop custom signatures that identify specific, unique risks associated with protected applications, preferably assisted through a regex tool.

C.3.4.7

The security policies must offer a high level of granularity. Switching between detection and policy enforcement (prevention) modes cannot be associated with the whole application, but must be granularly associated with every component of an application or every type of attack.

3.4.8

The solution must provide a comprehensive “profile learning” process: (a) Configuration facilities to specify trusted hosts that will let the WAF device learn only legitimate traffic. (b) Ability to protect from common web attacks while generating the profile. (c) The profile agent must be able to create very specific exceptions where necessary. Creating an exception for a name parameter to allow a name like “John Mc’Donalds” must not allow all SQL patterns, but only ones related to single quotes. (d) The profiler must learn the valid profiles from requests as well as responses. It must be able to parse the response content containing FORM elements to set up parameter profiles from the HTML like max lengths, parameter types – text input, hidden select / dropdowns menus with allowed lists of values on a session as well as global basis. (e ) There must be a provision to specify dynamic query parameters for determining unique page profiles. For example, query parameters like “page” and “action”, different values of which will generate different pages with different FORMs etc., even though the URL may remain same (/abc.html?page=1 versus /abc.html?page=2).




Y/N Remarks

The profiler must correctly learn these as 2 different URL profiles and not one URL profile for /abc.html with the combined FORMs from both pages.

C.3.4.9

There must be multiple profiles in the device user login, to support segregated responsibilities. These might include, but not be limited to device operators (for box configuration), application owners (for policy configuration), auditors (for log inspection), certificate managers, network admins etc. It must also be possible to create custom roles.

C.3.4.10

The solution must support role based access control and must support integration with LDAP and RADIUS authentication Databases for the authentication of the RBA users

C.3.4.11 It must be possible to authenticate such RBA users from an external LDAP service.

C.3.4.12

The product must provide the ability to specify trusted hosts (identified by IP addresses or IP address ranges) which sometimes need to be allowed to perform activities that are otherwise prohibited by policy.

C.3.4.13

The management application must include a Web Based interface with both HTTP and HTTPS access from dedicated management interface(s).

C.3.4.14

The solution must provide a “template” based solution to create security policy and sub policy templates, from existing policies or manually, and apply them to different application on the same or different device.

C.3.4.15 The solution must have a centralized management device or interface for managing multiple units

C.3.4.16 The solution must support integration with a centralized management platform over a web interface.

C.3.4.17 The solution must provide a customizable log format to easily integrate with any SIEM solution.

C.3.4.18 The solution must integrate with Web site vulnerability scanning tools

C.3.4.19

The solution must have the ability to track all security policy changes and have the ability to record all the pre and post values of each change

C.3.4.20 The solution must provide alerting mechanisms via email and SNMP traps.




Y/N Remarks

C.3.4.21

The solution must provide attack and traffic reports a. Reports must be customizable based on the information logged in the logs. b. Must be able to generate them on demand or deliver periodically via email or SFTP.

C.3.4.22 The solution must provide PCI compliance reports

C.3.5 XML Firewall

C.3.5.1 The solution must support protection of XML Web Services with common web application as well as XML specific attacks.

C.3.5.2 It must be possible to force conformance with full WS-I Basic specification.

C.3.5.3

The solution must provide for validating XML Documents and protecting against XML DoS and injection attacks (SQL, OS, XSS, XSRF etc.)

C.3.5.4 The solution must provide for validating SOAP messages, headers and body against a WSDL schema.

C.3.6 User Access Control

C.3.6.1

The solution must be able to offload user authentication for protected applications. It must be possible to specify custom login and logout pages for user authentication.

C.3.6.2 The authentication module must be able to integrate with external authentication directories such as LDAP, Radius etc.

C.3.6.3

The solution must support two factor authentication mechanisms: (a) Client SSL certificates + password (b) Integration with token based approaches like RSA SecurID (c) Integration with SMS Pass-code for 2-factor authentication over mobile phone SMS network.

C.3.6.4 The solution must support password policy check for administrators who manage the solution.

C.3.6.5

It must be possible to specify different authorization policies for different parts of the web sites, post authentication. For example, users from LDAP group A have access to /employee/* whereas only users from group B have access to /partners/*

C.3.6.6

The solution must allow for single sign on across different protected web applications. The user once authenticated must be able to browse through different applications across single and multiple cookie domains without having to re-login.




Y/N Remarks

C.3.6.7

It must be possible to track full user sessions (complete request and response bodies) and activity by a user id for auditing / troubleshooting purposes as required.

C.3.7 Application Delivery and Acceleration

C.3.7.1 The solution should have inbuilt load balancing ability which support layer 7 persistence

C.3.7.2

The solution must be capable to route different application content requests to different application servers. For example, it must allow to route all image requests to one server and all script processing requests to another server. a. It must be capable to add multiple servers to serve a particular type of content and load balance internally amongst them independent of the parent application's Load Balancing Policy.

C.3.7.3

It must be capable to cache selected outgoing responses so that the subsequent requests for the same content is directly served from the WAF instead of being forwarded to the server.

C.3.7.4

The solution must be capable to support outbound response compression to reduce bandwidth consumption for verbose content. Compression must be specifiable on a content type basis. E.g. compress JavaScript, XML etc.

C.3.7.5

The solution must be capable to operate on a reverse proxy architecture leveraging many key benefits like TCP Multiplexing, HTTP Caching and Compression, L4-L7 Load balancing (including custom protocol and non-http service load balancing). This provides a comprehensive solution for customers, thus eliminating need for appliances for specific functions.

C.3.8 Supports, Third party recognitions

C.3.8.1 Vendor is a legal entity in Bangladesh.

C.3.9 Warranty & Support Service

C.3.9.1 Must have 03 years OEM Warranty including subscription & Support and bidder must quote the manufacturer support part code.

C.3.10 Training

C.3.10.1 OEM Technical Training must have to provide for two (2) personnel of the NCC Bank for the supplied products and features.



PART-D: APPENDIXES

D.1 Schedule of Technical proposal

The bidder must provide the following information in the Technical offer:

1. Name, address, contact person, his/her email and phone number of the bidder to be written in its official letter head pad.

2. Documents evidencing the bidder’s qualification

a. Bidder’s valid Trade License and latest TIN/Income Tax Certificate and b. Experience Certificate of the bidder c. Credential of the proposed project manager who will execute the project if work order is given

to the bidder. d. Implementation plan elaborating all the phases of the project indicating the milestones, roles,

responsibilities, resources etc. e. Any other document that proves the strength of the bidder in favor of executing the project.

3. Annual Maintenance Contract agreement of the supplied tools.

4. A description of the Technical risk factors that might arise during the project and its remediation plan.

5. Bidder must provide Support Matrix with necessary documents.



D.2 Schedule of Price Proposal

The financial offer must be submitted in the following format and must include delivery, installation, customization, configuration of the supplied tools as mentioned in PART-C. It also includes the cost of the certification activities mentioned in PART-B and other associated costs. All costs must include applicable charges, Taxes, VAT etc., if any.

a) Cost of the supplied tools including VAT, TAX etc for lot:1, lot:2 and lot:3 in different documents

Item Name Unit Unit Price (i) (BDT)

Deployment and

configuration cost (ii) (BDT)

Total Price (Including three year service) (BDT)

AMC (BDT) Total

3 Year Licenses (x=i+ii)

4th Year (y) 5th Year (z) 5 Years price (x+y+z)

2

Note: The above figure must be quoted in the bid form for price proposal.



D.3 Form of Technical Proposal

National Credit and Commerce Bank Limited

13/1 & 13/2 Toyenbee Circular Road,

Motijheel Commercial Area,

Dhaka-1000, Bangladesh

Gentlemen:

We have examined the whole bidding documents thoroughly including the addenda nos ------. We have understood and checked these documents and have not found any error in them. We accordingly offer to execute all related activities including any other works in order to enable the bank to implement IT Security tools including supply, install, and configuration of the tools as mention in this bid document.

We further undertake, if invited to do so by you, and at our own cost, to attend a clarification meeting at a place of your choice, for the purpose of reviewing our technical proposal and duly noting all amendments and additions thereto, and noting omissions there from that you may require, and to submit a supplementary price proposal if the amendments, additions and omissions that you require would alter our price proposal as submitted with our bid.

We are, Gentlemen

Yours faithfully

Signature ------------------------- in the capacity of duly authorized to sign bids for and on behalf of -------------------------------------------------------------------------------------------------

Address

---------------------------------------------

---------------------------------------------

---------------------------------------------

Date -------------------------------



D.4 FORM OF PRICE PROPOSAL





Gentlemen:

We have examined the whole bidding documents. We have understood and checked these documents and have not found any errors in them. We accordingly offer to execute all related activities including any other works in order to enable the bank to IT Security tools including supply, install, and configuration of the tools as mention in this bid document at a total cost of (BDT) -----in figure-------(in words)

We agree to abide by this Bid until-------------------- and it shall remain bidding upon us and may be accepted at any time before that date. If our Bid is accepted, we will provide the specified performance security, Commence the works as soon as reasonably possible after receiving the Bank’s notice to commence, and complete the Works in accordance with the above-named documents within the time stated in the bidding document.

Unless and until a formal Agreement is prepared and executed this Bid, together with your written acceptance thereof, shall constitute a binding contract between us.

We understand that you are not bound to accept the lowest or any bid you may receive.

We are, Gentlemen

Yours faithfully

Signature ------------------------ in the capacity of duly authorized to sign bids for and on behalf of -------------------------------------------------------------------------------------------------

Address

---------------------------------------------

---------------------------------------------

---------------------------------------------

Date -------------------------------



D.5 Form of Performance Security (Bank Guarantee)

To:





WHEREAS____________________________ [name and address of Vendor] (hereinafter called the “Vendor” has undertaken to execute all related activities including any other works in order to enable the bank to obtain IT Security tools including supply, install, and configuration of the tools as mention in this bid document(hereinafter called the “Contract“);

AND WHEREAS it has been stipulated by you in the said Contract that the Supplier shall furnish you with a Bank Guarantee by a recognized Bank for the sum specified therein as security for compliance with its obligations in accordance with the Contract;

AND WHEREREAS we have agreed to give the Supplier such a Bank Guarantee;

NOW THEREFORE we hereby affirm that we are the Guarantor and responsible to you, on behalf of the Supplier, up to a total of __________________ [amount of Guarantee] _________________________________ [in words], such sum being payable in BDT and we undertake to pay you, upon your first written demand and without cavil or argument, any sum or sums within the limits of ____________________ [amount of Guarantee] as aforesaid without your needing to prove or to show grounds or reasons for your demand for the sum specified therein.

We hereby waive the necessity of your demanding the said debt from the Supplier before presenting us with the demand.

We further agree that no change or addition to or other modification of the terms of the contract or of the Works to be performed there under or of any of the contract documents which may be made between you and the Supplier shall in any way release us from any liability under this guarantee, and we hereby waive notice of any such change, addition or modification.

This guarantee shall be valid until the date of issue of the Performance Certificate.

Signature and Seal of the Guarantor _______________________________

Name of the Bank _______________________________

Address _______________________________

Date _______________________________

Date post:	29-Mar-2020
Category:	Documents
Upload:	others
View:	0 times
Download:	0 times