IT Certifications

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.

Considerations for Analyzing Existing Security Policies and Procedures
The ability to analyze existing security policies is necessary to the development of security design. Ask the following questions to analyze security policies:   70-236   70-293   MB2-632   70-620  117-202

Does the security policy meet business needs? Does an existing policy on Web sites, for example, cover the use of SSL to protect customer data? How about the security of that data once it is in the organization’s database? Are there policies that cover all aspects of the business’s operations? Are there, for example, policies to cover access to the Internet by employees or policies that cover the use of privately owned Personal Digital Assistants (PDAs) for storage of company, customer, or patient data?

Do the written policies follow the definition of a policy, or are they precise in defining exact implementation details or technology choices? There was concern, for example, that HIPAA regulations would specify the use of digital signatures on the transport of any patient or healthcare data and would specify what technologies and equipment should be used for enforcement. The bill did not do either. While HIPAA is a U.S. federal law and not a security policy, analyzing the law’s effects on healthcare organizations offers some of the same challenges as evaluating the effects of security policy on an organization, and a wealth of commentary can be found on the law to assist you in determining whether your analysis is in tune with experts in the field of law and information security.

How can the policy be enforced using technology? Policy should be written without undue consideration to what is technically possible. However, an analysis of the policy should result in a precise statement on what can and cannot be enforced with the technology currently in place, what additional technology might be purchased to fulfill the technical enforcement of the policy, the cost of purchasing additional technology for enforcement, and alternatives to the policy that can be recommended.

Is one security policy more important than another security policy? Is a policy that restricts user access to the Internet more or less important than a policy that requires customer data to be encrypted? Remember to evaluate whether the need for encryption is high because of risk of attack or whether encryption is being used for some other reason. For example, some have suggested that encrypting customer data may protect a company from having to follow the demands of a California law that requires a report be given to California customers if an attack is successful against your organization. You might determine that encryption is overkill given the nature of the information you are protecting and the layers of company infrastructure that would have to be penetrated to successfully attack it. You might, therefore, recommend a policy change or prioritize implementation differently when you understand the policy’s driver.

Analyzing Business Requirements for Information Security    70-547   70-291   SY0-101   70-270

When business managers state business requirements for an IT department, their requirements often do not consider security. Instead, managers ask for things such as quick turnaround, return on investment, and reduction in expenses—requirements that often lead to reduced security. As a security designer, you are responsible for aligning these business requirements with the IT department’s goals to design and deploy secure systems.

After this lesson, you will be able to

• Explain the process of analyzing business requirements.

• Describe common business drivers for security design.

• Explain the guidelines for:

  • Mitigating the cost of security.

  • Managing legal requirements.

  • Determining how security design affects end users.

  • Using the security design to mitigate risk.

  • Reducing the impact of interoperability on security.

• Describe threats to security introduced by maintainability issues.

• Analyze existing security policy and procedures.

• Categorize and secure data based on organization’s needs.

• Use data flow to determine where data is at risk.

• Analyze risks to security in the existing IT administration structure.

Estimated lesson time: 90 minutes

The Process: Analyzing Business Requirements

To analyze business requirements:

1. Review business requirements stated by management. Business requirements might be stated in terms of the budget for the project, the connectivity and types of data that must be available for use by partners, etc. Make sure you understand the stated purpose.

2. Make note of additional business requirements discovered during the review. Asking questions about the stated requirements, for example, might turn up additional requirements. Questions about the type of data to be shared, for example, might reveal the limitations of who can read the information, who is allowed to change it, and so on.

3. Analyze the business requirements. You do this so that you can make sure that the security design stays true to its goal of supporting the business. To help you analyze the business requirements, perform the following tasks:

   1. Develop a list of common business drivers—the objectives that propel the business forward and continue to make it profitable. (Examples of common business drivers are shown in the following section.) You can use this list to help you analyze all projects.

   2. Research how the business drivers will affect the security design and vice versa.

   3. Analyze existing security policies and procedures.

