Network Risk Assessment
settings TOC close
CHAPTER
4 Developing a Risk Management Plan
A RISK MANAGEMENT PLAN is a specialized type of project management. You apply many of the same techniques to risk management that you would when managing any project. At the core is the need to plan. As the old saying goes, if you fail to plan, you plan to fail. Without a risk management plan, failure is much more likely than success.
A well-documented risk management plan helps ensure you are able to reach your desired goal. Primarily, you create a risk management plan to mitigate risks. This plan helps you identify the risks and choose the best solutions. It also helps you track the solutions to ensure they are implemented on budget and on schedule. A fully implemented plan will include a plan of action and milestones (POAM). You can then use the POAM to track the project.
Chapter 4 Topics
This chapter covers the following topics and concepts:
• What the objectives of a risk management plan are
• What the scope of a risk management plan is
• How to assign responsibilities in a risk management plan
• How procedures and schedules are described in the risk management plan
• What the reporting requirements are
• What a plan of action and milestones is
• How to chart the progress of a risk management plan
Chapter 4 Goals
When you complete this chapter, you will be able to:
• Describe the objectives of a risk management plan
• Describe the purpose of a plan’s scope
• Identify the importance of assigning responsibilities
• Describe the purpose of the procedures list in a risk management plan
• List reporting requirements of a risk management plan
• Document findings of a risk management plan
• Create a plan of action and milestones
• Identify a milestone plan chart
• Identify a Gantt chart and define a critical path chart
Objectives of a Risk Management Plan
One of the important first steps for a risk management plan is to establish the objectives. The objectives become the road map for your plan. They help you identify where you’re going and, just as important, they help you know when you’ve arrived. You should establish objectives for the plan as early as possible.
The objectives identify the goals of the project. These objectives outline what you should include in the plan. Some common objectives for a risk management plan are:
• A list of threats
• A list of vulnerabilities
• Costs associated with risks
• A list of recommendations to reduce the risks
• Costs associated with recommendations
• A cost-benefit analysis
• One or more reports
While the reports document the above items, the risk management plan doesn’t end there. Once top managers receive a report, they will be able to make decisions based on the data. They will accept some recommendations. They may modify some. And they may defer some.
The next phase of the risk management plan covers implementation of the plan. Implementation involves the following tasks:
• Document management decisions.
• Document and track implementation of accepted recommendations.
• Include a POAM.
Throughout this chapter, two examples are used. These examples show how you can create a risk management plan for actual projects. The two examples are:
• Web site—Your company, Acme Widgets, hosts a Web site used to sell widgets on the Internet. The Web site is hosted on a Web server owned and controlled by your company. The Web site was recently attacked and went down for two days. The company lost a large amount of money. Additionally, the company lost the goodwill of many customers. This was the second major outage for this Web site in the past two months. There have been many outages in the past three years.
• Health Insurance Portability and Accountability Act (HIPAA) compliance—Your company recently purchased Mini Acme. Mini Acme has not complied with HIPAA. Management wants to identify the risks associated with this noncompliance. Managers also want to ensure that issues are corrected as soon as possible.
NOTE
The Health Insurance Portability and Accountability Act (HIPAA) was passed in 1996 to ensure protection of health information data. Title II of HIPAA covers the protection of health data.
After the chapter covers a topic, these examples are sometimes used to show how you could create a portion of the plan. The examples aren’t intended to show the only possible way to create a plan. An actual plan could vary based on the needs of your company.
Objectives Example: Web Site
The Acme Widgets Web site has suffered outages. These outages resulted in unacceptable losses. The losses could have been prevented by managing Web site risks. You can use the risk management plan to identify these risks.
The objectives of the plan are to:
• Identify threats—This means any threats that directly affect the Web site. These may include:
• Attacks from the Internet
• Hardware or software failures
• Loss of Internet connectivity
• Identify vulnerabilities—These are weaknesses and may include:
• Lack of protection from a firewall
• Lack of protection from an intrusion detection system
• Lack of antivirus software
• Lack of updates for the server
• Lack of updates for the antivirus software
NOTE
A firewall filters traffic. Firewall rules are configured to specifically allow certain traffic. Most firewalls block all traffic that is not specifically allowed. You can use both network and host- based firewalls. A network firewall usually consists of both hardware and software and filters traffic for the network. Individual systems can have a software firewall that filters traffic for a single system.
• Assign responsibilities—Assign responsibility to specific departments for collecting data. This data will be used to create recommendations. Later in the plan, you will assign responsibilities to departments to implement and track the plan.
• Identify the costs of an outage—Include both direct and indirect costs. The direct costs are the lost sales during the outage. The amount of revenue lost if the server is down for 15 minutes or longer will come from sales data. Indirect costs include the loss of customer goodwill and the cost to recover the goodwill.
• Provide recommendations—Include a list of recommendations to mitigate the risks. The recommendations may reduce the weaknesses. They may also reduce the impact of the threats. For example, you could address a hardware failure threat by recommending hardware redundancy. You could address a lack of updates by implementing an update plan.
• Identify the costs of recommendations—Identify and list the cost of each recommendation.
• Provide a cost-benefit analysis (CBA)—Include a CBA for each recommendation. The CBA will compare the cost of the recommendation against the benefit to the company of implementing the recommendation. You can express the benefit in terms of income gained or the cost of the outage reduced.
• Document accepted recommendations—Management will choose which recommendations to implement. They can accept, defer, or modify recommendations. You will then document these choices in the plan.
• Track implementation—The plan will track the choices and their implementation.
• Create a POAM—Include a POAM that assigns responsibilities. Management will use it to track and follow up on the project.
Objectives Example: HIPAA Compliance
Your company recently acquired Mini Acme. An inspection of some records indicates that health information isn’t protected. Your company is therefore not in compliance with HIPAA. Noncompliance can result in fines and jail time.
The purpose of this plan is to ensure compliance with HIPAA. The objectives of the plan are to:
• Identify threats—These could be both internal and external threats.
• Identify vulnerabilities—These are the weaknesses. They may include:
• Lack of policies preventing information sharing
• Lack of protection when the data is stored
• Lack of protection when the data is transmitted
• Assign responsibilities—Assign responsibility to specific departments to identify threats and vulnerabilities. You will use this data to identify corrective actions. Later, you can assign responsibilities to departments to implement and track the plan.
• Identify the costs of noncompliance—Costs include the legal fines associated with noncompliance. Additional costs may result from lawsuits or the loss of customer confidence.
• Provide recommendations—Create a list of recommendations. This list may include procedural changes. It could include protecting the data with access controls. It could also include encrypting the data during transmissions.
• Identify the costs of recommendations—Identify and list the cost of each recommendation.
• Provide a CBA—Complete a CBA for each recommendation. It will compare the cost of the recommendation against the cost of the compromise of data.
• Document accepted recommendations—Management will choose which recommendations to implement. Managers can accept, defer, or modify recommendations. These choices will be documented in the plan.
• Track implementation—The plan will track the choices and their implementation.
• Create a POAM—Include a POAM that assigns responsibilities. Management will use it to track and follow up on the project.
Scope of a Risk Management Plan
In addition to the objectives, it’s also important to identify the scope of a risk management plan. The scope identifies the boundaries of the plan. The boundaries could include the entire organization or a single system. Without defined boundaries, the plan can get out of control.
A common problem with many projects is scope creep. Scope creep comes from uncontrolled changes. As the changes creep in, the scope of the project grows. Changes bring in additional requirements. Uncontrolled changes result in cost overruns and missed deadlines.
For example, consider the HIPAA compliance example mentioned earlier. The objective of this project is to bring Mini Acme into compliance with HIPAA. Suppose you find other unprotected data that is not health data. It could be financial data, research data, or user data.
If you roll this data into the project, it would expand the project. You would have to identify threats and vulnerabilities. You would have to calculate the costs of the data loss. You would need to identify additional recommendations and their costs. All of this will take more time and more money.
This is not to say that the scope of a project should never change. The key is to control the changes. A risk management project manager should work with stake-holders to identify what changes are acceptable.
Scope Creep in Application Development
Scope creep is a common problem in application development. Programmers often see how a program can be improved by tweaking it a little here or there. Although the programmers are well intentioned, these changes can sometimes have far-reaching effects.
In one project, a programmer added an additional capability to a program. This change allowed the user to search through data. This was clearly outside the scope of the project. However, it didn’t take much time to program it and the change was added without much notice to anyone. The application was then shipped to the customer with the new capability.
The customer used the program successfully for a few months. Later, the format of the data was changed. The change of the format didn’t affect the primary purpose of the program. It still worked as required. However, the additional search feature no longer worked.
Who’s responsible for fixing the problem? The application developer was responsible.
A change that originally looked like added value actually became added liability. Even though the search capability was outside the scope of the project, it became part of the application. This added capability would have to be maintained just as any other part of the application needs to be maintained. The developer didn’t have much choice. If he refused to fix the problem, it would affect the perceived usability of the program.
At this point, it wasn’t easy to remove the added capability. It looked and behaved like a feature. While it would not have been missed if it was never added, it would now be missed if it was removed.
A stakeholder is an individual or group that has a stake, or interest, in the success of a project. A key stakeholder is a stakeholder who has authority to make decisions about the project, including the ability to grant additional resources. Examples of a key stakeholder could be a company executive such as a CIO or CFO. It could be a vice president who will “own” the project upon completion.
It’s good to involve stakeholders in drafting a scope statement. This involvement can be anything from drafting the statement to approving it. This involvement helps the stakeholder have ownership of the project. Ownership is also referred to as buy-in for the project.
NOTE
Companies typically have “C”-level executives identified as CEO, CIO, CFO, and so on. CCO is short for chief compliance officer. CEO is short for chief executive officer. CFO is short for chief financial officer. CIO is short for chief information officer. CSO is short for chief security officer. CTO is short for chief technology officer.
A true stakeholder has a vested interest in the project and wants to see it succeed. On the other hand, a stakeholder named as a figurehead without a stake in the project sees it as a nuisance. A project without a true stakeholder will often die due to lack of support. Resources aren’t allocated. Decisions aren’t made. Team members realize it’s not supported and stop contributing.
Consider the unprotected data from the HIPAA example. If a risk management team discovered unprotected financial data, the team could present its concerns to the project manager (PM). The PM can evaluate the data and determine that none of it is HIPAA related but realize it is important. The PM can pass the information on to a stakeholder as an issue of concern. A stakeholder may direct the PM to include the data in the plan. At that point, it is a controlled change.
Sample scope statements for the Web site and HIPAA compliance projects are provided in the following sections.
Scope Example: Web Site
The purpose of the risk management plan is to secure the Acme Widgets Web site. The scope of the plan includes:
• Security of the server hosting the Web site
• Security of the Web site itself
• Availability of the Web site
• Integrity of the Web site’s data
Stakeholders for this project include:
• Vice president of sales
• Information technology (IT) support department head
Written approval is required for any activities outside the scope of this plan.
Scope Example: HIPAA Compliance
The purpose of the risk management plan is to ensure compliance with HIPAA for Mini Acme’s data. The scope of the plan includes:
• Identification of all health data
• Storage of health data
• Usage of health data
• Transmission of health data
Stakeholders for this project include:
• CIO
• Human resources department head
Written approval is required for any activities outside the scope of this plan.
Assigning Responsibilities
The risk management plan specifies responsibilities. This provides accountability. If you don’t assign responsibilities, tasks can easily be missed. You can assign responsibilities to:
• The risk management PM
• Stakeholders
• Departments or department heads
• Executive officers such as CIO or CFO
NOTE
A risk management PM is sometimes called a risk management coordinator. The skills required of a successful risk management PM are the same skills required of a successful project manager for almost any project.
It’s important to ensure that any entity that is assigned a responsibility has the authority to complete the task. This is especially important for the PM.
For example, team members may not work directly for the PM. Technicians, say, might work in the IT department. They can be assigned as team members for a project. However, they may still report directly to supervisors in the IT department. So their taskings from the IT department and from the PM may compete with each other. If the PM doesn’t have the authority to resolve these problems, it can affect the success of the project. At the very least, the PM should have access to stakeholders to resolve problems.
The PM is responsible for the overall success of the plan. Some of the common tasks of a PM are:
• Ensuring costs are controlled
• Ensuring quality is maintained
• Ensuring the project stays on schedule
• Ensuring the project stays within scope
• Tracking and managing all project issues
• Ensuring information is available to all stakeholders
• Raising issues and problems as they become known
• Ensuring others are aware of their responsibilities and deadlines
Individual responsibilities could be assigned for the following activities:
• Risk identification—This includes identifying threats and vulnerabilities. The resulting lists of potential risks can be extensive.
• Risk assessment—This means identifying the likelihood and impact of each risk. A threat matrix is a common method used to assess risks.
technical TIP
Consider creating a threat-likelihood-impact matrix. A percentage from 10 percent to 100 percent is assigned for each likelihood. The impact severity is assigned a value between 10 and 100. The value is then calculated by multiplying the two values. Higher values indicate risks that should be addressed first. Lower values indicate risks that may be accepted.
• Risk mitigation steps—This means identifying steps that can reduce weaknesses. This can also include steps to reduce the impact of the risk.
• Reporting—This means reporting the documentation created by the plan to management. The PM is often responsible for compiling reports.
Examples of responsibility statements for the Web site and HIPAA compliance scenarios are presented in the following two sections.
Responsibilities Example: Web Site
The CFO will provide funding to the IT department to hire a security consultant. This security consultant will assist the IT department.
The IT department is responsible for providing:
• A list of threats
• A list of vulnerabilities
• A list of recommended solutions
• Costs for each of the recommended solutions
The sales department is responsible for providing:
• Direct costs of any outage for 15 minutes or longer
• Indirect costs of any outage for 15 minutes or longer
The CFO will validate the data provided by the IT and sales departments. The CFO will then complete a cost-benefit analysis.
Responsibilities Example: HIPAA Compliance
The human resources (HR) department is responsible for identifying all health information held by Mini Acme. The HR department is responsible for providing:
• A list of all health information sources
• Inspection results for all data sources regarding their compliance with HIPAA:
• How the data is stored
• How the data is protected
• How the data is transmitted
• A list of existing HIPAA policies used by Mini Acme
• A list of needed HIPAA policies
• A list of recommended solutions to ensure compliance with HIPAA
• Costs for each of the recommended solutions
• Costs associated with noncompliance
The IT department is responsible for providing:
• Identification of access controls used for data
• A list of recommended solutions to ensure compliance with HIPAA
• Costs for each of the recommended solutions
Using Affinity Diagrams
While it’s easy to assign responsibility, it may not be so easy to identify the tasks. One of the challenges is to generate lists of realistic threats, vulnerabilities, and recommendations. An affinity diagram can help with these tasks.
An affinity diagram is created in four basic steps. These are:
• Identify the problem—Create a basic problem statement. For example, consider the Web site problem. It could be stated as: “Web site outages result in lost sales.”
• Generate ideas—The more the better. The ideas can be about any elements of the problem. They can include threats and vulnerabilities. They can also include recommended solutions. Brainstorming is one method that can be used. In a brainstorming session, participants are encouraged to mention anything that comes to mind. All ideas are written down without any judgment. The creative process can often bring out a wealth of ideas.
• Gather ideas into related groups—After the ideas are generated, group them together. For a risk management plan, the groups will usually fit into categories of threats, vulnerabilities, and recommendations. Some of these categories may include subcategories. For example, you could divide vulnerabilities into network and server weaknesses.
• Create an affinity diagram—Figure 4-1 shows an example of an affinity diagram. It groups all of the ideas together.
In an actual scenario, the affinity diagram is likely to be much larger. You could divide threats into external and internal threats. There can be an almost endless list of vulnerabilities.
The CFO will validate the data provided by the IT and sales departments. The CFO will then complete a cost-benefit analysis.
Describing Procedures and Schedules for Accomplishment
You create this part of the risk management plan after the project has started. You include a recommended solution for any threat or vulnerability, with a goal of mitigating the associated risk. While you can summarize a solution in a short phrase, the solution itself will often include multiple steps.
For example, an existing firewall may expose a server to multiple vulnerabilities. The solution could be to upgrade the firewall. This upgrade can be broken down into several steps, such as:
• Determine what traffic should be allowed.
• Create a firewall policy.
• Purchase a firewall.
• Install the firewall.
NOTE
MITRE includes a risk management toolkit area on its Web site at http://www.mitre.org/work/sepo/toolkits/risk/index.html. This site includes information on creating affinity diagrams.
FIGURE 4-1 Affinity diagram.
• Configure the firewall.
• Test the firewall.
• Implement the firewall.
You can describe each of these steps in further detail. In addition, you can include a timeline for completion of each of the steps.
There are a couple of things to remember at this point:
• Management is responsible for choosing the controls to implement.
• Management is responsible for residual risk.
Because management has not reviewed the recommendations yet, this schedule will usually not include dates. Instead, the schedule will list how long it may take to complete any of the recommendations.
For example, a single recommendation may include five tasks. You can list the time required for each of these tasks. You can add start and end dates later.
Partial listings of procedures for the Web site and HIPAA examples are given in the following sections.
NOTE
A DoS attack is any attack designed to prevent a system from providing a service. A distributed DoS (DDoS) attack is a DoS attack launched from multiple systems at the same time. DDoS attacks often include zombie computers controlled in a botnet.
Procedures Example: Web Site
The Web site is vulnerable to denial of service (DoS) attacks from the Internet. This risk cannot be eliminated. However, several tasks can be completed to mitigate the risk:
• Recommendation—Upgrade the firewall.
• Justification—The current firewall is a basic router. It filters packets but does not provide any advanced firewall capabilities.
• Procedures—The following steps can be used to upgrade the new firewall:
1. Start firewall logging. This log can be used to determine what ports are currently being used. Logs should be collected for at least one week.
2. Create a firewall policy. A firewall policy identifies what traffic to allow past the firewall. This is a written document. It is created based on the content of the firewall logs.
3. Purchase a firewall appliance. A firewall appliance provides a self-contained firewall solution. It includes both hardware and software that provides protection for a network. Firewall appliances range from $200 to more than $10,000. The SS75 model is recommended at a cost of $4,000. It will arrive within 30 days after ordering.
4. Install the firewall. The firewall could be installed in the server room. Existing space and power are available there.
5. Configure the firewall. Technicians will use the firewall policy to configure the firewall.
6. Test the firewall before going live. Testing will ensure normal operations are not impacted. Technicians can complete testing in one week.
7. Bring the firewall online. Technicians can complete this step within a week after completing tests.
FYI
Firewalls labeled as appliances are intended to be easy to use. The implication is that you can plug them in and they work. You don’t have to be an expert in how they work. It’s like a toaster. You put bread in and toast comes out. You don’t have to know how the toaster works to make toast. Similarly, you don’t have to be an expert on firewalls to use a firewall appliance.
Procedures Example: HIPAA Compliance
Employees of Mini Acme are not aware of HIPAA. They don’t understand the requirements of the law. They don’t understand the consequences of noncompliance. You can complete the following tasks to mitigate the risk of noncompliance:
• Recommendation—Increase awareness of HIPAA.
• Justification—Make clear that noncompliance can result in fines totaling $25,000 a year for mistakes.
• Procedures—Use the following steps to increase awareness:
1. Require all employees to read and comply with HIPAA policies. Don’t create new policies. Require Mini Acme employees to read and acknowledge HIPAA policies currently in place. This can be accomplished in 30 days.
2. Provide training to all employees on HIPAA compliance. Training will include what data is covered by HIPAA. It will also include consequences of noncompliance. If approved, it will take approximately 60 days to create training materials. Training can be completed in 30 days.
Reporting Requirements
After you collect data on the risks and recommendations, you need to include it in a report. You will then present this report to management. The primary purpose of the report is to allow management to decide on what recommendations to use.
There are four major categories of reporting requirements. They are:
• Present recommendations—These are the risk response recommendations.
• Document management response to recommendations—Management can accept, modify, or defer any of the recommendations.
• Document and track implementation of accepted recommendations—This becomes the actual risk response plan.
• Create a plan of action and milestones (POAM)—The POAM tracks the risk response actions.
Presenting Recommendations
You compile the collected data into a report. It will include the lists of threats, vulnerabilities, and recommendations. You then present this report to management. Management will use this data to decide what steps to take.
It’s important to remember the overall goal of the risk management plan at this stage. The goal is to identify the risks and recommend strategies to reduce them. Most of the risks won’t be eliminated, but instead they will be reduced to an acceptable level. For every risk identified, there will be an accompanying recommendation to reduce the risk.
This report should include the following information:
• Findings
• Recommendation cost and time frame
• Cost-benefit analysis
Findings
The findings list the facts. Remember, losses from risks occur when a threat exploits a vulnerability. Risk management findings need to include threats, vulnerabilities, and potential losses. These are described as cause, criteria, and effect:
• Cause—The cause is the threat. For example, an attacker may try to launch a DoS attack. In this case, the threat is the attacker. When you list the cause, it’s important to identify the root cause. A successful attack is dependent on an attacker having access and the system being vulnerable. Risk management attempts to reduce the impact of the cause, or reduce the vulnerabilities.
• Criteria—This identifies the criteria that will allow the threat to succeed. These are the vulnerabilities. For example, a server will be susceptible to a DoS attack if the following criteria are met:
• Inadequate manpower—If manpower isn’t adequate to perform security steps, the site is vulnerable.
• Unmanaged firewall—Each open port represents a vulnerability. If ports are not managed on a firewall, unwanted traffic can be allowed in.
• No intrusion detection system (IDS)—Depending on the type of IDS, it can not only detect intrusions but also respond to intrusions and change the environment.
• Operating system not updated—Apply patches to the system as they are released and tested. If you don’t apply updates, the system is vulnerable to new exploits.
• Antivirus software not installed and updated—Antivirus software can detect malware. You should update it with definitions to ensure it will detect new malware.
• Effect—The effect is often an outage of some type. For example, the effect on a Web site could be that the Web site is not reachable any more.
An important consideration as you document findings is resource availability. It could be that all the discovered issues were previously known. However, money may not have been allocated to purchase the solutions in the past. It’s also possible that manpower wasn’t adequate to implement the solutions.
When adequate manpower isn’t available, security is often sacrificed for ease of use. Consider the Web site example. The first goal may be to ensure the Web site is operational. Once it’s up, resources may be used for other jobs. The Web site may still not be secure, backups may not be made, or other security issues may still exist.
A cause and effect diagram can be used to discover and document the findings. Figure 4- 2 shows a sample cause and effect diagram for the Web site scenario. In this diagram, the primary cause is an attack. The remaining items are contributing factors that allow the attack to succeed. The effect is an outage.
FIGURE 4-2 Web site cause and effect diagram.
There are several advantages to using a cause and effect diagram. It can help guide discussions during the discovery process. It can also help visualize the relationships between causes and effects in documentation. Cause and effect diagrams can be used for any problem.
NOTE
The cause and effect diagram is also called an Ishikawa diagram, or a fishbone diagram. It is used to link problems with causes.
A cause and effect diagram starts by creating the line and the ultimate effect. In Figure 4-2, the effect is the outage. Then you add additional items (the causes), making the diagram look similar to a fishbone. You can expand the diagram for any of the elements. For example, you could expand “attack” to include specific types of attacks. Attacks may include malware, DoS, buffer overflow, or other types of attacks.
When creating a cause and effect diagram, you can run out of ideas or focus on a single topic. To balance the diagram, consider the following five elements. You’re not required to include all the elements. However, you can use any of them to help identify causes:
• Methods—What methods could contribute to an outage?
• Machinery—What machinery issues could contribute to an outage?
• Manpower—What manpower issues could contribute to an outage?
• Materials—What material issues could contribute to an outage?
• Environment—What environmental issues could contribute to an outage?
Figure 4-3 shows another example of a cause and effect diagram. In this example, the cause is loss of confidentiality. The remaining items show the criteria that can allow the loss of data. For HIPAA, the effect can be substantial fines.
Recommendation Cost and Time Frame
In addition to the findings, the report will include a list of recommendations. These recommendations will address the potential causes and criteria that can result in the negative effect.
FIGURE 4-3 HIPAA compliance cause and effect diagram.
Each item should include the cost required to implement it. Also include the timeline to implement the solution. Management will use this data to decide if the solution should be applied.
For example, the following partial list of recommendations could be included in the Web site risk management plan:
• Upgrade firewall—Initial cost: $4,000. Ongoing costs: $1,000 annually. The initial cost will cover the purchase of the firewall. The ongoing costs are related to training and maintenance.
Purchase and install the firewall within 30 days of approval.
• Purchase and install IDS—Initial cost: $1,500. Ongoing costs: negligible. Purchase and install the IDS within 30 days of approval.
• Create plan to keep system updated—Initial cost: manpower. Ongoing costs: manpower.
Purchase and install the system within 30 days of approval.
• Install antivirus software on server—Initial cost: $75. Ongoing costs: negligible. Purchase and install the software within 30 days of approval.
Cost Estimate Accuracy
Because a CBA is only as valuable as its cost estimates, it’s important to get accurate data. However, this can be difficult. It helps to understand how data can be skewed.
Costs for solutions are often underestimated. For example, ongoing costs may not be included in the initial cost estimates. A product that looks easy to manage may require expensive training.
The success of a solution can be overestimated. A solution may be expected to reduce incidents by 90 percent. In practice, the reduction may be closer to 50 percent.
There are times when personnel don’t have a vested interest in providing accurate information. For example, sales personnel interested in an initial sale may sometimes gloss over ongoing costs. You can also expect them to stress the most positive aspects of their products.
• Update antivirus software—Initial cost: negligible. Ongoing costs: negligible.
Configure antivirus software for automatic updates after installation.
• Add one IT administrator—Cost: negotiated salary. Due to the ongoing maintenance requirements of these recommendations, an additional administrator is required.
NOTE
The individual ongoing costs may be small, but the cumulative requirements may be more. In this example, the time required to maintain these solutions may justify an additional administrator.
Cost-Benefit Analysis
The CBA is a process used to determine how to manage a risk. If the benefits of a control outweigh the costs, the control can be implemented to reduce the risk. If the costs are greater than the benefits, the risk can be accepted.
In this context, the CBA should include two items:
• Cost of the recommendation—The recommendation is the control intended to manage the risk. If you anticipate that there will be ongoing costs, you should include them in the calculation.
• Projected benefits—Calculate benefits in terms of dollars. Benefits can be expressed as money earned or losses reduced.
Management is responsible for making the decisions on how to manage the risks. An accurate CBA allows management to make intelligent decisions.
Here is a sample CBA for a Web site recommendation:
• Recommendation—Install antivirus (AV) software on the Web server.
• Cost of the recommendation—$75.
• Background—AV software was not installed on the Web server in the past because of performance concerns. Malware infected the Web server several times in the past year. These infections caused multiple outages on the Web server. The total downtime was five hours. The Web server generates approximately $500 per 15 minutes of uptime, or $2,000 per hour. AV software is expected to prevent 90 percent of infections.
• Loss before AV software—$30,000. Outages resulted in $10,000 of direct loss of revenue ($2,000 × 5 hours). Indirect losses are estimated to be $20,000. This includes the advertising costs to bring back lost customers.
• Expected loss with AV software—$3,000. The AV software is expected to reduce the losses by 90 percent ($30,000 – ($30,000 × .9) = $3,000).
• Benefit of AV software—$27,000 ($30,000 × .9 = $27,000).
• CBA—$26,925. The CBA is calculated as:
• Loss Before AV Software – Loss After AV Software – Cost of AV Software
• $30,000 – $3,000 – $75 = $26,925
You can’t overestimate the importance of accurate data. The key to completing an accurate CBA is starting with accurate data. Again, this is sometimes difficult to get. It often requires digging below the surface to determine costs.
Probing questions can often uncover flaws in the data. Consider the following scenarios and questions:
• If a control is said to reduce losses by 90 percent, you can ask, “How did you arrive at 90 percent?”
• If the cost of a control is given, you can ask, “Does this include any ongoing costs?”
Probing questions don’t need to be accusatory. The goal isn’t to create a conflict. Instead, the goal is to validate the data. Questions should be asked with a tone of “help me understand.” If the data is flawed, the presenter can easily get defensive. On the other hand, if the data is valid, the presenter can answer questions with facts to support the claims.
Risk Statements
Reports are often summarized in risk statements. You use risk statements to communicate a risk and the resulting impact. They are often written using “if/then” statements.
The “if” part of the statement identifies the elements of the risk. The “then” portion of the statement identifies the effect.
For example, the following risk statement could be used for the Web site:
• If AV software is not installed on the Web server, then the likelihood that the server will become infected is high. The Web server has a constant connection to the Internet.
• If the server is infected, then an outage is likely to occur. Any outage will result in $500 of lost sales for every 15 minutes of downtime.
You should be able to match the risk statements to the scope and objectives of the project. If the statement isn’t within the scope or objectives, the risk assessment may be off track. You’ll then need to go back and focus the findings or the recommendation.
Documenting Management Response to Recommendations
After you present your managers with the recommendations, they will decide what to do. They can accept, defer, or modify recommendations:
• Accept—Management approves the recommendation. Approved recommendations are funded and implemented. They will then be added to a POAM for tracking.
• Defer—Management can also defer a recommendation. It may still be implemented at a later time. However, do not include it in the list of accepted recommendations.
• Modify—Management can also decide to modify a recommendation. For example, you may recommend a firewall. Management may decide on two firewalls to implement a demilitarized zone (DMZ). On the other hand, you may recommend a $4,000 firewall. Management may decide to purchase an $800 firewall instead.
NOTE
A demilitarized zone (DMZ) is commonly used to protect Internet-facing servers. It usually consists of two firewalls. One firewall filters traffic from the Internet to the DMZ. The other firewall filters traffic from the internal network to the DMZ.
Documenting and Tracking Implementation of Accepted Recommendations
It’s important to document the decisions made by management.
As time passes, the decisions can become distorted if you don’t document them. This is especially true if the recommendations are deferred or modified.
Imagine you managed the risk management plan for the Web site. The plan recommended purchase of AV software, but this recommendation was deferred. Three months later, the system is infected with malware. A four-hour outage results in losses exceeding $8,000. You may be asked why the software wasn’t purchased.
If you documented the decisions, this is a simple matter to address. Without documentation, the result may be uncomfortable finger-pointing.
The documentation doesn’t need to be extensive. It could be a simple document listing the recommendation and the decision. It could look similar to this:
• Recommendation to purchase AV software—Accepted
Software is to be purchased as soon as possible.
• Recommendation to hire an IT administrator—Deferred
IT department needs to provide clearer justification for this. In the interim, the IT department is authorized to use overtime to ensure security requirements are met.
• Recommendation to purchase SS75 firewall—Modified Two SS75 firewalls are to be purchased as soon as possible. These two firewalls will be configured as a DMZ.
NOTE
A POAM is sometimes abbreviated as POA&M.
Plan of Action and Milestones
A plan of action and milestones (POAM) is a document used to track progress. POAMs are used in many types of project management. A POAM is used to assign responsibility and to allow management follow-up:
• Assignment of responsibility—The POAM makes it clear who is responsible for each task. When a task is not completed on schedule, it also makes clear whom to hold accountable.
• Management follow-up—PMs and upper-level management can use the POAM to follow up on a project. The POAM allows managers to quickly determine the status of any project. When project management tools are used, the source of the problem is often easy to identify.
POAMs are also useful for any audited projects. For example, HIPAA requires regular reviews. The POAM can show the progress the company has made to become compliant. If a company is not 100 percent compliant but can show it has made significant progress, fines may be waived or reduced. If a company doesn’t have any documentation indicating progress, maximum fines could be assessed.
There are no specific formats required for a POAM. One company may create a POAM in a Microsoft Excel spreadsheet with 15 columns for every item. Another company may create a POAM in a Microsoft Word document.
The POAM is a living document. It is not a report that is created once and is complete. Instead, you should update the POAM throughout the life cycle of a project. Additionally, the POAM may look different depending on the phase of the project. Early in the project, the POAM may be generic. Later in the project, it could be more specific.
For example, consider the Web site risk management plan. The Web site has been attacked. It has suffered two major outages in the last two months. The cause of these two incidents is probably well known. However, all the threats and vulnerabilities are probably not known. The initial POAM might have the following generic items:
• Approve risk management plan: Assigned to ______ Due by ______
• Identify threats: Assigned to ______ Due by ______
• Identify vulnerabilities: Assigned to ______ Due by ______
• Identify potential solutions: Assigned to ______ Due by ______
• Prepare risk management plan report: Assigned to ______ Due by ______
• Approve risk response plan: Assigned to ______ Due by ______
• Begin implementation of plan: Assigned to ______ Due by ______
• Complete implementation of plan: Assigned to ______ Due by ______
NOTE
A milestone is a scheduled event. It indicates the completion of a major task or group of tasks. Milestones are commonly used in project management to verify how the project is doing. When milestone dates are missed, the project is behind schedule.
Later, when management approves the specific recommendations, you can create a POAM for the approved and modified recommendations. Each recommendation within the POAM could have multiple line items. For example, the task of upgrading the firewall could be a major milestone. When all of the tasks are completed, the milestone is met.
• Log current firewall activity: Assigned to ______ Due by ______
• Purchase two SS75 firewalls: Assigned to ______ Due by ______
• Create firewall policy: Assigned to ______ Due by ______
• Test firewalls: Assigned to ______ Due by ______
• Implement external firewall: Assigned to ______ Due by ______
• Implement internal firewall: Assigned to ______ Due by ______
• Move Web server to DMZ: Assigned to ______ Due by ______
Project Management Software
There are many different versions of project management software available. One example is Microsoft Office Project. It includes different versions such as Microsoft Office Project Standard and Project Professional.
Project software includes additional tools that can be used to create charts. Charting tools provide a graphical representation of the project. They can also automatically detect the status of a project.
Some software will indicate the status of a project with colors such as green, yellow, or red. Green could indicate on schedule and on budget. Yellow could indicate a danger of going overschedule or overbudget. Red could indicate overschedule or overbudget.
A PM can enter data as the risk management project progresses. These charts will automatically be updated. It’s also possible to use a server to host data on multiple projects. Managers can access reports on any of the projects via a Web browser.
Each line item could include the following details:
• Task name
• Associated threat or vulnerability
• Risk level (low, medium, or high)
• Step or milestone name
• Assignment of responsibility
• Point of contact
• Estimated cost
• Actual cost
• Estimated person hours to complete task
• Actual person hours to complete task
• Scheduled start date
• Actual start date
• Milestone due date
• Current status
• Scheduled completion date
• Actual date of completion
• Comments
You can use different tools to assist in tracking the POAM. These tools don’t replace the POAM but instead provide graphical representations of the POAM and its progress. These tools include:
• Milestone plan chart
• Gantt chart
• Critical path chart
FIGURE 4-4 Milestone plan chart.
Charting the Progress of a Risk Management Plan
Managers often use charts to show the progress of a risk management plan. Charts provide a graphical representation of key information. As the saying goes, “a picture is worth a thousand words.” Similarly, a chart is worth a thousand words. The following sections cover some of the common charts managers use to track a plan’s progress.
Milestone Plan Chart
A milestone plan chart is a simple graphical representation of major milestones. It shows the major milestones laid out in a graphical format. If there are any dependencies between the milestones, this chart will show them. In other words, if milestone 2 can’t begin until milestone 1 has been completed, this chart will show this dependency.
It’s also common to include actual start and end dates in the chart. Figure 4-4 shows an example of a milestone plan chart.
The milestone plan chart can also help allocate resources. For example, the tasks in Figure 4- 4 aren’t dependent on one another. However, you can see that the tasks are staggered. It’s possible for each task to start at the same time. However, if the same person or same department will perform all of the tasks, it may not be possible to start each one at the same time.
In this case, start the longest task milestone first. In the figure, the M3 milestone will implement a DMZ and is the longest. Once you order the firewalls, you can start another task while waiting for the firewall to arrive. M2 can start at that point. Once you order the IDS software, you can start milestone M1.
This chart can also help management change the priority of any of the milestones. The installation of AV software may be considered the most important first step. The figure shows that the M1 is being delayed so that M3 can start first. This can be changed so M1 starts first with an accepted delay in the implementation of the DMZ.
FIGURE 4-5 Gantt chart.
Gantt Chart
A Gantt chart shows a project schedule. Gantt charts are commonly used in project management. The primary difference between the milestone plan chart and the Gantt chart is that the Gantt chart shows more detail.
Figure 4-5 shows an example of a Gantt chart. The shaded items show the tasks that have been completed. Notice that the Gantt chart is showing the detailed steps for the implementation of the DMZ.
The Gantt chart allows any manager to quickly view the progression and status of the project. In the figure, all of the tasks that were supposed to be completed before today are complete. The PM needs only to focus on the task in progress or future tasks.
NOTE
The Gantt chart was developed by Henry Gantt. He worked with the Army Bureau of Ordnance during World War I. He realized that processes could be controlled easier if they were broken down into smaller elements. As the often repeated saying goes: “How do you eat an elephant? One bite at a time.”
On the other hand, if previous tasks weren’t completed, the PM can quickly identify where to focus attention. For example, if the firewalls weren’t installed yet, the Install Firewalls task would not be shaded. The PM could see this element is past due and address the issue.
Most project management software automates the creation of Gantt charts. Additionally, as the tasks in the project are completed, it will automatically indicate completion in the chart. Before computers were so popular, these charts would be filled in by hand.
Critical Path Chart
Some tasks within a project can be delayed without impacting the project finish date. Other tasks must be completed on time. A critical path chart shows a list of project tasks that must be completed on time. If any task in the path is delayed, the overall project will be delayed.
FIGURE 4-6 Critical path chart.
For example, you cannot install a firewall until the firewall is purchased. If the purchase is delayed, the installation will be delayed. These two items would be in the critical path. On the other hand, you can delay creating a log of current firewall activity. As long as the delay isn’t too long, it won’t impact the overall schedule.
Figure 4-6 shows an example of a critical path chart. This is the critical path for the firewall project.
Compare Figures 4-5 and 4-6. Notice that two tasks are missing in Figure 4-6. Log Firewall Activity and Create Firewall Policy are not in the critical path. If these two tasks are slightly delayed, they will not delay the entire project. The only requirement is that they be completed before the Install Firewalls task starts.
CHAPTER SUMMARY
A risk management plan is a specific type of project plan. The project is to identify and mitigate risks. You start by creating objectives and a project scope. You then identify risks. Finally, you create a response plan as recommendations to mitigate the risks. Management can then choose to accept, defer, or modify the risks.
You then implement the recommendations. A primary tool used to track the recommendations is a plan of action and milestones (POAM). This POAM is a living document that is updated throughout the project. You can supplement it with different charting tools to ease project management tasks.