Phase II: Evaluation
CHAPTER 5: CONCEPTUAL MODELLING 5.1. Introduction
6.7. Demonstration of the Interface Prototype
6.7.2. Shared Situational Awareness
159
that users can easily infer the most pressing incident in the organisation. Figure 6-12 shows how the individual situational awareness incident projection simulation can be retrieved. Figure 6-12 shows the projected probability of incident occurrence (vertical) in relation to incident case type (horizontal) that occurred in the organisation.
Figure 6-12: An Instance of an Individual Situational Awareness Incident Projection Report
160
The ISIRT reviews, comprehends, projects, analyses and incorporates supplementary incident information. The system further shows the detailed data-set components required to review and report incidents at the individual level. After any stakeholder (end-user, management, ISIRT member) has registered and input the data required by the system, the information will be available for display for end-users and management. As part of the assessment, decision and response processes of ISIM, the ISIRT then determines the parameters of the incident such as
‘incident severity’ and ‘incident precaution’.
Figure 6-13: An Instance of Information Security Incident Severity Decisions by ISIRT
Figure 6-13 shows how ISIRT members engage in the processes of ISIM by analysing the incident attributes such as incident reporter, incident type, incident intention, incident source, IP address, and incident damage. The ISIRT uses these attributes to determine the incident severity level. This contextual information is shared with users which enhances their comprehension of information security incidents. Moreover, ISIRT members have the access and the credentials to notify users of actions taken and actions required by other users and stakeholders. It also helps users in comprehending the type of action to undertake after the review of the decision of the severity of the incident that users have previously reported to the system. The ‘precaution’ for incidents, which is part of the response process of ISIM, is significant in the proactive management of incidents. Accordingly, users can prioritise and characterise the incidents from their prior knowledge or the organisational information security policies and procedures of the institution or the national information security policies.
161
Moreover, it is their responsibility to engage with the recommended precautions. The
‘precaution’ function helps users to take actions as part of the response phase of ISIM.
Shared situational awareness includes various functions related to incident processes and other related functions such as conveyance, visualisation, and convergence. The shared situational awareness component coordinates the incident information received from individuals, analyses, comprehends, decides, and disseminates further information to other users.
Comprehension Component – Shared Situational Awareness
Comprehension of an incident at the shared level includes triangulation, and correlation of incidents. The comprehension function and report in the shared situational awareness originates from various stakeholders. In addition, the ISIRT comprehends and analyses the incident information to be incorporated in the central system for dissemination to all users. In the shared situational awareness component, as depicted in Figure 6-10, the comprehension process enables all users to get access and understand the shared incident information made by the ISIRT such as incident category, incident precaution and incident severity.
Projection Component – Shared Situational Awareness
The simulated interface prototype summarised and projected the occurrences of an incident.
This will possibly be implemented using statistical data extracted out of existing data. Thus, projection may be automated. The summarised projection can be presented in graphic illustrations based on required information such as severity, incident characteristics, and attack level. An example of showing a visualisation of the next incident predicted (i.e., projection) is shown in Figure 6-14 (for ISIRT) and Figure 6-20 (for managers). The projection information depicted in Figure 6-14 was not part of the demonstration for the participants, however, it was prototyped. The projection phase involves summary inference and reporting from the input system. These forms of reports can be retrieved for multiple users according to the incident type and severity level of the incident to be reported in an illustrated manner for shared visual understanding. These types of reports may be filtered according to the mechanisms of role- based access control however it is beyond the scope of this thesis to depict the various projections per role.
162
Figure 6-14: An Instance of an Information Security Incident Projection Report for ISIRT Members
(
The projection diagram (Figure 6-14) shows how incident parameters are related – it enables the ISIRT members to visualise and to consider the predictions of patterns of incident attacks over a period of months in their organisation (uppermost graphic). It also allows ISIRT members to visualise the projected incident pattern in the organisation through various characteristics such as the critical impact of the projected incident (lower graphic). Such projections of an incident support the decision-making processes of users, management and ISIRT for planning and preparation for the next incident.
The processes of ISIM follows a cyclic process – plan and prepare; detect and report; assess and decide; respond (i.e., prevent, reduce, recover); and lessons learnt. These processes should be stored in a CISID. The following section discusses how the different processes of ISIM are incorporated into the interface prototype of the model.
163 Planning and Preparation
The planning and preparation processes are promoted by the ISIRT in consultation with end- users and management. This part of the process was not demonstrated in the interface prototype as it is mostly related to managerial and the decision-making process. However, after managers have reviewed the incident comprehension summary report and various visualisations (see Figures 6-19 - 6-23), they can plan and prepare for future incidents.
Assessment
The ISIRT assesses and categorises incident information that is submitted from individual users. Figure 6-15, which is demonstrated for the participants and available in the prototype, shows the assessment of different incident information. It is the responsibility of the ISIRT team to verify, assess and provide incident metadata (such as incident category, incident cause, etc.) to the incident report. This is related to the attributes such as reported by incident type, incident intention and incident source, IP Address, damage, and incident cause.
Figure 6-15: Instance of an Incident Categorisation Report
Decision (Determine Severity)
ISIRT members are involved in the process of decision-making for various parameters of incident information (see Figure 6-13). ISIRT members determine the incident ‘precaution’
(i.e., the response) and severity. Note this is merely a subset of the activities that the ISIRT
164
must engage in during an incident scenario. Here, contextualisation of past experiences supports the decision-making processes of ISIM. The ISIRT determines incident severity as reported by individual users. For instance, ‘INCID 001’ was reported by ‘Abebe’ from ‘Branch C’. The damage is reported as a ‘software crash’. The ISIRT reviews the incident and may determine its severity to be ‘critical’. Perhaps the severity level for the incident by the user had been reported as ‘Information’ initially. (Note, a severity level of “Information” denotes a less critical incident and requires that users be merely informed about them). In this scenario, the revised severity level of the incident from the ISIRT will be disseminated to the users that have the required role-based privileges. This will assist in the relevant users having a shared situational awareness of the current state thus improving the stakeholder’s comprehensibility of incident information.
While it is suggested that these types of reports may be filtered according to the mechanisms of role-based access control, it is beyond the scope of this work to specify how the information per role will be disseminated as it will depend on the organisational context. Perhaps end-users may not have access to the user’s details who reported the incident in order to maintain privacy or perhaps managers will only have access to information related to their branch that they manage.
Response
Users can review the ‘response’ to an incident which is formulated by the ISIRT. For instance, users have awareness of what actions or ‘precautions’ to undertake for a certain incident. The response for a particular incident (such as changing passwords for a compromised system) may be reproduced from similar incidents within similar contexts. Figure 6-10 demonstrates the different types of precautions that users should be aware of for each incident. The CISID will store this type of information.
Lessons Learnt
To promote the ‘lessons learnt’, users are provisioned with a summarised data of incidents (i.e., closure report) The prototype demonstrated a possible approach to ensure compliance with the
‘precautions’ instituted by the ISIRT. The approach involves the receipt of personalised messages to ensure compliance. The compliance or non-compliance with information security
165
incident precautions will enable users to either gain access or to have their access rights suspended respectively. For instance, Figure 6-16 and Figure 6-17, which are demonstrated in the demo and available in the prototype show distinct compliance reports for two different users. Figure 6-16 shows a positive compliance report and Figure 6-17 shows a negative compliance report to suspend the user.
Figure 6-16: An Instance of a Positive Compliance Report
Figure 6-17: An Instance of a Negative Compliance Report
166 Conveyance and Convergence
The notion of conveyance and convergence is a key function within shared situational awareness. Figure 6-18, which is demonstrated to participants in the demo and available in the prototype shows the prototype interface of the conveyance and convergence mechanisms.
Figure 6-18 simulates the incident reporting mechanism in a converged approach so that it is retained in the central repository from multiple individuals for shared access. It is implied in the conceptual model that each user will convey (i.e., conveyance) raw information about an incident. It is possible that multiple users can convey information on the same incident type so that it will be combined by the ISIRT. Similarly, multiple users could convey information on similar (but not the same) incident, also contributing to a common understanding thus reaching convergence. The implementation of these processes is beyond the scope of this project.
Figure 6-18: Conveyance and Convergence of Incident Information