The final installment in our masking series closes with a simplified buyer’s guide for product selection. As with most security product buyer’s guides, we offer a fairly involved process to help customers identify their needs and evaluate solutions against each other. These guides address the difficulty of getting all stakeholders to agree on a set of use cases and priorities, which is harder than it sounds. We also offer guidance on avoiding pitfalls and vendor BS. Of course you still need to ensure that your requirements are identified and prioritized before you start testing, but the process with masking technologies is a bit less complicated than with other technologies.

The field of vendors has dwindled rapidly for one simple reasons: Customer requirements are narrowly defined along a few principal use cases (test data management, compliance, and database security), so most masking platforms focus their solutions along these lines. Only a couple full-featured platforms provide the necessary deployment models and sufficient database coverage to compete in all cases. But we often see a full-featured platform pitted against others that focus on a single use case, because not every customer needs or wants every possible capability. So don’t focus solely on ‘leaders’ in whatever analyst reports you may read, but cast your net across a wider group of vendors to start your ‘paper’ evaluations. That should give you a better idea of what’s available before you conduct a proof of concept deployment.

Define Requirements

Over and over again, we see dissatisfaction with security products stemming from a failure to fully understand internal requirements before product selection. We understand that it is impossible to fully evaluate questions such as ease-of-use across an entire organization before a product is in full deployment. But unfortunately, more often the real issue is lack of understanding of both the internal expectations for the product and where the organization is headed. So defining needs and getting input from all stakeholders are necessary for a successful product evaluation and selection.

• Create selection team: Even small firms have at least the technically-focused security and IT operations groups cooperate during the selection process; but typically different business units, along with risk, audit, and compliance have input as well. Identify the major stakeholders and designate a spokesperson for each group.
• Define what needs protecting: You need to identify the systems (file servers, databases, etc.) and data types to be protected. Summarize what the data is and how the systems are used, and map desired data flow if possible.
• Define how data will be protected: Map your protection and compliance needs to the systems, processes, and data from the previous step. Accept input from each stakeholder on the security and compliance requirements for each data type, and the risk or criticality of that data.
• Design your ideal deployment: Now that you have an understanding of what needs to be protected and how, document the specifics of integration and deployment. Determine what masks are appropriate for each data type, how data flows through your systems, and where your integration points should be.
• Define tests: Determine how you will verify that vendors meet your requirements. Decide what samples data sources and data types need to be tested. Confirm that adequate resources are available to thoroughly test the system. Pulling an old laptop from a drawer or an older server from a closet to run tests on is a way to ensure failure. Determine and assign responsibilities for who will test and who will evaluate the results. Tier the tests so the most critical elements are tested first, to weed out unworthy products as quickly as possible. Finally, figure how you will validate the efficacy of the masks, and whether they are genuinely producing suitable results.
• Formalize requirements: At this point you should have a very clear picture of what you need, so it’s time to document some of your requirements for a formal Request For Information (RFI) and Request For Proposals (RFP) to identify which vendors offer appropriate solutions, and then select the ones that best match your requirements for further evaluation. You should also have a good idea of your budget by this point – it will help guide your selection, and may force a phased deployment.

Vendor Selection

1. Deployment Architecture: Architecture is key because it determines compatibility with your environment. It also directly correlates with performance, scalability, management, and ease of deployment. Centralized masking servers, distributed deployments, on-database masking, and agents are all options – but which is best depends entirely on your environment and how you want to deploy. So testing your deployment model across sufficient systems is essential for developing a good idea of how well the masking solution fits your environment.
2. Platform coverage: Verify that the vendors support the relational and quasi-relational databases you need, as well as their ability to work with the applications and file servers you wish to integrate with. This is typically the first area where vendors “wash out” of the evaluation, when they don’t adequately support one of your critical platforms. You should review vendors’ published support matrices, but we suggest you also test your critical platforms to make sure they work to your satisfaction. How data is collected and managed varies from vendor to vendor, and how well each solution works with different database types can be an eye-opening comparison.
3. Use, customization, and management: Test the day-to-day tasks of adding data sources, performing discovery, adding masks, and customizing reports. You will be living with this UI and workflow on a daily basis, so ease of use is a major consideration. If the product is annoying during the evaluation process, it is unlikely to become more pleasant with familiarity. Poor user interfaces make administrators less likely to tune the system, and poor workflows are more likely to cause mistakes. Ease of use is rarely listed as an evaluation criterion, but it should weigh heavily in your choice of platform.
4. Scale and performance: Vendor reported performance and real world performance are quite distinct, so you need to evaluate all phases of the masking process. Agents may not meet expectations, in-place masking may have unacceptable impact on target systems, the masks you select may require extensive computational overhead, or centralized masking solutions may clog your network. Performance of these facets of a solution – especially scaled across your organization – provides a good idea of performance and scalability, and forewarning of possible issues to anticipate. It is essential to test and analyze scaling with very large databases such as Teradata and Hadoop, as well as latency of in-line masking products – there is simply no alternative to testing a production-sized installation.
5. Integration: Most customers only evaluate integration with their platforms and applications that house and serve data, but it’s important to determine how well the masking platform integrates with other supporting systems as well. Encryption, key management, reporting, workflow, identity, and access management all often integrate with masking, so investigate and test.
6. Check references: What do other customers say about the product, the company, and the support they provide? What did other customers expect from the product and where do they think it excels? These questions can tell you a lot about both the company and the product, so ask your perspective vendor for three references.

Negotiate

So you found an ideal product – can you afford it? When you do the math on what a masking product will cost, you need to account for not only what you need today, but at least your mid-term requirements as well. We have heard some vendors are inflexible on pricing, so you can always look for additional ways to reduce overall cost of ownership.

• Pricing & pricing models: There are a couple different ways vendors price their products: by number of databases under management, by volume of data masked, and by number and size of masking servers. Each of these models can have hidden costs – customer requirements grow over time as companies discover more and more data that must be protected. If your managed data doubles every 3 years, this can get quite expensive, so we recommend negotiation of a pricing plan that enables growth without linear price increases. We have seen several cases where the ‘best’ product did not win due to pricing.
• Services: We recommend that as part of the purchase you negotiate assistance with deployment. Most customers ask for assistance setting up compliance reports or tuning servers to scale across the organization. Most problems missed during the proof of concept pop up early in full deployment, so ask for deployment assistance. Among customers we surveyed ongoing platform management was fairly stable, but there was considerable ‘front-loaded’ effort for deployment and setup, while the amount of time spent on day-to-day management was relatively low. To rein in initial deployment costs and get up and running quickly, enlist the vendor’s team. This also provides mentors who know the product for your team. Push the vendor to provide assistance with deployment as part of the contract.
• Non-cash add-ons: As we mentioned, many customers struggle with costs of implementation across IT. Keep in mind that the incremental cost of software is zero, zilch, nada – so vendors can often bundle in a bit more to get the deal. It never hurts to ask for additional software licenses, support, or whatever.
• Service levels: If your team lacks deep of knowledge of how best to handle regulatory challenges, another non-cash sweetener could be an enhanced service level. Perhaps it’s a dedicated project manager to get your masks, policies, and reporting done. Maybe it’s the Platinum level of support, even though you paid for Bronze. For customers who lack in-house security and compliance expertise, a deeper service relationship can come in handy as requirements change.