Chapter 7: Preparation

(1)

MAMPU

7.0 Introduction

The preparation stage as illustrated in Figure 7.1: Preparation Diagram is not part of the risk assessment process in MyRAM. However, it is vital in determining the successful start of a MyRAM. It is at this preparation stage that the risk assessment team formed will understand the pre-requisites for a successful risk assessment exercise. Prior to the Preparation stage, one must recall that there is the High-Level Risk Assessment (HiLRA) which determines whether a detail RA using MyRAM is necessary or not. For the High-Level Risk Assessment, the senior management will be the approving authority for this exercise.

Figure 7.1: Preparation Diagram

7.1 Overview of this process

The senior management of an agency has the responsibility for meeting mission requirement and business objectives. As part as of a good conduct of due diligence, senior management must ensure that the necessary resources are effectively applied in the information security initiatives to meet the mission requirement. The Preparation stage is when decision has to be made with regards to the feasibility of a proper risk assessment project. At the agency level an existing ICT Steering Committee (Refer to Pekeliling. 4 Tahun 2004: Garis Panduan Mengenai Tatacara Memohon Kelulusan Teknikal Projek ICT Agensi Kerajaan) may commission an initial feasibility study for a RA project.

Goals

The preparation stage has the following goals;

1 To identify the requirements and justifications for a risk assessment exercise.

2. To specify the objectives and the resources (budget, manpower, time line) required to successfully complete the RA exercise.

3. To obtain endorsement from the senior management to proceed with the risk assessment exercise.

(2)

MAMPU

Tasks

1. Setting Up A Preliminary Risk Assessment Team

The preliminary risk assessment team should have a representative from the core business areas and the ICT department. The personnel selected should possess good understanding and knowledge of the targeted area of operations in the organisation. It is advisable that the ICTSO, or any other personnel member who has a role and responsibilities similar to those of the ICTSO to lead the team.

These personnel members usually are those who are familiar with Information security in general. The team should consist of one to three people, based on the anticipated action group workload that may include writing activities, presentations, and discussions.

2. Deliverables of the Preparation Stage

The deliverable is a proposal to conduct risk assessment exercise or project depending on the extent or size. The proposal should highlight the importance and key benefits of a risk assessment exercise in the context of the organisation’s security objectives.

The following elements need to be presented to the senior management for approval of the risk assessment activity.

i. Scope or Review Boundary – It is advisable that the scope is determined based on core functions of the agency. When the scoping is done for the first RA, only one (1) or two (2) core functions should be looked at. Once experience in performing RA activities is acquired, the agency can extend the boundary to include more processes or functions. Examples of documents that can be reviewed to determine the scope are:

• Client’s charter

• Work procedure manual

• Organisational structure

• Ketua Pengarah’s desk file/ fail meja

• Standard operating procedures

• Annual report.

ii. Manpower – Normally, it will take two (2) full-time RA team members and two (2) part-time staff to identify and analyze risks associated with two (2) core business functions.

iii. Duration – For core functions with approximately 100 assets, and at least two (2) full-time and two (2) part-time RA team members, the whole exercise may take approximately three (3) to four (4) months.

iv. Allocation of Budget – If the personnel of the agency perform the exercise, then the agency must look at costs associated with possible needs for training, software tools, and hiring external consultants. If no internal officers are available, the senior management will need to find alternatives to ensure that the risk assessment activity is performed.

Tasks (Preparation):

1. Setting Up A Preliminary Risk Assessment Team 2. Identify

Required Resources 3. Obtain Senior

Management Commitment And Approval

(3)

MAMPU

3. Obtain Senior Management Commitment and Approval

The proposal may be presented by the preliminary RA team in any suitable platform such as, a simple discussion session, a formal meeting or a more serious formal forum. All pertinent information that would assist in decision making should be tabled clearly and rationalized. The written approval to proceed or otherwise with the RA exercise should be obtained from the senior management.

Besides the endorsement on scope, objectives and timeline, the following commitment must be solicited:

i. Transparent, continual support of risk assessment activities by senior management.

ii. Formal assignment of RA team members.

iii. General directive to all relevant organisational personnel who may be required to cooperate in terms of information gatherings and sharing.

iv. Agreement on the roles and responsibilities within the risk assessment process.

v. Budget allocation if relevant.

vi. Commitment to review the results and to make informed decisions upon presentation of the RA deliverables at every crucial stage of the RA exercise.

The written approval or acknowledgment from the senior management can be in a form of a letter, memo, e-mail or any formal communication method specifying all the elements being endorsed.

(4)

MAMPU

Output:

a) Proposal b) A formal communication method specifying the members of the preliminary RA team

Table 7.1: Proposal

Table 7.2: Sample of Memo/Letter on Acknowledgement of RA Exercise to Be Conducted

Output (Preparation) 1. Proposal

The output of the preparation stage is a proposal as in table 7.1 and a formal communication in the formal of a memo or letter approving the RA exercise to be conducted as per table 7.2.

Proposal 1.0 Introduction

2.0 Purpose

3.0 Background of Risk Assessment 3.1 Objectives

3.2 Benefits 3.3 Implications 4.0 Recommended Scope

4.1 Scope 4.2 Resources 4.3 Budget 4.4 Timeline 5.0 Authorization

2. Sample of Memo/Letter

Memo/Letter

Subject: Acknowledgement of Undertaking RA Exercise Thanks.

_______________________________

< Approving Authority >

(5)

MAMPU

C ha pt er 8 : R is k A ss es sm en t P ro ce ss

Introduction Figure 8.1 below shows that there are ten (10) essential steps altogether in a risk assessment (RA) activity or exercise. Figure 8.1: Risk Assessment Process Diagram

(6)

MAMPU

The input for one step of the RA activity may be taken from the output of one of its previous steps.

Table 8.1 below provide the description of each step in the RA process and the subtasks involved in each step.

Table 8.1: Description of RA Steps

Steps Description Task(s) Involved

Establishment of Creates a basic component of a (a) Identify the risk Team (Step 1) risk assessment exercise. The assessment team

team members that possess vast members

knowledge of the organisation (b) Draw up Tasking are identified. The schedule and Schedule List logistics are also established to

ensure the smooth implementation of the whole exercise.

