My interesting

A security design framework is a structure on which all future security designs can be built. As a security designer, you should create a base security design framework on which your security designs can be built or you (or your design team) might end up with incomplete assessments, lack of follow-through, and an incomplete picture of the changing security landscape.    70-291   70-290    70-293   70-271    70-299

After this lesson, you will be able to

Describe the components of a security design framework.

Describe the process for creating a security design framework.

Identify the principles of information security design.

Explain the purpose of threat modeling.

Perform threat modeling.

Design a process for responding to incidents.

Design the use of segmented networks.

Design a process for recovering services.

Estimated lesson time: 80 minutes

Components of a Security Design Framework
A security design framework is a collection of items or components that should be considered when creating any information security design. Parts of a security design framework typically include the following concepts, which will be defined more fully in later sections:

Prevention, detection, isolation, and recovery.

The principles of information security design. These are concepts that should be reviewed when examining any IT process. If they can be applied, a more secure process will result.

Threat modeling. If you understand how a network or one of its components might be attacked, you can develop a better defense.

Incident response. When an attack occurs, what should be done?

Segmented network design. Isolating parts of the network can contribute to security. Each design should question the need for segmentation and propose how to isolate sensitive data and the computers that store or manage it.

Recovery processes. An attack, or even an accident, can mean the destruction of data, computers, or network infrastructure. Planning for the recovery of data, computers, and network infrastructure can prevent the loss from becoming a disaster.

Life-cycle review. Every security design has a life cycle. Security design, policy and procedure development, implementation of the security design, and management of the design and policies form the basis of a sound security framework. However, this is not a linear process. Each new product, process, and threat means re-analysis and possible revision. Security is not a job that is ever done.

Guidelines for Reducing the Impact of Interoperability on Security  70-643    NS0-201   70-237    70-271   70-642
Use the following guidelines to reduce the impact of interoperability on security. These guidelines refer to the process of encrypting data but also highlight the need to consider interoperability.

 Note  To make this example simple, this discussion is restricted to communications across the data network.
 

Determine what current processes will be part of the design. This is a good first step.

Develop a list of the hardware and software that will be used in the design. This list can be compiled by addressing the following issues:

What computers will be used? Are products such as routers, firewalls, and other network devices currently separating computers that must share information?

What operating system and version will be used? Is specific application software used? For example, is Microsoft Word used for documents? Is Microsoft Excel used for spreadsheets? Will documents be copied across the network? Collected from an intranet site? And will they be attached to e-mail messages or be in the body of e-mail messages?

Will the hardware and software used affect which security protocols can be used? Consider, for example, that IPSec is implemented at a lower layer than SSL. IPSec can be used to encrypt all data without any need to redesign the application. SSL, however, must be designed into the application.

Evaluate the capabilities of current processes, hardware, and software. The list of possible solutions that can be used in any particular security design depend on the capabilities of existing hardware and software and the capabilities of planned purchases of hardware and software. Use the following questions to evaluate current system capabilities and available products:

What security software and mechanisms currently exist? In today’s networks, the use of IPSec should be considered, as should virtual private networks (VPNs) for remote communications, SSL for access to intranet servers, and e mail encryption. The use of SSH (secure shell) is also a possibility for encrypting communications that might be used to manage databases and file servers where information resides. Many of these products and processes are built into Windows Server 2003

Are proprietary encryption products already a part of the network infrastructure?

Can all clients that will be used participate when specific communication protocols are selected? This will narrow the field of possibilities or determine the need for hardware and software upgrades.

Evaluate other communication protocols and software if no solution exists for your current configuration and if funding exists for additional purchases.

Review existing standards for communication protocols. How old is the standard? Do vendors adhere to it? Which vendors? Is there a wide range of implementation decisions to be made? Is the standard volatile or stable?

For each protocol, determine where interoperability issues exist. One way to make this determination is to contact other individuals and organizations that are already using the protocol you are considering. Ask your current vendors to provide you with contact information for customers who are using their products with the products that you already have or plan to purchase. Ask the contacts that they provide if both products work well together.

Determine the best communications protocol for each need. For each of your needs, rank the possibilities by determining cost to implement, availability, relative security offered, and interoperability issues. This process will show you how a protocol that seems best in one scenario is not well-suited to another scenario. For example, Internet Protocol Security/Layer Two Tunneling Protocol (IPSec/L2TP) is a better choice for VPNs than Point-to-Point Tunneling Protocol (PPTP) if security is the only parameter measured. However, other factors—such as the ability to transit Network Address Translation (NAT) or the cost to upgrade all client computers—might prevent it from being selected.

For an organization to stay in business and maximize profits, its management must consider certain business drivers for each business activity the organization undertakes. Common business drivers that the security design must address include the following:70-294  mb2-631   70-640   70-297   70-630

• The initial and ongoing cost of security The real and perceived cost of security will always be a driving factor in the implementation of security.

• Legal requirements for security Legal requirements affect implementation of security and other IT operational aspects, and the impact of these legal requirements is increasing. Deciding how much security is necessary and convincing management to accept the recommendation is not an easy chore. However, current and proposed laws support the design and development of sound security practices. Consequently, legal requirements often can be an ally to security designers rather than a burden.

The impact security decisions will have on end users For purposes of considering the effect of security on end users, end user is defined as an individual who uses a system to obtain, manage, or distribute information but is not limited to employees who work directly for the company. Customers who access their banking or other information via the Internet, partners who cross gateways to access shared information, and public use of company Web sites are all examples of end users relying on information systems. Security designers must consider the impact that security policies will have on end users. For example, changing the password policy to require the use of symbols, letters, and numbers in password, when users were not required to do so before, can greatly upset a large number of users. If users are not warned that such a change is coming and told what they need to do to, the uproar and complaints can affect productivity and even force a roll-back to a less secure password policy.

How security will mitigate risk Risk is often defined as the probability of suffering a loss. Risk management involves identifying risk and deciding what to do about it. Even if a risk cannot be eliminated, it can be addressed. Mitigation of risk is one the goals of information security.

In addition to these common business drivers, the IT department has business drivers of its own to consider:

Maintaining interoperability The best security design might not be implemented because it failed to take into account the nature of all operating systems and applications that are part of the organization’s network.

Achieving security maintainability goals Any operations design must achieve certain maintainability goals, and this is even more important with security designs. Security devices and procedures that are not maintained will eventually become ineffective.

Addressing scalability needs Many security designs can be implemented in a test network or small business with great success, but are impractical or fail when rolled out across more extensive systems. While you can’t always forecast system growth, you can evaluate a security design in light of the environment it will be deployed in and simply assume moderate growth over time.

The guidelines that follow will help you analyze these business and IT-specific drivers.