news

June 2017

(Un)informed about IT Risks?IT Information Management as Basis for Enterprise Risk Managment

Page 2 / 9

IT Risk ManagmentIT Risk Managment

Governance, Risk Management and Complian-ce – GRC – encompasses three important ac� -on levels in successful enterprise management. Without intending to exactly defi ne or limit the individual areas, the focus in the following will be on risk management. We understand risk management in this context as the handling of known and unknown risks by way of defi ned risk analysis. That includes an early confronta� -on of risks, the provision of strategies to mini-mise risks and the prepara� on of damage buf-fers in case a risk materialises.

The enterprise iden� fi es, analyses and assesses its risks within the scope of risk management. There are numerous approaches and standards available. Central for risk management are the ISO 31000 standards.

Management of Risk

• M_o_R Principles: Engages Stakeholders, Provides Clear Guidance, Informs Decision-Making

• M_o_R Approach: Risk Management Strategy, Risk Register

• M_o_R Process: Iden� fy, Assess (Please see the appendix for more informa� on about M_o_R)

We will focus specifi cally on the topics “Engages Stakeholders”, “Iden� fy” and “Assess” for data-bases. This is done against the background fact that generally no reliable informa� on and techni-cal documenta� on of individual systems (and most importantly: on the interac� on of systems) exists.

Data access and databases represent a crucial topic for IT, in which enterprise risk is generated. We will concentrate on the following subsec� ons of the M_o_R framework here in order to off er an ini� al pragma� c and fast approach to risk management:

While the principles and procedures described in ISO 31000 will fi nd basic applica� on in all or-ganisa� onal levels, the ALEXOS Management of Risk (M_o_R) approach off ers a further me-thodical op� on that appears signifi cant and prac� cal in view of the tasks described here la-ter. The purpose of M_o_R is mainly to provide organisa� ons with an effi cient framework for IT risk management.

In the following, we will discuss one of the cen-tral challenges of Enterprise IT on the basis of M_o_R: The availability and security of databa-ses.

Page 3 / 9

IT Risk ManagmentIT Risk Managment

Which are the key success factors to ensure compliance with various objec� ves and require-ments for database availability and security in the long run? Concepts and procedure models are of crucial importance. The avato Procedure Model for Database Risk Management is similar to the Procedure Model for IT Informa� on Management. It is a process with structured levels and clearly defi ned goals and stakeholders. The risk management process for databases (Oracle) ad-vances through the following stages:

avato Procedure Model for Risk Manage-ment: Databases

• Stakeholders: Determina� on and defi ni� on of stakeholders

• Goals: Defi ni� on and coordi-na� on of goals

• Scope & Objec� ves: Defi ni� on of the areas for analysis and their respec� ve objec� ves

• Scope & Priori� sa� on Details: Defi ni� on of detailed objec� -ves, parameters for each area and priori� sa� on

• Methods: Defi ni� on of metho-dology and methods of analy-sis

• Tools: Defi ni� on of tools for data acquisi� on and analysis

In terms of risk, this has signifi cant consequences:

• Down� me likelihood: Very few enterprises can accurately assess the likelihood of system down� mes

• Down� me consequences: In most enterprises, nobody can exhaus� vely assess the conse-quences of individual database down� mes

• Limited recovery capabili� es: There is generally no reliable informa� on on whether and wit-hin what � me frame databases can be recovered completely

Page 4 / 9

IT Risk ManagmentIT Risk Managment

Mul� ple stakeholders generally have very diff erent requirements in terms of objec� ves and emphasis. Typical stakeholders are:

• IT Governance, including Supplier Governance• IT Audit and IT Compliance, including regulatory requirements• IT Service Management, including Con� nual Service Improvement, Standardisa� on & Auto-

ma� on, Self-Service Func� onali� es and Supplier Management

Stakeholders

Once the stakeholders and their objec� ves and priori� es are known, these can be aligned and coordinated. The result is then agreed with all stakeholders and ideally put down in wri� ng. In this phase it is par� cularly important to dis� ngu-ish between long-term goals and specifi c mid-term objec� ves. This phase is mainly about fi n-ding common ground with the stakeholders and about coordina� ng long-term goals.

Typical Risk Management Goals are:

• Knowing the risks (in terms of databases in the sense of unauthorised access or down� -mes) and understanding them