4. Document what you learn. If you document what you learn, your security design can start with an orderly discussion of the business drivers and business requirements and how you have considered them. This information will make it easier for business decision-makers to accept and support your design recommendations.

The rest of this lesson provides information that you can use to help you analyze business requirements.

Identifying the Sources of Risk: It’s Not as Simple as It Seems
Many risk management experts caution that we should look for all sources of risk. They identify the sources of risk as people, processes, and technology. Other experts include things beyond our control, such as your ISP’s lax password policy that could be a risk to the security of your organization’s data. Identifying the sources of risk, however, is not always simple. SY0-101 70-272 70-630

In 1998, a small Midwestern consulting firm’s telephone system was rendered inoperable in the middle of a business day when the system administrator changed the account used to run the service for the software-based Private Branch Exchange (PBX) system. The change was made, in accordance with the PBX system documentation, to facilitate the delivery of voice mail directly to the employees’ mailboxes. However, when the PBX system was brought back on line, the phones were all dead. Fortunately, the administrator was able to determine that the problem could be rectified by granting the new account appropriate permissions on the database. Nowhere in the PBX system documentation was that step listed or even alluded to.

It is easy to see, after a loss occurs, how it happened. Yet if you had been evaluating the risks associated with the PBX, which source of risk would you have identified?

Was the source of the risk people related? The systems administrator has to make changes to systems configuration from time to time—did she make a mistake or proceed without all the information? Did the administrator make a change to the configuration without thinking of the possible consequences? If she had reviewed the process with others, she might have questioned why permissions were not being reassigned.

Was the source of the risk technical? The system might have failed because its configuration was in error. Wouldn’t a better design have warned the administrator that a change in accounts might cause a problem? New error messages in Microsoft Windows Server 2003 and Windows XP Professional seek to warn users and administrators of nonreversible operations, such as password resets, that might damage the ability to access critical data such as encrypted files. 70-297 70-640 mb2-631

Was the source of the risk process related? Should the operational procedures have been required to be tested or at least reviewed before they were implemented? Or, perhaps such a major change should have been made during less critical business hours.

Threats to Security Introduced by Security Maintainability Issues
Any operations design must satisfy maintainability goals, and this is even more important with security design. If security cannot be maintained, it might be eliminated. The following threats to security can result when security designers forget to consider maintainability:

If a security design has a high reliance on people following a written policy that cannot be enforced via technical controls, it is unlikely that adherence to the policy will continue over time.

If a technical control is difficult to maintain, its enforcement might weaken over time. If there is no way, for example, to prevent the introduction of modems into the network and strict restrictions on Internet access are enforced via the local area network (LAN) connection, users might use modems as alternative paths to access the Internet. In doing so, they breach security by avoiding filters, access controls, and logging.

When controls must be renewed and it is difficult to do so, business productivity will be disrupted. Can certificates be automatically reissued before they expire, or must new certificates be manually obtained? Who will manage the intrusion detection systems when the person who received training and cared for the intrusion detection systems for three years leaves the company?

Important Support for security maintainability is important. In Windows Server 2003, functions such as Group Policy can be used to reapply security settings on a periodic basis. Computer and user certificates can be automatically deployed. Security templates can be reapplied to stand-alone systems and used to audit security compliance. 70-294 70-647 70-291

Considerations for Determining How Security Design Affects End Users
To help you determine how a change in security can affect end users, ask yourself these questions: 1D0-410 70-431 70-299

How will a stronger password policy actually work at the end-user level? Will requiring a longer password mean more passwords are written on paper where unauthorized users might discover them? Will it mean loss of productivity or additional help desk labor because of an increased need to reset passwords?

What will adding an account lockout policy do to users? Account lockout policies lock accounts after a number of incorrect password attempts. The number of false attempts allowed is adjustable. Will the number of allowed attempts accommodate remote users, or will fumble-fingered sales personnel be unable to enter their orders because their account gets locked out? How long will the policy keep accounts locked out? Local users might be able to wait the 10 minutes or until the help desk can reset their account. Can the traveling executive seeking critical information on a dial-up line afford to waste that much time attempting to contact the help desk?

