Research

Define Needs The first step in the process is to determine your needs, keeping in mind that there are two main drivers for File Activity Monitoring projects, and it’s important to understand the differences and priorities between them: Entitlement management Activity monitoring Most use cases for FAM fall into one of these two categories, such as data owner identification. It’s easy to say “our goal is to audit all user access to files”, but we recommend you get more specific. Why are you monitoring? Is your primary need security or compliance? Are there specific business unit requirements? These answers all help you pick the best solution for your individual requirements. We recommend the following process for this step: Create a selection committee: File Activity Monitoring initiatives tend to involve three major technical stakeholders, plus compliance/legal. On the IT side we typically see security and server and/or storage management involved. This varies considerably, based on the size of the organization and the complexity of the storage infrastructure. For example, it might be the document management system administrators, SharePoint administrators, NAS/storage management, and server administration. The key is to involve the major administrative leads for your storage repositories. You may also need to involve network operations if you plan to use network monitoring. Define the systems and platforms to protect: FAM projects are typically driven by a clear audit or security goal tied to particular storage repositories. In this stage, detail the scope of what will be protected and the technical specifics of the platforms involved. You’ll use this list to determine technical requirements and prioritize features and platform support later. Remember that needs grow over time, so break the list into a group of high-priority systems with immediate requirements, and a second group summarizing all major platforms you may need to protect later. Determine protection and compliance requirements: For some repositories you might want strict preventative security controls, while for others you may just need comprehensive activity monitoring or entitlement management to satisfy a compliance requirement. In this step, map your protection and compliance needs to the platforms and repositories from the previous step. This will help you determine everything from technical requirements to process workflow. Outline process workflow and reporting requirements: File Activity Monitoring workflow varies by use. You will want to define different workflows for entitlement management and activity monitoring, as they may involve different people; that way you can define what you need instead of having the tool determine your process. In most cases, audit, legal, or compliance, have at least some sort of reporting role. Different FAM tools have different strengths and weaknesses in their management interfaces, reporting, and internal workflow, so think through the process before defining technical requirements to prevent headaches down the road. By the end of this phase you should have defined key stakeholders, convened a selection team, prioritized the systems to protect, determined protection requirements, and roughed out process workflow. Formalize Requirements This phase can be performed by a smaller team working under the mandate of the selection committee. Here, the generic needs from phase 1 are translated into specific technical features, and any additional requirements are considered. This is the time to come up with criteria for directory integration, repository platform support, data storage, hierarchical deployments, change management integration, and so on. You can always refine these requirements after you begin the selection process and get a better feel for how the products work. At the conclusion of this stage you will have a formal RFI (Request For Information) for vendors, and a rough RFP (Request For Proposals) to clean up and formally issue in the evaluation phase. Evaluate Products As with any products, it can be difficult to cut through the marketing materials and figure out whether a product really meets your needs. The following steps should minimize your risk and help you feel confident in your final decision: Issue the RFI: Larger organizations should issue an RFI though established channels and contact the leading FAM vendors directly. If you’re a smaller organization start by sending your RFI to a trusted VAR and email the FAM vendors which appear appropriate for your organization. Perform a paper evaluation: Before bringing anyone in, match any materials from the vendor or other sources to your RFI and draft RFP. Currently few vendors are in the FAM market, so your choices will be limited, but you should be fully prepared before you go into any sales situations. Also use outside research sources and product comparisons. Bring in vendors for on-site presentations and demonstrations: Instead of a generic demonstration, ask each vendor to walk through your specific use cases. Don’t expect a full response to your draft RFP – these meetings are to help you better understand the different options and eventually finalize your requirements. Finalize your RFP and issue it to your short list of vendors: At this point you should completely understand your specific requirements and issue a formal, final RFP. Assess RFP responses and begin product testing: Review the RFP results and drop anyone who doesn’t meet any of your minimal requirements (such as platform support), as opposed to ‘nice-to-have’ features. Then bring in any remaining products for in-house testing. You will want to replicate your highest volume system and its traffic if at all possible. Build a few basic policies that match your use cases, and then violate them, so you get a feel for policy creation and workflow. Select, negotiate, and buy: Finish testing, take the results to the full selection committee, and begin negotiating with your top choice. Internal Testing In-house testing is the last chance to find problems in your selection process. Make sure you test the products as thoroughly as possible. And keep in mind that smaller organizations may not have the resources or even the opportunity to test before purchase. A few key aspects to test are: Platform support and installation: Determine agent or integration compatibility (if needed) with your repositories. If you plan to use agents or integrate with a document management system, this is one

