Financial Services · Managed platform (Imperva)

Database Security

Watch who queries your customer databases, and catch bulk extraction as it happens

Overview

What you are buying

Moraph resells, implements and runs Imperva database activity monitoring for the databases that hold customer, account and transaction data. Imperva records the queries run against those databases, applies the policies you approve, and raises alerts on activity such as unusually large reads of sensitive tables. Moraph tunes the policies, triages the alerts with your security team, and produces the audit evidence your examiners and auditors ask for.

The problem it solves

Customer data sits in a handful of databases that many people and applications can reach: database administrators, developers with production access, reporting tools and service accounts. Native database logging is often turned off for performance or kept where the administrators who generate it can also change it. When a large extract happens, nobody may notice until the data appears somewhere it should not. Monitoring tools that are installed but not tuned produce so many alerts that the important ones are missed.

  • No independent record of who read sensitive tables, or how much
  • Database administrators control the same logs that would record their activity
  • Bulk reads by service accounts and reporting tools are hard to tell apart from misuse
  • Monitoring policies left at defaults produce alerts nobody has time to review

Who uses it

  • CISOs and information security officers at banks, credit unions, broker-dealers and lenders
  • Database and infrastructure teams who run the databases behind core banking and lending
  • Security operations teams who investigate data access
  • IT audit and compliance teams responsible for database access controls
  • Institutions that own Imperva but need it tuned and operated

Requirements it supports

Interagency Guidelines Establishing Information Security Standards (12 CFR Part 364, Appendix B; 12 CFR Part 30, Appendix B)FTC Safeguards Rule under the Gramm-Leach-Bliley Act (16 CFR Part 314)NYDFS Cybersecurity Regulation (23 NYCRR Part 500)SEC Regulation S-P (17 CFR Part 248), including its incident response program requirementsPCI DSS v4.0 Requirement 10 (logging and monitoring access to cardholder data)Sarbanes-Oxley Act Section 404 (internal control over financial reporting)

The product supports these requirements; meeting them remains your organization’s responsibility.

Responsibilities

Who is responsible for what

Imperva provides the monitoring platform, Moraph implements and operates it, and your institution decides what is monitored and what happens when an alert is real.

AreaMoraphImpervaYour organization
LicensingResells the Imperva licence or subscription and manages renewals with youSets licence terms and entitlementsAgrees the scope of databases and accepts the vendor's terms
Platform availabilityMonitors the management servers, gateways and agents and raises vendor cases when neededProvides the software and any vendor-hosted components under its own service commitmentsProvides servers, network placement and capacity for components in your environment
ConfigurationBuilds and maintains audit and security policies, classification and retention settings to the agreed baselineProvides policy templates and documentationApproves the baseline and every change to it
Agents and coveragePlans agent and gateway deployment and reports coverage gapsSupplies agents and gateways and their supported platformsInstalls or permits installation on database servers under your change process
Identity and accessConfigures sign-in and roles for the management console and service portalSupports directory and single sign-on integrationDecides who holds which role
Monitoring and alertsTriages alerts and escalates those needing a decisionGenerates alerts according to configured policiesInvestigates escalated alerts and decides whether they are incidents
Incident responsePreserves monitoring evidence and supports your investigationResponds to issues in its own software and servicesLeads incident response and any customer or regulatory notification
ChangesPrepares, tests and applies approved change requestsPublishes release notesApproves changes and change windows
Patches and updatesPlans and applies updates to agents, gateways and management serversReleases updates and security fixesApproves maintenance windows and keeps database servers on supported versions
Policy decisionsRecommends what to audit, alert on and, if wanted, blockNoneDecides what is monitored, what is sensitive and whether anything is blocked

See how it works

A short walkthrough