What will be the side-effects of moving to smart cards? What will happen when users forget their smart cards at home and attempt to use an office mate’s card? If restrictions on card removal (sessions are logged off when smart cards are removed) are set, two users cannot use the same smart card and maintain consecutive sessions. This solves a long-standing dilemma as well—that is, how to restrict each user to one session at a time on the network. These are positive side-effects that affect users. However, smart cards can also have a negative effect. In the Microsoft Windows 2000 environment, smart card certificate renewal is not automatic. This situation can have a major impact on end users because they must figure out how to renew certificates. Although this is not a difficult chore, it can be for some users. When thousands of users must do so, many of them will have problems. This will put a large strain on the help desk and might affect the productivity of the users, as after certificates expire users cannot work until they renew the certificate. In Windows Server 2003, you can implement automatic renewal. If you do not consider the impact of security on end users, you might miss this critical step.

Guidelines for Using the Security Design to Mitigate Risk
Follow these guidelines to incorporate risk mitigation strategies into your security design:

Look at IT operations with an eye to risk. This approach can help in the development of more secure systems.

Develop a risk model for IT operations as a part of any security framework.

Don’t limit risk modeling to the evaluation of potential security risks, but incorporate the development of a long-term risk management strategy into the company’s IT operations.

Find out who manages risk for the organization. You will find them to be a ready source of information on risks to your organization.

Incorporate other people’s knowledge about risks into security designs.

Require continuous risk assessment and response. Your security design should continually search for new risks and periodically evaluate known risks. Consider that viruses and worms, historically perceived as risks related to e-mail, are now spread by attacks against vulnerable services such as Web and database services exposed to the Internet. Modern malicious code is a blended threat and targets various segments of the computing environment, and as such, requires constant vigilance. ex0-100 70-291 SY0-101 70-270

Integrate risk management into all roles, including IT roles and those of every process owner. Process owners can take responsibility for identifying risks and managing them. If end users circumvent security, for example, by sharing passwords, they put systems at risk. Human Resources can be involved by ensuring that employees are aware of security risk factors, and if dictated by policy, by enforcing sanctions against people who do not comply.

Legal Requirements that Influence Security Design 70-643 156-215.1 70-631 642-811
To make time spent with legal advisors efficient and productive, the security framework should include a living document that includes concise, IT-friendly statements about each law that might affect IT projects. Here is an example of current laws that might be examined for their relevance to projects. The review of such a list might point out, for example, the need for better technical controls on access to patient or employee data, or the need for discussion on improving integrity controls on financial data. Any discussion of whether the law might affect how the project should be designed should ultimately involve the organization’s legal advisors. This short list of laws to be explored is not intended to be a comprehensive list:
Graham Leach Bliley. Financial institutions (that is, any company that provides financial products or services) have their own set of legislation that controls how they must manage the privacy of customer financial information. It restricts use and disclosure of non-public personal information.
Sarbanes-Oxley Act of 2002 (Public Company Accounting Reform and Investor Protection Act). This act targets publicly traded or registered companies. Private firms are also complying. Many restrictions are related to the operation of public accounting firms, and the act also includes strict requirements for records retention to prevent document destruction. For example, if a firm is engaged by a company to do an audit, that firm cannot also provide development of financial services or accounting software for the company. The CEO and CFO must sign a statement that accompanies the company’s annual report stating that all information in the report is correct. This might sound tangential to information security until you consider the question, “How can they attest to accuracy if they are not prepared to defend the security of their financial computer programs and attest to the integrity of the data?” The act also requires that internal controls be reported. Internal controls = security infrastructure. MB7-515 MB7-517 70-299

Homeland Security Act of 2002 (Provision Computer Security Enhancement Act). This act provides increased surveillance powers for law enforcement agencies, including surveillance conducted on the Internet. The act includes provisions to make it easier for federal agencies to obtain customer information from Internet service providers (ISPs).

