Practical example

The scenarios given in the preceding sections describe management settings as found in typical IT organisations today. This section aims to complement the high-level scenarios by showing an example pro- cess in more detail. It is intended to illustrate the challenges arising when the process specification described in Section 2.3.2 is employed in order to govern an aspect of infrastructure management—in this case, the patching of software components—while using commonly encountered types of management tools (described in Section 2.3.4). Thus, the technical example examined in this section aims to narrow the gap between the management scenarios treated in the foregoing sections (2.1 and 2.2) and the actual process translation scheme ad- dressed in Chapter 4. Then again, due to its structure, the example can be viewed as a third scenario, that focuses on the technical de- tail in dealing with process-oriented management, instead of paying attention to scale, inter-domain issues and operational complexity.

2.3.1. Setting

Consider an IT organisation like the ones presented in the scenar- Processes and

management

tools ios. It has committed to process-oriented management, and it has defined a number of vital IT management processes in a detailed manner, based on the ITIL. Among these are Incident, Change and Configuration management. The organisation uses tools to support its processes and strives to automate process execution. It also em- ploys a suite of systems and network management applications.

A common case in any organisation operating IT infrastructure is Operative practice the discovery of security flaws in the deployed application software. In recent time, when important flaws are discovered in a software, its producer or distributor is expected to offer her customers a solu- tion. Such solutions includepatchesthat correct the flawed software behaviour, work-arounds that offer a way to operate the software without exposing to a certain risk, or new, corrective releases of the software. Typically, periodic notifications of new threats, as well as the solutions available are issued by email. Examples include the bulletins sent by most Linux distributors, as well as the notifications issued by various Computer Emergency Response Teams (CERT). In urgent cases, supplementary notification are issued in order to shorten the time-span during which customers are exposed. Our example organisation takes security issues seriously and aims to integrate the evaluation of security bulletins, the acquisition of corrective means (e.g. patches), as well as their deployment, into its operational IT management processes. Naturally, this task should be accomplished using the facilities already present in the organisation, and elicit the smallest possible amount of additional effort on the part of the management crew.

2.3.2. Example process partition

As a first step, the handling of patches is included in the process specification. A possible result is sketched in Figure 2.4.

1. Once the discovery of a security flaw is advertised, this infor- mation is made available to the incident management process. This process is responsible for handling situations that disrupt nominal operation of services (see Section 3.1.1.1).

2. Within the incident management process, an incident record is filed.

3. The affectedConfiguration Items(CI), i.e. systems, are identi- fied by means of the organisation’sConfiguration Management Database(CMDB).

4. Based on this information, the incident can be classified ac- cording to its severity and the expected impact on the iden- tified CIs. Classification associates a priority, noted in the incident record, with the security loop-hole in question.

Queue Incident Record Query CMDB

Classify incident

Notify Service Desk File Request for Change

Rollback change Patch failed Incident resolved

Manual handling Req. Manual Intervention

PIR success? no

yes

Execute standard change

no Trigger standard action ?yes

incident Management

Post implementation review

Change Management

Urgent patch

5. The organisation’s Service Desk should be notified of the sit- uation in order to be able to respond to customer’s queries, if necessary.

6. Any change should be handled by thechange management pro- cess; therefore, a Request for Change (RfC). For recurring, low-impact changes, it is common to define a class of changes asstandard change, which are pre-authorised require less effort from the change management process.

7. The change is scheduled in a Forward Schedule of Change (FSC) according to its priority.

8. At the appropriate point in time, given by the FSC, the patch is actually installed on the group of machines requiring it. 9. A Post Implementation Review (PIR) ensures the continuity

of service from the machines that have been patched.

10. If the PIR is deemed successful, the incident is marked as solved, and a message is generated to propagate the notifi- cation of success.

11. In the contrary case, if the PIR identifies unacceptable flaws, the change is rolled back, and the relevant parties are notified of the failed change.

The deploying of security patches on the organisation’s machines spans two different processes. It involves arguably two different ad- ministrative domains: that of the software distributor advertising the patch, and that of our example organisation.

2.3.3. Automation of activities

In our setting, several of the activities can be performed automati- cally, without human supervision. Examples include creating an in- cident record and placing the record in a queue, notifying the Service Desk, classification according to formal criteria, and the installation of the patch.

Some of the activities require human interaction. The obvious case is the Manual Intervention action. If a patch is deemed as critical, human supervision is necessary. Another example is the evaluation of the installed patch within thePIRactivity. Some aspects of the change can be evaluated in an automated manner, e.g. the success

Vulnerable server Infrastructure Monitoring_system Workflow management system Trouble− ticket system Package manager install update observe function issue ticket execution trigger informationrelay

Figure 2.5.: Management tools involved in the example setting.

or failure of the installation itself, the ability of the updated software to run, or the ability of an updated component to interact normally with other components. Other aspects concerning the behaviour of a component after change may be more subtle, and intervention of a human administrator may be necessary to confirm their functioning correctly.

2.3.4. Tools

The activities in our example can be supported by appropriate tools. The process activities pertaining to incident management can be supported by a ticketing tool, the deployment and rollback of a patch can be facilitated by a packet management utility, and some of the activities (e.g. the CMDB query) may be supported by in-house tools designed with our example organisation’s setup in mind (e.g. interface and schema of its CMDB).

The diagram in Figure 2.5 shows the tool setup in our example. The outer sector contains tools for process support, while the next-inner sector contains the tools for technical management. The managed infrastructure resides at the core of the diagram. The arrows in- dicate interaction between two components. Solid arrows denote interaction which is easily achievable, as it conforms to the purpose

of a component. The dashed arrows suggest interactions that are heavily dependent on the interfaces and data exchange formats of the interacting components.

2.3.5. Challenges

Several issues must be dealt with in order to effectively support ex-

ecution of our example workflow partition. Interoperability issues Heterogeneity of interfaces arising from different interfaces and data formats in the tools must

solved. In our example, this applies e.g. to interoperation between the monitoring system and the trouble-ticket system (effectively, all

dashed arrows in Figure 2.5). The solutions need to be revised ev- Dealing with change ery time a product is exchanged or new ones are added. Changes to the process, as well as changes in the tool-set must be handled

graciously and in a cost effective manner. The collection of tools for Distributed process execution process support and technical management can itself be viewed as a

distributed system. Effective process execution, including the dele- gation of management action to management tools (e.g. the packet manager, in our case) must be feasible even if the components/tools are widely distributed, and some of them reside in other administra- tive domains.

The above challenges, as well as those ensuing from the two scenar- ios described in Sections 2.1 and 2.2, impose requirements on the management approach presented in this thesis. Thus, to effectively address these challenges, the policy-based process realisation scheme proposed in this work must satisfy the set of requirements pertaining to the scenarios described in this chapter. This set of requirements is introduced and discussed in the following section.