Database activity monitoring (DAM) and data protection
Databases hold an organization’s most critical information, yet most of the activity in them comes from people who already have legitimate access. So protecting a database is not only about stopping an external attack, but about understanding who does what with the data inside.
Visibility at the data layer
Who accessed which database, which objects and what they did.
Meaningful events, not all the SQL
Only what genuinely matters for security goes to the SOC.
No impact on production
The collection method is chosen for the infrastructure and tested under real load.
Database Activity Monitoring solutions
Hafaza Tech designs and implements DAM and related data security solutions based on Imperva and Krontech — from the assessment of critical databases and the choice of collection method through to monitoring policies, audit and SOC integration.
The main data security platform in the Hafaza Tech portfolio. Imperva Data Security Fabric brings together several related layers: data discovery and classification, activity monitoring, risk analytics, audit and reporting, and data protection.
DAM provides monitoring of application and privileged user activity, while classification and analytics add context — how well an action matches policy and the sensitivity of the data.
Most relevant where activity has to be controlled centrally across a heterogeneous, hybrid infrastructure. Not every component is mandatory for every customer — the set is defined by the goals of the project.
Offers DAM as part of its own data access architecture. The solution is used for monitoring and auditing activity and can be complemented by related controls, including dynamic data masking and access management.
An additional option for projects that need a local architecture for data monitoring and protection.
Specific database engines, collection methods and capabilities are verified against the current product version during the project or pilot.
DAM stands for Database Activity Monitoring. It is not a database access management system: access is governed by PAM and by the database engine’s own controls, while DAM is responsible for visibility and audit of what happens inside.
What DAM is
Observing and analysing what happens inside the database
A modern DAM should help answer not only “which query was executed”, but the more practical question: who performed the action, which data they reached, how well that matches policy and whether the event requires investigation.
What the monitoring covers
Authentication and connections
SQL queries and database commands
Access to tables, schemas and other objects
Actions of privileged accounts
Activity of service and application accounts
Changes to data and database configuration
Policy violations and unusual behaviour
Legitimate access does not mean an acceptable action
Databases are accessed by administrators, developers, support, applications, integrations and contractors.
Examples that need context
An administrator exports a large volume of customer data. A service account starts querying tables it does not normally touch. An application changes its usual pattern of requests.
It is not always an attack
The cause may be a new application release, a changed business process or an administrative task. But such behaviour needs an explanation and security context.
What DAM gives you
Visibility directly at the level of activity in the database: not just a successful authentication, but which actions were performed and on which data.
So the question is not “does the user have access”, but “does the action performed match their role, their usual behaviour and the policy”.
Native audit and DAM
DAM does not necessarily replace the database’s built-in audit
Modern database engines have their own audit mechanisms, and in many environments these cover a significant part of the logging requirements. DAM can use native audit, centralise it and enrich it — depending on the architecture.
Where DAM adds value
Centralised monitoring of different database engines
Common security policies
Normalisation of activity
Control of privileged users
A single searchable log
Behaviour and risk analytics
Integration with the SOC
Two classes of activity to watch first
For a security team, the key distinction is between the actions of people with broad privileges and the requests of applications, which generate most of the traffic to the database.
Privileged activity
Database administrators and other privileged users have broad rights inside the engine. What matters is seeing not only the login, but the actual actions: reading sensitive data, changing records, creating users, changing permissions and configuration, bulk exports, administrative commands.
DAM adds a further layer of observation and audit for such actions.
Applications and service accounts
Most activity is generated by applications and service accounts rather than people directly. So you need to know which applications reach the database, under which accounts, which objects they normally touch and which operations are normal for them.
An unexpected change in the pattern of requests may mean compromise, abuse or simply an application update — and calls for context rather than an automatic conclusion that it is an attack.
So the basic task of the project is not to “log everything”, but to learn to tell normal behaviour in each category from what needs to be reviewed.
The same operation can carry different risk
A select from a technical table and a select from a table of personal data are different security events.
That is why monitoring is reinforced by data discovery and classification. It helps to understand where sensitive data sits, which data types are stored, who accesses them and how well that access matches policy. DAM also works without a separate classification layer — classification simply raises the value of monitoring where the sensitivity context matters.
An anomaly is not an incident in itself. A new target database, an unusual time, a sharp rise in the volume of requests or atypical commands are a reason to review — together with the context: who the subject is, how critical the asset is, which data is affected and what is happening in the business process.
What can prioritise events
Sensitivity of the data affected
Criticality of the asset
Role and privileges of the subject
Deviation from usual behaviour
Volume of access
Time and source of the connection
How DAM collects database activity
There is no universally best method: the architecture is chosen for the database engine, the deployment model and the customer’s requirements.
Network monitoring, for example, may have limitations for local connections to the database and for encrypted traffic, while an agent or native audit option carries different operational trade-offs. So the collection method is chosen for the real infrastructure, not from a single universal template.
Audit and compliance
A centralised log of database activity
The system has to make it possible to reconstruct the whole picture of an event. This is needed for investigations, control of privileged users, internal audit, compliance and forensic analysis.
What the log is used for
Incident investigation
Control of privileged users
Internal audit
Compliance
Forensic analysis
Retention periods are designed up front — taking into account the volume of activity, storage, regulatory requirements and how far back an investigation needs to be able to look.
DAM and the SOC
DAM should not exist apart from the security processes. At the same time there is no need to send every SQL query to the SIEM: for large databases that creates a high volume of low-value telemetry and quickly runs into storage cost.
DAM acts as a specialised filter and a source of context: it parses activity at the database level and passes on only the events that matter for security. The SOC then gets visibility into the databases without analysing the whole query stream.
What is worth sending to the SIEM
Policy violations
Suspicious privileged activity
Atypical access
High-risk operations
Significant audit events
DAM and adjacent technologies
DAM overlaps with other controls but does not replace them. For critical systems these technologies are usually used together.
PAM
Governs privileged access: who gets it, to what and on what terms.
DAM
Controls activity inside the database and access to data objects.
DLP
Controls the use and transfer of sensitive information across channels.
Data masking
Hides or transforms sensitive values.
Database performance monitoring
Covers latency, locks, slow queries and availability — that is not a security task.
A wider data security architecture
Modern platforms complement monitoring with discovery and classification, risk analytics, audit and data protection. But DAM remains a control in its own right: visibility and audit of activity.
How Hafaza Tech implements DAM
There is no need to start with every database at once. Priority usually goes to payment systems, customer databases, credential stores, financial systems and critical business applications.
01
Assessment
02
Scope
03
Architecture
04
Pilot
05
Monitoring policies
06
SIEM integration
07
Tuning
08
Support
09
Regular review
We identify the critical databases, engine types and versions, sensitive data, privileged users, application and service accounts, the existing native audit, the network architecture, compliance requirements and SOC integration.
We choose a collection method for the specific infrastructure and verify local and remote connections, encrypted traffic, performance impact, resilience, segmentation, storage and compatibility with the database engines.
The pilot runs on real activity. It has to answer: do we see the actions we need, do we tell privileged, application and service access apart, is it clear which data objects were touched, is a searchable log kept, can useful policies be written without excess noise, and what goes to the SIEM.
We separately verify visibility of local connections, behaviour with encrypted traffic, how the chosen collection method behaves on failure and the performance impact under realistic load. For DAM the last point is particularly important.
After the pilot we define policies for privileged activity, access to sensitive data, administrative changes, atypical behaviour, critical objects and high-risk operations. Over-broad policies quickly create noise, so the quality of the rules matters more than their number.
After rollout we watch database coverage, the state of collectors and agents, policy effectiveness, false positives, new databases and application accounts, changes in sensitive data and the health of the SIEM integration.
Imperva or Krontech?
The choice depends on the customer’s architecture. For DAM, testing against real activity matters most, so we prefer a pilot to a comparison of feature tables.
Databases and environment
Engine types, number of databases, on-premise or cloud infrastructure, hybrid scenarios.
Who we control
Privileged users, application and service accounts, requirements for sensitive data.
Collection architecture
The collection method, visibility of local and encrypted traffic, resilience.
Audit
Depth and retention, how usable the log is for investigation and internal audit.
Integrations
Delivery of significant events to the SIEM and context for the SOC.
Operations
Performance impact, licensing, operational complexity.
What a good DAM means
It should answer six questions — and do so without undue impact on how the database runs.
Who accessed the data · what exactly happened inside the database · which objects were touched · whether the action matches policy and usual behaviour · whether events can be reconstructed for investigation and audit · whether the SOC receives a meaningful signal.
Any other questions? We will definitely answer!
Didn't find the answer to your questions? Send your question below and our support team will answer it soon. We are here to help you with cybersecurity!
Ask a question!
Get a consultation!
If you want to learn more about our cybersecurity services or are not sure which solutions are right for you, leave a request and our specialists will contact you for a free consultation.
Related solutions
Complementary solutions for comprehensive infrastructure protection and a higher overall level of information security.
PAM
Control of privileged access to the systems where the data is stored.
DLP
Control of the transfer of sensitive information outside the organization.
SIEM
Correlation of database events with the rest of the security telemetry.