USA Patriot Act. This act was established to deter and punish acts of terrorism. The act includes a directive for the U.S. Secret Service to develop a national network or electronic crime task force; amends the federal criminal code to allow wire, oral, and electronic communications when the case includes terrorism offenses, chemical weapons, and computer fraud and abuse; amends federal criminal code to include surveillance and interception of computer trespassing; and amends federal criminal code to include wiretaps to intercept teleconferences. In one famous case quoted to support passage of the act, a hacker stole teleconference services from a company and used them to plan and execute hacking attacks. Law enforcement agencies could not get authority to tap into the teleconferencing session. The act now gives investigators the ability to request that authority. The act also extends definitions to include cable companies, who, during the passage of earlier bills, were not providing Internet access services but who now are.

California law SB 1836. This law is an amendment to the California Information Practices Act that says if you do business with residents of California, have their unencrypted information in your databases, and are then hacked, you must notify each of those California residents that their personal information might have been compromised. This law is a California law that affects every state in the U.S. XK0-002 70-536 70-284

Guidelines for Mitigating the Cost of Security
Follow these guidelines to minimize the cost of security: 70-293 70-431 70-236 70-642

Always insist on a clear and complete statement of the cost that security adds to any project. Whether the cost is prepared by vendors, internal IT staff, management, or the security designer, it must be complete.

Look at security solutions that reduce cost. Are there security technologies suitable for this project that can reduce overall cost and thus improve profitability? An example of such technologies is the use of Secure Sockets Layer (SSL) encryption accelerator cards in e-commerce projects. People rarely doubt the need for secure servers to protect the transmission of sensitive customer or partner financial information during an e-commerce transaction. However, SSL encryption does reduce the number of transactions that can be processed per minute. Slowing the processing of monetary transactions is not a good thing, but removing SSL encryption is not an acceptable solution. SSL-encryption accelerator cards are the answer. Although these cards add cost to a security project, they pay for themselves because they allow the number of possible SSL-encrypted transactions to increase and provide the required care of customer information as it traverses the Internet.

Look for security technologies that, if not employed, absolutely will result in the failure of the project or will result in large, unnecessary expenses. No one today can imagine running an e-mail gateway without antivirus protection. However, it was not long ago that the purchase of such products was seen only as an expense that might be useful. Many organizations learned the hard way that not providing and frequently updating antivirus protection on both the gateway and the end-user machine leads to business interruptions and larger expenses than the cost of providing protection in the first place.

Look for other tangential business drivers that, if not analyzed, can lead to increased expense. For example, confidentiality and integrity—or perhaps the lack of confidentiality and integrity—are becoming increasingly larger legal issues. Ignorance of relevant laws and regulations is not an excuse not to follow them. Potentially large fines and lawsuits can be the result of failure to follow current laws. Another example is that although designing and deploying security can be expensive and require significant expertise, the lack of security can cost even more. The hard costs of the security design—such as costs for equipment, training, and so on—should always be a part of the project cost-benefit analysis. In some cases, it can be shown that adding security reduces the cost of doing business.

Guidelines for Managing Legal Requirements
Follow these guidelines to manage legal requirements: 70-271 770-445 70-237 NS0-201
Have the organization’s legal team review each security design.
Improve the security design team’s awareness of current legal requirements.
Require the security design team to prepare legal compliance as part of its design.
Have a frank discussion with IT-knowledgeable attorneys early in each product or process development cycle.