Goals

This phase includes the defi ni� on of the areas for analysis (scope) and their respec� ve objec� -ves. In terms of Oracle databases, the emphasis in this example is on database availability. The “Scope & Objec� ves” of a high-level analysis regarding database availability could look like this:

• Database So� ware• Database Infrastructure• Database Confi gura� on & Setup• Monitoring• Database Availability Concept & Implementa� on • Database Disaster Recovery Capability & Tes� ng• Database Interface Points

Scope & Objectives

• Assessing the risks in terms of probability of occurrence and poten� al damage• Risk monitoring/control

Page 5 / 9

IT Risk ManagmentIT Risk Managment

Now we will look at defi ning the depth of detail for the “Scope & Objec� ves” listed above. Addi-� onally, the various objec� ves are priori� sed. The following detail informa� on is crucial with re-gards to Oracle database availability and security:

• Database So� ware: Modules, version and patch level implemented • Database Infrastructure: Server basis, opera� ng systems and their versions and patch levels,

as well as storage, storage confi gura� on and network• Database Confi gura� on & Setup: Standard installa� ons and confi gura� ons, as well as databa-

se users. It is also important to know, whether “In-Place-Migra� ons” to newer versions were implemented for the installa� on in the past.

• Monitoring: Is there monitoring of database performance, storage performance and u� lisa-� on, CPU u� lisa� on and network u� lisa� on in place? Are there limit values in place for im-portant parameters and are these measured and documented periodically? Is there suffi -cient aler� ng in place and are there defi ned guidelines (work instruc� ons) available?

• Database Availability Concept & Implementa� on: Failover and backup concept with detailed process descrip� ons, periodic tes� ng of all processes and verifi ca� on of all relevant work instruc� ons. Detailed descrip� ons of most recent tests (most importantly restore) and docu-menta� on of the results. The implementa� on of RAC and Dataguard (where in use) must be described in detail.

• Database Disaster Recovery Capability & Tes� ng: DR concept and tes� ng, as well as the most recent DR test and a detailed descrip� on of that test, complete with results. An important point here is to include the applica� on in its en� rety and to not limit tes� ng to database re-covery only. It also includes transac� on consistency across all applica� on modules and all interface points to other systems.

• Database Interface Points: Interdependencies between separate databases and all interface points between databases and applica� ons must be documented in detail.

Scope & Prioritisation Details

Page 6 / 9

IT Risk ManagmentIT Risk Managment

The methodology within the scope of risk ma-nagement will always depend on the areas for analysis and may be mul� faceted. Let us now have a closer look at the methodology in terms of our Oracle database example. The procedure is based on the M_o_R process.

Methods

• Iden� fy: In terms of the availability of Orac-le databases, “Iden� fy” cannot be limited to historical data about incidents and issu-es (including a root cause analysis), even if their consistent assessment will contribute to a proac� ve system stabilisa� on. The number and frequency of non-cri� cal inci-

dents alone will not allow conclusions regarding the risk of down� mes and most importantly: the poten� al impact. The parameters described above off er a much more target-oriented analysis.

• Assess: “Assess” in accordance with M_o_R consists of two parts: “Es� mate” and “Evaluate”. “Es� mate” allows a priori� sa� on of risks. Which risks should be assessed how in terms of Oracle databases? In addi� on to tradi� onal topics like so� ware version, patch level and basic infrastructure, DR tes� ng and recovery capability are of crucial importance. “Evaluate” me-ans the understanding of risks by way of assessing threats and opportuni� es with regards to ac� vi� es.

• Plan: During the “Plan” phase, ac� ons with regards to threats and opportuni� es are prepa-red. The objec� ve here is to minimise threats and maximise opportuni� es.

• Implement: Planned ac� ons are executed and implementa� ons are monitored.

ToolsThe defi ni� on of tools will always be at the end of the pro-cess. It focuses mainly on the areas data acquisi� on and analysis. Data acquisi� on must go beyond tradi� onal CMDB informa� on and must cover central topics like con� nuity (backup/restore, failover), recovery and interface points.

Page 7 / 9

IT Risk ManagmentIT Risk Managment