Illustrative screens of how Moraph runs the service, with fictional sample data. They are not screens of Imperva itself, which belongs to its vendor.

  1. Step 1

    Rollout tracker

    Databases come under monitoring in order of sensitivity, with agent status and blockers in view.

    DatabasePlatformSensitive tablesCapturePoliciesStatus
    CORE-DB-01 (fictional)Oracle42AgentAppliedMonitoring
    LOAN-DB-02 (fictional)SQL Server18AgentAppliedLearning
    CARD-DB-01 (fictional)Db211GatewayPendingNetwork change needed
    RPT-DW-01 (fictional)SQL Server27AgentNot startedAwaiting approval
    Databases come under monitoring in order of sensitivity, with agent status and blockers in view.
  2. Step 2

    Alert triage

    Moraph reviews each alert against approved jobs and changes before anything reaches your security team.

    AlertPolicyUserRows readMoraph triageStatus
    DB-8813Bulk read of customer tablesvc-report-041,250,000Matched scheduled jobClosed
    DB-8817Bulk read of customer tableUser 3390410,000No matching job or changeEscalated
    DB-8820Privileged schema changedba-02n/aMatched change CR-2207Closed
    DB-8824Access from new source hostapp-lending3,200New app server, confirmedTuning proposed
    Moraph reviews each alert against approved jobs and changes before anything reaches your security team.
  3. Step 3

    Escalated alert

    Escalations carry what your security team needs to decide: the query, the volume, the source and what Moraph checked.

    DB-8817 · Bulk read of customer table

    Database
    CORE-DB-01 (fictional)
    User
    User 3390 (developer group)
    Source host
    Workstation WS-1187
    Rows returned
    410,000
    Time
    Outside usual working hours

    Checked by Moraph

    • No approved change or scheduled job matches
    • User has not queried this table in the previous 90 days
    • No privileged session recorded for this user
    Escalations carry what your security team needs to decide: the query, the volume, the source and what Moraph checked.
  4. Step 4

    Policy tuning request

    Policy changes that reduce noise are proposed with evidence, approved by your team and recorded.

    CR-2231 · Add new lending app server to known sources

    1. Alert DB-8824 repeated 14 times from a new hostMoraph service engineer
    2. Host confirmed as new lending app serverDatabase administrator
    3. Change approvedInformation security officer
    4. Policy updated and verifiedMoraph service engineer
    Policy changes that reduce noise are proposed with evidence, approved by your team and recorded.
  5. Step 5

    User rights review

    Data owners review who holds rights on sensitive databases, and removals are tracked.

    LOAN-DB-02 (fictional) · User rights review

    Data owner
    Lending operations lead (fictional)
    Accounts with access to sensitive tables
    23
    Confirmed
    19
    To remove
    3
    To reduce
    1

    Changes requested

    • Remove two developer accounts from production
    • Remove dormant account svc-legacy-09
    • Reduce reporting account to read-only on two tables
    Data owners review who holds rights on sensitive databases, and removals are tracked.
  6. Step 6

    Monthly service review

    Each month Moraph reviews coverage, alerts and tuning with your team and records decisions.

    Monthly service review · Example Savings Bank (fictional)

    Databases monitored
    17 of 19 in scope
    Agents unhealthy
    1
    Alerts triaged
    212
    Escalated
    4
    Tuning changes
    6

    For decision

    • Approve gateway network change for CARD-DB-01
    • Decide on blocking policy for direct developer access to production
    • Confirm retention period for audit data
    Each month Moraph reviews coverage, alerts and tuning with your team and records decisions.

Workflows

The principal workflows

  1. Discover and classify

    Moraph uses Imperva's discovery and classification to find the databases in scope and the tables that hold sensitive data, and agrees the list with your data owners.

    • Database servers in scope identified from your inventory and network scans
    • Imperva classification scans tables for account numbers, identifiers and other sensitive data
    • Results reviewed with data owners and false matches removed
    • Sensitive tables and columns recorded in the monitoring baseline
    • Databases ranked for rollout by the sensitivity of what they hold
  2. Monitor

    Imperva agents or gateways capture database activity independently of the database's own logging, and audit policies record the access your policy requires, including privileged users and sensitive tables.

    • Agents installed on database servers, or gateways placed on the network path
    • Audit policies record privileged user activity and access to sensitive tables
    • Security policies define what raises an alert, such as large result sets or access from unusual sources
    • Known applications and service accounts profiled so their normal activity is recognized
    • Audit data retained for the period your policy sets
  3. Triage and respond

    Moraph reviews Imperva alerts, sets aside activity explained by approved jobs or changes, and escalates the rest to your security team with the query, user, source and volume involved.

    • Alert received from Imperva with the query details
    • Moraph checks it against approved jobs, change records and known behavior
    • Explained alerts closed with a reason; others escalated to your security team
    • Your team decides whether it is an incident and what to do
    • Policy tuned where alerts repeat without value, with your approval
  4. Evidence and review

    Moraph produces the reports your auditors expect, such as privileged user activity and access to sensitive data, and reviews coverage and tuning with you each month.

    • Scheduled reports on privileged activity and sensitive data access
    • Database user rights reviewed with data owners
    • Coverage gaps and agent health reported
    • Monthly service review records decisions and open items

