Monitoring and Event Management

We need to monitor events, but monitoring covers more than events. Monitoring can be used, for example, to make sure devices are operating correctly, even without any events being generated. Monitoring actually looks for conditions that do not generate events.

Event management is about having useful notifications about the status of the IT infrastructure and services. Event management sets up rules to ensure that events are generated so they can be monitored, captured, and acted on if necessary. Action is the key to event management.

The particular notifications themselves may be vendor specific. However, they are likely to use Simple Network Management Protocol (SNMP), an Internet standard protocol for managing devices on IP networks. Devices that typically support SNMP include routers, switches, servers, workstations, printers, modem racks, and more. Because SNMP is an open standard, it makes interaction between different products simpler. Events must generate useful notifications. The time taken to create meaningful descriptions, with suggested actions, will save effort later.

Event management can be enormously useful in managing large and complex infrastructures. It is often the case, however, that the full value of these tools is not realized. This is usually because there has been insufficient time spent making sure they are configured correctly to only notify staff of events for which they actually need notification. Failing to specify the correct thresholds, for example, will mean that far too many breaches are reported, causing staff to ignore them because they are seldom significant. Of course, this means that significant events may be missed. If events are not filtered properly, the service management tool would be flooded with multiple spurious events, which would make it difficult to use its ability to automatically raise incidents.

Another important definition is that of an alert: An alert is a warning that a threshold has been reached, something has changed, or a failure has occurred. Alerts are often created and managed by system management tools and the event management process. Creating an alert when a disk or mailbox is nearly full is one such example.

Informational, Warning, and Exception Events

Some events indicate a failure that must be fixed, whereas others simply flag that something has happened and should be recorded. These are two types of event: the first is an exception and the second informational. There is a third type—a warning event. A warning event signifies unusual but not necessarily exceptional behavior. Warning events require further analysis to determine whether any action is required. Events will be handled according to their type.

Here are some examples of each type of event:

• Informational
  • A scheduled workload has completed.
  • A user has logged in to use an application.
  • An email has reached its intended recipient.
• Warning
  • A server’s memory utilization reaches within 5 percent of its highest acceptable performance level.
  • The completion time of a transaction is 10 percent longer than normal.
• Exception
  • A user attempts to log on to an application with an incorrect password.

Notice that not all of these examples relate to a failure. (Failures would be alerts.) Some simply contain information, but information that for some reason it is important to record. For example, the business might want to maintain a record of who is using an application for audit purposes.

There are no definitive criteria for determining the type of an event; it depends very much on the specific situation of the organization. For example, an event might be that a previously unknown device has been detected on the network. Some organizations allow their staff to attach their own laptops to the corporate network, in which case the event would be informational. In a highly secure organization, it would almost certainly be treated as an exception.

Filtering

The next topic we’ll examine is event filtering. We don’t have complete control over the notifications that are generated by the configuration items. Hardware manufacturers determine which notifications will be generated, and they may not have provided their customers with the ability to switch them off. A common experience when first beginning to monitor networks is that the monitoring tool is swamped by unrecognized and therefore unneeded notifications.

Filtering prevents the event management system from being overwhelmed by discarding notifications of events that have no significance to the organization.

There are four possible approaches to the problem:

• The first approach is to integrate event management into each service management process. What this means is that each process will identify the events that it is interested in.
• The second approach is to include event management requirements into the design of new services.
• A third approach is to use trial and error—evaluate notifications on a case-by-case basis and adjust the filtering accordingly.
• The final approach is to plan the introduction of event management within a formal project.

These approaches are not mutually exclusive; many organizations will adopt some hybrid of them.

Designing for Event Management

Successful event management in service operation requires analyzing and planning for what will be required. This should happen in the service design phase, although it will continue to be adjusted in service operation. Many organizations attempt and abandon event management, or they fail to achieve real value from it because this crucial design phase has been neglected.

The following questions should be asked when designing a service or planning the introduction of new technology:

• What needs to be monitored?
• What type of monitoring is needed?

  Why are we monitoring?

