Skip to main content

The landscape of IT risk

Within Information Technology (IT) there was meant to be a common language but that is far from being achieved. The language used by developers, service managers, Information Security or even data centre experts remains different. Each use their own terminology and risk managers have their own version too. It is often highlighted that IT and business see things from different perspectives and this is exacerbated by the silos within IT itself.
Risk, as far as IT is concerned, has typically always been about dealing with threats and invariably is centred on technology. The first problem is that the approach lacks balance often only the negative is highlighted without the positive being acknowledged.  The impression might be that a situation in IT is in dire straits while in reality it isn't. In most cases a SWOT (Strength, Weakness, Opportunities and Threats) analysis is used to achieve a balanced approach but often this tends to be subjective.
The second problem is that the landscape of IT is more than just technology but also about people and processes. Risk management needs to deal with the latter as well as technology otherwise only a selective view of the risks are presented.
In many organisations, Information security tends to be an island. The attention seems to be heavily focused on security breaches and crime. All security professionals preach the attributes of confidentiality, integrity and availability. However, the time is focused mostly on confidentiality which is all about information and services being accessible to only those who are authorised. Very few actually address integrity (safeguarding the accuracy and completeness of information and services) and availability (authorised customers have access to the information and services when required). If we draw a matrix of this, this is what it will look like:

Taken into context then the overall landscape would be nine blocks, much like a nought and crosses grid. In the scenario above only one block is used which means that 89% of the landscape is never addressed. Further, only half the block might be covered as only the negative is addressed and not the positive.
Each of these blocks should have identified threats. Optimally, these threats can be verified from a knowledge base which will provide a source of information and ensure that unknowns to the person doing the assessment are also taken into account.
The risk of a threat is a product of the impact and probability of the threat. The impact is the consequences and the probability is the likelihood or vulnerability. This risk is now analysed to determine its rating on a scale from low to high. A decision is then made on this risk from addressing it to even ignoring it. All valid decisions if there are made with knowledge.  Often the risks are addressed with valid controls that are underpinned with suitable countermeasures.
The above methodology broadly describes a standardised approach to assess risk within IT. This is crucial when assessing the consequences of a major incident. The above can be utilised in the reporting and analysis component of the major incident process to provide a balanced risk assessment of the crisis that has occurred. The method lends heavily on CRAMM but has been simplified for rapid use. CRAMM (CCTA Risk Analysis and Management Method) is a risk management methodology which uses an automated tool based on qualitative risk assessment methodologies. It is used by going through the stages of a CRAMM review, i.e. asset identification and valuation, threat and vulnerability assessment, and countermeasure recommendation. CRAMM is a comprehensive and flexible tool especially for justifying prioritised countermeasures at a managerial level. However, it typically requires qualified and experienced practitioners as opposed to the tool and methods described here are much more simplistic.
A tool is available from under the Resources menu to perform a rapid risk assessment suitable for projects and major incidents within the IT landscape. Direct link here.  Furthermore, DS is able to assist in providing consulting and training with respect to the major incident process.


Popular posts from this blog

The importance of the major incident process

ITIL mentions the Major Incident process as a special case of the incident management process as well its close relationship to problem management.  However, the Major Incident process requires greater clarity and specification as in many large enterprises the process is crucial for overcoming a crisis. A Major Incident typically defined as an incident with severe negative business consequences and an important duty of any designated Information Technology (IT) resources is to deal with Major Incidents in a structured manner.  We will address this important topic in a series of articles that specifically addresses the process and crisis management in general. Read the full article here .

NeDi - a great open source tool for network management

NeDi is an open source software tool which discovers, maps and inventories your network devices and tracks connected end-nodes. Features Network Discovery, management & monitoring Netflow & sFlow based traffic analysis IT Inventory & lifecycle management Network topology visualisation Locate & Track Computers Security audits & more VM, DC management Printer management Backup Configs IT Reports Read more about it here or contact DS to find out more.

On board PowaINFRA gateway deployment

DS has an on board version of the PowaINFRA gateway that can be deployed on a vehicle. The gateway is powered by the 12V of the vehicle and typically installed under the dash. Additionally, the gateway has an extra sensor and metric ability of using Geo-location. The on board PowaINFRA gateway has the same capabilities as the standard PowaINFRA gateway and is compatible with the sensors in the PowaINFRA range. Other vehicle tracking systems are typically wired and thus rely on the sensors to be connected to contacts on the main unit. No only is this a more difficult installation but it limits the number of sensors installed in a vehicle as it is not cost effective. Most vehicle installation of refrigerated trucks only have one temperature probe installed, either on the output or return vents of the cooling units. This is typically located at the front of the refrigeration trailer and the cooling varies within the trailer. Thus it is likely that the load can ex