Database Activity Monitoring (DAM) is designed to provide an organization with visibility into the use of the data within its databases. This visibility is essential for maintaining compliance with regulations like PCI DSS, HIPAA, and GDPR and for protecting this data against unauthorized access and potential breaches. By following these six steps, an organization can fully deploy and configure Imperva DAM.
The site tree defines the structure of an organization’s websites to simplify DAM. Site trees can be structured in a number of different ways. For example, a multinational organization may wish to divide their sites by target country. Alternatively, site trees can be structured based upon departments or individual applications.
A site tree is valuable because it simplifies visibility and management for an organization’s resources . When creating new policies, it is possible to specify a certain portion of the site to tree to apply them to. This enables modifications to be quickly and logically applied to all or a specific subset of an organization’s sites.
A critical component of DAM is understanding the data that the organization is trying to protect. Different types of data may need different protections, security controls, and reporting requirements driven by regulatory compliance and internal policy.
Imperva DAM can help an organization to identify where sensitive data is stored within its databases. This can be accomplished either by searching based upon predefined patterns of sensitive data (payment card details, phone numbers, etc.) or custom regular expressions or searches for particular database column needs. DAM will then scan the databases and provide a report on all of the data that is discovered that matches the search parameters.
After identifying stores of classified, sensitive, or protected data within the databases, it is possible to start using DAM to protect this data. The first step in this process is defining audit policies.
An audit policy describes scenarios in which an event should be recorded in the system’s audit logs. For example, maintaining PCI DSS compliance requires an organization to control access to customer payment card data. After identifying where this data is contained within an organization’s databases, the next step would be to create a policy that monitors for access attempts for this data. If a user or application attempts to access customer payment card data, then the access attempt is logged. This log can then be used for incident detection and response and during a compliance audit to demonstrate that no unauthorized parties were able to access this protected data.
An organization’s audit policies are a balance of visibility and usability. While it is possible to log everything, this can require a massive amount of storage and result in an unusably large audit log. On the other hand, failing to log something critical could place compliance or data security at risk. A good starting point for developing audit policies is looking at the compliance requirements for applicable regulations and monitoring access to the data that these regulations protect.
The goal of audit policies is to define the “normal” events that, nonetheless, need to be monitored and logged within an organization, like access attempts to sensitive information. Security policies, on the other hand, are designed to detect the anomalies that could indicate a potential or ongoing data breach.
For example, it may be normal for an organization’s employees to make database queries that return tens of results; however, a significantly larger request is an anomaly and should be investigated. Under these circumstances, the organization should have a security policy in place that triggers if a database query returns thousands of records. If this occurs, it is likely to be an attempted data breach, and the security team should be notified so that they can respond appropriately.
The details of an organization’s security policies are specific to that organization. For example, one company may be accustomed to queries that return tens of records, while, for another, requests for hundreds of thousands of records may be normal and expected. Security policies should be designed to minimize false positives while still being capable of detecting true attacks.
DAM collects most or all of the data that an organization requires for database security and regulatory compliance. However, this data is only useful if it is presented to the user in an easily digestible and usable form.
Imperva DAM provides a number of default reporting templates that cover common use cases and provide a good starting point. However, these reporting templates can be customized to meet an organization’s unique needs. This includes everything from customizing the information included in the report to scheduling automated report delivery.
Deploying DAM is a multi-stage process, and it can also be a moving target. The data stored in various databases, regulatory requirements, and internal policy can all change.For this reason, it is important to regularly revisit these steps. This can help to identify missed information, misconfigured policies, and inaccurate reporting.
Imperva DAM provides an organization with the visibility and control that it needs to maintain regulatory compliance and detect breaches of sensitive data. By following these six steps, it is possible to get Imperva DAM up and running and improve an organization’s database monitoring and protection.Watch the entire webinar on Operational Best Practices for a Successful Data Activity Monitoring Deployment - Community WebinarAdditional Resources: Resource Bundle: Imperva DAM Deployment Best Practices - Common questions around DAM DeploymentResource Bundle: Imperva Database Activity Monitoring Q&A - In depth questions and answers around all things DAM.
Contact Us
JoinBenefitsLearn More
Terms of Use