• When should events be generated?
• What information should be communicated?
• Who are messages intended for?
• Who will respond to the event?

When event management is first established, these questions should be asked about the existing services and infrastructure. Stakeholders who must be consulted include the business, process owners, and operations management staff. Each of these groups will have monitoring requirements, and each could be involved in handling events when they occur.

Instrumentation

Instrumentation refers to specific ways to monitor and control the infrastructure and services. A number of practical issues need to be addressed when designing an event management system:

• How will events be generated? In the case of bought-in components, of course, this question is really, How are events generated?
• How will they be classified? This is not straightforward, and classifications can change over time.
• How will they be communicated and escalated? How exactly will the events get to the appropriate function? For example, how will an exception event trigger the incident management process? Ideally, this will be automated by integrating the event and incident management tools so that an incident will be logged automatically. Of course, this can only happen if the two tools have the necessary functionality.
• What data must be included in the event notification? What data will be needed for the event management system itself to interpret and make sense of the event, and what data will be needed by the function that will respond to the event? If the event relates to an error, then it should include necessary diagnostic information such as error messages and codes. Again, for bought-in software, this question is really, What data is included?
• Another question to be asked relates to the type of monitoring to use. Should it be active or passive?
• Where will event data be stored? There is likely to be a significant amount of event data, so the question of storage is important. Associated with this is the question of how long the data should be retained. This decision must be made on a case-by-case basis in consultation with the relevant stakeholders. Policies relating to retention may also be developed where there are specific requirements from the business, for example, financial sector regulatory requirements.
• How will supplementary data be gathered? In some cases, the event data alone will not be sufficient to evaluate the event. For example, it might be necessary to integrate the event management system with a configuration management database (CMDB).

Correlation Engine

As events are detected, the event management system must interpret and make decisions about how to handle them. This is done by software known as a correlation engine. The correlation engine allows the creation of rule sets that it will use to process events.

Using a correlation engine will enable the system to determine the significance of each event and whether there is any predefined response to an event. Patterns of events are defined and programmed into correlation tools for future recognition. The correlation engine can translate component-level events into service impacts and business impacts, as shown in Figure 3.1.

Event Notification

Let’s look at the initial process activities in a little more detail. Event notification refers to the communication of information about an event. You’ve already seen that some components will generate notifications independently, whereas others have to be prompted by polling.

Event Detection and Logging

Some events will be detected directly by the event management tool. Other events will be detected by a software agent running on the device being monitored. This agent then generates a notification that can be detected by the event management tool. All events are logged.

Correlation and Filtering

In first-level correlation, a decision about whether any further action is required is made, including whether the event has any significance to the organization. Correlation will determine whether an event is informational, a warning, or an exception. We discussed filtering earlier; this is necessary to stop staff from being overwhelmed with events that do not require any action, or multiple reports of the same fault.

Informational events are closed at this point. Exception events will trigger one of the other service management processes. Warning events will go forward to second-level correlation.

Next, we consider the criteria that might be used by the second-level correlation engine to interpret an event:

• The number of similar events might be significant. For example, an event might notify us of an unsuccessful attempt to access our network. If this is just a single instance, we might treat it as informational, but if there have been 500 such attempts in the last 5 minutes, we might judge that we are the target of an organized attempt to break in.
• The number of devices generating similar events might be significant. It might indicate a widespread virus infection, for example.
• The data supplied with the event might indicate its significance.
• Events related to device utilization might be compared with a defined threshold.

The correlation engine determines whether the event requires some action or whether it can be treated as informational and closed.

Actions Taken

Response selection covers a number of possible options. These include the following:

Automation Some events indicate conditions that can be resolved automatically without human intervention. For example, if a file server is detected to be nearly full, then a script could be run that would free up space by archiving old data.

Human Intervention Some events will require human intervention—an alert from a smoke detector, for example. It’s important that the alert be directed to the right person and that the individual knows what to do.

