We have already covered the Monitoring phase, for examining activity and database transactions. In monitoring mode, database activity monitoring (DAM) platforms are deployed "out of band", collecting activity and generating alerts as a third party observer. DAM can also be used to block dubious queries and enforce proper database use. The typical database activity monitoring customer does not employ blocking and can skip this step. For those who do employ DAM to protect databases, understand that we are differentiating between monitoring and protection for several reasons.
- Blocking is a more advanced DAM feature that can have serious side effects, and is typically employed only after monitoring policies are successfully in place.
- Policies are based on information discovered through monitoring.
- Blocking rules are commonly predicated on comparison to a known behavioral profile, with the profile built over time from monitoring output.
- Blocking warrants more carefully crafted rules to enforce business policies, and on a more practical level additional routine maintenance -- as application queries, database structures, and use cases evolve.
Logically it makes sense to include blocking under the protection phase, but we do it this way because it's much easier to account for the time and resources by splitting blocking into a separate task from normal activity monitoring. The sequence of events is pretty straight forward: you will have something specific you want to address, such as ad-hoc database connections or SQL injection. Identify the databases, create the policy that describes the goal, and then specify the DAM rule or rules that perform the work. DAM tools often provide a level of abstraction, so you set the pre-defined policy, and the rules that form that policy are implemented on your behalf.
Identify
- Time to identify what activity to block. This could be specific queries, connection types, users, or simply undefined actions.
- Time to identify databases to protect.
Define
- Time to create rules and polices. Based on the activity you want to block, fully describe what activity you want to guard against, and define the rules to implement the policy.
- Time to specify blocking method. Depending upon the platform, there are options on how to block activity: within the database, dropping connections, interception of query, etc. Account for the time it takes to compare and select the option you want.
- Time to specify incident handling & review.
Deploy
- Time to deploy blocking rules.
- Optional: time to deploy additional functions. Add installation and configuration costs for features required to block activity. This may include reconfiguration of the network or redeployment of the DAM product.
- Optional: time to build behavioral profiles. If your blocking methodology relies upon user behavior baselines you need to collect activity for comparison.
- Optional: time to integrate with existing systems. If event handling for blocked activity if different than for monitored events, add incremental costs of additional processes or integration work that needs to be performed and was not included in the Monitoring task of the Secure phase.
- Variable: Time to evaluate effectiveness. Evaluate false positive and false negatives and adjustment policies.
Document
- Time to document policies and event handling.
-Adrian Lane