Establishment of Determines the scope of the risk (a) Identify the scope of Review Boundary assessment process. The final the risk assessment (Step 2) scope will be submitted to the (b) Obtain approval from

senior management for approval. senior management Upon approval, the risk (c) Gather information assessment team will collect all related to the review the relevant materials and boundary

information related to the review (d) Prepare the Review

boundary. Boundary Document

(e) Revisit Step 1 as necessary

Identification of Identifies all the assets which (a) Identify related assets Assets (Step 3) are within the scope of the risk (b) Group and classify assets

assessment (review boundary). (c) Identify assets’ owners and custodians

(d) Verify and validate the findings of the questionnaires Valuation of Assets Assigns semi-quantitative values (a) Identify dependencies and Establishment to the assets and determines associated with the

of Dependencies their dependencies. assets

Between Assets (b) Assign a quantified

(Step 4) value to each asset

(c) Verify and validate the findings of the questionnaires

(7)

MAMPU

Steps Description Task(s) Involved

Assessment of Determines types of threats (a) Create a generic Threat (Step 5) associated with the assets, and threat profile

their relative levels. (b) Identify all relevant threats to assets (c) Verify and validate

the findings of the questionnaires Assessment of Identifies all potential (a) Identify potential Vulnerability vulnerabilities which may be vulnerabilities exploited (Step 6) exploited by threats. In addition, by threats

it will rate the relative (b) Verify and validate vulnerability exposure levels. the findings of

the questionnaires Identification of Identifies all types of existing & (a) Review existing and Existing & Planned planned safeguards which have planned safeguards for Safeguards been or will be deployed to protecting the assets (Step 7) protect the assets. (b) Verify and validate

the findings of the questionnaires Analysis of Impact Quantifies the business impacts (a) Determine the business (Step 8) of the assets accordingly. The loss

calculation will be based on the (b) Determine the impact assets’ values & business loss. levels

(c) Verify and validate the findings of the questionnaires

Analysis of Ascertains the likelihood of (a) Determine the likelihood Likelihood threats & vulnerabilities that of threats &

(Step 9) may happen, with or without vulnerabilities that

safeguard(s) in place. may happen

(b) Verify and validate the findings of the questionnaires

Calculation of Calculates the risk level for (a) Calculate the risk level

Risk each asset, based on the for each asset

(Step 10) impact value & likelihood results.

(8)

MAMPU

8.1 Risk Assessment Steps 8.1.1 Step 1: Establishment of Team Overview of this process

The establishment of the RA Team entails the appointment of RA team leader and members. It is suggested that team leader should be the designated ICTSO of the organisation. As for team members the number and the area of representation depends on the scale of the exercise and the targeted area for risk assessment. The team members are selected carefully based on their level of involvement in the organisation, as well as their experience particularly in the ICT infrastructure and the organisation’s core business.

Goals

The goals of this process are:

1. To obtain dedicated team members.

2. To assign tasks to all team members with associated roles and responsibilities.

Tasks

1. Identify The Risk Assessment Team Members

The RA team plays a major role in ensuring the success of this exercise. Since this team plays such a role in the assessment, it is of utmost importance to select a string of team members who possess sufficient skills and experience in the ICT infrastructure of the organisation to ensure the smooth implementation of the entire exercise.

a. Risk Assessment Team

The organisational chart for the RA team consists of the project advisor, project manager, team leader(s) or team member(s). It is important to acknowledge that the project advisor plays a vital role in an RA project. The role played is not only as and when advise is required but must conduct final evaluation, reviews and authorization of all output and documents before they are presented to the senior management at all stages and steps of the project.

Members should possess good knowledge of and experience in their organisation’s procedures and have relatively ample knowledge of the ICT infrastructure of the organisation. Representatives from the management and operational (technical) levels are needed to ensure the success of the RA activity.

Tasks (Step 1):

1. Identify The Assessment Team Members 2. Draw up Tasking Schedule List

(9)

MAMPU

Below is an example of the risk assessment team organisation chart.

Figure 8.2: RA Team Organisation Chart b. Roles and Responsibilities

The RA Team will be responsible for defining the boundary of the assessment.

The members will gather and analyze information as well as produce the risk assessment’s final report. Some other roles and responsibilities include:

i. Stating roles and responsibilities in general for all team members to set the participation expectation for all members.

ii. Gathering, analyzing and reporting the findings of the risk assessment exercise.

iii. Making sure that all tasks are performed properly.

iv. Coordinating logistics and schedules for the exercise.

Depending on the scope or the review boundary of the RA exercise, agency may determine who should be appointed as the project advisor. For example, the role of project advisor could be executed by the Head of Section, Head of Department or business owner. Below are the specific responsibilities for every designated personnel member who is involved in the risk assessment exercise.

Project Advisor

Project Manager

Team Leader (s)

Team Member (s)

(10)

MAMPU

Table 8.2: Roles and Responsibilities for the Risk Assessment Team Function in

RA Team Responsibilities

Project Advisor (a) As the main and only advisory person for the RA exercise.

(b) Ensure the required process(es) and procedure(s) are followed.

(c) Resolve any RA exercise issues.

(d) Conduct final evaluations, reviews and authorization of all output and documents before they are presented to the senior management.

Project Manager (a) Manage the exercise as a whole on a daily basis.

(b) Ensure timely completion of the exercise.

(c) Works closely with the team leader and team members.

(d) Conduct reviews of all output and documents before they are presented to the Project Advisor.

(e) Reports to: Project Advisor.

Team Leader(s) (a) Regularly ascertain the scope of work.

(b) Evaluate results, assess gaps and provide feedback.

(c) Perform(s) all tasks defined under each step.

(d) Report(s) to: Project Manager.

Team (a) Perform all tasks defined under each step.

Member(s) (b) Report(s) to: Team Leader(s).

The recommended experience level in corresponding areas for other risk assessment team members is as follows:

i. Team Leader: at least one (1) year experience in ICT projects. A background in information security would greatly aid the entire RA exercise’s success.

ii. Team Members: no risk assessment experience or training necessary, though experience in ICT recommended.

2. Draw up Tasking Schedule List

The risk assessment team will identify some basic necessities of logistics and will notify the management of its scheduled tasks. The purpose of the schedule is to ensure that all team members are aware of the time allocated for specific tasks and to make sure that none of the organisation’s operations is interrupted.