Incident Exception events will normally trigger the incident management process. Ideally, the event and incident management systems will be integrated so that an incident record can be raised automatically. A word of warning, however: this should be implemented only when you are happy that the filtering of events is working correctly. If this is not the case, your incident management system will be flooded with thousands of spurious incidents!

Problem The problem management process might be triggered if the organization has a policy of always investigating the root causes of incidents that impact key services. Event management can support such a policy by automatically raising a problem record when it detects such an incident.

Change Change management can be triggered in two circumstances:

• First, if a previously unknown device is detected, an RFC should be raised, which can be progressed as appropriate by change management to have the device either added to the CMS or removed if required.
• The second circumstance is if a change is needed. For example, a server might need to be allocated more storage from a storage area network (SAN).

Remember, sometimes it will be necessary to trigger a combination of these responses.

Review and Closure

There could be thousands of events each day, so it’s unlikely that every one of them could be reviewed. It’s sensible to review only what the service provider considers to be significant events. It is probably unnecessary to review events that have triggered other service management processes except to ensure that the triggers were effective.

Most events are neither opened nor closed but just logged in management systems or system logs. Many others can be closed automatically. For example, when a script is triggered to respond to an issue, the script itself could check that the corrective action has worked and generate an event to that effect.

Triggers

Any type of change in state can trigger event management, and an organization should define which of these state changes need to be acted on. Some examples are shown here:

• Exceptions to any level of CI performance defined in the design specifications or standard operating procedures.
• A breach of a threshold in an OLA could also generate an event.
• Any exceptions to a process, such as a failure to complete a process within the target time. An exception could also be a routine change that has been assigned to a build team or a business process that is being monitored by event management.
• The completion of an automated task or job could trigger the issuing of an event, as could a status change in a server or database CI.
• A user accessing a particular application or database could also cause an event to be issued if this is information that the business or the IT department wanted to know about. For example, IT may wish to track how often a service is being used to decide on the number of licenses required, or the business may wish to know how often a customer service representative needs to refer to the knowledge base to answer a query, as this might indicate a training requirement.
• The more usual trigger for an event, such as a situation in which a device, database, or application has reached a predefined threshold of performance.

Inputs

Inputs to event management usually come from service design and service transition. They include the examples listed here:

• Operational and service level requirements associated with events and their actions.
• Alarms, alerts, and thresholds for recognizing events.
• Event correlation tables, rules, event codes, and automated response solutions that will support event management activities.
• Roles and responsibilities for recognizing events and communicating them to those who need to handle them.
• Operational procedures for recognizing, logging, escalating, and communicating events.
• SLAs, which can be used by the correlation engine to determine the significance of an event or to identify a performance threshold.
• Rule sets that are provided by technical or application management staff based on the monitoring and management requirements. For example, the capacity management process would define the capacity thresholds that should generate an event.
• The roles and responsibilities of all those involved.
• Procedures for logging and escalating events as required.

Outputs

Outputs from event management are usually passed to other service management processes, such as incident management, change management, and request fulfillment. They include the examples listed here:

• Events that have been communicated and escalated to those responsible for further action
• Incident, problem, change, or request records required as a result of an event
• Event logs describing what events took place and any escalation and communication activities taken to support forensic, diagnosis, or further CSI activities
• Events that indicate an incident has occurred
• Events that indicate the potential breach of an SLA or OLA objective
• Events and alerts that indicate completion status of deployment, operational, or other support activities
• Populated service knowledge management system (SKMS) with event information and history

The most obvious output of the process is the events themselves. These should have been communicated and escalated to the appropriate people. Another output is a chronological event log describing what events took place and any escalation and communication activities taken. This may be useful information if further investigation is required or to spot possible improvement opportunities.

Some events output by event management will indicate that an incident has occurred, and others will warn of the potential breach of an SLA or OLA objective. Of course, as we have said, not all events show that something is wrong, and many events will just indicate successful completion of deployment or operational activities. The data output from event management can be used to populate the SKMS with the event information and history.

Interfaces between Event Management and the Lifecycle Stages

