MCITP MCSE Boot Camp

Risk Discussion Preparation

Before the risk discussions commence, the Security Risk Management Team should invest time in researching and clearly understanding each element to be discussed. The following information covers best practices and further defines each element in the well-formed risk statement in preparation for facilitating discussions with stakeholders.

Identifying Risk Assessment Inputs

The risk assessment team must prepare thoroughly before it meets with stakeholders. The team is more effective and discussions are more productive when the team has a clear understanding of the organization, its technical environment, and past assessment activity. Use the following list to help collect material to be used as inputs into the risk assessment process:

• New business drivers — Refresh your understanding of the organization priorities or any changes that have occurred since the last assessment. Pay particular attention to any mergers and acquisitions activity.
• Previous risk assessments — Review past assessments, which provide perspective. The risk assessment team may have to reconcile the new assessment against previous work.
• Audits — Collect any audit reports relevant to the risk assessment scope. Audit results must be accounted for in the assessment and when selecting new control solutions.
• Security incidents — Use past incidents to identify key assets, understand the value of assets, identify prevalent vulnerabilities, and highlight control deficiencies.
• Industry events — Identify new trends in the organization and external influences. Government regulation, laws, and international activity may significantly affect your risk posture. Identifying new trends may require substantial research and assessment from your organization. It may be helpful to dedicate personnel to review throughout the year.
• Bulletins  —  Review known security issues that are identified on the Web, in newsgroups, and directly from software vendors.
• Information security guidance — Conduct research to determine whether new trends, tools, or approaches to risk management are available. Industry standards can be leveraged to improve or help justify the risk assessment process or help identify new control strategies. International standards are another key input.

This guide incorporates concepts from many standards such as the International Standards Organization (ISO) 17799. Careful evaluation and application of standards allows you to use the work of other professionals and provide a degree of credibility with organization stakeholders. It may be helpful to specifically reference standards during risk discussions to ensure the assessment covers all applicable areas of information security.

Identifying and Classifying Assets

The scope of the risk assessment defines the areas of the organization under review in the data gathering discussions. Business assets within this scope must be identified to drive the risk discussions. Assets are defined as anything of value to the organization. This includes intangible assets such as company reputation and digital information and tangible assets such as physical infrastructure. The most effective approach is to be as specific as possible when defining business assets, for example, account information in a customer management application. You should not discuss impact statements when you are defining assets. Impact statements define the potential loss or damage to the organization. One example of an impact statement might be the availability of account data in the customer management application. Impact statements are expanded on later in the risk discussion. Note that each asset may have multiple impacts identified during the discussion.

While you identify assets, also identify or confirm the owner of the asset. It is often more difficult to identify the person or group accountable for an asset than it may seem. Document specific asset owners during the facilitated risk discussions. This information may be useful during the prioritization process in order to confirm information and communicate risks directly to asset owners.

To help categorize assets, it may be helpful to group them into business scenarios, for example, online banking transactions or source code development. When working with non – technical stakeholders, begin the asset discussion with business scenarios. Then document specific assets within each scenario.

After assets have been identified, the second responsibility of the Business Owner is to classify each asset in terms of potential impact to the organization. Classifying assets is a critical component in the overall risk equation. The section below aids in this process.

Assets

Business assets can be tangible or intangible. You must define either type of asset sufficiently enough to allow Business Owners to articulate asset value in terms of the organization. Both categories of assets require the stakeholder to provide estimates in the form of direct monetary loss and indirect financial impact.

Tangible assets include physical infrastructure, such as data centers, servers, and property. Intangible assets include data or other digital information of value to the organization, for example, banking transactions, interest calculations, and product development plans and specifications.

As appropriate for your organization, a third asset definition of IT service may be helpful. IT service is a combination of tangible and intangible assets. For example, a corporate IT e-mail service contains physical servers and uses the physical network; however, the service may contain sensitive digital data. You should also include IT service as an asset because it generally has different owners for data and physical assets. For example, the e-mail service owner is responsible for the availability of accessing and sending e-mail. However, the e-mail service may not be responsible for the confidentiality of financial data within e-mail or the physical controls surrounding e-mail servers. Additional examples of IT services include file sharing, storage, networking, remote access, and telephony.

Asset Classes

Assets within the scope of the assessment must be assigned to a qualitative group, or class. Classes facilitate the definition of the overall impact of security risks. They also help the organization focus on the most critical assets first. Different risk assessment models define a variety of asset classes. The Microsoft security risk management process uses three asset classes to help measure the value of the asset to an organization. Why only three classes? These three groupings allow for sufficient distinction and reduce the time to debate and select the appropriate class designation.

The Microsoft security risk management process defines the following three qualitative asset classes: high business impact (HBI), moderate business impact (MBI), and low business impact (LBI). During the risk prioritization step, the process also provides guidance to quantify assets. As appropriate for your organization, you may choose to quantify assets during the facilitated risk discussions. If you do, beware of the time required to reach consensus on quantifying monetary values during the risk discussion. The process recommends waiting until all risks have been identified and then prioritized to reduce the number of risks needing further analysis.

Note   For additional information on defining and categorizing information and information systems, refer to National Institute of Standards and Technology (NIST) Special Publication 800-60 workshops, "Mapping Types of Information and Information Systems to Security Categories," and the Federal Information Processing Standards (FIPS) publication 199, "Security Categorization of Federal Information and Information Systems."