When it comes to managing the security for the systems on a network, many administrators are tempted to install service packs and hotfixes the moment that they are released. Although such a strategy can keep you on the cutting edge of security, following the strategy blindly will eventually lead to cutting yourself. 70-284 70-272 70-630 70-297
Although Microsoft has excellent processes in place for testing its service packs and hotfixes, from time to time an update is withdrawn because it has unintended consequences that severely impact upon some customer’s systems. It is also possible that you may work in an environment that has a unique mix of applications. Microsoft cannot test for all eventualities and it is possible that a released hotfix or service pack may disable an important customized business application that your organization is dependent on. An ounce of prevention is worth a pound of cure, and a strategy of thoroughly testing hotfixes and service packs before you roll them out to your organization can save you hours, perhaps days, of mopping up operations if something goes wrong. It is also worth remembering that even though a hotfix may be able to be installed on a system, this does not mean that the hotfix should be installed on a system. Careful judgments should be made as to whether or not the hotfix is applicable and relevant for the environment that it might be deployed in. Finally, it is important to know how to get back from a position once you have arrived there. Even with thorough testing something can be missed, and having an effective rollback strategy before a service pack or hotfix is rolled out is much better than attempting to develop such a strategy once a hotfix is installed on production systems and is causing unforeseen problems.
IP Security (IPSec) is a network layer technology that is used to secure communications. IPSec encrypts the information carried by Internet Protocol (IP) datagrams. This means that even if these packets are captured, the data contained within the packets exists only in an encrypted form and cannot be read by the interceptor. IPSec has been supported natively since Microsoft Windows 2000. Microsoft Windows Server 2003 ships with three default IPSec policies that can be applied by means of Group Policy objects (GPOs) or local policy. These policies are as follows:

Client (Respond Only). When this policy is configured, the computer will use IPSec only if its communication partner requests that such a connection be established. The client itself will not request that IPSec be used.

Server (Request Security). When this policy is configured, the computer will request that its communication partner use IPSec. If the communication partner is unable to service this request, communication will continue in an insecure manner.

Secure Server (Require Security). When this policy is configured, the computer will communicate only with partners that support IPSec.

On top of this set of IPSec policies, specific policies can be created that are more specific. These policies can be restricted to specific hosts, subnets, and protocols. Custom policies can also be deployed by means of GPOs or local policy. 70-640 70-647 70-270 70-291

IPSec is considered by many to be the future of communication. Without IPSec, transmissions across a network are unencrypted. Such transmissions can be intercepted by packet sniffing utilities. This could potentially lead to valuable information falling into the hands of unauthorized parties. With IPSec, even if communication is intercepted, it cannot be read because the content is encrypted

Security templates are text files that store policy settings from the Security node in an Active Directory Group Policy. These text files can be imported and applied to GPOs, altering the settings in the GPO to conform to a particular security standard. Because they are text files, security templates are often far easier to manipulate than GPOs.  MB4-641  000-M26  70-448  000-209   MB4-640   352-001  642-524  HP0-M17

Security templates can be edited in two ways. The first is by using the Security Template snap-in of the Microsoft Management Console. This method is the simplest way to edit the templates because it displays them in a form that is similar to that of the Group Policy Editor. Because security templates are stored in text file format, you can also edit security templates by using a text editor such as Notepad. This method is far more complicated and requires detailed knowledge of the security template syntax. Unless there is a compelling reason to do so, use the Security Template snap-in, because editing by using Notepad might lead to inadvertent errors in a template which, when applied, could make a system insecure.

After a security template is created, it must be deployed before it can have any influence on the security configuration of a system. Security templates are generally deployed by importing them into a Group Policy object. Once they have been imported into a Group Policy object, that Group Policy object can then be applied to sites, domains, and organizational units. Security templates can also be deployed by importing them into local Group Policy objects on standalone systems that are not a part of the domain. This can be done by editing the local Group Policy object (gpedit.msc) or by importing the template using the secedit command.

The principles involved in deploying a security template across a domain are similar to the principles involved in deploying Group Policy objects. In general, deployment should be as specific as possible. Grouping target systems into organizational units or sites is far preferable to deploying GPOs with security templates applied at the domain level. This way only the systems that are the targets of these policies will have to process them, and systems for which the policies are not relevant will not be delayed. The more Group Policy settings that are applied within a domain to all machines, the longer those machines take during startup and logon to process all of the policies to reach a final configuration.