Roles and permissions

Who does what in the product

Each role below is a starting point. During implementation we set them up to match your teams, and every action anyone takes is recorded in the audit trail.

Information security officer

CISO, information security officer, IT risk manager

Owns the database monitoring policy and the decisions on what is monitored, alerted on and blocked.

Sees

  • All alerts, reports and service reviews
  • The policy baseline and every change to it
  • Coverage gaps and exceptions

Does

  • Approves the policy baseline and change requests
  • Decides on escalated alerts or delegates to security operations
  • Approves any blocking policy
  • Grants auditors and examiners read-only access
  • Accepts coverage exceptions

Cannot

  • Edit or delete captured audit data
  • Apply policy changes directly without the change process
Approvals
Approves policy changes, blocking, coverage exceptions and auditor access.
Notified about
Escalated alerts, changes waiting for approval, coverage gaps and the monthly service review.

Security operations analyst

SOC analyst, security engineer, incident responder

Investigates escalated database alerts alongside other security signals.

Sees

  • Escalated alerts with Moraph's triage notes
  • Audit data for the users and databases involved in an investigation
  • Database alerts in your SIEM

Does

  • Investigates escalated alerts
  • Requests additional audit data or searches
  • Records the outcome of each investigation
  • Opens incidents under your incident procedure

Cannot

  • Change monitoring policies
  • See unmasked values unless your institution grants it
Approvals
Incident decisions follow your incident procedure.
Notified about
Alerts escalated by Moraph.

Data owner

Business data owner, application owner, head of lending or deposit operations

Confirms which data is sensitive and who should have rights to it.

Sees

  • Classification results for their databases
  • User rights on their databases
  • Summary access reports for their data

Does

  • Confirms or corrects classification results
  • Reviews and certifies user rights
  • Requests rights changes through your database team

Cannot

  • Change monitoring policies
  • See detailed audit data outside an approved investigation
Approvals
Rights changes they request are applied by your database team under your access process.
Notified about
Classification reviews and user rights reviews due.

Database administrator

Database administrator, database engineer

Supports deployment and explains database activity, while their own privileged activity is monitored.

Sees

  • Agent status on their database servers
  • Questions from Moraph about activity on their databases

Does

  • Installs or permits agent installation under change control
  • Confirms the purpose of jobs, hosts and service accounts
  • Applies user rights changes after review

Cannot

  • Change monitoring policies or stop monitoring
  • View or alter audit data about their own activity
Approvals
Agent installations and database changes follow your change process.
Notified about
Agent health issues on their servers and questions raised during triage.

Moraph service engineer

Moraph database security engineer, Moraph service manager

Deploys, tunes and operates Imperva and triages its alerts for you.

Sees

  • Alerts, audit data needed for triage, and coverage
  • Policies and configuration
  • Moraph service portal records for your service

Does

  • Triages alerts and escalates those it cannot explain
  • Proposes and applies approved policy changes
  • Monitors agent, gateway and server health
  • Manages vendor support cases
  • Runs user rights reviews and the monthly service review

Cannot

  • Decide that an alert is or is not an incident
  • Apply policy changes or blocking without approval
  • Access your databases directly
Approvals
Every change needs your approval; emergency actions are limited to those agreed in advance and reported afterwards.
Notified about
Imperva alerts, agent and gateway health issues and vendor notices.

Auditor or examiner (read-only)

Internal auditor, external auditor, regulatory examiner (under temporary access)

Reviews database monitoring controls and evidence without being able to change anything.

Sees

  • Policies, coverage and change history
  • Reports on privileged activity and sensitive data access within scope
  • User rights review results

Does

  • Reads and exports reports within their scope, with each export logged
  • Requests specific audit extracts through the information security officer

Cannot

  • Change anything
  • See unmasked values
  • Keep access after it expires
