👆 Search ABOVE for your Database Activity Monitoring Questions👆
Database activity monitoring (DAM) identifies and reports unauthorized behavior without severely impacting operations or productivity. This gives DAM solutions a valuable edge over native auditing measures. This resource bundle pulls together community discussions and resources into one easy place for you to access. It’s a collection of our resources to support you throughout your on-boarding process, as well as supplement your product education as you navigate the platform.
Database Activity Monitoring (DAM) - Resource Bundle
👆 Click above to see more DAM Deployment questions and answers
Imperva Customers have asked many questions around deployment of DAM. Here are some FAQ's around Imperva DAM deployment. If you missed it, go and listen to our Community webinar on Operational Best Practices for a Successful Data Activity Monitoring Deployment
- 6 Steps to Deploying Imperva DAM - In this blog, Imperva's DAM specialist Craig Burlingame talks about 6 steps on how to deploy Imperva's DAM product. 1. Configure site tree, Discovery and Classification, Define audit policies, Define security policies, Define reports and review. It's a quick and easy read.
- How the On-Prem DAM/WAF devices are deployed, the architecture types for different types of clients. As for DAM and WAF gateways, each will have a different set of deployment modes that are supported. DAM=IMPVHA bridge, sniffing, or sniffing cluster. WAF=IMPVHA bridge, TRP, Sniffing, KRP, NGRP. Clients in these scenarios would be web clients connecting to web applications, or database clients connecting to databases. In either case, the gateway will have the ability to inspect that traffic based on port, ip address (and certificate for decryption) configurations. In the case of DAM, if the agent is installed, the agent is responsible for auditing all of this database client traffic and passing that back to the gateways.
- What are the challenges we face while deploying DAM solutions at client side, such as agent installation, or client specification or discussion on TPS consideration before deployments. As for sizing, as a general rule, we estimate 100TPS per core per on the database server. Each model of appliance has a total number of TPS/HPS that are supported based off of the model of gateway. If clustering is in place, we reduce that capacity number by 10%, due to there needing to be resources allocated to clustering sync processes. In the event you have a database server that you are looking to capture more data that the estimation, or if there is a large database that exceeds the size of. a single appliance, we have a "large-scale" cluster configuration that can handle larger databases. We have also introduced flex pricing allowing customers to purchase based on a total number of database servers or agents, and giving the. flexibility to deploy as many gateways as needed to accommodate. Another recommendation I can make for the general sizing discussion, is the notion of performance monitoring on our appliances. When you initially deploy, you may experience an increase in traffic where a gateways was find, and then becomes overwhelmed based on that increase in utilization. For this, we recommend on-going performance monitoring to keep visibility on the health of appliances over time. This will capture CPU, network, disk, counters, etc, and output that to influxdb, new relic, and/or general SIEM in json via syslog. https://github.com/imperva/mx-toolbox/tree/master/performance-monitoring
- What needs to be determined prior to deploying DAM. • What groups need to be involved (Security, DBAs, Auditors, …)? It’s key to getting all groups involved, so it’s not just security trying to apply and understand policies. • How DAM is going to be used – Is it to meet a specific compliance requirement (SOX, HIPPA, PCI-DSS) and the basic audit and security policies • How events and reporting will be handled [ i.e. Where do you want to send the info, How do the events get resolved *** key item that I’m still trying to get resolved] It is important to engage members of the following teams: Database Admin, Security architecture, infrastructure, automation team (agent installation, patch management processes), SIEM team, SOC, Compliance, and application or business owners. All of these process are unique to each organization, but are critical to be discussed and mapped out prior to a deployment if we want to actually. show value and solve business problems. Automation is an extremely important part of this process, as it will mean the effectiveness and ability to scale. Also, if there are any other integrations that are required, like integration with ServiceNow, or ITSM, CMDB, etc.
Database Monitor Agent
We get a lot of questions around agents. This section will focus on FAQ's from Imperva customers around DMA.
Management Server (MX)
- Identifying database servers to monitor • Are servers based on risk of sensitive data/application [Do you have an accurate db server inventory? What environments do you need to cover (prod, qa, various tests)] • Data classification [Access needed to run data classification scans, Running scans and Determining false positives] • Determining if DB and OS are supported [Now easier with Data Security Coverage Tool] It is important to start with a comprehensive list of your assets. If you have them in a CMDB, we can integrate and pull those ips and. configs from that system, if you do not, we can help weigh a service discovery scan to identify any databases on the network. Next step, is to perform data classification scans to identify which of those databases have sensitive data, or are in scope. If they do have sensitive data, it is important to monitor them. Correct that we can use the data security coverage tool to determine if the OS is supported for agent installation. We can also leverage the which_ragent.sh script on the FTP server to identify this as well.
We receive a lot of questions and answers around the MX topic. This section will focus on Q&A and other content around MX. Management Server (MX) provides a centralized management tool for up to 15 WAF Gateways, enabling large scale deployments in distributed environments.
WAF Gateway, previously SecureSphere
, is equipped with a number of tools that enable the auditing of activity to database servers the querying of this data upon demand. Imperva Community has several questions and answers around this.
- How to differ events from IPC, Beq, SSH, RDP, console in audit data? In the audit screen you will be able to see if it is "Local" or "Remote" traffic, you can also track the OS-User Chain to see if someone used sudo or RDP when connecting to the database.
- What is the difference between kernel and user space agents? What differences are expected to be seen in Audit Data? The biggest difference is where the agent runs from, if not a kernel module, then there are less dependencies on the lower level kernal components making a single agent more versatile on a per operation system from a coverage perspective. There should be no difference in the level or type of audit between the two.
Imperva Community held a LIVE Database Activity Monitoring (DAM) Ask Me Anything Session
to where we had Imperva customers ask the experts any question about their Imperva's DAM product. Click the link above and see all the question with the answers to it. Login to the community and ASK
your DAM questions here
Still can't find what your looking for? Login to the Imperva Community
CLICK 👉 HERE 👈 TO ASK YOUR QUESTION.