After data on the risks and recommendations has been collected, the data needs to be included in a report. This report will then be presented 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:
The collected data is compiled into a report, which will include the lists of threats, vulnerabilities, and recommendations. This report is then presented to management. Management will use this data to decide what steps to take.
Remembering the overall goal of the risk management plan is important 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. Every risk identified will be accompanied by a recommendation to reduce the risk.
This report should include the following information:
The findings list the facts. Remember that losses from risks occur when a threat exploits a vulnerability. Risk management findings need to include threats, vulnerabilities, and potential losses. The findings are described as cause, criteria, and effect:
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.
An important consideration as findings are documented is resource availability. Possibly, all the discovered issues were previously known. However, money may not have been allocated to purchase the solutions in the past. Also, possibly, manpower wasn’t adequate to implement the solutions.
When adequate manpower isn’t available, security is often sacrificed for ease of use. Consider the website example. The first goal may be to ensure the website is operational. Once it’s up, resources may be used for other jobs. The website 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 an example of a cause and effect diagram for the website 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.
Using a cause and effect diagram has several advantages. It can help guide discussions during the discovery process and help visualize the relationships between causes and effects in documentation. Cause and effect diagrams can be used for any problem.
A cause and effect diagram starts by creating the line and the ultimate effect. In Figure 4-2, the effect is the outage. Then, additional items are added (the causes), making the diagram look similar to a fishbone. The diagram can be expanded for any of the elements. For example, “attack” could be expanded to include specific types of attacks. Attacks may include malware, DoS, buffer overflow, or other types of attacks.
The cause and effect diagram is also called an Ishikawa diagram, or a fishbone diagram. It is used to link problems with causes.
When creating a cause and effect diagram, running out of ideas or focus on a single topic might happen. To balance the diagram, the following five elements can be considered, but not all of them need to be included. However, any of them can be used to help identify causes:
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 or criminal charges such as jail time.
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.
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.
Each item should include the cost required to implement it. The timeline should also be included to implement the solution. Management will use this data to decide whether the solution should be applied.
For example, the following partial list of recommendations could be included in the website risk management plan:
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:
Management is responsible for making the decisions on how to manage the risks. An accurate CBA allows management to make intelligent decisions.
Here is an example of a CBA for a website recommendation:
The importance of accurate data can’t be overestimated. The key to completing an accurate CBA is starting with accurate data. Again, sometimes, accurate data is difficult to get. Finding accurate data often requires digging below the surface to determine costs.
Probing questions can often uncover flaws in the data. Following are scenarios and questions to be considered:
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.
Reports are often summarized in risk statements. Risk statements are used 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, and the “then” portion of the statement identifies the effect. For example, the following risk statement could be used for the website:
The risk statements should be able to be matched 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, which means the findings or the recommendation need to be focused.
After the recommendations have been presented to the managers, they will decide what to do. They can either accept, defer, or modify recommendations:
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, and the other firewall filters traffic from the internal network to the DMZ.
Documenting the decisions made by management is important. As time passes, the decisions can become distorted if they are not documented, which is especially true if the recommendations are deferred or modified.
For example, in managing the risk management plan for the website, the plan recommended purchase of antivirus 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. The question may be asked why the software wasn’t purchased.
If the decisions had been documented, this would be 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: