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.
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.
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.
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 of the most important steps.
- Performance: Is network or agent performance acceptable for you environment? Are there other operational considerations driving you toward one model or the other? Don’t set arbitrary standards – monitor performance on your production systems to ensure your tests represent operational requirements. This is most important if you have massive repositories with high-volume access.
- Policy creation and management: Create policies to understand the process and its complexity. Will built-in policies satisfy your requirements? Are there wizards and less-technical options for non-technical experts to create policies? Then violate policies and try to evade or overwhelm the tool to learn its limitations.
- Incident workflow: Review the working interface with those employees who will be responsible for enforcement.
- Directory integration
- Entitlement workflow: Is it a closed loop or manual?