Bảo mật hệ thống mạng part 12 pot

Chapter 5: Policy 71 NOTE: It is never a good idea to retaliate. This may be an illegal act and is not recommended in any situation. Authority An important part of the IRP is defining who within the organization and the incident re - sponse team has the authority to take action. This part of the procedure should define who has the authority to take a system offline and to contact customers, the press, and law enforcement. It is appropriate to identify an officer of the organization to make these decisions. This officer may be a part of the incident response team or may be available for consultation. In either case, the officer should be identified during the development of the IRP not during the incident. Documentation The IRP should define how the incident response team should document its actions. This is important for two reasons, it helps to see what happened when the incident is over, and it may help in prosecution if law enforcement is called in to assist. It is often helpful for the incident response team to have a set of bound notebooks for use during an incident. Testing of the Procedure Incident response takes practice. Do not expect that the first time the IRP is used, everything will go perfectly. Instead, once the IRP is written, hold several walk-throughs of the proce- dure with the team sitting around a conference room table (see Appendix D for sample inci- dent response scenarios). Identify a situation and have the team talk through the actions that will be taken. Have each team member follow the procedure. This will identify obvious holes in the procedure that can be corrected. The IRP should also be tested in real-world situations. Have a member of the security team simulate an attack against the organization and have the team respond. Such tests may be announced or unannounced. Configuration Management Procedure The configuration management procedure defines the steps that will be taken to modify the state of the organization’s computer systems. The purpose of this procedure is to iden - tify appropriate changes so that appropriate changes will not be misidentified as security incidents and so the new configuration can be examined from a security perspective. Initial System State When a new system goes into production, its state should be well documented. This doc - umentation should include at a minimum: ▼ Operating system and version ■ Patch level ▲ Applications running and versions In addition, it may be appropriate for cryptographic checksums to be created for all sys - tem binaries and any other files that should not change while the system is in production. Change Control Procedure When a change is to be made to a system, a configuration control procedure should be ex - ecuted. This procedure should provide for the testing of the proposed change before im - plementation. Additionally, the procedure for the change and the back-out procedure should be documented in the change request. After the change is made, the system con - figuration should be updated to reflect the new state of the system. Design Methodology Organizations that have projects to create new systems or capabilities should have a de - sign methodology. This methodology lays out the steps that the organization will follow to bring a new project into production. A design methodology includes many steps that are not security-related and thus will not be covered in this discussion. However, the ear - lier Security becomes involved in a new project, the more likely it is that proper security will be incorporated into the final system. For each of the design phases listed in the fol- lowing sections, we will discuss the security issues that should be examined. Requirements Definition The methodology should specify that security requirements be included during the require- ments definition phase of any project. The methodology should point to the organization’s security and information policies for some requirements. In addition, the requirements docu- ment should identify sensitive information and any key security requirements for the project. Design During the design phase of the project, the methodology should specify that Security be represented to make sure that the project is properly secured. Security staff may partici - pate as members of the design team or as reviewers. Any security requirements that can - not be met by the design should be identified and, if necessary, the waiver process should be started. When the system is being coded, software developers should be taught about poten - tial coding problems like buffer overflows. In this case, security awareness training may be appropriate as the coding of the project is started. Test When the project goes to test, the security requirements should be tested as well. It may be appropriate for the Security staff to assist in the writing of the test plan. Keep in mind that security requirements may be hard to test (it is hard to prove a negative—for exam - ple, that an intruder should not be able to see sensitive information). 72 Network Security: A Beginner’s Guide Implementation The implementation phase of the project also has security requirements. During this pro - cess, the implementation team should be using proper configuration management proce - dures. In addition, before a new system goes into production, the Security staff should examine the system for vulnerabilities and proper security policy compliance. Disaster Recovery Plans Every organization should have a disaster recovery plan (DRP). However, many organi - zations do not have one because they see them as very expensive and they do not feel that they can afford a hot site. DRPs do not necessarily require a hot site (an alternate location for operations that has all the necessary equipment configured and ready to go). Rather, a DRP is the plan that an organization will follow if the worst happens. It may be a very simple document that tells key staff to meet at a local restaurant if the building burns. Other documents may be much more complex and define how the organization will con - tinue to operate if some or all of the computer systems are unavailable. A proper DRP should take into account various levels of failures: single systems, data centers, and entire sites. The following sections give more detail as to what type of infor- mation should be included in each section. Single System or Device Failures Single system or device failures are the most likely. This type of failure may include a disk, motherboard, network interface card, or component failure. As part of the develop- ment of this part of the DRP, the organization’s environment should be examined to iden- tify the impact of any single system or device failure. For each failure, a plan should be developed to allow operations to continue within a reasonable amount of time. What “reasonable” means depends on the criticality of the system in question. For example, a manufacturing site that relies upon one system to produce production schedules and to order supplies may require this system to be up within four hours or production will be impacted. This type of failure could be solved by having a spare system that could be brought online or by a clustered system solution. The choice will depend upon the cost of the solution. Regardless of what solution is chosen, the DRP specifies what must be done to con - tinue operations without the failed system. The DRP should be written in conjunction with operational departments of the organization so they understand what steps they must take in order to continue operations. Data Center Events The DRP should also provide procedures for a major event within a data center. If a fire should occur, for example, and the data center is not usable, what steps must be taken to reconstitute the capabilities. One issue that must be addressed is the potential loss of equipment. The plan should include some way to acquire additional equipment. Chapter 5: Policy 73 74 Network Security: A Beginner’s Guide If the data center is not usable but the rest of the facility is, the DRP should define where the new equipment will go as well as how communication lines will be reconsti - tuted. A hot site is an option for this type of event but hot sites are costly. If a hot site is not part of the plan, the organization should examine other potential locations within the fa - cility or at other facilities to rebuild the computer systems. As with single system events, the DRP should identify how the organization will con - tinue operations while the systems are rebuilt. Site Events Site-destroying events are the types of events most often thought of when we speak of a DRP. These types of events are the least likely to occur but also the most damaging to an or - ganization. For a DRP to plan for such events, every department of the organization must participate in its creation. The first step is for the organization to identify the critical capa - bilities that must be re-established in order for the organization to survive. If the organiza - tion is an e-commerce site, the most critical systems may be the computer systems and the network. On the other hand, if the organization manufactures some type of product, the manufacturing operations may be much higher priority than the computer systems. Testing the DRP A DRP is a very complex document and it is unlikely that the first attempt at writing one will result in immediate success. Therefore, the DRP should be tested. Testing is not only necessary to make sure the DRP is currently correct but to make sure that it stays that way. DRP tests can be very expensive and disruptive to an organization. With this in mind, it may be appropriate for the organization to identify key employees and perform walk-throughs of the plan periodically and full-scale tests on a yearly basis. CREATING APPROPRIATE POLICY Now that we have identified and discussed all of the policies that an organization might have, let’s talk about creating a policy that is appropriate for your organization. Each or - ganization is different. Therefore, each organization will have different policies. This does not mean to say that policy templates are useless. On the contrary, policy templates are very useful for an organization to examine and to learn from. However, copying some other organization’s policy word for word is not the best way to create your policies. Defining What Is Important The first step in creating organizational policy is to define which policies are important for you. Not every policy will be needed by every organization. Also, depending on the situation that your organization is in, there may be some policies that are needed more than others. For example, an organization that delivers information over the Internet may require a disaster recovery plan more than a computer use policy. The organization’s security staff should be able to identify which policies are most important. If not, a risk as - sessment should provide guidance in this area. Security staff should also look for assistance from system administrators, Human Re - sources, and the general counsel’s office to determine which policies are most important. Defining Acceptable Behavior Some employee behavior will be acceptable and some will not. What is acceptable will dif - fer based on the culture of the organization. For example, some organizations may allow all employees to surf the Internet without restriction. The culture of the organization is thus relying on the employees and their managers to make sure work is being completed. Other organizations may place restrictions on which employees are allowed access to the Internet and even then load software that restricts access to certain “unacceptable” Web sites. The policies for these two organizations may differ significantly. In fact, the first orga - nization may decide not to implement an Internet use policy at all. It is important for se - curity professionals to remember that not all policies fit all organizations. Before a security professional begins drafting policy at a new organization, the security profes- sional should take some time to learn the culture of the organization and the expectations of the organization with regard to its employees. Identifying Stakeholders Policy that is created in a vacuum rarely succeeds. With this in mind, it is up to the secu- rity professional to drive the development of policy with the help of other members of the organization. Security should seek the advice of the organization’s general counsel and Human Resources Department when developing any policies. Other groups that should be included in the process may include system administrators, users of computer sys- tems, and physical security. Generally speaking, those who will be affected by the policy should be included in the process of developing the policy so that they will gain an understanding of what is expected. Defining Appropriate Outlines The development of a policy starts with a good outline. One set of possible outlines has been provided earlier in this chapter. There are many sources of good policy outlines available. Some of these sources are in books but some are available on the Internet as well. For example, RFC 2196, The Site Security Handbook, provides a number of outlines for various policies. Policy Development Security should drive the development of security policies. This does not mean that secu - rity should write the policies without input from other departments but it does mean that security should take ownership of the project and see that it gets done. Chapter 5: Policy 75 Begin the process with your outline and a draft of each section of the policy. At the same time contact your stakeholders and tell them of the project. Invite the stakeholders to be part of the project. Those who agree should be sent a draft of the policy and invited to a meeting where the draft will be discussed and comments made. Depending on the size of the organization and which policy is being developed, there may be a single meet - ing or several. At the meeting, Security should act as the chair. Work through the policy section by section. Listen to all comments and allow discussion. Keep in mind, however, that some comments may not be appropriate. In these cases, Security should provide the reasons why a risk would be increased or not managed properly. Make sure that the rest of the at - tendees understand the reasoning behind the choices of the policy. It may be appropriate to repeat this process for the final draft. When complete, take it to management for approval and implement. DEPLOYING POLICY Policy creation is the easy part. In order to create it, you only had to get a small number of people involved. To effectively deploy the policy, you need to work with the whole organization. Gaining Buy-In Every department of the organization that is affected by the policy must buy into the concept behind it. Getting this done is made somewhat easier because you involved all the stake holders in the creation of the policy. You can show the department man- agers that someone from their part of the organization was involved and voiced that department’s concerns. It also helps if management has agreed that policy is important and needs to be implemented. A message from upper management saying that this policy is impor - tant and that it will be implemented will go a long way to helping gain department management buy-in. Education Employees who will be affected by a new policy must be educated as to their responsibili - ties. This is Security’s responsibility. Human Resources or Training can help but it is up to the Security department to educate employees. This is especially important when it comes to changes that directly affect all users. Take, for example, a change to the pass - word policy. On Monday morning, all user passwords must be eight characters in length and some mixture of letters and numbers and they will expire in 30 days. When you make this type of change on a Windows domain, all passwords are expired immediately. This will force every user to change passwords on Monday morning. Without education, they will not choose good passwords and will probably call the Help Desk. Likewise, if they 76 Network Security: A Beginner’s Guide . the creation of the policy. You can show the department man- agers that someone from their part of the organization was involved and voiced that department’s concerns. It also helps if management. include a disk, motherboard, network interface card, or component failure. As part of the develop- ment of this part of the DRP, the organization’s environment should be examined to iden- tify. for this type of event but hot sites are costly. If a hot site is not part of the plan, the organization should examine other potential locations within the fa - cility or at other facilities to