Finally, let’s consider the interfaces event management has with the other lifecycle stages and their associated processes. Event management can interface with any process that requires monitoring and control, especially those that don’t require real-time monitoring but do require some form of intervention following an event or group of events. First we’ll consider how the process can even help the business directly.

Event Management Process Owner

The event management process owner’s responsibilities may include

• Carrying out the generic process owner role for the event management process (see Chapter 1)
• Planning and managing support for event management tools
• Ensuring the integration of this process with other processes in the operational lifecycle stage by working with other process owners

Event Management Process Manager

The event management process manager’s responsibilities may include

• Carrying out the generic process manager role for the event management process (see Chapter 1)
• Planning and managing support for event management tools
• Coordinating the interfaces between this and other service management processes

Event Management Process Practitioner: Other Roles

There may not be a specific identification of a “practitioner” role in the event management process, but the activities are carried out by a number of other roles.

Separation of Requests and Incidents

Some organizations separate requests from incidents because incidents are unplanned and unwanted; a major aim of service management is to reduce the number of incidents through improved design, problem management, and continual service improvement. In contrast, there may be a policy of increasing the number of items that can be dealt with through the request fulfillment process. The targets for incidents and requests may be very different: requests often have specified lead times, which are dependent on other factors (such as the user not being given access until they have attended a training course), whereas with incidents, the aim is to resolve each one as quickly as possible. Where there are a significant number of requests to be fulfilled, a separate process with a different record type should be used. This allows the service provided to be monitored and reported on in a more appropriate way than using incident reporting. Also, it is likely incidents will be given priority over requests, resulting in requests not meeting SLA targets because fixes take precedence. Similarly, if dealing with requests has an impact on incident resolution, the customer will be dissatisfied.

Request Models

The process needed to fulfill a request will vary depending on exactly what is being requested, but it can usually be broken down into a set of activities that have to be performed. For each request, these activities should be documented into a request model. In this case, a request model defines how to handle a particular, frequently occurring request.

The model should define the sequence of actions that must be performed, who will perform them, and the required timescales for each of the steps as well as for the fulfillment of the complete request. Any escalation paths that may be required should also be included.

Menu Selection

The effectiveness of request fulfillment is hugely enhanced if it is supported by a software tool, and probably a tool that is web based. Such a tool should feature a menu of available services from which the user is able to select. The provision of all the required information can be enforced by using mandatory fields and providing drop-down lists of possible options. In addition, the tool should set the user expectations by showing lead times, costs, and so on.

Where organizations are already offering a self-help IT support capability to the users, it makes sense to combine this with a request fulfillment system as described.

Specialist web tools that offer this type of “shopping basket” experience can be used together with interfaces directly to the back-end integrated ITSM tools used to manage the request fulfillment activities.

Request Status Tracking

The request owner must be able to track requests through their lifecycle and report progress to the requester where appropriate. Each organization will choose the appropriate statuses for its needs, but let’s consider the most common statuses that are used:

• Draft indicates that a request is being prepared for submission. For whatever reason, at the moment the requester is unable or unwilling to submit the request.
• In Review indicates a request that has been authorized but is now under review by the relevant fulfillment team. They could be planning a desktop installation, for example.
• Suspended indicates that fulfillment activity has been suspended. This may be because the fulfillment group is waiting for action or information from the requester.

The other common statuses—Waiting Authorization, Rejected, Canceled, In Progress, Completed, and Closed—are self-explanatory.

Prioritizing and Escalating Requests

All service requests should be prioritized based on a standard set of criteria. This can be done by considering the impact and urgency of a request, as with incident management. Alternatively, an organization might have set lead times for different request types.

A variety of reasons exist for escalating a request. Perhaps the obvious one is that a request might not be fulfilled within agreed timescales. Escalation might also be required if the process is being misused by the business. For example, the relocation of up to five workstations might be a service request but more than five would require the submission of a change request. Some managers in the business might try to get around this limitation by submitting several requests, each for five workstations but amounting to a large number in total. The request owner should be on the alert for this and escalate in the agreed manner.