The activities included in the schedule (using a Gantt Chart as one of the tools) are:

(a) Activities (Tasks) (b) Duration

(c) Start Date and Finish Date (d) Assigned Personnel (e) Venue

(11)

MAMPU

Resources (such equipment) need to be allocated for the following tasks:

(a) Establishment of Review Boundary

(b) Identification and Valuation of Assets (Step 3 and Step 4) (c) Assessment of Threats (Step 5)

(d) Assessment of Vulnerabilities (Step 6) (e) Identification of Safeguards (Step 7) (f) Analysis of Impacts (Step 8)

(g) Analysis of Likelihood (Step 9) (h) Calculation of Risk (Step 10)

Documents produced for Establishment of Team (Step 1):

1. Team Member List 2. Tasking Schedule List

(12)

MAMPU

Output (Step 1):

a) Team Member Listb) Tasking Schedule List

MyRAM/Form/S1-1.0 Output (Step 1):

1. Team Member List

The team member list contains the names of the team members, their respective job functions, and the associated sector/unit/department/division/vendor. A letter, memo, e-mail or any formal communication method of appointment will be attached together with this Team Member List for the official establishment of this RA team. The format of the memo or letter can vary depending on the agency’s format. CIO as the senior management personnel would approve the form. A sample format of the Team Member List is as in Table 8.3.

Table 8.3: Team Member List

No. Name Job Sect/Unit/Dept/ RA Function Function Div/Vendor

Prepared by: Reviewed by: Approved by:

Note: The sign-offs should be with the official stamp.

2. Tasking Schedule List

The tasking schedule list contains tasks, personnel, and duration. Table 8.4 is a sample format of the Tasking Schedule List.

Table 8.4: Tasking Schedule List

No Activity Venue SRA Team

Date Task Details

1.0 Activity Name (Y Days : Start Date – End Date) Output:

1. Output A

Note: The sign-offs should be with the official stamp.

MyRAM/Form/S1-2.0

(13)

MAMPU

8.1.2 Step 2: Establishment of Review Boundary Overview of this process

The appointed Team Leader(s) and Project Manager should initiate this step, Step 2:

Establishment of Review Boundary. The team will gather some basic information on key business operations of the organisation. Several key personnel should be interviewed as part of the information-gathering activity related to the ICT infrastructure. A review boundary must be identified and justified. The results should be tabled for further approval and endorsement by the senior management before the risk assessment process is taken to another level.

Goals

The goals of this process are;

1. To identify the appropriate review boundary.

2. To get consensus and approval from the senior management on the agreed review boundary.

Tasks

1. Identify the Scope of the Risk Assessment

The team will gather basic information regarding the key business operations of the organisation. All the relevant business processes are reviewed and studied closely.

At this point, there will be several discussion sessions, interviews and meetings with the operational area key personnel. The requirements put forward will be officially documented and presented to the senior management. The scope of the review boundary can take various forms as outlined below:

(a) By assets.

(b) By business processes or functions.

(c) By departments.

Nevertheless, it is recommended that the team use the core business functions or processes as its review boundary. This is in line with the requirement stipulated in BS 7799.

However, if they deem it fit, agencies can use assets or departments/divisions as the basis of their scope of boundary. Those agencies that do not have a significant amount of ICT assets (hardware, software, services, people, or data/information) may want to use assets as their scope of review boundary. Agencies that have multiple complex departments/divisions may choose to use those departments/divisions as their scope of review boundary.

Final approval and endorsement from the senior management is required before the whole exercise of analyzing and identifying risks can commence. The subsequent steps for the entire RA activity are based on the review boundary approved by the senior management.

Tasks (Step 2):

1. Identify the scope of the risk assessment 2. Obtain approval from senior management 3. Gather information related to the review boundary 4. Prepare the Review Boundary Statement Document 5. Revisit Step 1 as necessary.

(14)

MAMPU

2. Obtain Approval from Senior Management

Before obtaining approval from senior management on the review boundary or scope of the risk assessment, the project advisor must review and finalize the documents for approval. Approval from senior management is required to ensure senior management is committed to the RA activity.

3. Gather Information Related to the Review Boundary

The list of questionnaires as listed in Annex D must be answered by the asset owner, custodian or relevant personnel and noted by the RA team. Some of the questions may need to be forwarded to others, either from the management or operational groups, for answers and clarification. The findings to the questionnaires in Annex D will assist the RA team in analyzing the current posture of the infra and info structure of the defined scope. These questionnaires are not limited to this step only.

Some of the questions may need to be asked at other steps, namely Step 3 through Step 9. Some of the findings may need to be re-examined to ensure completeness and authenticity at other steps as well.

Relevant documentation, files (in hard and soft copies), and agreements as well as any proprietary documentation which relates directly and indirectly to the agreed scope are gathered.

Some means of information gathering include the following documents:

(a) Network Topology.

(b) Service-Level Agreements.

(c) Security Policies.

(d) Standard Operating Procedures.

(e) Corporate Information security Statements.

(f) Process Flow of Business Functions.

To complement the above documents, the RA team may use other means for information gathering, such as interviews and additional tools, for example network topology scanning tool.

The documents required during this task are not limited to those of the list above.

Any relevant documents deemed necessary should be analyzed as well.

MyRAM must also benefit by making use of existing support services and recorded information in the Malaysian Public Sector. The risk assessment team may obtain relevant information from the Jabatan Perkhidmatan Awam (JPA), Jabatan Kerja Raya (JKR), building maintenance contractor, Office of Chief Government Security Officer (CGSO) and other supporting agencies.

4. Prepare the Review Boundary Document

The Review Boundary Document is as per Output (Step 2) of this methodology. The risk assessment team needs to justify the content for every topic in the document.

It is in this document that we will know vital information such as purpose of the risk assessment (RA) exercise, core businesses, supporting business process and external interfaces involved in the RA scope. Apart from that, personnel, information assets, sites/buildings information are also analyzed.

(15)

MAMPU

Risks which are imported and exported to and from an agency are disclosed in the External Interfaces section. This section deliberates on third parties (external interfaces) involved and the risks they carry into or out of an agency. The RA team should take note of these risks in order for them to estimate the final risk. Depending on the scope or the review boundary of the RA exercise, only then can an agency determine who will give approvals for the output produced in the RA steps. For example, approval can be given by the Head of Section, Head of Department or business owner. Senior management must also be made aware of these risks in order for them to decide whether to accept, reduce, transfer or avoid them.