Approvals
Access is granted by the information security officer with a scope and an end date.
Notified about
Nothing by default.

Permissions at a glance

ActionSecurity leadSOC analystData ownerDBAMoraph opsAuditor
View alertsView onlyView onlyNo accessNo accessFullView only
Triage and close alertsFullFullNo accessNo accessFullNo access
Decide an alert is an incidentFullFullNo accessNo accessNo accessNo access
Search audit dataView onlyView onlyNo accessNo accessView onlyNo access
Confirm data classificationView onlyNo accessOwn work onlyNo accessFullNo access
Change audit and security policiesApprovesNo accessNo accessNo accessFullNo access
Enable a blocking policyApprovesNo accessNo accessNo accessFullNo access
Install and update agentsApprovesNo accessNo accessOwn work onlyFullNo access
Certify user rightsView onlyNo accessOwn work onlyNo accessNo accessView only
View reports and service reviewsView onlyView onlyOwn work onlyNo accessView onlyView only
Grant auditor accessApprovesNo accessNo accessNo accessNo accessNo access
  • Full
  • Own work only
  • Approves
  • View only
  • No access

How access is controlled

  • Database administrators are monitored, not monitoring: they cannot change policies, stop monitoring or see audit data about their own activity.
  • Moraph triages, but your institution decides. Only your security team can treat an alert as an incident, and blocking is enabled only on policies your information security officer approves.
  • Roles are configured with you during implementation and can follow your identity provider's groups. Access to unmasked query values is granted separately and only where needed.
  • Every policy change, triage decision and report export is recorded, and auditors receive temporary read-only access with a defined scope and an end date.

Features

What it does

Independent activity capture

Imperva records database activity through its own agents or gateways, separate from the database's native logs, so administrators cannot alter the record of their own actions.

Sensitive data discovery

Imperva scans databases for tables and columns holding customer identifiers, account numbers and similar data, and Moraph reviews the results with your data owners.

Bulk extraction alerts

Security policies raise alerts when a user or account reads an unusually large volume from sensitive tables, or reads them from an unexpected source or at an unexpected time.

Privileged user monitoring

Activity by database administrators and other privileged accounts is audited in full, including schema changes, permission changes and direct reads of sensitive data.

Application profiling

Imperva learns the normal queries of known applications and service accounts, so departures from that profile can be flagged.

Optional blocking

Where your institution chooses, Imperva can be configured to block specific activity, such as a defined query pattern from an unapproved source. Moraph enables blocking only on policies you approve.

User rights review

Imperva reports who holds which permissions on each database, and Moraph runs periodic reviews of those rights with data owners.

Policy tuning

Moraph adjusts audit and security policies as alerts are reviewed, so noise is reduced and each change is approved and documented.

Alert triage

Moraph reviews alerts against approved jobs and changes and passes those needing a decision to your security team with the details attached. Automated suggestions may help sort alerts; people make the decisions.

Coverage and health monitoring

Moraph watches agent and gateway health and reports databases that are not being monitored, for example after a server rebuild.

Audit reporting

Scheduled reports on privileged activity, sensitive data access and policy changes, prepared for auditors and examiners.

Change management

Every policy, agent and configuration change goes through a change request your team approves, with the result verified.

Integrations

How it connects to your systems

Connects toHowWhat flows
DatabasesImperva agents or gateways monitor the database platforms it supports, such as Oracle, Microsoft SQL Server, IBM Db2 and others, confirmed against your versions during design.In: database activity captured by agents or gateways.
SIEMAlerts and selected audit events forwarded to your security information and event management system for correlation.Out: alerts and audit events in syslog or the format your SIEM accepts.
Identity provider and directoryConsole users sign in through your identity provider, and directory data helps attribute database activity to real people.In: user identity, group membership and directory attributes.
IT service managementApproved changes and scheduled jobs from your service management tool are used to explain expected activity during triage.In: change records and job schedules. Out: incident references.
Privileged Access ManagementWhere you also use Moraph's managed CyberArk service, privileged sessions can be matched to the database activity they produced.In: privileged session metadata, by agreement.
Moraph service portalAlerts, change requests, coverage and monthly service reviews tracked in Moraph's service portal, available to your team through single sign-on.Out: service records, triage notes and review reports.

Each integration is confirmed in discovery and specified in the design. See how an engagement progresses.