Approval

As you’ve seen, many requests will incur a cost that must be approved. Some requests will have a standard charge—a software license or a standard workstation, for example. In other cases, the fulfillment group must establish the cost in the context of what exactly has to be done, as with an equipment move, for example. The role within the business responsible for approving the spend should be identified within the request model. Financial approval can be automated, and it may take place before the request is seen by the service desk. Requests for standard cost items may be routed to the approver before arriving at the desk.

Sometimes other types of approval are needed. These may include compliance with the organization’s policies, especially in regard to information security, or technical approval to confirm that the request will work with the infrastructure. Request fulfillment must have the ability to define and check such approvals where needed. Procedures for obtaining required approvals should be included as part of the request fulfillment models to save time in processing the service request.

Coordination of Fulfillment Activity and Closure of the Request

A request, including fulfillment, can be handled in many ways. Some requests can be automated—password resets, for example. When human intervention is needed, the request can be fulfilled by a dedicated fulfillment group, the technical support teams, suppliers, or a combination of these. Remember, though, that ownership of requests should remain with one team—usually the service desk, unless a dedicated request team exists.

The service desk should monitor and chase progress and keep users informed throughout, regardless of the actual fulfillment source.

When the service request has been fulfilled, it must be referred back to the service desk for closure. The service desk should go through a closure process that checks to see whether the user is satisfied with the outcome.

Receiving the Request

The first activity is receiving the request. Most service requests are received either from the web portal or at the service desk, but they could come in by other routes, such as email or even as requests for change (RFCs). From the point of view of the service provider, the preferred route is through the web portal because this will reduce the calls to the service desk. Not all incoming requests will be service requests; they could be incidents or change requests, in which case they must be routed to the appropriate process.

Logging the Request

When a request is received, it should be logged and allocated a unique reference number, and all necessary information should be recorded. The web portal should be designed to help the requester provide the necessary information. The request record should be updated as necessary as the request proceeds through its lifecycle with date- and time-stamping to maintain a track of what happened and when.

Validating the Request

The request is examined to confirm that it is valid; this includes making sure the request is within the scope of the IT services being offered. The web portal may help by restricting what can be logged to the available types of service requests. These tools ensure that the source of the request is valid and that only valid types of request are issued. Any requests that are invalid should be returned to the requester with an explanation; for example, the requested service might not be provided by the service provider.

Categorizing the Request

Categorizing the request will enable future analysis and reporting. As with the categorization of incidents, some thought should be given to the system employed. Requests can be categorized in a number of ways. For example, they can be categorized by activity, such as password reset or software installation. Another example is categorizing by the function that will fulfill the request.

Prioritizing the Request

Prioritization will be in line with business need, taking into account the impact and urgency of the request. A model like the one described in Chapter 2, “Incident and Problem Management,” for the prioritization of incidents could also be used here.

Authorizing the Request

We discussed the need for all requests to be authorized as one of the request policies. The degree of rigor needed here depends very much on the type of request. Requests that cannot be authorized should be returned to the requester with an explanation of rejection.

Fulfilling the Request

After a request has been authorized, it is reviewed by the service desk and the appropriate fulfillment function is determined. In some cases, this will be the service desk itself; in others it might be a dedicated fulfillment team or even a supplier.

The request is then fulfilled by performing the actions specified in the appropriate request model. The request model can take a number of forms. In many organizations, it will simply be described in a written document; in others, a workflow tool will be used.

Completion and Closure of the Request

When the request has been fulfilled, it can be closed. Usually there will be a two-stage closure. The first stage simply records that, so far as the service provider is concerned, the fulfillment actions are complete. The second stage is the final closure, which should be performed only after consulting the requester.

If the service performed is chargeable, then at this point the appropriate charging mechanism is triggered. This might be sending a bill or registering a recharge. The service desk should check that the request documentation is up-to-date and that it is correctly categorized before final closure. Any updates to the CMS need to have been completed. This is also the time to conduct a satisfaction survey.