In successful database risk management, essen� al components must be implemented with a clear focus on formulated objec� ves. Suffi cient informa� on, periodic and complete tes� ng and meaningful monitoring are the key to success if you want to know risks, assess and control them.Essen� al informa� on for all cri� cal databases includes their versions, patch level, database so� -ware and their infrastructure (servers, OS, storage, network). Database confi gura� ons and setup are of central importance, as are all database users, all database interdependencies and the in-terface points between databases and applica� ons.

Summary

In terms of availability, a number of concepts and periodic tes� ng are decisive factors in addi� on to the above informa� on. These include a failover concept and its periodic tes� ng, a backup/restore concept and restore tests, as well as a disaster recovery test. The la� er two in par� cular must be carried out in condi� ons similar to actual produc� on and must include applica� ons, as well as all database interface points. The test confi gura� on, implementa� on and results must be documented me� culously and tests must be repeated in the wake of major changes (database size, new interface points, new applica� on release roll-outs).

This informa� on creates the prerequisites needed to be� er assess down� me likelihoods, to spe-cify the consequences of down� me more accurately and to generate recovery capabili� es for at least the most essen� al systems.

Further Information / Community

We are looking forward to feedback or ideas for future newsle� ers and whitepapers.

For ques� ons and/or ideas just send us an email to marke� ng@avato-consul� ng. com.

Imprint

Date: Juni 2017

Author: Josef Kraitz

Contact: marke� ng@avato.net

www.avato-consul� ng.com

© 2017 avato consul� ng ag

Page 8 / 9

IT Risk ManagmentIT Risk Managment

The AXELOS Management of Risk Pocketbook is guided to put on eff ec� ve framework for risk management in place. The framework is based on four basic concepts:

• M_o_R Principles• M_o_R Approach• M_o_R Process• Embedding and reviewing M_o_R

Appendix: The M_o_R Framework

Basis to develop and maintain an enterprise risk management. High level statements providing for general guidance for enterprise risk management, such as:

• Aligns with objec� ves: Risk management needs to be con� nuously aligned with enterprise objec� ves.

• Fits the context: Fi� ng the current context requires an accurate understanding of changing internal and external contexts.

• Engages stakeholders: Requires knowing the stakeholder and to build up a suffi cient commu-nica� on

• Provides clear guidance: Stakeholders need to see how risk management iden� fi es, assesses and controls risks. Important to Risk Management is a coherent approach across all units.

• Informs decision-making: Risk management is responsible to provide suffi cient informa� on to decision-makers.

• Facilitates con� nual improvement: Basis for con� nual improvement are historical data • Creates a suppor� ve culture: Risk management creates a culture, where risks, costs of pre-

ven� on and consequences are known and where poten� al wins and losses are known• Achieves measurable value: Risk management should achieve measurable value to the enter-

prise by suppor� ng a cost eff ec� ve and effi cient risk preven� on

M_o_R Principles

Enterprise implementa� on of risk management principles, taking into account enterprise speci-fi c needs and objec� ves.

• Risk management policy: Descrip� on of the formal risk management approach• Risk management process guide: Descrip� on of processes, roles and responsibili� es• Risk management strategy: Detailed descrip� on of risk management implementa� on for an

organiza� onal unit or ac� vity• Risk register: Documenta� on of all iden� fi ed riskIssue register: Documenta� on of all current

unplanned situa� ons

M_o_R Approach

Page 9 / 9

IT Risk ManagmentIT Risk Managment

• Risk improvement plan: Documenta� on of all ac� ons required to improve risk management • Risk communica� ons plan: Descrip� on of how risk management communicates to all stake-

holders• Risk response plan: Documenta� on of response plans to individual risk. Liked to risk register• Risk progress report: Regular report on progress of risk management ac� ons

See descrip� on in "Methods". M_o_R Process

Embedding risk management into organiza� onal culture and to safeguard that risk management con� nues addressing enterprise requirements.

• Changing the culture for risk management: Regardless of the size of the organiza� on, risk management in terms of documented policies, process guides, strategy, plans and reports needs to be understood, valued and considered

• Measuring the value: Risk management is not an end in itself. The value of risk management to the enterprise needs to be measured con� nuously.

• Overcoming the common barriers to success: Typical barriers are lack of organiza� onal cul-ture and understandable and manageable policies

• Iden� fying and establishing opportuni� es for change.

Embedding and Reviewing M_o_R