The scope identifies the boundary of the risk assessment. When participants understand the scope, they are less likely to change it. Identifying the scope of the risk assessment helps keep it on track. In contrast, uncontrolled changes result in scope creep. Scope creep causes cost overruns and missed deadlines.

For example, FIGURE 5-1 shows a web server configured in a network. The server hosts a website that is accessible from the Internet. Customers can access the website and purchase products. The web server hosts the website application. The back-end database server hosts data.

The scope could be set to focus only on the web server. Alternatively, the scope could include the web server and the database server. Both of the firewalls in the demilitarized zone (DMZ) could also be included.

The web server was attacked several times in the past year. Some of these attacks resulted in the website crashing or the web server failing. However, existing controls protected the data on the database server, and it was not accessed inappropriately or lost. In this example, the database server might not be included. Also, the database server could be included just to ensure the existing controls will protect against current risks.

No decision is right or wrong in what to include in or exclude from the scope. Management will ultimately decide what is included in the scope. The most important point is to make a choice.

The risk assessment also identifies critical areas that should be included. Identifying these critical areas helps the risk assessment team focus on what’s important. For example, a scope could include a web server, a database server, and a firewall. The risk assessment could then identify the following critical areas:

• Web server—Addressing all elements of the web server includes hardware, the operating system, and the website application. For hardware, any single point of failure could be the focus. A single point of failure (SPOF) is any piece of hardware whose failure can take down the website. A process that regularly updates the operating system should be considered as well as applying best practices to prevent attacks on the website application, which include those for buffer overflow and SQL injection attacks.
• Database server—The database server hosts about 20 databases. The risk assessment should include only the databases accessed by the web server through the firewall. SQL injection attacks should definitely be considered. However, the primary protection from SQL injection attacks will be implemented in the website application.
• Internal firewall—The internal firewall controls all traffic to and from the internal network. All traffic in the risk assessment does not need to be included. Only the rules affecting communication between the web server and database server need to be addressed.

When critical areas are identified, areas that are most critical to the business should be the main focus. Profitability and survivability were mentioned previously in this chapter. The risk assessment needs to balance potential profits and losses. Losses that threaten an organization’s survivability are critical.

Some data is critical, such as financial and customer data. Other data, such as public data, doesn’t need the same level of protection. Similarly, some servers or IT services are critical, whereas other servers and services are less critical.

Although including only critical areas certainly makes sense, the risk assessment team may not understand what is critical to management. The team should stay focused on what management considers important.

Risk assessment team personnel should not be the same people who are responsible for correcting deficiencies, which helps avoid a conflict of interest.

For example, an administrator is responsible for implementing controls on a web server. His or her input may be biased by his or her desire to implement the control. If disinterested parties provide the input, chances are better of getting accurate, objective data.

Regardless, input should be obtained from the responsible department. Its staff probably has excellent insight into the problems and how to fix them. However, when prioritizing risks and determining the usefulness of controls, input from the people who correct deficiencies should not be the deciding factor.