5. Revisit Step 1 as Necessary

After the review boundary is established, it may be necessary to revisit Step 1 to ensure that the team established is sufficient in number and skill.

Documents produced for the Review Boundary (Step 2):

1. Review Boundary Statement.

2. List of Related Materials Used.

3. List of Questionnaires With Findings

Output (Step 2)

The following are sample output documents of step 2.

1. Review Boundary Document

Table 8.5: Review Boundary Document

Output:

a) Review Boundary Document b) List of Related Materials Used c) List of Questionnaires With Findings

Table of Content Acronyms List of Figures List of Tables 1.0 Purpose

2.0 Background of Review Boundary 3.0 Review Boundary Statement

4.0 Key Business Processes and Functions 5.0 Supporting Business Processes

6.0 External Interfaces

7.0 Personnel Involved in the Scope 8.0 Information Assets

9.0 Sites/Buildings 10.0 Conclusion

< Project Manager > < Project Advisor > < Senior Management Personnel >

Note: The sign-offs should be with the official stamp.

(16)

MAMPU

2. List of Related Materials Used

Table 8.6: List of Related Materials Used

MyRAM/Form/S2-2.0

Name Description

Prepared by: Approved by:

< Team Leader > < Project Manager >

3. List of Questionnaires With Findings

Table 8.7: List of Questionnaires

MyRAM/Form/S2-3.0 By Who (Function No. <Topic> Question Answer Remark or Name – If

Applicable)

Notes:

(a) A sign-off for the questionnaires is required at the High-level Recommendations stage.

(b) The sign-offs should be with the official stamp.

(17)

MAMPU

8.1.3 Step 3: Identification of Assets Overview of this process

The appointed Team Leader(s) should initiate this step, Step 3: Identification of Assets.

The team members will be heavily involved throughout the process. Discussions as well as interviews with all relevant systems owners and custodians are means of getting necessary information on assets. Assets in the context of information security management may be in three forms;

• information assets represent the organisation’s critical data and information, either physical or electronic form;

• technical assets represent those that support the storage, transmission, and processing of data and information which are an important means to transforming data and information for use by the organisation;

• people can be an asset to the organisation because they can be the primary way of storing, transporting, and processing data.

All relevant assets within the review boundary established in Step 2 needs to be identified by the risk assessment team. These assets will be placed in their respective categories for ease of processing at a later step. The assets will be verified for the correctness of the classification, assets’ descriptions and further un-documented utilization of the assets.

Goals

The goals of this step are;

1. To gather all the assets to be assessed (in relation to the agreed review boundary).

2. To verify the validity of each asset before the assessment begins.

Tasks

1. Identify Related Assets

This is one of the most important steps in the entire risk assessment activity. All assets that are within the scope of the review boundary are to be identified. Various techniques of asset-gathering can be utilized. The most popular gathering method is by scheduling brainstorming sessions where the risk assessment team sits down with all the participants and comes up with answers to questions like:

• “What are your most important assets in your daily job?”

• “Are there any specific policies to protect the assets?”

• “What will happen if an asset is compromised?”

2. Group and Classify Assets

After gathering all the important assets that need to be assessed, the team has to classify all the assets based on each one’s classification:

(a) Hardware (b) Software (c) Services

(d) Data or Information (e) People

Tasks (Step 3):

1. Identify Related Assets 2. Group and Classify Assets 3. Identify Assets’ Owners and Custodians 4. Verify &

Validate the Findings of the Questionnaires

(18)

MAMPU

In some cases, the ICTSO will decide whether the identified asset is a hardware, software or services asset based on the more dominant classification of the asset.

For example, in certain cases, a firewall can either be a hardware or software asset.

Following is the asset classification with detailed descriptions.

Table 8.8: Asset Classification and Description Classification Definitions

Hardware A tangible asset which is used to support the information- processing and storage facilities of the organisation.

Examples: computers, servers, communication equipment, safes, etc.

Software Application software or system software such as operating systems, database systems, networking system software, or office applications that provide information-processing facilities to the organisation.

Examples: applications, development tools, utilities, system software, etc.

Services Services or systems (not in nature of standalones (Accessibility physical hardware or software) that support other assets Services and to perform their functions. For examples:

Supporting

Services) (a) Accessibility services

ii. Network services such as LAN, WAN, etc.

iii. Access Restriction System such as card access system.

(b) Supporting services – utilities such as electricity, air- condition, and suppression fire system, etc.

Data or Documented (paper or electronic) information or

Information intellectual information which is used to meet the missions and/or objectives of the organisation.

Examples: system documentation, operational procedures, business records, clients’ profiles, etc.

People Persons who have knowledge and skills to conduct the daily in-scope business functions of agencies in order to achieve business objectives or missions. The People assets are listed based on their respective job functions, instead of the individual personnel members.

Examples: general managers, software engineers, system administrators, etc.

3. Identify Assets Owners and Custodians

Each asset identified must have its owner and/or a custodian. The owners and custodians will need to verify the validity and correctness of the related information gathered. The assets identified are those owned by the processes or departments defined in the previous step – Step 2. In order to minimize efforts in identifying relevant assets within the Review Boundary, the RA team may refer to the Borang KEW 313 which contains a comprehensive inventory list of assets in government agencies.

(19)

MAMPU

4. Verify and Validate the Findings of the Questionnaires

The questionnaires distributed and asked in Step 2 need to be revisited. The findings need to be verified and validated to ensure completeness and authenticity.

Note: A sign-off for the questionnaires is required at the High-level Recommendations stage.

Document produced for Identification of Assets (Step 3):

1. List of Assets.

Output (Step 3)

1. List of Assets

Table 8.9: List of Assets

Output:

a) List of Assets

MyRAM/Form/S3-1.0

< Team Leader > < Project Manager > <Project Advisor>

No. Asset Asset Asset Owner Custodian Location Description

Group ID Name of Asset

8.1.4 Step 4: Valuation of Assets and Establishment of Dependencies between Assets

Overview of this process

