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 choose passwords that they cannot remember, they will call again the following day or write the password down. Neither action is good for the organization. A better approach would be to conduct security-awareness training where employees are told of the coming change and taught how to pick strong passwords that are easy to remember. At the same time, the Help Desk can be informed of the change so they know what to expect. Security can work with System Administration to see if there is a way to phase in the change so not every employee needs to change passwords on the first day. This approach makes for a smoother transition. Implementation As the example in the previous section shows, radical changes to the security environ - ment can have adverse effects on the organization. Gradual, well-planned transitions are much better. Given that, Security should work with System Administration or other af - fected departments to make the change as easily as possible. Remember, security is al - ready looked at as an impediment to getting work done. There is no reason to prove this idea to the employees. USING POLICY EFFECTIVELY Policy can be used as a club but this is rarely an effective way for Security to use policy. It is much more effective when used as an education tool. Keep in mind that the vast major- ity of employees have the best interests of the organization at heart and do try to do their jobs to the best of their abilities. New Systems and Projects As new systems and projects begin, the existing security policies and design procedures should be followed. This allows Security to be a part of the design phase of the project and allows for security requirements to be identified early in the process. If a new system will not be able to meet a security requirement, this allows time for the organization to understand the added risk and to provide some other mechanism to man - age this added risk. Existing Systems and Projects As new policies are approved, each existing system should be examined to see if it is in compliance and if not, if it can be made to comply with the policy. Security should work with the system administrators and the department that uses the system to make the ap - propriate changes. This may entail some development changes that cannot be imple - mented immediately. Security must understand that some delay may occur and work with the administrators and departments to make sure the changes are done in a timely fashion within the budget and design constraints of the system. Chapter 5: Policy 77 Audits Many organizations have internal audit departments that periodically audit systems for compliance with policy. Security should approach the Audit department about new poli - cies and work with them so that the auditors understand the policy before they have to audit against it. This exchange should be a two-way exchange. Security should explain to Audit how the policy was developed and what Security expects from the policy. Audit should explain to Security how the audits will be done and what they will look for. There should also be some agreement on what types of systems will be considered adequate for various policy sections. Policy Reviews Even a good policy does not last forever. Every policy should be reviewed on a regular basis to make sure it is still relevant for the organization. Once a year is appropriate for most policies. Some procedures, such as an incident response procedure or disaster re - covery plan, may require more frequent reviews. During a review, all of the original stakeholders should be contacted along with any other departments that felt left out of the original process. Ask each for comments on the existing policy. Perhaps a single meeting should be held if there are significant comments (these include comments from Security). Make the policy adjustments, get approval, and start the education process again. 78 Network Security: A Beginner’s Guide CHAPTER 6 Managing Risk 79 Copyright 2001 The McGraw-Hill Companies, Inc. Click Here for Terms of Use. S ecurity is about managing risk. Without an understanding of the security risks to an organization’s information assets, too many or not enough resources might be used or used in the wrong way. Risk management also provides a basis for valuing of information assets. By identifying risk, you learn the value of particular types of informa - tion and the value of the systems that contain that information. WHAT IS RISK? Risk is the underlying concept that forms the basis for what we call “security.” Risk is the potential for loss that requires protection. If there is no risk, there is no need for security. And yet risk is a concept that is barely understood by many who work in the security industry. Risk is much better understood in the insurance industry. A person purchases insur - ance because a danger or peril is felt. The person may have a car accident that requires sig - nificant repair work. Insurance reduces the risk that the money for the repair may not be available. The insurance company sets the premiums for the person based on how much the car repair is likely to cost and the likelihood that the person will be in an accident. If we look closely at this example, we see the two components of risk. First is the money needed for the repair. The insurance company needs to pay this amount if an acci- dent occurs. This is the vulnerability of the insurance company. The second component is the likelihood of the person to get into an accident. This is the threat that will cause the vulnerability to be exploited (the payment of the cost of repair). When risk is examined, we therefore must understand the vulnerabilities and the threats to an organization. Together, these two components form the basis for risk. Figure 6-1 shows the relationship between vulnerability and threat. As you can see from the figure, if there is no threat, there is no risk. Likewise, if there is no vulnerabil - ity, there is no risk. Vulnerability A vulnerability is a potential avenue of attack. Vulnerabilities may exist in computer sys - tems and networks (allowing the system to be open to a technical attack) or in administra - tive procedures (allowing the environment to be open to a non-technical or social engineering attack). A vulnerability is characterized by the difficulty and the level of technical skill that is required to exploit it. The result of the exploitation should also be taken into account. For instance, a vulnerability that is easy to exploit (due to the existence of a script to perform the attack) and that allows the attacker to gain complete control over a system is a high-value vulnerability. On the other hand, a vulnerability that would require the attacker to invest significant resources for equipment and people and would only allow the attacker to gain access to information that was not considered particularly sensitive would be considered a low-value vulnerability. 80 Network Security: A Beginner’s Guide TEAMFLY Team-Fly ® Vulnerabilities are not just related to computer systems and networks. Physical site security, employee issues, and the security of information in transit must all be examined. Threat A threat is an action or event that might violate the security of an information systems environment. There are three components of threat: ▼ Targets The aspect of security that might be attacked. ■ Agents The people or organizations originating the threat. ▲ Events The type of action that poses the threat. To completely understand the threats to an organization, all three components must be examined. Targets The targets of threat or attack are generally the security services that were defined in Chapter 3: confidentiality, integrity, availability, and accountability. These targets corre - spond to the actual reason or motivation behind the threat. Confidentiality is targeted when the disclosure of information to unauthorized individuals or organizations is the motivation. In this case, the attacker wishes to know something that Chapter 6: Managing Risk 81 Figure 6-1. The relationship between vulnerability and threat would normally be kept from him, such as classified government information. However, information that is normally kept private within commercial organizations, such as salary information or medical histories, can also be a target. Integrity is the target when the threat wishes to change information. The attacker in this case is seeking to gain from modifying some information about him or another—for example, making a change to a bank account balance to increase the amount of money in the account. Others may choose to attack the transaction log and remove a transaction that would have lowered the balance. Another example might be the modification of some data in an important database to cast a doubt on the correctness of the data overall. Companies that do DNA research might be targeted in such a manner. Availability is targeted through the performance of a denial-of-service attack. Such attacks can target the availability of information, applications, systems, or infrastructure. Threats to availability can be short-term or long-term as well. Accountability is rarely targeted as an end unto itself. When accountability is targeted by a threat, the purpose of such an attack is to prevent an organization from reconstruct - ing past events. Accountability may be targeted as a prelude to an attack against another target such as to prevent the identification of a database modification or to cast doubt on the security mechanisms actually in place within an organization. A threat may have multiple targets. For example, accountability may be the initial tar- get to prevent a record of the attacker’s actions from being recorded, followed by an attack against the confidentiality of critical organizational data. Agents The agents of threat are the people who may wish to do harm to an organization. To be a credible part of a threat, an agent must have three characteristics: ▼ Access The ability an agent has to get to the target. ■ Knowledge The level and type of information an agent has about the target. ▲ Motivation The reasons an agent might have for posing a threat to the target. Access An agent must have access to the system, network, facility, or information that is desired. This access may be direct (for example, the agent has an account on the system) or indirect (for example, the agent may be able to gain access to the facility through some other means). The access that an agent has directly affects the agent’s ability to perform the action necessary to exploit a vulnerability and therefore be a threat. A component of access is opportunity. Opportunity may exist in any facility or net - work just because an employee leaves a door propped open. Knowledge An agent must have some knowledge of the target. The knowledge that is useful for an agent includes ▼ User IDs ■ Passwords 82 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. 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. departments to make sure the changes are done in a timely fashion within the budget and design constraints of the system. Chapter 5: Policy 77 Audits Many organizations have internal audit departments