Database activity monitoring for Bangladesh Bank ICT Security Guideline v4.0

Bangladesh Bank’s ICT Security Guideline is the security rulebook for banks and financial institutions operating in Bangladesh. Version 4.0 tightens what supervised institutions must be able to show about the systems that hold customer and transaction data, and few systems matter more to that story than the database. This is a practitioner’s view of what the guideline expects around database activity, and how to produce the evidence an examiner will ask for without disrupting production.

What the guideline expects of your databases

Regulatory ICT guidelines of this kind converge on a small set of database controls. You do not need the exact clause numbers to plan for them; you need to be able to answer four questions with evidence:

• Who touched the data, and when? Privileged and administrative access to production databases must be recorded: logins, schema changes, bulk reads and exports, and permission grants, not just application traffic.
• Can the record be trusted? Audit evidence has to be protected against tampering, including by the administrators it monitors, and retained for a defined period.
• Would you notice misuse? Unusual activity, such as access outside normal hours, a service account behaving like a person, or a sudden large extract, should raise an alert while it still matters.
• Where is the sensitive data? You cannot protect what you have not located, so classification of the columns holding personal, financial, and payment data is a prerequisite, not an afterthought.

Why agentless monitoring fits a regulated estate

The instinct is often to install an agent on each database. In a regulated estate that instinct is expensive: an agent is new software on a production system that already runs under change control, and every version of it is something your risk function now has to assess.

Every enterprise database engine already keeps an audit trail of its own: Oracle Unified Auditing, SQL Server Audit, PostgreSQL’s pgaudit, MongoDB’s audit log, and their equivalents. An agentless approach reads that native trail through a read-only account and correlates it centrally. Nothing is installed on the production database, there is no in-line component in the data path to fail, and the monitoring itself introduces no new privileged software to defend. For an examiner, “we read the engine’s own audit stream and never touch the database” is a much shorter conversation than justifying an agent fleet.

Turning activity into audit evidence

Monitoring is only half the requirement; the other half is producing evidence an examiner accepts. Two properties do most of the work:

• A tamper-evident trail. When each record is hash-chained (for example, a SHA-256 chain) and stored insert-only, any later edit or deletion breaks the chain and is detectable. A daily verifier that checks for chain breaks and sequence gaps turns “trust us” into “here is the proof it was not altered.”
• Reports mapped to the framework. Raw logs do not satisfy an auditor; a report that maps observed activity to specific guideline requirements does. The honest version of this also shows its gaps: a report that timed out should say so rather than render a false pass.

A short readiness checklist

• Inventory every production database engine and version in scope.
• Confirm each engine’s native auditing is enabled and captured centrally.
• Classify the columns holding personal, financial, and payment data.
• Protect the audit trail against tampering and set a retention period.
• Define what “abnormal” looks like per account, and alert on it.
• Produce framework-mapped reports you can hand an examiner unedited.

How Vyrell approaches it

Vyrell, our database activity monitoring platform, is built for exactly this shape of problem. It is agentless (a read-only audit account per target, with nothing installed on the production database) and reads the native audit facility across ten engines. Its policy library ships 26 rules mapped to the Bangladesh Bank ICT Security Guideline v4.0, each with a matching report in the reporting engine, alongside 215 security rules and 21 framework rule-packs in total. The audit trail is SHA-256 hash-chained and insert-only, with a daily verifier, and its behaviour analytics score accounts against their own statistical baselines. A typical deployment takes one to two days, because there is no agent to roll out.

None of this is unique to Bangladesh Bank’s guideline: the same controls underpin PCI-DSS, ISO 27001, and most financial-sector ICT rules. The point is that the evidence you build for one is largely the evidence you build for all of them.