The appointed Team Leader(s) should initiate this step, Step 4: Valuation of Asset and Establishment of Dependencies between Assets. The team members will be heavily involved in this step. Discussions as well as interviews will be held during this period of time to gather necessary information for valuing of assets.

All of the identified assets will be assigned with values based on the concept of Confidentiality, Integrity and Availability (CIA). Each rating will be based on the value of the assets in relation to CIA that is agreed upon by the owners or custodians.

In addition, the dependencies of the assets are determined to gauge their criticality within the infrastructure.

(20)

MAMPU

Tasks:

1. Identify Dependencies Associated with The Assets 2. Assign a Quantified Value to Each Asset 3. Verify &

Validate the Findings of the Questionnaires

Goals

1. To establish the dependencies of the assets.

2. To assign a quantified value to each identified asset.

Tasks

1. Identify Dependencies Associated with The Assets

Most of the assets in any organisation are not independent or ‘stand-alone’. Usually they interact with other assets - hardware, software, services, information. The dependency relationship must be identified and verified by the owners and custodians, including the owners of any supporting assets. Only immediate “neighbours” of the assets which are within the scope of the review boundary will be examined.

For example, the asset in question (or within the scope), asset A, depends on asset B. B is also within the scope, but it depends on C, which is not. When considering the dependencies between assets, we look only at the immediate “neighbours” (in this example, asset B. Asset C is not considered as an immediate “neighbour”).

2. Assign a Quantified Value to Each Asset

As it is hard for the team as well as the owners to place a monetary value on each asset, a quantified value based on the Confidentiality, Integrity and Availability (CIA) will be assigned instead.

Notes:

(a) Agencies can modify the example criteria used to fit into the agencies’

environments.

(b) Project advisor must advise the RA team the importance of giving realistic asset values to ensure no false risk rating result.

Table 8.10 details out the descriptions of CIA.

Table 8.10: CIA Descriptions

CIA Description

Confidentiality (C) This is the effect on the system and/or the organisation that would result from the deliberate, unauthorized or inadvertent disclosure of the asset. The effect of unauthorized disclosure of confidential information can result in loss of public confidence, embarrassment, or legal action against the organisation.

Integrity (I) This is the effect on the system and/or the organisation that would result from deliberate, unauthorized or inadvertent modification of the asset. If the loss of system or data integrity is not corrected, continued use of the contaminated system or corrupted data could result in inaccuracy, fraud, or erroneous decisions. Also, violation of integrity may be the first step in a successful attack against system availability or confidentiality. For all these reasons, loss of integrity reduces the assurance of a system.

(21)

MAMPU

Availability (A) This is the effect on the system and/or the organisation that would result from deliberate or accidental denial of the asset’s use. If a mission-critical system is unavailable to its end users, the organisation’s mission may be affected.

Loss of system functionality and operational effectiveness, for example, may result in loss of productive time, thus impeding the end users’ performance of their functions in supporting the organisation’s mission.

The next table (Table 8.11: Assets Group with Their Respective CIA) explains that the Confidentiality, Integrity, and Availability values must be taken into consideration when it comes to asset groups of Hardware, Software, Services and Data/Information. For the asset group of People, only the Confidentiality and Availability values need to be considered.

Table 8.11: Assets Group with Their Respective CIA

Asset Group Confidentiality(C) Integrity (I) Availability(A)

Hardware √ √ √

Software √ √ √

Services

(a) Accessibility Services √ √ √

(b) Supporting Services N/A N/A √

Data/Information √ √ √

People √ N/A √

Notes:

(a) Integrity is not applicable for People Asset Group as it is immeasurable or unquantifiable.

(b) Confidentiality and integrity for Supporting Services Asset Group is immeasurable or unquantifiable.

Legend:

√ Taken into consideration

N/A Not applicable (Not taken into consideration)

In considering the values of the CIA for assets identified, the RA team, owners and custodians must be mindful of the dependencies of assets. Some assets may not be critical on their own, however may become critical when considering the type of information stored or when other assets depend on availability of the assets in question.

Agencies must decide what the acceptable, tolerable downtime for the Hardware, Software, Services and Data/Information types of assets when considering the Availability factor. The next tables (Table 8.12: Hardware Value Rating, 8.13:

CIA Description

(22)

MAMPU

Software Value Rating, 8.14: Accessibility Services Value Rating, 8.15: Supporting Services Value Rating, 8.16: Data/Information Value Rating and 8.17: People Value Rating) provide examples of tolerable downtime.

If there is a case where the attributes fall under two (2) or more different levels (for example, the “Description” falls under both Low and Medium levels in Table 8.12: Hardware Value Rating), then best judgment must be made. The owners must at the end decide what would best describe the asset value rating for the hardware piece in question.

The following are guidelines on assigning a value to asset. Each agency must decide what is the best way of determining the asset values):

(a) Identify the highest value among the CIA values and use this value as the final value for the asset. For example for Hardware asset #1, the “C” value is Medium, the “I” value is Low, and the “A” value is High, then the final asset value is High. The same concept applies to all types of assets.

(b) A three (3)-quadrant value-rating table is used in evaluating the CIA values resulting in a three (3)-level asset values. The following six (6) tables provide guidelines on how to determine assets’ values. Agencies can modify the criteria used in the following tables (Table 8.12: Hardware Value Rating, 8.13: Software Value Rating, 8.14: Accessibility Services Value Rating, 8.15:

Supporting Services Value Rating, 8.16: Data/Information Value Rating and 8.17: People Value Rating) to fit into the agencies environments.

Table 8.12: Hardware Value Rating

Value Rating Description

C:

The hardware device is used maximally in processing and/or storing information that is classified as “Terbuka” in the Malaysian Public Sector.

I:

Low Security breaches to the device could result in loss of public confidence. However, information is insignificantly affected and the loss of functionality is minimal.

A:

The processes will still be operational or functional but slow if the time of unavailability of the devices is more than 2 weeks.

C:

The hardware device is used maximally in processing and/or storing information that is classified as restricted and/or confidential or termed as “Terhad” and/or “Sulit” in the Malaysian Public Sector.

I:

Medium Security breaches to the device could result in loss of public confidence, inaccuracy, fraud, or erroneous decisions, as well as cause the organisation’s mission to be affected with some losses of functionality and operational effectiveness.

A:

Some of the operations/functions will be suspended if the time of unavailability of the device is between 1 to 2 weeks.

