Skip to main content

RIRA - Rapid IT Risk Assessment - a dimensional approach

 

I have previously written about RIRA, also known as the Meerkat Method. Information Technology (IT) risk is a measure of the extent to which the IT landscape is exposed based on the exploitation of vulnerabilities by a potential threat. Risk is composed of two elements:

  1. the consequence that an exploited vulnerability would have on the organization’s mission or operations
  2. the likelihood that such an exploitation would occur.

A risk assessment is the process of analysing and then interpreting risk associated with potential threats and vulnerabilities. The risk assessment acts as a means to help evaluate the efficiency and effectiveness of various security controls and countermeasures.

RIRA (Rapid IT Risk Assessment) is a methodology that been been defined to create and complete and initial assessment with minimal effort and is suitable for project management and even problem management. It defines the IT landscape as follows:

RIRA

The primary IT landscape domains are people, processes and technology. Often risk assessments only concentrate on technology and sometimes only on Information Security. Business transformation efforts similarly concentrate on the process improvement strategies and business process re-engineering; resulting in the people aspect of the change initiative being ignored. Up to three quarters of business re-engineering efforts do not achieve their objectives and subsequently do not sustain themselves over the long term, and one of the most commonly sited reasons for their failing is due to the lack of focus on the organization’s culture. Thus the RIRA methodology not only addresses risk for the traditional technology and Information security perspective but also the business focus on process and the organization's perceptive on people.

The attributes of the risk on this landscape are determined by:

  • Confidentiality. Information and services is accessible only to those authorized
  • Integrity. Safeguarding the accuracy and completeness of information and services
  • Availability. Authorized customers have access to the information and services when required

Information Security is treated as a special case as follows:

RIRA

The attributes of the Information Security landscape with respect to principles are:

  • Authenticity. It is necessary to ensure that the data, transactions, communications or documents (electronic or physical) are genuine. It is also important to validate that both parties involved are whom they claim they are for the sake of authenticity.
  • Non-repudiation. In law, non-repudiation implies one's intention to fulfil one’s obligations under a contract or transaction. It also implies that a party to a transaction cannot deny having received or having sent an electronic record. Electronic commerce uses technology such as digital signatures and encryption to establish authenticity and non-repudiation.

In addition there are security-related concepts when deploying a security solution. These include:

  • Identification. The process by which an individual professes an identity and accountability is initiated. An individual must provide an identity to a system to start the process of authentication, authorization and accountability. Providing an identity can be typing in a username, swiping a smart card, waving a proximity device, speaking a phrase, or positioning face, hand, or finger for a camera or scanning device. Proving a process ID number also represents the identification process. Without an identity, a system has no way to correlate an authentication factor with the individual.
  • Authorization. Once an individual is authenticated, access must be authorized. The process of authorization ensures that the requested activity or access to an object is possible given the rights and privileges assigned to the authenticated identity. In most cases, the system evaluates an access control hierarchy that compares the individual, the resource, and the intended activity. If the specific action is allowed, the individual is authorized or else rejected.
  • Accountability and auditability. An organization’s security policy can be properly enforced only if accountability is maintained, i.e., security can be maintained only if subjects are held accountable for their actions. Effective accountability relies upon the capability to prove a subject’s identity and track their activities. Accountability is established by linking a person to the activities of an online identity through the security services and mechanisms of auditing, authorization, authentication, and identification. Thus, accountability is ultimately dependent on the strength of the authentication process. Without a reasonably strong authentication process, there is doubt that the correct human associated with a specific user account was the actual entity controlling that user account when an undesired action took place.

The methodology is mapped as follows:

No alt text provided for this image
No alt text provided for this image
No alt text provided for this image
No alt text provided for this image

The methodology requires the follow steps to be executed for each of the IT landscape domains:

  • List IT. List all of the dangers or possible situations associated with the event activity that may expose services or information to threats. List these in the template. Use experts or experienced people to provide additional advice on your risk assessment.
  • Assess IT. Rate or assess what the vulnerability (likelihood) is of services and information being exposed to threats and what the impact (consequences) could be as a result of the threat occurring
  • Fix IT. Identify what practical measures could be put in place to eliminate or reduce the likelihood of the threat occurring. This is where changes are made to the event to reduce the risks. Use the hierarchy of control system to minimise or eliminate threats by putting in place potential to manage the threats once you have assessed their risk level.

Each of the attributes are assessed in a similar fashion (as can bee seen from this example):

No alt text provided for this image

Each risk threat is associated with a domain and attribute and is rated for impact and vulnerability, both using a scale starting at zero and with a maximum value of 4. The impact (also known as the consequence) is rated as follows:

  • Negligible (0). Persons requiring first aid; Insignificant costs incurred; Minimum impact to reputation.
  • Low (1).  Injuries resulting in lost time and claims; Some costs incurred; Minor isolated concerns raised by stakeholders, customers.
  • Moderate (2).  Rehabilitation required for injured persons; Costs incurred; Media and community concerned.
  • Major (3). Serious health impacts for people or permanent disability; Severe costs incurred; Widespread media coverage.
  • Catastrophic (4). Multiple deaths; Escalated and debilitating costs; Adverse media coverage.