Trigger

As previously explained, the request fulfillment process is triggered when a user submits a request. As you have seen, this may be delivered directly to the service desk or via the web portal where users can choose from a list of possible requests.

Inputs

The main input to the process is a request from the user. As you’ve seen, this can come by a variety of routes, each with its own format of information. Another significant input is the authorization form that may be required for some requests. Some requests may be logged as RFCs. Some requests will be for information, whereas others are for standard goods or services to be supplied.

Outputs

The following list includes examples of outputs from the process:

• Requests that have been authorized or rejected and those that are canceled.
• Some requests may be rerouted as incidents. For example, a user requests a new laptop because their current machine keeps crashing. This could be rerouted to resolve the fault and thus save unnecessary expenditure on new equipment.
• Status reports may be output from the process.
• Where a standard change is required, an RFC must be created.
• Some requests may be routed as changes because they are asking for nonstandard products or applications and need to be approved for use within the organization.
• The request should be updated as it is fulfilled.
• When the request is completed, the output will be a fulfilled request, which should then be closed.
• The final output is the update to the CMS when standard changes have been made.

Interfaces

Examples of primary interfaces with request fulfillment are as follows:

Financial Management for IT Services Some requests may be chargeable, and financial approval may be required.

Service Catalog Management The services that can be requested should be listed in the service catalog.

Release and Deployment Management This will interface with request fulfillment when the request concerns the automatic deployment of new or upgraded components. In such cases, the release is predefined, built, and tested and then deployed on request.

Service Asset and Configuration Management The CMS will need to be updated following any changes that may have been made as part of fulfillment activities. Where appropriate, software license checks and updates will also be necessary.

Change Management When a change is required to fulfill a request, it will need to be logged as an RFC and progressed through change management.

Incident and Problem Management As discussed, requests may be handled using the incident management process. Where appropriate, it will be necessary to relate service requests issued by IT to any incidents or problems that created the need for the requests.

Access Management This process may be involved with request fulfillment activities to ensure that those making requests are authorized to do so in accordance with the information security policy. Request fulfillment can act as the input to the access management process in relation to the creation and deletion of accounts.

Request Fulfillment Process Owner

The request fulfillment process owner’s responsibilities may include

• Carrying out the generic process owner’s role for the request fulfillment process (see Chapter 1)
• Designing request workflows and models
• Working with other process owners to ensure an integrated approach across all processes

Request Fulfillment Process Manager

The request fulfillment process manager’s responsibilities may include

• Carrying out the generic process manager’s role for the request fulfillment process (see Chapter 1)
• Planning and managing support for request fulfillment tools and processes
• Coordinating interfaces between this and other service management processes
• Handling staff, customer, and management concerns, requests, issues, and inquiries
• Ensuring that request fulfillment activities operate within service level targets
• Proactively seeking improvements in the process
• Managing the gathering of customer and user feedback on the process
• Managing resources and resourcing levels
• Ensuring that service requests are carried out in a timely manner and according to any required authorization
• Representing request fulfillment at CAB
• Reviewing process records for accuracy and consistency

Request Fulfillment Process Practitioner/Analyst

This role is responsible for the day-to-day activities and ensures that service requests are completed to a high level of customer satisfaction. The role includes the following:

• Providing a single point of contact and end-to-end responsibility to ensure service requests are properly carried out
• Triaging service requests at point of contact to allocate resources
• Communicating service requests to other process areas involved in the process
• Ensuring service requests are appropriately logged

The initial handling of service requests is commonly carried out at the service desk, but the eventual fulfillment will be undertaken by the appropriate service operational staff, or suppliers, as required. Often there is no need for additional or specific roles to be identified. In certain circumstances, where the workload justifies it, a dedicated team may be created to carry out the process.

Request Access

A request for access can be made in a number of ways:

