Selecting a Risk Assessment Methodology

Once the decision has been made to perform a risk assessment, an outline will need to be created to guide the process by deciding what specific steps to take. Performing a risk assessment isn’t a project decided on one day and completed the next. It takes time and planning.

The two primary types of risk assessment approaches are quantitative and qualitative. This chapter helps to paint the overall picture of both approaches. In general, a risk assessment involves the following steps:

  • Identifying assets and activities to be addressed
  • Identifying and evaluating relevant threats
  • Identifying and evaluating relevant vulnerabilities
  • Identifying and evaluating relevant controls
  • Assessing threats, vulnerabilities, and exploits
  • Evaluating risks
  • Developing recommendations to mitigate risks
  • Presenting recommendations to management

Before progressing with the risk assessment, two preliminary actions need to be completed. These are:

  • Defining the assessment
  • Reviewing previous findings

Defining the Assessment

What will be assessed needs to clearly be defined. If a system is to be assessed, then the system needs to be described. An example of a system might be the Human Resource department’s (HR’s) personnel records database. If a process is to be assessed, then the process needs to be described. An example of a process would be the Finance department’s creation of an invoice.

An important factor is to describe the system or process as it is right now. A risk assessment is a point-in-time assessment, unlike overall risk management, which is a continuous process.

When describing the system or process, two primary areas are often the focus:

  • Operational characteristics
  • Mission of the system

The scope of the risk assessment is also important to define to help prevent uncontrolled changes, which can result in cost overruns and missed deadlines.

NOTE

Scope of risk assessments: According to NIST SP 800-30, “the scope of the risk assessment determines what will be considered in the assessment. Risk assessment scope affects the range of information available to make risk-based decisions and is determined by the organizational official requesting the assessment and the risk management strategy.” Similar to “scope creep,” when unplanned work gets added to a project, the risk manager needs to define the risk assessment scope to avoid unplanned data gathering and analysis.

Operational Characteristics

Operational characteristics define how the system operates in an environment. Just naming the system, such as “Email server,” is not enough; instead, how the system is currently configured and operating needs to be identified.

For example, FIGURE 6-1 shows a single email server in a network that handles all email to and from the Internet. The server also provides email services for all clients in the internal network. But the illustration in Figure 6-1 is old and doesn’t reflect the organization’s current configuration.

A network diagram showing an outdated configuration of an email server.

FIGURE 6-1 Outdated configuration of email server in the organization’s network.

FIGURE 6-2, on the other hand, shows the organization’s current network diagram, which has a demilitarized zone (DMZ). The DMZ includes an email server used to send and receive email from the Internet and an internal email server that sends and receives email from the DMZ server but does not interact with the Internet.

A network diagram showing an updated configuration of an email server.

FIGURE 6-2 Upgraded diagram showing an internal email server and an email server in a DMZ.

The differences between Figures 6-1 and 6-2 help show the importance of documenting current operational characteristics. What would happen if a risk assessment was begun by evaluating the threats against the system in Figure 6-1? The obvious answer is that the information would be outdated and valuable time would be spent on the wrong effort.

The risk assessment needs to be performed against the current system. However, the current configuration isn’t always apparent or readily available. Sometimes, discovering the current configuration takes some digging. Here are two simple questions that can be asked:

  • Do the diagrams to be used show all of the current systems?
  • Is the documentation to be used of the current systems’ configurations?
Mission of the System

The mission of the system defines what the system does. Compared with the operational characteristics of the system, the mission is easy to define. The definition of the mission for any single system can be as short as a paragraph or can consist of simple bullet statements.

For example, an email system could have the following mission: The email server provides all email services for the organization, which include the following functions:

  • Routing email between internal clients
  • Accepting email from external email servers and routing to internal clients
  • Accepting email from internal clients and routing to external email servers
  • Scanning all email attachments and removing malware
  • Scanning all email for spam and stripping out confirmed spam

Managing Configuration and Change

Configuration management and change management are two important risk management processes, and they also have a direct impact on risk assessments. Sometimes, these two processes are mentioned together, but they are different.

Configuration management ensures that similar systems have the same or at least similar configurations. It focuses on the arrangement of the various parts of a system. When systems are very similar, techniques, such as baselines, scripting, and automation, can be used to configure them more efficiently. Systems that share the same configuration are easier to maintain collectively and to evaluate for risks.

Change management prevents unapproved changes to systems, thereby reducing risks. All changes are formally requested using a change management process. Technical experts review the requests and then either approve or disapprove them. Change management is critical to allow any proposed changes to be reviewed for new risk. Any proposed changes must be documented, assessed, and approved by the business/process owner. And, if needed, new controls might be included to mitigate any new risk. The goal is to reduce unintended outages that result from changes.

When change management is not implemented, a change to one system can easily cause an outage in another system. For example, a technician in a large organization is troubleshooting a problem with a printer. The printer isn’t automatically receiving an Internet Protocol (IP) address, which prevents print jobs from reaching the printer. The technician manually assigns an IP address and verifies the printer is working.

The IP address assigned to the printer is also assigned to a server that other technicians are repairing at the time. After the technicians repair the server and bring it online, it no longer works properly. The printer has the server’s IP address, causing an IP address conflict. The technicians have to spend extra time troubleshooting the issue and correcting both problems.

These problems could have been avoided had a change management process been in effect. The printer technician would have submitted the change request for the printer, and the administrator who assigns IP addresses would have easily seen the conflict and denied the request. Therefore, the server wouldn’t have had an extended outage.

Additionally, a change management process ensures the correct documentation for changes. Simply put, configuration management is about the arrangement of the components of a system, whereas change management is about the modification of the components.

When an organization has mature processes in place for configuration and change management, risk assessments are easier to perform because identifying the current status of a system is easier and available documentation is more up to date.

Reviewing Previous Findings

If previous audits or risk assessments are available, they should be reviewed. These reports can contain much valuable information to make the job of performing a risk assessment easier.

These reports list assets, threats, and vulnerabilities and should also list controls currently in place. They may provide recommendations for additional controls. Three items especially worth investigating are:

  • Recommendations—Previous recommendations give insight into several issues. They address threats, vulnerabilities, and controls that were considered relevant at the time. Even though many issues may have changed, some of them may be the same or similar.
  • Current status of accepted recommendations—Ideally, all previously accepted recommendations are in place. The effectiveness of approved and implemented recommendations can then be measured. However, if an approved recommendation isn’t in place, the previous report may help in determining why it wasn’t implemented. Perhaps the hardware or software is still in the purchasing pipeline, or the approved recommendation was simply ignored.
  • Unapproved recommendations—The recommendations that were not approved can also give some insight into the business. They may indicate that the organization is willing to accept a higher level of residual risk or that the organization suffered losses that would have been mitigated by an unapproved control. If the latter is true, then management may be more receptive to the control at this time.
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.219.103.183