@Taofik Jolaoso,
Congratulations on your
Impervian Spotlight! To answer this question:
Around the topic of monitoring mode versus blocking mode there is a little bit more concern in putting things into a blocking mode on the database side versus on the web application firewall side. The web application firewall side is intended to mitigate a bunch of traffic. You get a bunch of noise there and you're expecting to block that based on what you know about.
On the database activity monitoring side, there's fear of blocking something that's a production transaction. We want to be selective about what we want to block. A lot of customers would be very selective about to do that successfully, things that we know that we can block or what we would start with.
For example, should you ever be dropping a table on a production database? That's something I can confidently say, let's put a policy in place and block or prevent that from happening. Certain operations like I should never escalate user privileges or create new users or delete users on a production box unless it's following a change control process.
Those sorts of things you can absolutely put into a block mode confidently. As far as other monitoring the block mode, it would really depend on the policy definition, and what you are looking to accomplish. I go back to what is it that we know for a fact that we can block and mitigate against? What is our biggest risk associated with that? That would be modification to schema like dropping tables.
Secondarily, there may be things that we can easily implement like if it's a PCI type application and we have a credit card table, should there ever be more than one record containing a credit card, leaving that table, at any time. Applications don't typically do a select star against the credit card table. We can look at the number of record leaving certain tables and have policies around that as well to prevent excessive record access.
Those are things as a general statement that you could put in like X number of records over a certain period of time, that sort of a thing. The last part about thi is there is a question here about when DBAs are all logged in with the database with assist DBA role. So there are two types of users with databases, there is programmatic users that are invoking access from code, maybe applications of scripts. Then there are interactive users, DBAs that log in from their toad or SQL developer or whatever client they have and do different types of things all the time. The programmatic users, those behaviors and those activities are repetitive and they fall into a pattern. It shouldn't really deviate that much because it's code, it's executing and it does the same thing every single time depending on the input parameters.
Then the DBAs, you would not be able to put them into that box of saying, "Hey, I'm expecting the same things from you." Because they do different activities all the time, every day. What we can do is look for deviations from what is known and expected from our service accounts. So if an application user, a service account logs in from an associate or the application servers IP address from the correct client and the access tables that are known, great. This is where the profiling feature can actually come in really useful, I can develop a profile for my service accounts and say, this is what a positive security model looks like. This is what you should be doing.
If you deviate from this, I want to block that or prevent any deviation from that. So that's another example of a way that you can put something into blocking confidently because you already know what those behaviors and activities should look like. But those are some general examples of how we've seen blocking be useful in production. And then of course you can set policies to a lots of other things that don't necessarily need to be blocking.
------------------------------
Brian Anderson
------------------------------
Original Message:
Sent: 09-17-2020 10:27
From: Adesola Jolaoso
Subject: Database Activity Monitoring (DAM) Ask Me Anything Session
@Christopher Detzel,
Thank you for this opportunity. My first question is how long is enough to run your policies in monitoring mode? Secondly, Is it really necessary to turn ON BLOCK MODE when DBA's are login to the database with SYSDBA role? To optimize the usage of our DAM, how do we plan for the switching from MONITORING to BLOCK mode? Its so sad I will be missing out on this event. Will be back to read through insightful questions from the Impervians on this thread
------------------------------
Adesola Jolaoso
CBN
Abuja
Original Message:
Sent: 09-15-2020 08:41
From: Christopher Detzel
Subject: Database Activity Monitoring (DAM) Ask Me Anything Session
Hello Imperva Community –
We are looking forward to our Ask Me Anything (AMA) session on Friday, September 18th, 2020 from 10:00 – 11:00 AM CT featuring @Brian Anderson, Director of Technology (Office of the CTO), as well as @Paul Aiuto, Michael Watson, Ofer Breda, Aaron Connell, and @Jim Burtoft (prm) from our Sales Engineering team!
Our experts will be answering any and all of your questions around our Database Activity Monitoring product.
Event Instructions:
- If you are able to attend the event live, RSVP here and join our webinar session!
- Reply directly to this thread with your questions and an expert will reply to all questions received starting at 10:00 AM CT this Friday.
- Use @mentions when responding to a specific expert.
Please reach out to me, your community manager, with questions or for help at
communitymanager@imperva.com.
If you are unable to make it during the time of the event, post your question to this thread and we will be sure it receives an expert response this Friday! Make sure to check back here following the session to see all of the amazing questions asked by your peers and the responses from our experts.
#DatabaseActivityMonitoring
#AllImperva
------------------------------
Christopher Detzel
Community Manager
Imperva
------------------------------