|
VIBRANTBOOTCAMP.CO.UK |
|
MCSE Boot Camp |
|
|
| MCSE CCNA CCNP Boot camp UK : |
Vibrant
Microsoft Notes :
Join Vibrant MCSE
Boot camp Training in UK.
Risk Discussion PreparationBefore 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 InputsThe 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:
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 AssetsThe 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. AssetsBusiness 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 ClassesAssets 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." |
|
|
|
|