• The access request could be handled as a service request through the request fulfillment portal.
• It may result from the completion of a request form.
• If the change of access affects many users, a request for change will probably be used. For example, the transition of a new service will mean updating the access rights of everyone who will use the service.
• Another route is through an automated process. For example, each year a college or university will enroll possibly thousands of new students, and each of them must be granted access to student IT services. This is often done automatically by the student registration system when the student actually registers.
• The request may also come automatically from the HR system when a new member of staff is recorded or the status of an existing employee changes, such as when someone resigns or is transferred or promoted.

All requests, whether or not they are valid, are logged.

Verifying and Validating

The access request must then be verified. The identity of the requester must be confirmed, and the access requirement must be judged as legitimate.

Usually, an existing user’s username and password are accepted as proof of identity. In more secure environments, biometric data or physical identification devices can be used.

For new users, some physical evidence of identity will be required, such as official proof of identity (such as a passport or driver’s license).

New users include not only new permanent staff members but also temporary and third-party users such as visitors, contract staff, and vendors. The organization will define how a request will be verified.

The second aspect of verification is checking that the request is legitimate—that is, the user is authorized to have the rights requested. This verification must be independent of the requester. A user cannot verify the legitimacy of their own request. Often a request will be verified by a line manager or HR. Requests that come by way of a RFC will have been authorized through the change management process.

Some services will be available for use by anyone who requests them; there should be a policy that defines this. If the request is not valid, then it will be logged and returned to the requester. An incident may be raised to investigate why an invalid request was created, if thought necessary. A valid request will be actioned appropriately.

Provide Access

The task of providing rights is often delegated to a specialist technical or application team that has the necessary knowledge and skills. This task can be automated by using access management tools that interface with multiple applications. This is only possible, of course, if the design of the applications included this as a requirement.

Access rights are associated with a role: a payroll clerk has the right to use the payroll system. Users can occupy multiple roles, each of which brings a set of rights, and sometimes these conflict with some enterprise policy such as the separation of duties. For example, it is usual practice to ensure that a person who places an order with a supplier is not able to authorize payment. Where a role conflict occurs, access management should escalate the issue to the appropriate stakeholder, who will be someone in the business area concerned. (For example, if the roles are within the finance department, the issue would be referred to the appropriate stakeholder in that department; if the roles are within the IT department, the appropriate IT manager would be consulted.)

Monitor Access

Once the access has been granted, the status of the user should be monitored to ensure that they still have a valid requirement for the access. In practice, this can be difficult to achieve. Access management should be notified of staff who leave so that their access can be revoked, and many organizations have robust procedures to ensure that this is done. Many organizations encounter difficulty in tracking the changing roles and accompanying access requirements of users, especially those who have been in the organization for many years. In this situation, new access requirements are added to existing rights, with no verification that the existing rights are still required. Consideration should be given to adding questions about existing access requirements to the access request form. The HR department needs to be made aware of the importance of supplying information regarding changing job roles to access management in order to protect the organization’s data. Access management should understand these different types of staff changes and determine how it will become aware of them. Ideally, this will be automated by an interface with the HR system. The failure to respond to changes in status is a common security issue. It leads, for example, to computer accounts remaining available for use even though the users have left the organization.

The tracking access activity might trigger a security incident if, for example, an unsuccessful attempt to access a service is made by a valid user.

Remove Access

The last activity that we’ll look at is removing or restricting a user’s rights. There are a number of circumstances when this might be necessary. Although in many cases the modification is permanent, such as in the case of dismissal or promotion, there may be situations where this is only temporary. For example, in some organizations, a user’s computer account is suspended when they go on leave.

Access should be permanently revoked when a user leaves an organization; again, the HR department needs to understand the importance of informing access management quickly in this situation.

Access management has to ensure that rights are not improperly used, which will require that access is logged and tracked. The degree of oversight required is determined when the service is designed and the appropriate logging mechanisms are provided. Should possible misuse be detected, the process must respond appropriately. This will usually entail raising a security incident and alerting stakeholders. In this situation, access may be temporarily revoked during the investigation, with access being restored if the misuse is deemed to have been an innocent mistake or permanently revoked if it is found to be deliberate. The access management process may be required to provide a record of access, perhaps in the context of the investigation of criminal behavior.

