Combined Bank Senior Officer Exam 16 October 2026 — Question Solution | সমন্বিত ব্যাংক (ব্যাংকার্স সিলেকশন কমিটি) সিনিয়র অফিসার নিয়োগ পরীক্ষা ২০২৬ — প্রশ্ন সমাধান

A firewall, an IDS and an IPS all inspect network traffic, but they differ in where they sit and what they do with suspicious traffic.

• Firewall: an inline device or software that enforces an access policy between networks or zones (Internet, DMZ, LAN). It allows or denies traffic by rules on IP addresses, ports, protocol and connection state; a next-generation firewall (NGFW) also checks applications and users. Its default rule is "deny all that is not explicitly allowed".
• IDS (Intrusion Detection System): a passive, out-of-band monitor. It receives a copy of traffic (switch SPAN/mirror port or a network TAP), compares it with attack signatures or a baseline of normal behaviour (anomaly detection), and raises an alert. It does not block traffic.
• IPS (Intrusion Prevention System): an inline system with IDS-style detection that acts in real time: it drops the malicious packets, resets the connection or blocks the attacker's IP.

Comparison

Feature	Firewall	IDS	IPS
Main job	Control access by policy	Detect and alert	Detect and block
Placement	Inline, at the boundary between zones	Out-of-band (SPAN port/TAP)	Inline, usually behind the firewall
Decision basis	Rules: IP, port, protocol, state (NGFW: application, user)	Signatures + anomaly/behaviour	Signatures + anomaly/behaviour
Inspects payload?	Mostly headers (NGFW: deep inspection)	Yes, deep packet inspection	Yes, deep packet inspection
Response	Permit / deny	Alert, log, notify SOC	Drop, reset, block, alert
Effect of a false positive	A wrong rule blocks a service	Only a false alarm	Legitimate traffic is blocked
Effect on network	Small latency	None (gets a copy)	Some latency; a failure can cut traffic (fail-open/fail-closed)
Typical examples	Perimeter/NGFW appliances, host firewalls	Snort or Suricata in IDS mode, Zeek	Snort or Suricata in inline mode, NGFW IPS module

Placement in a bank network

graph LR
    I["Internet"] --> RT["Edge router"]
    RT --> FW["Firewall (policy)"]
    FW --> DMZ["DMZ: web and mail servers"]
    FW --> IPS["IPS (inline, blocks)"]
    IPS --> CS["Core switch"]
    CS --> LAN["Branch LAN and servers"]
    CS -.->|"SPAN copy"| IDS["IDS sensor (alerts only)"]
    IDS -.->|"alerts"| SOC["SIEM / SOC"]

How each contributes to security

1. Firewall: reduces the attack surface. Only the needed services are reachable (e.g. only TCP 443 to the internet-banking server). The rest is denied, and zones such as the DMZ and the core banking network stay separated.
2. IPS: stops attacks inside allowed traffic. An exploit can arrive over permitted port 443; the firewall lets it in, but the IPS recognises the exploit pattern and drops it before it reaches the server. For HTTPS this needs TLS inspection (the traffic is decrypted at the NGFW/IPS, or at a load balancer in front of it), because an IPS cannot match patterns inside encrypted traffic.
3. IDS: gives visibility. It sees attacks, policy violations, scans and insider activity without touching traffic. Its alerts and logs feed the SIEM/SOC for investigation and forensics, and they help tune firewall and IPS rules.

Together they form defence in depth. Each control also has trade-offs: tuning is needed to reduce false positives (an IPS can block real users) and false negatives (a new zero-day exploit has no signature yet).

Example: an attacker scans the bank's public IP. The firewall blocks every port except 443. An SQL-injection request is then sent over 443: the IPS, which sees the decrypted traffic, drops it, and the IDS logs the scan and the attempt for the SOC.

Exam tip: Firewall = gatekeeper (allow/deny by rules); IDS = CCTV camera (watches and alarms, out-of-band); IPS = security guard (watches and stops, inline).

A Man-in-the-Middle (MitM) attack happens when an attacker secretly places himself between the customer and the bank's server. All traffic passes through the attacker, while both sides believe they are talking directly to each other. The attacker can then read the traffic (breaking confidentiality), change it (breaking integrity) and impersonate either side (breaking authenticity).

How it compromises an online banking session

sequenceDiagram
    participant C as Customer
    participant M as Attacker in the middle
    participant B as Bank web server
    C->>M: Joins fake Wi-Fi Cafe_Free, so DNS and ARP point to the attacker
    C->>M: Opens bank site over http (first request)
    M->>B: Opens a real HTTPS session to the bank
    B-->>M: Real login page
    M-->>C: Same page over plain HTTP (SSL stripping)
    C->>M: User ID, password, OTP
    M->>B: Replays credentials and OTP at once
    B-->>M: Session cookie, logged in
    M->>B: Changes beneficiary and amount of a transfer

1. Get in the path: a rogue "evil twin" Wi-Fi hotspot, ARP spoofing on a shared LAN, DNS spoofing that sends the bank's name to the attacker's IP, or a rogue DHCP server that hands out the attacker as gateway or DNS.
2. Defeat encryption: use SSL stripping (the victim is kept on HTTP while the attacker uses HTTPS to the bank), or show a fake certificate and hope the user clicks through the warning.
3. Steal and abuse: capture the user ID, password and OTP and relay them in real time. The attacker can also steal the session cookie (session hijacking) or alter a transfer's beneficiary account or amount while the customer sees normal pages.

Technologies to mitigate the threat

Technology	How it stops MitM
TLS 1.3 (HTTPS everywhere)	Encrypts and authenticates the channel. The server proves its identity with a CA-signed certificate. TLS 1.3 (RFC 8446) removed weak ciphers and uses forward secrecy (ephemeral Diffie-Hellman), so traffic recorded today cannot be decrypted later. Old SSL/TLS 1.0/1.1 should be disabled.
HSTS (RFC 6797) + preload list	The bank tells browsers "only ever use HTTPS for this domain". The browser upgrades http to https and refuses to click through certificate errors, which defeats SSL stripping. The preload list built into browsers protects even the very first visit.
Certificate / public-key pinning (mobile banking app)	The app accepts only the bank's own certificate or key, so a fake or rogue-CA certificate is rejected even on a hostile network.
MFA / OTP	A stolen password alone is not enough. A plain OTP can still be relayed in real time, so banks add transaction signing (the OTP or push approval shows and is tied to the amount and beneficiary) and phishing-resistant FIDO2/passkeys, which do not work on a fake domain.
Secure session handling	Cookies set with Secure, HttpOnly and SameSite; short session timeouts; re-authentication for a new beneficiary; device binding; fraud monitoring of unusual location, device or amount.
Network protections	WPA3/802.1X Wi-Fi, Dynamic ARP Inspection and DHCP snooping on switches, DNSSEC and encrypted DNS, VPN on untrusted networks.

User hygiene (customer awareness)

• Type the bank's address or use the official app. Check for https://, the padlock and the exact domain.
• Never ignore a certificate warning.
• Avoid public Wi-Fi for banking, or use mobile data or a trusted VPN.
• Never share an OTP or PIN; a bank will never ask for it.
• Keep the OS, browser and app updated; enable SMS/e-mail alerts for every transaction.

Exam tip: MitM = "secret relay". The core defence is encryption plus authentication of the bank's identity (TLS 1.3 with valid certificates), backed by HSTS against SSL stripping, pinning in apps, transaction-bound MFA, and customer awareness.