There is no such thing as "the best" database security add-on or product, and looking at magic graphs or maturity curves that tell organizations how to select the right product won't help. The right product is the one that is the best fit for an organization based on its requirements and constraints.
While most database security tools offer a full complement of capabilities, they do not all excel in the same areas. What's more, each customer brings his own set of constraints, so the deciding factors have more to do with how an enterprise wants to use the product than the product itself.
It could be a manpower issue, and it may not have the personnel to manage more full-function platforms vs. simpler, more automated options. It could be a matter of cost -- the better product is too expensive or the organization prefers to spend operational expenditure instead of capital expenditure. In some cases, an enterprise's choices are limited, as some vendors simply won't return their phone call if they are not buying over a million dollars in product.
To help guide readers through the database security add-on selection process, this article provides the following steps to help them prepare for procurement, screen out products that won't work, and then compare the ones that -- at first blush -- meet their requirements. We'll also arm readers with some general considerations for making their final selection.
Get the stakeholders: Who's in charge? One of the serious obstacles for organizations selecting database security tools is the split between database, compliance, operations and security teams. Database administrators have long managed security issues for their systems, but new compliance and security demands are pulling in security professionals who have limited database skills. What's more, budget commonly comes from audit and compliance teams who have even less technical sophistication.
The key to a successful database security program is to get these teams working together, along with application administrators, and divide up duties based on expertise and security/compliance requirements, and realistic assessment of the work needed to deploy and maintain the system. Each stakeholder needs to then share expertise for the effort to succeed.
Define requirements: There are two basic tasks organizations need to do before starting to look at database security add-on products: Clearly identify which systems need to be protected, and determine the protection and compliance requirements on those systems. The first phase may simply be a list of applications or databases supplied by internal audit; or the list of systems may come through a discovery process, such as running system scans or data discovery. Determining what protection or compliance controls are needed to meet an organization's requirements is a more difficult step.
For some systems, enterprises might want strict preventative security controls, while for others they may want comprehensive activity monitoring to meet compliance requirements. In this step, map protection and compliance needs to the platforms and systems from the previous step. This will help determine everything from technical requirements to process workflow. It will also underscore the need for cross-database capabilities, and the advantages of platforms that can implement a single policy across different operating environments. Finally, prioritize the requirements so that -- in the event none of the vendors meet your complete list -- you can rank those that get closest to the ideal.
Build the RFI: Once you have determined the requirements, it's time to formalize the Request for Information or Request for Procedure -- RFI/RFP, respectively. A smaller team working under the mandate of the selection committee will save time and resources during this phase. Here, the generic previously defined requirements are translated into specific technical features, and additional environmental requirements added.
This is the time to come up with any criteria for directory integration, additional infrastructure integration, data storage, hierarchical deployments, change management integration and so on. Advanced protection mechanisms can produce side effects that alter application and business logic, so it's important to document expectations in advance.
Do the organization a favor and create an RFP from scratch. Using a template pulled off the Internet will likely contain a bunch of questions the enterprise doesn't need, and means the procurement team is skimming through vendor responses they are not all that interested in.
Initial vendor screening
Response Evaluation: As with any product, it's sometimes difficult to cut through the marketing materials and figure out if a database security add-on product really meets an organization's needs. Remember that vendors will spin their responses in the most favorable light, and often equate one security approach as being equal to -- or superior than -- something else. There is no shortcut, and enterprises need to carefully review the RFI responses to see which ones meet their needs.
Weed out: Organizations should be trying to narrow the field to two or three vendors for evaluation. Fewer than two and they'll likely miss out on identifying better products or competitive pressure on pricing. More than three and the work to evaluate between the players becomes onerous. Smaller firms should try engaging a trusted VAR to help differentiate between the different database security tools. If they have access to peers in security or compliance at other firms, ask them which products they use and why in an effort to pare down the list.
How to test: Now it's time for an organization to have the vendors compete head-to-head and see how well they meet its requirements in a proof of concept (PoC) evaluation. Have test cases prepared in advance, and allocate real hardware for the test, not some ancient laptop that has been sitting in a closet for the last two years. The organization will want to test installation, performance, database compatibility and policy creation at a minimum, and have it reflect real-world situations.
Do not let the vendor run the evaluation process, as it will always succeed when using its pre-canned demo, and that tells nothing about the realities of its database security add-on product. Surprise the vendors into responding to real-life situations and issues that the organization will face day in and day out. Have the vendor demonstrate if the 'out of the box' capabilities are as it claims, and just how much work and customization goes into a product roll out.
We recommend capturing log files or database traffic in advance, with and without security "events," and see which ones the vendor can detect. Unless an organization does a real-world trial, it won't know how well the specific products it is evaluating really work.
Final decision: Gather all of the data from the PoC and see how the results of internal testing ultimately match requirements. It's also critical to understand the long-term livability of the product, as sometimes the database security add-on easiest to set up is not the easiest to own and operate long term. In some cases, management seems trivial, but the extensive vendor support provided during the PoC simply creates an illusion. And there is a giant gap between "potential" and "reality," where some systems "theoretically" monitor the entire universe, but in practice, a single vendor platform -- be it masking or activity monitoring or logging -- will only support a single large target database.
Make sure the product works as advertised and the organization assessed the UI and how easy it was to use; ease-of-use is a key factor in long-term happiness with database security software. Then select the product that is the closest match to the initial requirements and begin the negotiation process.
How to negotiate: Database security tools can be expensive. Never let a vendor know it's won before going into the negotiating process, as it reduces leverage. If timing is not critical, delay decisions until the close of the quarter to put additional pressure on the vendor for better pricing or in order to get critical add-ons for maintenance or upgrades. We strongly encourage including professional services and work required to get the product fully deployed in the original bid; organizations want to avoid cases where investment is not fully usable for several years while waiting for deployments or customizations. This is just a waste of money.
Pricing models: Vendor pricing models are often ludicrously complex, such as pricing per database CPU cores, or by the number of SQL statements being processed. Organizations likely do not have those metrics, nor do you care. We've witnessed cases where a vendor clearly won a PoC, but was ultimately rejected because when the full deployment costs were calculated based upon one of these ridiculous models, they would have been five times the original estimate.
Make sure to have realistic estimates up front and push back for a more understandable -- less complex -- pricing. Ask the vendor if it will agree to eat any costs that vary more than 10% from the original estimates to ensure there are not hidden costs.
Be sure to check out the other features in this series: Part one is an introduction to database security tools for the enterprise. Part two defines four scenarios for deploying database security tools in the enterprise. Part four compares the top database security tools on the market.
Find out what the four enterprise scenarios for database security tools are