Once again, I have knocked off a series of posts for a new white paper. The title is “Understanding and Selecting a File Activity Monitoring Solution”. Although there are only a few vendors in the market, this is a technology I have been waiting a few years for, and I think it’s pretty useful. There are basically two sides to it: Entitlement management: Collecting all user privileges in monitored file repositories, linking into your directory servers, and giving you a highly simplified process for cleaning up all the messes and managing things better when moving forward. Activity monitoring: Full activity monitoring for all your file repositories in scope… including alerting for policy violations. It’s pretty cool stuff – imagine setting a policy to alert you any time someone copies an entire directory off the server instead of a single file. Or copying 30 files in a day, when they normally only open 1 or 2. And that’s just scratching the surface of the potential. The links to all the posts are below, and I could use any feedback you have before we convert this puppy to a paper and post it. (If you are seeing this in RSS, you will have to click the post to see all the links, because I’m too lazy to add them in manually). Share:

The Ponemon Institute has released a white paper, What auditors think about Crypto (registration required). I downloaded and took a cursory look at their results. My summary of their report is “IT auditors rely on encryption, but key management can be really hard”. No shock there. A client passed along a TechTarget blog post where Larry Ponemon is quoted as saying auditors prefer encryption , but worded to make their study sound like a comparison between encryption and tokenization. So I dove deep into their contents to see if I missed something. Nope. The study does not compare encryption to tokenization, and Larry’s juxtaposition implies it is. The quotes from the TechTarget post are as follows: Encryption has always been a coveted technology to auditors, but organizations that have problems with key management may view tokenization as a good alternative and Tokenization is an up and coming technology; we think PCI DSS and some other compliance requirements will allow tokenization as a solid alternative to encryption. and In general auditors in our study still favor encryption in all the different use cases that we examined, Which are all technically true but misleading. If you had to choose one technology over another for all use cases, I don’t know of a security professional who wouldn’t choose encryption, but that’s not a head to head comparison. Tokenization is a data replacement technology; encryption is a data obfuscation technology. They serve different purposes. Think about it this way: There is no practical way for tokenization to protect your network traffic, and it would be a horrible strategy for protecting backup tapes. You can’t build a VPN with tokenization – the best you could do would be to use access tokens from a Kerberos-like service. That does not mean tokenization won’t be the best way to secure data at rest security now or in the future. Acknowledging that encryption is essential sometimes and that auditors rely on it is a long way from establishing that encryption is better or preferable technology in the abstract. Larry’s conclusion is specious. Let’s be clear: the vast majority of discussion around tokenization today has to do with credit card replacement for PCI compliance. The other forms of tokens used for access and authorization have been around for many years and are niche technologies. It’s just not meaningful to compare cryptography in general against tokenization within PCI deployments. A meaningful comparison of popularity between encryption and tokenization, would need to be confined to areas where they can solve equivalent business problems. That’s not GLBA, SOX, FISMA, or even HIPAA; currently it’s specifically PCI-DSS. Note that only 24% of those surveyed were PCI assessors. They look at credit card security on a daily basis, and compare relative merits of the two technologies for the same use case. 64% had over ten years experience, but PCI audits have been common for less than 5. The survey population is clearly general auditors, which doesn’t seem to be an appropriate audience for ascertaining the popularity of tokenization – especially if they were thinking of authorization tokens when answering the survey. Of customers I have spoken to, who want to know about tokenization, more than 70% intend to use tokenization to help reduce the scope of PCI compliance. Certainly my sample size is smaller than the Ponemon survey’s. And the folks I speak with are in retail and finance, so subject to PCI-DSS compliance. At Securosis we predict that tokenization will replace encryption in many PCI-DSS regulated systems. The bulk of encryption installations, having nothing to do with PCI-DSS and being inappropriate use cases for tokenization, however, will be unchanged. At a macro level these technologies go hand in hand. But as tokenization grows in popularity, in suitable situations it will often be chosen over encryption. Note that encryption systems require some form of key management. Thales, the sponsor of Ponemon’s study, is a key vendor in the HSM space which dominates key management for encryption deployments. Finally, there is some useful information in the report. It’s worth a few minutes to review, to look get some insight into decision makers and where funding is coming from. But it’s just not possible to make a valid comparison between tokenization and encryption from this data. Share: