Product and Solution Selection

Product and Solution Selection

The security architecture and migration strategy (which now embodies your approved and prioritized requirements) may recommend specific products, or it may recommend going through a competitive process to select products. In either case, partner selection isn’t final until costs and schedules are nailed down, funding approved, and contracts signed.

???????????????????????????????????????The architecture is an important foundation for selecting the right vendors, partners, and approaches. However, additional tools are required during product evaluation and procurement. Relatively informal Requests for Information (RFIs) can bring the team up to speed on the advantages and disadvantages of various products. Formal requests for proposals (RFPs) should form the final basis for vendor selection and tasking.

First, based on your security architecture, arrive at a short list of vendors or partners for further consideration. Because the architecture covers a number of different functional areas, no one supplier will be able to provide the full solution. However, within each zone (Trusted, Restricted, DMZ, Management, Audit) use the fewest possible number of vendors and try to maximize the integration between those vendors. Also consider what tools and standards you’ll need to integrate across layers (e.g., provisioning as a Management Zone tool that works with the other zones).

Next, complete any information gathering necessary to make a decision as well as obtain and evaluate formal proposals from vendors. Finally, select vendors and partners and obtain funding to proceed with the project.

Develop Shortlist of Vendors and Partners

Developing a vendor shortlist is your first step in selecting architecture solutions. By narrowing the universe of product choices down to a few (perhaps between one and four), the shortlist helps focus time and energy on the most likely solutions. Developing a short list of vendors and partners can be complex. You may want to look at a different, though overlapping, set of vendors for internally hosted, co-sourced and/or externally managed purposes.

Develop Security RFI/RFPS, Evaluate, and Select

During the RFI/RFP process, you must decide on a procurement approach, hire or task procurement support resources, define evaluation criteria, develop procurement documents, hold an RFI/RFP workshop with each bidder to clarify technical architecture and process, and evaluate proposals from bidders.

Depending on how you’ve layered your architecture, you may need to conduct multiple RFI/RFP processes to acquire the specified security infrastructure. For example, in our generic security architecture model, you might issue an RFP for the Identity and Access Management functions, and another for Network Perimeter functions.

RFI

Thus, how many RFI/RFP procurement processes you require depend on how you’ve layered your architecture, the functional groups and what integration points you have defined. It could also depend on whether your team favors relying on a single System Integrator tasked to provide a whole solution, versus working with multiple vendors individually (best-of-breed). The following discussion, therefore, pertains to managing one, or multiple, RFI/RFP processes.

Defining the Procurement Approach

If your vendor shortlist has more than one vendor listed, then you will need a competitive RFI/RFP process to select a supplier. Even if a single security solution supplier has been selected for a particular requirements set, you may want to request a formal proposal prior to signing an order.

It is up to you to decide how formal the process of selecting the supplier should be. There are advantages and disadvantages to having a “heavy” RFI/RFP process. A lightweight process with fewer steps and fewer demands on the vendor and on your proposal review team can move faster. A heavy process requesting a great deal of information and proof points for vendors takes longer but also increases your certainty that you have chosen the right solution and may also result in more competitive pricing.

Hiring/Tasking Procurement Support Resources

In almost all cases, we recommend that customers do their own evaluation of the security information and proposals they receive in response to their RFI or RFP. Letting vendors or system integrators define the entire solution and tasking for you without any review is like letting a fox into the henhouse. Use your own staff and/or a vendor-independent consultant to help evaluate proposed solutions and tasking.

Developing RFPs

A competitive RFP process tests the vendor’s mettle and drives down the price. It gives you a chance to get comfortable with the account team and the consultants from the vendor(s). But if you commit to the competitive process, be prepared to spend some time and money on that process. Don’t push out a half-baked RFP that’s cut and pasted from the architecture and your contract boilerplate. Instead, make sure it’s a good RFP that defines a level playing field for vendor evaluation. Request the right information in the right way.

The architecture forms the backbone of the RFP by defining technical specifications and definitions for security services (such as dynamic roles) and additional capabilities (such as rules-based services). This helps you put the vendor’s differentiated product marketing “fluff” into a common technical framework. But the RFP must also tell the vendors what your evaluation criteria really are and provide instructions to the vendor on how to respond. You need to get answers from the vendors in a form that lets you compare apples to apples and oranges to oranges.

RFP Workshop and Evaluation

Don’t judge proposals by their weight alone. Depending upon the scope of the requirements, you may want to give a hard page limit. Don’t just throw the documents over the wall. Give the vendor enough time to respond. Also, for large complex systems such as identity management solutions, we strongly recommend that you have an in-depth, in-person RFP workshop meeting with each bidder and that you bring your professional advisors to this workshop.

RFI Scorecard

The RFP workshop is important because it gives the vendor a chance to learn more about your environment and goals. It gives you a chance to get to know the vendor’s key technical people. Also, you’ll learn a lot more about the vendor’s product and solution-development approach, and you’ll get some high-level design work done up front. After the workshop, you can and should expect a much more specific, tailored proposal from the vendor than you would otherwise have received. After all, you don’t want to review a proposal offering no more than a marketing spiel and/or a phony, cut and paste “solution.” Rather, you want a well-thought out proposal for a real solution that’s tailored to your environment.

Vendor ComparisonEvaluating the Proposals

After the proposals are in and the workshops have been held, roll up your sleeves and analyze each proposal. During the RFP development process you should have identified the evaluation criteria to be used. Create an RFP summary matrix to compare the responses and prioritize key functional requirements. Be very open with team members; avoid hidden agendas. Use your IT Architecture Principles (discussed earlier under architecture) to get intangible considerations (such as preferences for best-of-breed vs. single vendor products, mature vs. leading-edge technology, or existing relationships with a particular partner) out on the table. These considerations need to become part of the weighted set of factors going into making a decision.

Security Solution Bake-Off

A network security product or solution bakeoff is an important step in the RFI/RFP evaluation, negotiation, and planning process because it offers the best way to understand the real capabilities and performance of the devices you are considering. As we all know, a bit of preparation on the front end is always required to get accurate results. Combine that with insider knowledge and you can ensure an accurate and deterministic network device evaluation.

The following graphic depicts an example of a methodology that was used to test across Firewall, IPS, VPN and Management solutions driven by real-world penetration testing mapped to validating RFI requirements for Detection, Response, Alert/Logging, Correlation, Reporting, and so on.

Network Security Evaluation

Obtain Funding Approval to Execute Strategy

Now that the final proposal(s) are in and the best solutions have been selected, you’ll be asking for the first time for serious money. If expectations were built correctly at the beginning of the process, then the price tag may not come as a big surprise. On the other hand, this is where the rubber meets the road, and you may once again be questioned about the value of the security project. In fact, you may feel that selling security is a forever process— it is. Security is part diplomacy, part salesmanship and, part the art of integration to build a holistic system.

Thanks for your interest!

Nige the Security Guy.

Advertisements