(23)

MAMPU

Value Rating Description

C:

The hardware device is used maximally in processing and/or storing information that is classified as highly confidential or termed as

“Rahsia” and/or “Rahsia Besar” in the Malaysian Public Sector.

I:

High Security breaches to the device could result in loss of public confidence, inaccuracy, fraud, or erroneous decisions, as well as cause significant loss of core functions and operational effectiveness.

A:

The operations/functions will stop if the time of unavailability of the device is less than or equal to 1 week.

Table 8.13: Software Value Rating

Low C:

The software package or application is used maximally in processing and/or storing information that is classified as “Terbuka” in the Malaysian Public Sector.

I:

Security breaches to the software could result in loss of public confidence; however, information is insignificantly affected and the loss of functionality is minimal.

A:

The processes will still be operational or functional but slow if the time of unavailability of the software is more then 2 weeks.

C:

The software package or application is used maximally in processing and/or storing information that is classified as restricted and/or confidential or termed as “Terhad” and/or “Sulit” in the Malaysian Public Sector.

I:

Medium Security breaches to the software could result in loss of public confidence, inaccuracy, fraud, or erroneous decisions, as well as cause the organisation’s mission to be affected with some losses of functionality and operational effectiveness.

A:

Some of the operations/functions will be suspended if the time of unavailability of the software is between 1 to 2 weeks.

(24)

MAMPU

C:

The software package or application is used maximally in processing and/or storing information that is classified highly confidential or termed as “Rahsia” and/or “Rahsia Besar” in the Malaysian Public Sector.

I:

High Security breaches to the software could result in loss of public confidence, inaccuracy, fraud, or erroneous decisions, as well as cause significant loss of core functions and operational effectiveness.

A:

The operations/functions will stop if the time of unavailability of the software is less than or equal to 1 week.

Table 8.14: Accessibility Services Value Rating

C:

The services are used maximally in transferring information that is classified as “Terbuka” in the Malaysian Public Sector.

I:

Low Security breaches to the services component could result in loss of public confidence; however, information is insignificantly affected and the loss of functionality is minimal.

A:

The processes will still be operational or functional but slow if the time of unavailability of the services is more than 2 weeks.

C:

The services are used maximally in transferring information that is classified as restricted and/or confidential or termed as “Terhad”

and/or “Sulit” in the Malaysian Public Sector.

I:

Medium Security breaches to the services could result in loss of public confidence, inaccuracy, fraud, or erroneous decisions, as well as cause the organisation’s mission to be affected with some losses of functionality and operational effectiveness.

A:

Some of the operations/functions will be suspended if the time of unavailability of the services is between 1 to 2 weeks.

Value Rating Description

(25)

MAMPU

Value Rating Description

High C:

The services are used maximally in transferring information that is classified as highly confidential or termed as “Rahsia” and/or

“Rahsia Besar” in the Malaysian Public Sector.

I:

Security breaches to the services could result in loss of public confidence, inaccuracy, fraud, or erroneous decisions, as well as cause significant loss of core functions and operational effectiveness.

A:

The operations/functions will stop if the time of unavailability of the services are less than or equal to 1 week.

Table 8.15: Supporting Services Value Rating

Low A:

The processes will still be operational or functional but slow if the time of unavailability of the services is more than 24 hours.

Medium A:

Some of the operations/functions will be suspended if the time of unavailability of the services is between 6 to 24 hours.

High A:

The operations/functions will stop if the time of unavailability of the services are less than or equal to 5 hours.

Table 8.16: Data/Information Value Rating

C:

The data/information that is classified as “Terbuka” in the Malaysian Public Sector.

I:

Low Any security breaches would affect the security objectives of the organisation. However, they would NOT introduce operational issues.

A:

The processes will still be operational or functional but slow if the time of unavailability of information is more than 2 weeks.

(26)

MAMPU

C:

The data/information that classified as restricted and/or confidential or termed as “Terhad” and/or “Sulit” in the Malaysian Public Sector.

I:

Medium Any security breaches would not cause significant damages; however, they would introduce operational issues as well as insignificant loss of public confidence.

A:

The non-critical operations/functions will be temporarily suspended if the time of unavailability of information is between 1 to 2 weeks.

C:

The data/information that is classified as highly confidential or termed as “Rahsia” and/or “Rahsia Besar” in the Malaysian Public Sector.

I:

High Any security breaches would cause significant damages to some of the business functions and threaten the survival of the organisation.

A:

The operations/functions will stop if the time of unavailability of information is less than or equal to 1 week.

Table 8.17: People Value Rating

C:

The role of the personnel requires him/her to handle* “Rahsia”

and/or “Rahsia Besar” information less than 10% of the time, and

“Sulit” and/or “Terhad” information less than 10% of the time, Low and “Terbuka” information most of the time.

A:

If the personnel is unavailable,

• operations in the organisation will meet objectives, however

• operations are slow compared to normal/usual.

Value Rating Description

(27)

MAMPU

C:

The role of the personnel requires him/her to handle* “Rahsia”

and/or “Rahsia Besar” information less than 20% of the time, and

“Sulit” and/or “Terhad” information less than 20% of the time.

Medium A:

If the personnel is unavailable:

• operations in the organisation will meet objectives, however

• certain operations will be put on hold temporarily, nevertheless, it can still be passed on to another personnel member with the same role for handling.

C:

The role of the personnel requires him/her to handle “Rahsia” and

“Rahsia Besar” information more than 20% of the time.

A:

High If the personnel is unavailable:

• operations in the organisation will fail to meet their objectives.

• most or all critical processes will have to be suspended with no substitutions.

Note:

The term “handle” here does NOT refer to handling by couriers. It refers to handling of information by authorized personnel who can read or see the information.

3. Verify and Validate the Findings of the Questionnaires

Document produced for Valuation of Assets and Establishment of Dependencies between Assets (Step 4):

1. Summary of Asset Value and Dependencies.

Value Rating Description

(28)

MAMPU

Output:

a) Summary of Asset Value and Dependencies

Output (Step 4)

1. Summary of Asset Value and Dependencies

Table 8.18: Summary of Asset Value and Dependencies

MyRAM/Form/S4-1.0

8.1.5 Step 5: Assessment of Threats Overview of this process