Security and privacy

How your data is protected

Single sign-on

Your staff sign in to the Imperva console and Moraph's service portal through your identity provider, so your password and multi-factor policies apply.

Role-based access

Who can view audit data, change policies or see captured query values follows their role, and database administrators do not administer the monitoring of their own activity.

Sensitive values masked

Imperva can mask sensitive values captured in queries and results, so reviewers see the activity without seeing customer data where it is not needed.

Moraph staff access

Moraph engineers work through role-based access you approve, and cannot use keys to your data without explicit, time-bound authorization.

Complete audit trail

Changes to Imperva policies and settings are logged, and Moraph's service portal records every change request, approval and triage decision.

Audited operations

Moraph is SOC 2 Type II and ISO/IEC 27001 audited company-wide, and its service records are hosted in the United States, United Kingdom or Australia region you choose.

Company-wide controls, independent audits (SOC 2 Type II and ISO/IEC 27001) and data residency are described in our Trust Center, where you can request the evidence pack.

Reporting

What you can report on

10 standard reports, grouped by who uses them. Each shows who it is for, how it can be broken down, how it is delivered and what it is used for. The data behind them is also available to your own reporting tools.

Coverage

Monitoring coverage

For information security officer and platform owner

Databases in scope, how each is captured, agent and gateway health, and databases not yet or no longer monitored.

Break down by
Database, Platform, Capture method, Status
Delivered as
Service portal view; monthly service review pack
Used for
Knowing which sensitive data is actually being watched.

Sensitive data inventory

For data owners and information security officer

Tables and columns classified as sensitive in each database, with who confirmed the classification and when.

Break down by
Database, Data type, Data owner, Confirmation date
Delivered as
Imperva reports; CSV export
Used for
Keeping monitoring pointed at the data that matters.

Activity

Privileged user activity

For information security officer, auditors

Activity by database administrators and privileged accounts on sensitive databases, including schema and permission changes.

Break down by
User, Database, Action type, Period
Delivered as
Scheduled Imperva report; PDF and CSV export
Used for
Evidencing independent review of privileged database activity.

Sensitive data access

For information security officer and data owners

Who and what read sensitive tables, how often and in what volume, by user and application.

Break down by
Table, User or application, Source host, Volume band, Period
Delivered as
Scheduled Imperva report; CSV export
Used for
Spotting access that does not fit the data's purpose.

Alert triage log

For security operations and information security officer

Every alert, Moraph's triage reason, whether it was escalated, and the final outcome recorded by your team.

Break down by
Policy, Database, Outcome, Period
Delivered as
Service portal view; monthly service review pack
Used for
Showing that alerts were reviewed and decided.

Governance

User rights review

For data owners, information security officer, auditors

Accounts with rights on sensitive databases, the data owner's decision for each, and changes requested and completed.

Break down by
Database, Account type, Decision, Review cycle
Delivered as
Service portal view; PDF and CSV export
Used for
Evidencing periodic review of database access.

Policy change history

For information security officer, auditors

Every change to audit and security policies, with the reason, who approved it and when it took effect.

Break down by
Policy, Change type, Approver, Period
Delivered as
Service portal view; CSV export
Used for
Showing that tuning was approved and did not quietly reduce coverage.

Tuning summary

For information security officer and security operations

Policies producing the most alerts that were closed as expected, and the tuning proposed or applied for each.

Break down by
Policy, Closure reason, Period
Delivered as
Monthly service review pack
Used for
Directing tuning effort where it removes the most noise.

Monthly service review

For platform owner and information security officer

Coverage, alerts, escalations, tuning, changes, vendor notices and decisions needed, for the month.

Break down by
Month, Area
Delivered as
PDF pack and review meeting
Used for
Running the service with your team and recording decisions.

Audit extract

For internal audit and examiners

Captured activity for a chosen database, user or period, with sensitive values masked, prepared on request.

Break down by
Database, User, Date range
Delivered as
On request; CSV export
Used for
Answering specific audit and examination requests.

Exports, access and evidence

  • Activity reports come from Imperva itself; service reports such as triage logs, tuning, changes and reviews come from Moraph's service portal.
  • Reports can be scheduled and exported to CSV, and governance reports to PDF for audit and committee packs.
  • Alerts and audit events can be forwarded to your SIEM so database activity is reported alongside other security data.
  • Reports respect each viewer's role and masking settings: data owners see summaries for their own data, and only approved roles see query details.
  • Running and exporting a report is recorded, and auditors can be given read-only access to reports within a defined scope.