The vulnerability is mapped as by attribute as follows:

  • Loss is a confidentiality threat
  • Error is an integrity threat
  • Outage is an availability threat.
No alt text provided for this image

This is much like the old DOS prompt of Abort, Retry, Fail? which amounts to abandonment, degradation and recoverability.

The vulnerability (also known as the likelihood) is rated as follows:

  • Negligible (0). No known or recorded incidents of occurrence; Remote chance, may only occur in exceptional circumstance.
  • Low (1).  Very few known incidents of occurrence; Availability recovered in days; Has not occurred yet, but it could occur sometime.
  • Moderate (2). Availability recovered in hours; Incidents or dangers have occurred infrequently in the past.
  • Significant (3).  Similar dangers have been recorded on a regular basis; Availability recovered in minutes; Considered that it is likely that the event could occur.
  • High (4). It is expected to occur in most circumstances; Availability required (excluding scheduled maintenance); There is a strong likelihood or danger of re-occurrence.

The rating of the threat is the product of the impact and vulnerability, which has a maximum value of 16. The risk level is categorized as follows:

  • Low (0-5)
  • Medium (6-11)
  • High (12-16)

The fix IT part of the methodology which is separated into mitigation and evaluation components is also similar across attributes:

No alt text provided for this image

The controls are defined as:

  • Eliminate (the threat).  Remove or stop the threat if possible, remove the cause or source of the threat, by eliminating the machine, task or work process. If this is not practical, then substitute.
  • Substitute (the process).  Use a less problematic process. If this is not practical, then engineer.
  • Engineer (change the technology).  Introduce different technology. Improve maintenance procedures. If this is not practical, then:
  • Isolate.  Separate or isolate the threat from people by relocation or by changing the operation.   If this is not practical, then administer
  • Administer.  Design and communicate written or verbal procedures that prevent the threat from occurring.  If this is not practical, then protect
  • Protect.  Provide protect measures appropriate to the risk. Provide training information and supervision to ensure that the measures will be effective and efficient.

The decisions reached about a risk are:

  • Control and countermeasures. Determine what controls are currently in place and which are appropriate to use in relation to mitigation of issues which are likely to occur.
  • Transference.  Transferring the cost of the risk occurring to another party such as an insurer
  • Acceptance.  Accepting a risk without implementing any mitigating measures
  • Avoidance. Disabling or stopping the activity which contributes most to the risk potentially occurring.

The speadsheet for RIRA is available here.

Please contribute to the subject matter by commenting below.

Ronald Bartels
This article was originally published over at LinkedIn: RIRA - Rapid IT Risk Assessment - a dimensional approach

Comments

Popular posts from this blog

Why Madge Networks, the token-ring company, went titsup

There I was shooting the breeze with an old mate. The conversation turned to why Madge Networks which I wrote about here went titsup. My analysis is that Madge Networks had a solution and decided to go out and find a problem. They deferred to more incorrect strategic technology choices. The truth of the matter is that when something goes titsup, its not because of one reason only, but a myriad of them all contributing to the negative consequence. There are the immediate or visual ones, which are underpinned by intermediate ones and finally after digging right down, there are the root causes. There is never a singular root cause for anything but I'll present my opinion and encourage everyone else to chip in. All of them together are more likely the reason the company went titsup. As far as technology brainfarts go there is no better example than Kodak . They invented the digital camera that killed them. However, they were so focused on milking people in their leg

Flawed "ITIL aligned"​ Incident Management

Many "ITIL aligned" service desk tools have flawed incident management. The reason is that incidents are logged with a time association and some related fields to type in some gobbledygook. The expanded incident life cycle is not enforced and as a result trending and problem management is not possible. Here is a fictitious log of an incident at PFS, a financial services company, which uses CGTSD, an “ITIL-aligned” service desk tool. Here is the log of an incident record from this system: Monday, 12 August: 09:03am (Bob, the service desk guy): Alice (customer in retail banking) phoned in. Logged an issue. Unable to assist over the phone (there goes our FCR), will escalate to second line. 09:04am (Bob, the service desk guy): Escalate the incident to Charles in second line support. 09:05am (Charles, technical support): Open incident. 09:05am (Charles, technical support): Delayed incident by 1 day. Tuesday, 13 August: 10:11am (Charles, technical support): Phoned Alice.

Updated: Articles by Ron Bartels published on iot for all

  These are articles that I published during the course of the past year on one of the popular international Internet of Things publishing sites, iot for all .  These are articles that I published during the course of the past year on one of the popular international Internet of Things publishing sites, iot for all . Improving Data Center Reliability With IoT Reliability and availability are essential to data centers. IoT can enable better issue tracking and data collection, leading to greater stability. Doing the Work Right in Data Centers With Checklists Data centers are complex. Modern economies rely upon their continuous operation. IoT solutions paired with this data center checklist can help! IoT Optimi