\The appointed Team Leader(s) should initiate this step, Step 5: Assessment of Threats.

The team members will be heavily involved in this step. Discussions as well as interviews will be held during this period of time to gather necessary information for determining threats.

A generic threat profile now needs to be created. It will consist of the related threat list (based on the catalogue provided in Annex A), as well as other related threats that are not on the list. For consistency and relevance, owners and custodians will need to be consulted accordingly. Each asset will then be mapped to the associated threats.

Goals

1. To produce a generic organisational threat profile.

2. To identify all relevant threats to assets.

Tasks

1. Create A Generic Threat Profile

Based on the provided threat list in Annex A, the team will come up with a threat profile specific to the organisation. The simple guidelines below can be used to create the generic organisational threat profile.

C I A No. Asset

Group Asset ID Asset

Name Value Asset

Depended On

Dependent

Asset Asset Value

< Team Leader > <Project Manager > <Project Advisor>

Tasks (Step 5):

1. Create A Generic Threat Profile 2. Identify All Relevant Threats

(29)

MAMPU

To Asset 3. Verify and Validate The Findings of The Questionnaires

Output:

a) Generic Threat Profile

b) Relevant Threats

Note: The sign-offs should be with the official stamp.

(a) Threats which have occurred before.

(b) Threats which may occur if there is no pro-active prevention action taken.

(c) Threats which may occur even if proactive prevention has been taken.

2. Identify All Relevant Threats To Assets

All assets that have been identified in Step 3 are mapped to their relevant threats.

One asset may correspond to various threats. This task will be initiated by the risk assessment team and will, at a later stage, be verified by owners and custodians.

3. Verify and Validate the Findings of the Questionnaires

The questionnaires (provided in Annex D) distributed and asked in Step 2 need to be revisited. The findings need to be verified and validated to ensure completeness and authenticity.

Notes:

(a) To avoid a ‘false’ risk rating at the end of the risk assessment process, careful assessment must be done when identifying the threats.

(b) A sign-off for the questionnaires is required at the High-level Recommendations stage.

Document(s) produced for Threat Assessment (Step 5) are:

1. Generic Threat Profile.

2. Relevant Threats to Assets.

Output (Step 5)

1. Generic Threat Profile

Table 8.19: Generic Threat Profile

MyRAM/Form/S5-1.0 Threat Threat ID Threat Name Threat Description Group

(30)

MAMPU

2. Relevant Threats to Assets

Table 8.20: Relevant Threats

8.1.6 Step 6: Assessment of Vulnerabilities Overview of this process

The appointed Team Leader(s) should initiate this step, Step 6: Assessment of Vulnerabilities. The team members will be heavily involved in this step. Discussions as well as interviews will be held during this period of time to gather necessary information for determining vulnerabilities.

All potential vulnerabilities that may be exploited by threats (Step 5) are identified. The generic vulnerability catalogue is in Annex B. These vulnerabilities must be thoroughly reviewed.

Goals

The goal of this step is specifically to determine the vulnerabilities for each asset.

Tasks

1. Identify Potential Vulnerabilities Exploited By Threats

The respective vulnerabilities which may compromise the security of assets need to be identified. In most cases, assets that belong to the same classification or group have the same vulnerabilities. However, this is not always true.

Based on the vulnerability list provided in Annex B, the team will come up with a vulnerability profile specific to the assets identified. One asset may have several vulnerabilities. The list created needs to be verified by the team, the owners, and the custodians of the assets.

2. Verify and Validate the Findings of the Questionnaires

Document produced for Vulnerability Assessment (Step 6):

1. List of Potential Vulnerabilities to Assets.

MyRAM/Form/S5-2.0 No. Asset

Group Asset ID Asset Name Threat

Group Threat ID Threat Name

Tasks (Step 6):

1. Identify Potential Vulnerabilities Exploited By Threats 2. Verify and Validate Findings of The Questionnaires

(31)

MAMPU

Output (Step 6) A sample output document for this step is as per table 8.21. 1.List of Potential Vulnerabilities To Assets Table 8.21: List of Potential Vulnerabilities to Assets MyRAM/Form/S6-1.0 No.Asset Asset IDAsset Threat Threat Threat Vulnerability Vulnerability Vulnerability GroupName GroupIDName GroupIDName Prepared by:Reviewed by:Approved by: < Team Leader >< Project Manager ><Project Advisor> Note:The sign-offs should be with the official stamp.

Output: a) List Of Potential Vulnerabilities to Assets

(32)

MAMPU

8.1.7 Step 7: Identification of Existing and Planned Safeguards Overview of this process

The appointed Team Leader(s) should initiate this step, Step 7: Identification of Existing and Planned Safeguards. This step is to determine the relevant existing or planned safeguards for each identified asset. Chosen planned safeguard must be based on Annex C: Generic Safeguard List.

Goal

The goal of this step is specifically to identify all relevant existing and planned safeguards or controls for each asset.

Tasks

1. Review Existing and Planned Safeguards For Protecting the Assets

Safeguards (control)s are identified. The types of safeguards that need to be considered are classified according to the ten (10) domains in Annex C which are as the following:

(a) Security Policy

(b) Organisational Security

(c) Asset Classification and Control (d) Personnel Security

(e) Physical and Environmental Security

(f) Communications and Operations Management (g) Access Control

(h) System Development and Maintenance (i) Business Continuity Management (j) Compliance

One asset may have several safeguards already in-placed or planned. Project advisors must consider the most cost effective safeguards in his/her recommendations.

2. Verify and Validate the Findings of the Questionnaires

Document produced for Identification of Existing and Planned Safeguards/Controls (Step 7):

1. Existing and Planned Safeguards.

Tasks (Step 7):

1. Review Existing and Planned Safeguards for Protecting The Assets 2. Verify and Validate The Findings of The Questionnaires

(33)

MAMPU

Output (Step 7) A sample output document for this step is as per table 8.22. 1.Existing and Planned Safeguards Table 8.22: Existing and Planned Safeguards MyRAM/Form/S7-1.0 No.Asset Asset IDAsset Threat Threat Threat Safeguard Current Type GroupName GroupIDName ID withSafeguard RelatedSolution Safeguard Name Existing Planned Prepared by:Reviewed by:Approved by: < Team Leader >< Project Manager ><Project Advisor> Note:The sign-offs should be with the official stamp.

