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.