One of the advantages to using security templates to configure the security settings in Group Policy objects is that they provide a documented point of reference for determining what went wrong when unexpected results appear. The security configuration and analysis tool can be used to look into the expected results. An administrator can also diagnose where what was planned diverged from what actually happened. One of the most common problems that occurs when security settings are applied is that the rules of Group Policy inheritance are forgotten. Policies applied at the organizational unit level override those applied at the domain level, which in turn override those applied at the site level, which finally override those that are applied locally. This gets even more complicated when policies are applied with the “no override” and “block inheritance” settings. Understanding how these options work is the key to diagnosing problems that occur in the application of security templates.  HP0-M23  000-938   000-100  000-960  000-995  190-805  HP0-S16

WEP 70-640 70-297 70-630
WEP is a wireless security protocol that helps protect your information by using a security setting, called a shared secret or a shared key, to encrypt network traffic before transmitting it over the airwaves. This helps prevent unauthorized users from accessing the data as it is being transmitted.

Unfortunately, some smart cryptographers found several theoretical ways to discover WEP’s shared secret by analyzing captured traffic. These theoretical weaknesses were quickly implemented in freely available software. The combination of free tools for cracking WEP encryption, the ease of capturing wireless traffic, and the dense proliferation of wireless networks have led WEP to become the most frequently cracked network encryption protocol today.

Security Alert You won’t need to understand the details of the WEP standard for the exam, but it is an interesting study on how not to make an encryption protocol. The most easily exploited weakness of WEP is that many of WEP’s possible initialization vectors (IVs) are cryptographically weak and can expose individual bytes of the WEP key. WEP changes these IVs over time, and an attacker who captures millions of packets will eventually gather enough packets with weak IVs to crack the entire WEP key. Some wireless network adapters intentionally avoid using weak IVs, which makes it much more time-consuming to expose the WEP key. Ask your network adapter vendor what they’ve done to make WEP communications more secure. For more detailed information on WEP’s weaknesses, search for the paper titled “Weaknesses in the Key Scheduling Algorithm of RC4” on the Internet. MB2-631 70-294 70-647

Besides weak cryptography, another factor contributing to WEP’s vulnerability is that WEP is difficult to manage because it doesn’t provide any mechanism for changing the shared secret. On wireless networks with hundreds of hosts configured to use a WAP, it is practically impossible to regularly change the shared secret on all hosts. As a result, the WEP shared secret tends to stay the same indefinitely. This gives attackers sufficient opportunity to crack the shared secret and all the time they need to abuse their ill-gotten network access.
WEP
WEP is a wireless security protocol that helps protect your information by using a security setting, called a shared secret or a shared key, to encrypt network traffic before transmitting it over the airwaves. This helps prevent unauthorized users from accessing the data as it is being transmitted.

Unfortunately, some smart cryptographers found several theoretical ways to discover WEP’s shared secret by analyzing captured traffic. These theoretical weaknesses were quickly implemented in freely available software. The combination of free tools for cracking WEP encryption, the ease of capturing wireless traffic, and the dense proliferation of wireless networks have led WEP to become the most frequently cracked network encryption protocol today.

Security Alert You won’t need to understand the details of the WEP standard for the exam, but it is an interesting study on how not to make an encryption protocol. The most easily exploited weakness of WEP is that many of WEP’s possible initialization vectors (IVs) are cryptographically weak and can expose individual bytes of the WEP key. WEP changes these IVs over time, and an attacker who captures millions of packets will eventually gather enough packets with weak IVs to crack the entire WEP key. Some wireless network adapters intentionally avoid using weak IVs, which makes it much more time-consuming to expose the WEP key. Ask your network adapter vendor what they’ve done to make WEP communications more secure. For more detailed information on WEP’s weaknesses, search for the paper titled “Weaknesses in the Key Scheduling Algorithm of RC4” on the Internet.

Besides weak cryptography, another factor contributing to WEP’s vulnerability is that WEP is difficult to manage because it doesn’t provide any mechanism for changing the shared secret. On wireless networks with hundreds of hosts configured to use a WAP, it is practically impossible to regularly change the shared secret on all hosts. As a result, the WEP shared secret tends to stay the same indefinitely. This gives attackers sufficient opportunity to crack the shared secret and all the time they need to abuse their ill-gotten network access. 70-270 SY0-101 70-291