Output: a) Existing and Planned Safeguards

(34)

MAMPU

8.1.8 Step 8: Analysis of Impact Overview of this process

The appointed Team Leader(s) should initiate this step, Step 8: Analysis of Impact. The team members will be heavily involved in this step. Discussions as well as interviews will be held during this period of time to gather necessary information for determining impact to the agencies if an asset is compromised.

The impact value resulting from a specific asset being compromised (damaged, destroyed, or stolen) is quantified. Output from several of the previous steps is used here as input.

Goals

The goals for this step are;

1. To determine the business loss if an asset is compromised.

2. To determine the impact level of each compromised asset.

Tasks

1. Determine The Business Loss

When considering the business loss on assets, it may be necessary to consider not only the replacement value of the assets, but also their reputation value, since not all assets can be quantified. However, while it is hard to put a value on reputation, business loss calculation due to compromise of reputation may be determined by the highest decision-making authority with consensus from the respective people involved with the asset.

In determining the business loss of each asset, the following guidelines can be used.

Agencies can modify the criteria used in the tables (Table 8.23: Business Loss Value Rating - Hardware, 8.24: Business Loss Value Rating - Software, 8.25: Business Loss Value Rating - Services, 8.26: Business Loss Value Rating – Data/Information and 8.27: Business Loss Value Rating - People) to fit into the agencies’ environments.

As one can see, three (3)-quadrant value-rating tables are used here in evaluating the business impact.

For the asset group of Hardware, Software and Services, the business loss value rating tables 8.23, 8.24 and 8.25 are used respectively. Please refer to the aforementioned tables when assigning hardware, software or services values.

Notes:

(a) Agencies can modify the criteria used to fit into the agencies’

environments.

(b) Project advisor must advise the RA team the importance of giving realistic asset values to ensure no false risk rating result.

Tasks (Step 8):

1. Determine The Business Loss 2. Determine The Impact Levels 3. Verify and Validate The Findings of The Questionnaires

(35)

MAMPU

Table 8.23: Business Loss Value Rating – Hardware

Business Explanation and Outcome

Loss Level

Low The impact of loss or unavailability of the asset is minor or negligible and will NOT bring any financial loss. Security breaches to the device will NOT cause disruptions to conduct daily operations of the organisations.

Medium The impact of loss or unavailability of the asset is considerable and could possibly bring financial loss. Security breaches to the device could result in inconveniences/disruptions to conduct daily operations of the organisations.

High The impact of loss or unavailability of the asset is intolerable and could bring high financial loss. Security breaches to the device could result in total disruptions to conduct daily operations of the organisations.

Table 8.24: Business Loss Value Rating – Software

Loss Level

Low The impact of loss or unavailability of the software package or application is minor or negligible and will NOT bring any financial loss. Security breaches to the software will NOT cause disruptions to conduct daily operations of the organisations.

Medium The impact of loss or unavailability of the software package or application is considerable and could possibly bring financial loss.

Security breaches to the software could result in inconveniences /disruptions to conduct daily operations of the organisations.

High The impact of loss or unavailability of the software package or application is intolerable and could bring high financial loss.

Security breaches to the software could result in total disruptions to conduct daily operations of the organisations.

(36)

MAMPU

Table 8.25: Business Loss Value Rating – Services

Loss Level

Low The impact of loss or unavailability of the asset is minor or negligible and will NOT bring any financial loss. Security breaches or interruption to the service(s) will NOT cause disruptions to conduct daily operations of the organisations.

Medium The impact of loss or unavailability of the asset is considerable and could possibly bring financial loss. Security breaches or interruption to the service(s) could result in inconveniences /disruptions to conduct daily operations of the organisations.

High The impact of loss or unavailability of the asset is intolerable and could bring high financial loss. Security breaches or interruption to the service(s) could result in total disruptions to conduct daily operations of the organisations.

For the asset group of Data/Information, reputation values, as well as efforts required in replacing and/or recovering information compromised can be used.

To better explain the process in determining business loss for asset group of Data/Information, please refer to the guideline in Table 8.26: Business Loss Value Rating – Data/Information. If there is a case where the attributes fall under two (2) different levels (for example, the “Explanation and Outcome” falls under both Low and Medium levels in Table 8.26: Business Loss Value Rating – Data/Information), then best judgment must be made. The owners must then decide what would best describe the business loss value rating for the data or information in question.

Table 8.26: Business Loss Value Rating – Data/Information

Loss Level

Low No loss of confidence by the public or other parties. Requires very minimal resources in terms of time, and personnel with minimal skills needed to replace and/or recover the information.

Medium Some loss of confidence by the public or other parties. Requires some resources, in terms of time, with personnel with minimal skills needed to replace and/or recover the information.

High Total loss of confidence by the public or other parties. Requires significance resources in terms of time, with skilful and qualified personnel needed to replace and/or recover the information.

For the asset group of People, qualitative replacement values can be used. To do so, the RA team needs to consider the knowledge, and skills required by the job functions. To better explain the process in determining business loss for asset group of People, please refer to the guideline Table 8.27.

(37)

MAMPU

Table 8.27: Business Loss Rating – People

Loss Level

Low Understanding of the business processes and some skills required.

Medium Substantial knowledge and skills in handling business process with minimal guidance required.

High Must be extremely knowledgeable and the only reference for the subject matters with vast skills in relation to the business processes.

2. Determine The Impact Levels

At this point the asset value variable that was discovered in Step 4 is utilized.

Impact is a function of asset value and business loss of a particular asset.

The impact level matrix table below is a recommended table. It is derived from experiences in RA activities carried out for telecommunication and financial institutions. An agency may come up with another matrix table that may represent its organisation better than what is presented here.

Impact = Function (Asset Value, Business Loss)

If three (3)-quadrant value-rating tables are used throughout the whole exercise, then a three (3)-quadrant matrix table needs to be used here as well.

Table 8.28: Impact Level Matrix

Business Asset Value

Loss Low Medium High

Low L L M

Medium L M H

High M H H

Legend of Impact Level:

Low Medium High

3. Verify and Validate the Findings of the Questionnaires

The questionnaires distributed and asked in Step 2 need to be revisited.

The findings need to be verified and validated to ensure completeness and authenticity.

(38)

<