Triggers

Access management is triggered by a request for a user or users to access a service or group of services. This could originate from a number of circumstances.

The first possible trigger is an RFC, especially where a large number of access changes are required, perhaps as part of a rollout or project.

Another possible trigger is a service request. This is usually initiated through the service desk, or input directly into the request fulfillment system, and executed by the relevant technical or application management teams.

A request from human resources is another possible trigger. In this situation, HR management personnel make the request through the service desk. These requests are usually as a result of hiring, promoting, relocating, termination, or retirement.

The final trigger may be a request from the manager of a department, who could be performing a human resources role or who could have made a decision to start using a service for the first time.

Inputs

The inputs to the process are those that relate to the triggers, such as these:

• Authorized RFCs and authorized requests to grant or terminate access rights
• The security policies of the enterprise
• Any information about the identity of users

Other inputs are the operational and service level requirements for granting access to services, performing access management administrative activities, and responding to events related to access management.

Outputs

The access management process has the following outputs:

• The provision of access to IT services in accordance with information security policies
• The access management records showing when access has been granted or denied and the reasons for the denial
• Timely communications concerning inappropriate access or abuse of services

Interfaces

The access management process interfaces with a number of other service management processes.

A key interface is the one with information security management. As already stated, access management acts under the guidance and instruction of information security management and plays an essential part in ensuring that the requirements of the information security policies are met.

Many requests for access will come from the change management process in the form of authorized requests for change or even standard changes.

It is through the service level management process that access requirements and criteria are agreed on with the business on a service-by-service basis.

The relationship of the process with IT service continuity management is interesting. Access requirements may need to be varied should the continuity plan be invoked. Also, there may be a need to grant temporary access when the plan is being tested.

Request fulfillment provides a route for users to submit access requests.

Identity

Examples of things that may be included in the identity of a user are

• Name
• Address
• Contact details, such as telephone number and email address
• Physical documentation, such as driver’s license, passport, or marriage certificate
• Numbers that refer to a document or an entry in a database, such as employee number, tax number, government identity number, driver’s license number
• Biometric information, such as fingerprints, retinal images, voice recognition patterns, DNA
• Expiration date (if relevant)

Access management should provide access to IT services or organizational information to any legitimate users. These could include permanent employees or contractors temporarily engaged by the organization, vendor personnel such as account managers or support staff, or customers.

It is normally the responsibility of the organization to verify a user’s identity before they join the organization and are granted access to IT systems or services. But IT will need to verify that the correct person is associated with the information provided. The higher the level of organizational security, the more information will be required to verify an individual.

Temporary access is just as important to manage as permanent access. Any identification will be captured and filed as part of an employee record.

Users, Groups, Roles, and Service Groups

It is often helpful to group numbers of users together to make the management of access rights more effective. The term user profile or user template can be used to describe these.

Many organizations have a standard set of services that users can access and may use this for grouping users together. But it must be flexible enough for the individual requirements to be catered for, as well as providing sufficient control. A catalog of user roles may be useful to help the definition of user groups.

However, the data profiles of all groups or users must be subject to the relevant legislation or governance—for example, the Data Protection Act (UK), or state-specific legislation in the US. This should be specified as part of the information security management policy.

Access Management Process Owner

The access management process owner’s responsibilities may include

• Carrying out the generic process owner role for the access management process (see Chapter 1)
• Designing access request workflows
• Working with other process owners to ensure an integrated approach to the management of access request across the lifecycle

Access Management Process Manager

The access management process manager’s responsibilities may include

• Carrying out the generic process manager role for the access management process (see Chapter 1)
• Planning and managing support for access management tools and processes
• Coordinating interfaces between access management and other service management processes

Access Management Process Practitioner/Other Roles

Access management is the operational execution of the information security management and availability management processes. As a consequence, the practitioner roles are most likely to be defined by these design processes, based on the content of the information security policy. These roles can be identified as follows.