Deployment

Where and how it runs

Agents in your environment

Imperva agents on database servers and management components in your data center or cloud account, operated by Moraph.

Network gateways

Gateways on the network path to databases where installing agents is not possible, with the coverage trade-offs documented.

Existing Imperva estate

If you already own Imperva, Moraph can take over operations after a baseline review of coverage and policies.

Security controls, independent audits and data residency are set out in our Trust Center. Engagement models and what drives a quotation are on Working with Moraph.

Implementation

What a rollout involves

The general phases are on Working with Moraph. For this product, they involve the following.

Scoping and design

We agree which databases are in scope, how activity will be captured, and the audit, alert and retention policy. We need your database inventory and contacts for each database team.

Discovery and classification

Imperva discovery and classification run against the databases in scope, and results are confirmed with your data owners.

Deployment

Management servers, gateways and agents are deployed under your change process, starting with the databases that hold the most sensitive data.

Learning and baseline

Policies run in alert-only mode while normal application and administrator activity is profiled and expected jobs are recorded.

Tuning

Alerts from the learning period are reviewed with your security team, and policies adjusted until what is raised is worth reviewing.

Transition to managed service

The service moves to steady-state triage, coverage monitoring, change management and monthly service reviews.

Limitations

What it does not do

Worth knowing before you evaluate it.

  • Moraph is not Imperva. Moraph resells, implements and operates the platform; Imperva develops it and is responsible for its software and any services it hosts.
  • Imperva's own service commitments, product roadmap and any outages of its services apply. Moraph does not change them.
  • Licences are subject to Imperva's terms, which you accept as part of the purchase.
  • Monitoring covers the databases and platforms Imperva supports and where agents or gateways are deployed. Databases outside that coverage are reported as gaps.
  • Alerting detects activity as it is captured; it does not by itself stop an extraction. Blocking is available only for policies you approve and can affect legitimate activity if set too broadly.
  • Moraph triages alerts but does not replace your security operations center, and does not decide whether an event is a reportable incident.
  • Encrypted database connections may need additional configuration for activity to be captured, depending on the method used.
  • Audit data retention is limited by the storage you provide or license.

Evaluation checklist

What to test in a demonstration or pilot

Questions worth putting to us, and to any other vendor you are considering.

  1. Pick one sensitive database and review what would be captured and how
  2. Ask how a bulk read by a service account is told apart from misuse
  3. Review a sample escalated alert and decide whether it gives your team enough to act
  4. Measure monitoring overhead on a test system with your own workload
  5. Confirm who can change monitoring policies, and that database administrators cannot alter the record of their own activity
  6. Read the responsibilities table with your vendor management team

Questions

Frequently asked questions

Does this stop data being stolen?

It records and alerts on database activity, which lets your team see and respond to bulk extraction. Imperva can also block defined activity, but only on policies you approve, because blocking can interrupt legitimate work.

Will monitoring slow our databases?

Agents and gateways add some overhead, which depends on the database, the volume and the policies. It is measured during the pilot on your own systems before wider rollout.

Can our database administrators turn off the monitoring?

The monitoring is administered separately from the databases, and agent stoppages and policy changes raise alerts and are logged. Your institution decides who holds administrative rights in Imperva.

How is it priced?

The Imperva licence is resold under Imperva's terms, with Moraph's implementation and managed service priced separately, usually by the number of databases in scope. See Working with Moraph for what drives a quotation.

Who decides whether an alert is an incident?

Your institution. Moraph triages alerts and escalates those it cannot explain, with the evidence; your security team decides and leads any response.

We already own Imperva. Can Moraph run it?

Yes. Moraph starts with a baseline review of your coverage and policies, agrees what needs fixing, and then operates the deployment under the same change and reporting model.

Next steps

Evaluate Database Security

Buying through a formal procurement? See How to buy for purchasing routes, accessibility conformance reports and company information. Documentation: Database Security guides on docs.moraph.com (getting started and security guides are public; setup, administration and integration guides are for client accounts). Support: Database Security support guide.