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.

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.

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.

Evaluating 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.

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.

Develop Security Architecture

Develop Security Architecture

The next step is to build the security architecture and migration strategy. This strategy lays the foundation for a successful deployment and the ongoing integration of additional applications and services. We cannot emphasize enough that the quality of up-front planning is one of the biggest factors determining the success and degree of payoff from a security project.

This section enables organizations to assemble and align the pieces necessary to develop, update, or validate a modular and flexible security architecture. The goals are as follows:

• Identify and review business objectives
• Identify and review current architecture, its implementation, and strategy
• Identify and review security policy, privacy issues, risks, and associated liability
• Align the security architecture with the business plan
• Validate the architecture against requirements
• Document the security architecture and gain consensus and buy-in
• Develop and guide a two to three-year adaptive migration strategy
• Spawn projects to realize budgeted and prioritized subcomponents

Developing a security architecture and migration strategy should be accomplished in four phases. The first two phases involve doing your homework: identifying the business drivers, defining and collecting requirements, and assessing the current infrastructure environment. With a solid base of requirements, you can proceed to develop the security architecture and migration plan.

Identify IT Principles, Business Drivers and Requirements

To inventory your current business drivers and requirements, you must identify and interview the business units, asset, and application owners. To do this you need to use effective survey instruments and summarize the resulting interview notes in a clear (sometimes even tabular) form. It’s important not to start with a blank slate. Instead, begin with good interviewing instruments such as survey questionnaire templates.

You should also learn about the corporate culture and the enterprise IT Architecture Principles. Determine the opinions of IT executives and your sponsor about issues such as single-vendor versus best-of-breed environments, insourcing versus outsourcing, technology risk taking versus technology conservatism. You will want to know whether managers take strong positions or keep to the middle of the road and to align yourself with those positions when appropriate.

Your general-purpose security infrastructure needs to meet a number of functional, performance, cost, and process requirements across an evolving extended enterprise. Thus, a prioritized business requirements analysis summary is the output from the business driver identification and requirements process. This requirements list is the foundation for your architecture and migration strategy.

Once you have a detailed requirements list that combines generic requirements with those gathered from the interviews, you should prioritize and categorize the requirements. This process should involve the extended project team to maximize buy-in and ensure that the requirements have legitimacy.

Assess the Current Infrastructure Environment [Current State]

Today’s enterprise network tends to be very fragmented and quite complex— hindering even the best efforts to secure systems. The disparate nature of your network creates inherent weaknesses in your organization and in your ability to control information privacy, access, and movement. The issue is exacerbated by the rapid pace of migration to diverse modes of processing, which is driven by user demands, technological evolution, off-the-shelf applications, and their inability to integrate.

Performing an assessment assists you in understanding the issues, shortfalls, and what risks your organization is exposing its infrastructure to. If you are a publicly held company, or are planning to go public, the Securities and Exchange Commission (SEC) requires that you understand all your corporate risks, and convey this information to your potential investors in your prospectus. Having an assessment done by an independent external authority demonstrates that your organization has observed due diligence and objectivity in working toward a secure infrastructure.

An assessment demonstrates management’s due diligence to ensure site availability, data integrity, and information protection for your organization, partners, and customers. It does not guarantee that your site cannot be successfully attacked or compromised. The report does, however, give you a profile of your security posture at a given snapshot in time. This profile can be used as a guide (the current state) that can be contrasted against the security architecture (goal state) and a gap analysis conducted to develop your migration strategy. See Adaptive Security Architecture Lifecycle blog.

The security-focused infrastructure assessment also benefits you by facilitating improvements as follows:

• Service customer expectations and build customer loyalty
• Reduce site outages and performance problems
• Create secure and seamless information access
• Take precautions during acquisitions or mergers
• Meet contractual obligations
• Gain competitive advantage
• Enable corrective action
• Qualify for information protection insurance

Penetration Testing

Penetration testing can use many methods to attempt a system break-in. In addition to using active automated tools as described above, penetration testing can be performed “manually.” For many systems, default configurations, lax patch procedures or a lack of internal controls on applications are common vulnerabilities that penetration testing can target. Penetration testing is a very powerful technique; preferably, it should be conducted with the knowledge and consent of management. A large organization may do well to begin by taking stock of how many vulnerable systems are present in their organization, thereby measuring trends in their network security maturity and compliance to configuration standards.

While penetration studies provide necessary and valuable data on vulnerabilities and exposures, they are symptomatic of a major problem that really needs to be addressed in multiple areas. These include the source, in vital processes that wrap around the architecture, such as configuration management, and the integration and automation of security management (Network Behavior Anomaly Detection, or NBAD).

Develop Security Architecture [Goal State]

The security architecture serves as an evolving technical blueprint for the next two to three years of your infrastructure. It may be a vendor-neutral framework or it may specify vendors. This depends on whether you want to cut to the chase and deploy right from the architecture or whether you plan to use the architecture as an intermediate step moving toward product selection and procurement processes. A vendor-neutral framework should be provided in either case, if only as a yardstick for evaluating solutions.

The architecture should be based on product capabilities that are here today, but it should also anticipate and adapt to emerging trends that will become important in the next two to three years. The architecture should be based on your organization’’s IT Architecture Principles, and it should recommend high-level transition or migration strategies for product selection, implementation, and deployment. In addition, it should provide a high-level risk analysis and risk mitigation strategy.

It should also define your organizational framework for managing security services, examples such as:

Develop Migration Strategy and Plan

As we’’ve said, the architecture should be accompanied by a migration strategy with recommendations for product selection, implementation, and deployment. The migration strategy should provide customers with a transition plan, high-level risk analysis, and risk-mitigation strategy. It should define an organizational framework for managing security services. It may also include cost estimates and other data requested by management.

Conducting a migration strategy planning workshop is an excellent vehicle to bring all of the stakeholders to a common, shared level of understanding. It is an opportunity to sell the security architecture and reach consensus, consider the various functional components that are required and, based upon need, factor in dependencies and priorities. For example, security services such as access management portals require a trusted time service as well as general-purpose directory service. Therefore, the real supporting infrastructure need is identified with everyone present, and funding is justified and committed.

The transition plan is especially important. Security architecture projects are large and multi-faceted, typically requiring months or years of ongoing effort. It is possible to get bogged down in analysis paralysis and emerge from months of planning with no tangible accomplishments to show for the effort. Therefore, architecture and migration planning efforts should proceed as time boxed activities, each lasting a few weeks or months and culminating in functional consensus and iterative improvement.

The first major milestone in your transition plan is completing the baseline security architecture and migration strategy. A second could be completing product or solutions procurement. The third milestone lies in achieving a production security infrastructure deployment. Achieving this milestone should take several months, provided you have the resources for detailed design, implementation planning, and solutions development.

Once in production, you’’ll have a working model that demonstrates some of the benefits of a general-purpose security infrastructure and provides a solid foundation for ongoing security integration and consolidation. To complete an initial production solution in a reasonable period, however, you must not only have resources, but you must also limit the scope of the undertaking. The best plan is to pick low-hanging fruit by integrating a few applications or services at a time.

The next blogs in the series will offer advice on, as follows:

• Product and Solution Selection
• Implementation Planning
• Operations Cutover
• The Adaptive Security Lifecycle

Thanks for your interest!

Nige the Security Guy.