Front cover
Using the IBM Security Blueprint to Address Business Risks for Employee
Offboarding
Redguides
for Business Leaders
Axel Buecker
Gordan Greenlee
Calvin Powers
Investigating business risks and mitigation
controls for offboarding procedures
Introducing control processes and maturity
models using the IBM Security Blueprint
Applying product and service solutions to
the maturity model
Executive overview
In today's dynamic business environments, an organization develops relationships with its
customers, contractors, and business partners at a faster pace than ever before. The IBM®
Smart IT Infrastructure1 initiative is designed to take these challenges head on, making the
IT infrastructure as nimble and resilient as the organization needs it to be.
One of the major concerns across all types of organizations is the need to remove access to
IT assets as quickly as possible when a relationship with an employee, contractor, or business
is ended, especially if the relationship ends on less then congenial terms. As we note later in
this guide, surveys from the Ponemon Institute2 have shown that even loyal employees are
tempted to steal data and commit malicious acts when they leave an organization.
In this IBM Redguide™ publication, we discuss processes and procedures for offboarding
individuals to help ensure that the access and entitlements are removed in a timely fashion to
mitigate risks of data theft and other malicious activity.
In “Introducing the IBM Security Framework and IBM Security Blueprint” on page 2, we
introduce the IBM Security Framework and the IBM Security Blueprint because these are
used for our offboarding discussion to ensure that all important aspects are addressed. In
the IBM Redbooks® publication Introducing the IBM Security Framework and IBM Security
Blueprint to Realize Business-Driven Security, REDP-4528, we describe the IBM Security
Framework and the IBM Security Blueprint in more detail.
In “Business risks in employee offboarding” on page 5, we discuss the business risks that
drive the need for offboarding processes and the required measurements to prove that the
risks are being mitigated.
In “Introducing control processes for employee offboarding” on page 7, we present several
control processes that need to be in place to mitigate the offboarding risks from using the IBM
Security Blueprint. These processes are designed for companies who typically divide up
offboarding responsibilities between HR, the IT organization, and IT system owners. The
processes are based on experiences with IBM clients and IBM's own experiences with
implementing offboarding processes.
1
For more information visit the following Web site:
2
Visit the Ponemon Institute at http://www.ponemon.org/index.php
http://www.ibm.com/ibm/ideasfromibm/us/smartplanet/topics/itinfrastructure/20081215/index.shtml?&re=sph
© Copyright IBM Corp. 2009. All rights reserved.
1
In “Introducing a maturity model for employee offboarding controls” on page 17, we introduce
a maturity model for offboarding security processes. Different organizations may accept
varying risk levels in regards to offboarding and they may want to investment differently for
offboarding control processes. The maturity model is designed to accommodate these
differences.
Finally, in “IBM solutions to address maturity levels” on page 18, we sketch out some of the
different products and services that can be applied at each of the maturity levels.
Introducing the IBM Security Framework and IBM Security
Blueprint
Business leaders are expected to manage risk in their areas of responsibility in the same way
that CFOs manage risks in their domains. Security risks and the potential impact on IT need
to be communicated to executive peers in business terms. Additionally, they need to align IT
security controls with their business processes, monitor and quantify IT risk in business
terms, and dynamically drive business-level insight at the executive level. They need to
manage risk and orchestrate security operations in a way that enforces compliance and
optimizes business results.
IBM created a comprehensive IT security framework to describe key business security
concerns, as shown in Figure 1.
Figure 1 The IBM Security Framework
The IBM Security Framework groups concerns into five key security domains, shown at the
center of the diagram. These domains are wrapped by the unifying topic of Security
Governance, Risk Management, and Compliance.
While the IBM Security Framework addresses business oriented concerns, the IBM Security
Blueprint describes a technology-agnostic and solution-agnostic view of the security
management processes and security controls that need to be in place to address the
business security concerns.
2
Using the IBM Security Blueprint to Address Business Risks for Employee Offboarding
The top-level components of the IBM Security Blueprint are shown in Figure 2.
Figure 2 The IBM Security Blueprint
The Foundational Security Management services describe the top-level services that need to
be implemented in order to achieve the required functionality addressed in the IBM Security
Framework. These represent the layers where the business requirements, as defined in the
IBM Security Framework, are converted to top-level IT services to fulfill these requirements.
At this point, the threshold has been crossed from pure business related viewpoints to actual
IT systems.
The more common Security Services and Infrastructure layer contains infrastructure
elements and services that are used by the top level services in the Foundational Security
Management services. These services represent control points in the IT environment.
3
The Foundational Security Management services components follow Architectural Principles
to manage the common Security Services and Infrastructure using a closed-loop, risk
management process, as shown in Figure 3.
Figure 3 Foundational Security Management controls closed loop
To learn more details about the IBM Security Framework and the IBM Security Blueprint,
please refer to the IBM Redpapers™ publication Introducing the IBM Security Framework and
IBM Security Blueprint to Realize Business-Driven Security, REDP-4528.
The IBM Security Blueprint Redguide publications series are detailed investigations into
specific types of security controls, the business risks they address, and technology neutral
discussions of how to implement these controls. These guides are organized according to the
Blueprint components to ensure all aspects of risk management are addressed in the control.
This particular guide addresses the business risks and IT risks associated with employees,
contractors, and business partners ending their relationship with an organization, especially
when the circumstances may not be congenial.
Throughout this guide, we use the term employee, but the concepts and processes described
here are equally applicable to contractors and business partners. We use the term employee
as a shorthand way of referencing all people who are ending their relationship with an
organization.
4
Using the IBM Security Blueprint to Address Business Risks for Employee Offboarding
Business risks in employee offboarding
On 23 February2009, the Ponemon Institute released an independently conducted research
study called Data Loss Risks During Downsizing3, which documented the business risks
associated with laid off employees by conducting surveys of laid off employees.
The research study showed a particular problem with data theft even from employees who left
the organization on good terms with their employer. According to the study:
“More than 59% report that they kept organization data after leaving their employer. It is
very interesting to note that employees who do not trust their former employer to act with
integrity and fairness are more likely to take the data. Sixty-one percent of respondents
who were negative about the organization took data while only 26% of those with a
favorable view took data.”
The research study also asked the laid off employees how they took the data:
“It is interesting that most employees (61%) who stole valuable customer and other
business information are taking it in the form of paper documents or hard files. The next
most popular means of transferring data is by downloading information onto a CD or
DVD (53%) or onto a USB memory stick (42%) followed by sending documents as
attachments to a personal e-mail account (38%).”
Furthermore many employees who left were well aware that their IT credentials had not been
revoked:
“Employees were able to access their former employer’s computer system or network after
departure. According to 24% of respondents, their ability to access data continued after
they left the organization creating a data security risk. Of these respondents, 32% say that
they accessed the system and their credentials worked and 38% say their co-workers told
them that their access rights continued. In the case of 35% of the respondents, access to
the system continued one week or longer.”
Even though the respondents were assured of their anonymity, the actual numbers may be
under-reported due to the sensitive nature of the questions.
The financial impact of these malicious incidents can be huge. On 6 October 6 2009,
ComputerWorld posted an article Former DuPont researcher hit with federal data theft
charges4 relating the latest charges against Hong Meng, a former top researcher. Meng is
accused of downloading hundreds of DuPont trade secret level documents regarding organic
LED (OLED) technology with the intent of taking them with him to his next employer.
3
4
The study can be found at the following Web site:
http://www.ponemon.org/local/upload/fckjail/generalcontent/18/file/Data%20Loss%20Risks%20During%20Do
wnsizing%20FINAL%201.pdf
This article can be found at the following Web site:
http://www.computerworld.com/s/article/9139014/Former_DuPont_researcher_hit_with_federal_data_theft_
charges
5
As another example of the huge impact that these malicious events can have, the CERT
Coordination Center and the US Secret Service published a public report in 2004 titled Insider
Threat Study: Illicit Cyber Activity in the Banking and Finance Sector5. One of the case
studies in the report was a case of employee offboarding risk:
“In March 2002, a ‘logic bomb’ deleted 10 billion files in the computer systems of an
international financial services organization. The incident affected over 1300 of the
organization’s servers throughout the United States. The organization sustained losses of
approximately $3 million, the amount required to repair damage and reconstruct deleted
files. Investigations by law enforcement professionals and computer forensic professionals
revealed the logic bomb had been planted by a disgruntled employee who had recently
quit the organization because of a dispute over the amount of his annual bonus.”
A follow-up study by the same organizations in 2005 titled Insider Threat Study: Computer
System Sabotage in Critical Infrastructure Sectors6 noted how common it is for insider threats
to come from ex-employees:
򐂰 The majority of the insiders were former employees.
򐂰 At the time of the incident, 59% of the insiders were former employees or contractors of
the affected organizations and 41% were current employees or contractors.
򐂰 The former employees or contractors left their positions for a variety of reasons. These
included the insiders being fired (48%), resigning (38%), and being laid off (7%).
Key risks to consider
The key risks that need to be mitigated for employee offboarding scenarios are:
򐂰 Employees' ability to copy sensitive and proprietary information from IT applications and
systems to local portable media and then physically remove that information from the
premises.
򐂰 Employees' ability to e-mail documents and information from IT applications to personal
e-mail accounts.
򐂰 Employees' ability to continue to access IT systems after they have left the organization.
򐂰 Employees' ability to access physical documents after they have left the organization.
򐂰 Employees' ability to install malware on IT systems they leave behind.
Outcome measurements for risk mitigation
When a former employee uses data assets from a former employer without authorization, the
former employer often becomes aware of the data use. For example, suppose an employee
steals a marketing e-mail list from the organization and starts using the e-mail list to solicit
business for a competitor organization that hired the employee. Often, mailing lists are spiked
with beacon addresses that are monitored for unauthorized activity. This can enable the
employer to detect that a laid off employee has used the stolen mailing list.
5
6
6
This report can be found at the following Web site: http://www.cert.org/archive/pdf/bankfin040820.pdf
This report can be found at the following Web site: http://www.cert.org/archive/pdf/insidercross051105.pdf
Using the IBM Security Blueprint to Address Business Risks for Employee Offboarding
There are other ways in which the organization may become aware that laid off employees
are using proprietary or sensitive information. It is important that organizations have a
process by which these incidents can be reported and evaluated. The incidents need to be
evaluated both for their business cost/impact and for the root cause of the breach: How did
the employee access the data? From which systems/processes did the data come? When did
the employee actually access and copy the data?
To augment the cases of discovered incidents, an organization might randomly audit IT logs
of activity after an employee leaves to look for incidents of unauthorized data access.
By building a catalog of these incidents, both from accidental discovery and by audit
investigations, the organization can quantify the incidents both in terms of numbers of
incidents in a time period and the cost of those incidents in the time period.
The success of an employee offboarding process is judged by its ability to reduce the number
and severity of these incidents.
Introducing control processes for employee offboarding
As described above the IBM Security Blueprint uses a closed-loop risk-management based
framework for security management that is adapted to specific security controls.
This risk management-based framework follows a basic plan-do-check-act/react set of
components that IBM adapts to IT security management as:
򐂰
򐂰
򐂰
򐂰
Security Policy Management
Control deployment and execution
Risk and Compliance Assessment
Command and Control Management
7
Figure 4 shows the IBM security management approach to risk adapted to the employee
offboarding scenario.
Num ber of mali ci ous
incid ents from laid
off empl oyees and
th ei r financial
i mpact.
Entitlem ent rem oval
control processes
Data & I nf ormati on
P rotec tion Mgmt
Off-boarding
di rectives and
performance goals
Com mand and
Control Mgmt
Ident ity , A ccess &
Enti tlement Mgmt
S ecurit y Policy
Management
S of tware, Syst em &
Service Ass urance
I T Service
Management
Performance &
Com pli an ce
metrics
Directi ve com pliance reports
Performance metric reports
Threat & Vulnerabilit y
Management
P hysical A sset
Management
Risk & Com pli ance
Assessment
Pro cess risk assessm ent
Performance metri cs fo r off-boarding processes
Process com pleteness and i ntegri ty reports
Knowl edge
Figure 4 Foundational Security Management controls closed loop for employee offboarding
The employee offboarding controls are broken down into processes for each of these
components of IT system management and are described in the following sections.
Security Policy Management
In the employee offboarding scenario, the necessary security policy is relatively straight
forward because the approach to mitigating the risk is simple to describe. Let us take a closer
look at the following details:
򐂰 Develop an employee offboarding policy.
򐂰 Classification of IT systems and HR processes.
Develop an employee offboarding policy
Based on known past incidents involving the abuse of IT systems access by employees who
have left the organization, the Chief Information Security Officer (CISO) should identify the
systems that pose the highest risk for abuse and the HR scenarios that are most likely to
incite malicious activity by leaving employees.
For the purpose of our discussion, we assume there are two categories of systems with
respect to employee offboarding:
򐂰 High risk systems are those that provide broad access to the IT environment, such as
remote VPN accounts, master authentication directories, such as an LDAP directory or
Microsoft® Active Directory, and systems that contain highly sensitive information.
򐂰 Low risk systems include everything else.
8
Using the IBM Security Blueprint to Address Business Risks for Employee Offboarding
We also assume there are two basic types of HR offboarding processes
򐂰 Normal termination of employment
򐂰 Emergency Block
Normal termination of employment processes occur when people retire from the organization
or otherwise resign. In these situations, they go through normal HR processes for legal
separation from the organization, whether the relationship is an employee/employer
relationship, contractor relationship, business partner relationship, and so on. The Emergency
Block process is used when an urgent personnel matter has caused the organization or
manager to no longer trust an employee until a further investigation is conducted and needs
to remove the employees access to IT systems as quickly as possible.
Of course, an organization could have more than two types of system classification or more
than two types of HR offboarding processes. For example, the processes for offboarding
contractors may be significantly different than offboarding employees and may carry with it a
much different level of risk.
For each system classification and HR process, a security policy must be developed to
address the business risks. The fundamental objective is to eliminate the window of
opportunity for employees who have left the organization to engage in malicious activities, so
the security policy would be expressed in terms of reducing the window of opportunity to a
particular goal. These security policy goals would reflect the particular combination of risk
level and HR process and might be expressed in a similar way as shown in Table 1.The CISO
will ensure that access to IT systems by former employees will be removed within the time
frames shown in Table 1.
Table 1
Time frames for access removal
Offboarding process
Low risk systems
High risk systems
Normal termination of
employment
Access removed within 1 week
Access removed within 48 hours
Emergency Block
Access removed within 24 hours
Access removed within 24 hours
Note that a policy addresses delegation of responsibility and goals to be achieved, not
necessarily how the policy's goals should be met.
Classification of IT systems and HR processes
Once the risk levels and offboarding processes have been identified, the key IT system within
the organization must be inventoried and classified according to the policy's risk definitions.
There may be unique characteristics for each IT system's offboarding process that may need
to be negotiated in per-IT system policies.
For example, in some cases, offboarding an employee may be a labor and cost expensive
process, and if there is any chance that the employee may be brought back, for example,
unblocked from an Emergency Block, it may make sense for the IT system to first suspend the
employee's access for a certain amount of time before finalizing the removal of credentials.
So a policy may need to be negotiated with that IT system owner about the amount of time it
keeps credentials suspended.
9
Control deployment and execution
The control processes for the employee offboarding scenario require a centralized IT
infrastructure and centralized information services about employees, contractors, business
partners, and so on, which are described in the following sections. Once the infrastructure is
in place, a set of business processes to support the offboarding security policy can be
described.
The business processes to implement the employee offboarding scenario are shown in
Figure 5 and described in the following sections:
򐂰 HR processes
򐂰 Directory processes
򐂰 Identity management processes
HR Ev ent
Subsc ri ber
Queue
On/ Off boarding
Trigger
HR Syst em s
Directory Updat e
Appl ication
Outsourc ed s erv ice
providers
On/Of fboardi ng
Ev ent
Queue
Master
Direct ory
HR Ev ent
Subsc ri ber
Queue
HR Ev ent
Subsc ri ber
Queue
E mergency Block
Applicat ion
Block Lis t
HR Process es
Rec ent ly Deleted
Enti ties Direct ory
On/ Of f-boarding
Service B us
Direc tory Proc ess es
Internal Ident ity
Management
Servers
IT S ystems
Ident ity M anagement Proc esses
Of f-boarding Event
Audit S erv er
Compl ianc e Trac ki ng P roc es ses
Figure 5 Business processes to implement employee offboarding
HR processes
The HR processes represent the sources of HR events. In this particular control, we are
primarily interested in HR events that indicate that an employee has left the organization.
From an HR perspective, there may be many different HR offboarding processes for different
types of employees, contractors, business partners, and so on. For the purposes of our
discussion, this scenario assumes that the HR offboarding processes can be grouped into
two main categories: Normal Termination of Employment and Emergency Block.
Trusted sources of personnel information
Most companies need to plan for the fact that there may be multiple independent HR systems
within the organization. This can be due to the fact that different departments manage
different types of relationships (employees, contractors, business partners, and so on) or due
to mergers and acquisitions and other business ventures.
In order to ensure completeness, the IT organization must identify all of the relevant HR
systems that manage the termination of relationships. These systems are the trusted sources
of personnel information.
10
Using the IBM Security Blueprint to Address Business Risks for Employee Offboarding
Globally Unique Identifiers UIDs
Because there can be multiple trusted sources of information within an organization, almost
always using disparate, independent IT systems to run them, the IT organization cannot count
on the HR systems using a consistent identification scheme for people. Therefore, the IT
organization must develop a globally unique identity system for all individuals in the
organization, regardless of their role or governing HR system.
The most common approach to solving this problem is to assign each trusted source of
personnel information a unique HR Source identifier.
A globally unique identifier (UID) for individuals can then be constructed by concatenating
the HR Source identifier with the person's identifier within that HR system.
The Emergency Block Application
Emergency Block processes are usually initiated by a manager or some responsible
individual and are not necessarily coordinated with other HR processes. They are usually
considered urgent and must be initiated immediately. In most cases, this means that a
separate application needs to be developed to grant managers and others sufficient authority
to initiate an Emergency Block.
The Emergency Block Application adds the UID of a person to a Block List, which represents
all employees that have been blocked. The Emergency Block Application must also provide a
procedure for unblocking an employee if the crisis is resolved appropriately, which can be a
form of onboarding to restore a person record in the directory and their identities and
credentials in downstream systems.
HR update processes
The trusted sources of event information are responsible for synchronizing their information
with the Master Directory by sending personnel update events to the Directory Update
Application. These updates are sent when new people are added to the HR system or
changes are made to their information (name changes, employee status changes, job
position changes, and so on).
These are sent to the Directory Update Application on a periodic basis, often daily.
These updates are not described further in this document, but are generated and processed
in a similar fashion to the offboarding Event Triggers described below.
On/offboarding Event Trigger processes
For Normal Termination of Employment processes, the trusted sources of personnel
information will perform the appropriate business process for their system and, at some point,
the relationship between the employee and the organization has been officially terminated.
This point represents the trigger that starts the offboarding process for the IT systems.
As described above, Emergency Block processes are usually initiated by an application that
is integrated with HR systems but is accessible by people outside of HR who may need to
initiate the emergency block. These processes activate an immediate offboarding process
and notify the HR systems that the process has been initiated.
11
In both types of HR processes, a common set of information needs to be conveyed to the
Directory Processes to trigger the offboarding:
򐂰 The UID of the individual whose relationship with the organization is being terminated.
򐂰 In some cases, the type of termination process may also be communicated, in this case,
either Normal Termination of Employment or Emergency Block.
򐂰 A Unit of Work or Transaction Identifier is an identifier that can be used to trace the
source of the termination trigger back to a specific transaction authorized by a specific
person.
Given the diversity of trusted sources of personnel information that are likely to exist in an
organization, it is almost certain that the HR systems will not have a common format for
representing these offboarding event triggers, so a common format will need to be designed
to represent these triggers.
Given that directories almost always follow LDAP protocols, one common format used for
these events is the LDAP Data Interchange Format (LDIF).You could also consider using one
of the industry standards: Directory Service Markup Language (DSML) or the Service
Provisioning Markup Language (SPML).
These HR on/offboarding events are sent to a Directory Update Application. Because of the
sensitive nature of these events, these events should be signed by the trusted source of
personnel information and validated by the Directory Update application. Likewise, the
transmission of these events should be encrypted to protect the confidentiality of this
information.
To manage availability and resilience of these events and to ensure that none of the events
are lost, a loosely coupled delivery mechanism, such as a message queue or service bus,
should be used.
The employee offboarding event triggers must also be stored in the offboarding event audit
server for compliance tracking purposes.
Directory processes
The directory processes are usually managed by the IT organization and represent the
aggregation of all HR personnel information from all trusted sources into a Master Directory
and the ongoing management of that directory information.
The directory processes are also responsible for delivering employee offboarding events to
internal and external subscribers.
Master Directory
The Master Directory aggregates all of the personnel information from the trusted sources of
personnel information into a common directory indexed by the UID.
Note that while trusted sources of personnel information may have only one type of
person/relationship in them (for example, employee, contractor, business partner, and so on),
the Master Directory contains all types of people associated with the organization. As
mentioned earlier, in this guide we use the term employee, but the processes apply to all
individuals who have a relationship with the organization. The directory processes and the
identity management processes apply to all types of people regardless of whether they are
employees, contractors, or business partners. From an IT perspective, the only necessary
representation of the person is the UID.
12
Using the IBM Security Blueprint to Address Business Risks for Employee Offboarding
However, the Master Directory will contain additional attributes about the person, received
from the HR update processes or other trusted sources of personnel information. Whenever
possible, the Master Directory should avoid maintaining sensitive personal information, such
as government issued identifiers. However, there may be cases where maintaining sensitive
identifiers is required.
For example, suppose one of the IT systems that needs to have employee access removed is
a personal health record portal that is deployed internally. This application may index its
credentials by Social Security Number or Tax Payer ID number. In this case, it may need to
know these identifiers in order to offboard employees and remove their access rights. In this
case, the Master Directory would need to maintain this information so that the application can
translate the UID into the Social Security Number that it understands.
In cases where the Master Directory is required to store sensitive personal information, the
appropriate data security controls need to be put into place for both the stored information
and the transmission of the information to other systems.
Note: The Master Directory change log is filtered by a process that detects on/offboarding
events that are broadcast to a wide variety of systems for removing accounts and
credentials. In some cases, this may represent a high volume of transaction processing
with systems that may be dispersed across a wide geographic area, depending on how
you manage the directory information tree and its nodes. In some cases, it may make
sense to create replicas of the Master Directory in different geographies to offload some of
the processing load and to improve the resiliency of the process. The discussion for the
overall directory topology and locations of the Master Directory and replicas is not included
in this guide, but should be considered when planning a deployment.
Block List
The Block List represents a list of people for whom a manager or authorized person has used
the Emergency Block Application to immediately offboard individuals and terminate their
access to IT systems. It is essentially a list of UIDs that is used to ensure that no other
systems add information about an individual back to the directory.
Recently Deleted Entities Directory
The Recently Deleted Entities Directory, which could be a separate node within the Master
Directory or a separate directory, maintains a list of records for people who have been
offboarded within a certain time frame. These directory entries contain information about the
deleted individuals that may be needed by downstream Identity Management Servers to
resolve UIDs to identifiers they understand. Without this list, the information would be gone
from the Master Directory before the IT systems receive notification of the offboarding event.
Typically, this directory keeps records available for a specified time period, often 90 days, and
then deletes them permanently.
The directory update process
As mentioned earlier, the trusted sources for personnel information send HR updates to the
Directory Update Application to ensure that the Master Directory stays synchronized with the
HR systems.
For HR events that represent the offboarding of an employee, the Directory Update
Application must log the receipt of the offboarding request into the employee Offboarding
Event Audit Server and then delete the person specified by the UID from the Master Directory
and copy the record to the Recently Deleted Entities Directory.
13
For HR events that represent other types of updates, such as add and modify requests, the
Directory Update Application must filter those requests against the Block List to ensure that
people who have been blocked byway of the Emergency Block process are not inadvertently
added back to the Master Directory.
Likewise, when the Emergency Block Application is used to unblock an employee, the
Directory Update Application must be able to restore the person's entry when they are
removed from the Block List, allowing for normal HR feeds for this person.
The logic regarding which events should be filtered and not filtered can become complex.
This is why the individual trusted sources for personnel information should not be given direct
access to the Master Directory. Instead, the Directory Update Application should be the only
application with authority to change the Master Directory. The Directory Update Application
becomes both a centralized place to enforce blocking logic and audit checkpoint to log the
receipt and processing of HR update events.
HR event broadcasting process
The changes made by the Directory Update Application to the Master Directory represent the
changes that need to be reflected across the IT environment. In particular, when a person's
UID is removed from the Master Directory, a trigger for an offboarding event for IT systems
that have accounts and credentials for that person must be initiated.
There may be many changes to the Master Directory due to other HR processes that are not
relevant to offboarding. The on/offboard trigger process filters the Master Directory change
log and builds the appropriate on/offboarding events, which are then passed to the
On/Offboarding Service Bus.
The On/Offboarding Service Bus maintains a list of subscribing Identity Management Servers
to ensure delivery of the on/offboarding events to each of the subscribers. The delivery
mechanism may involve either push or pull mechanisms. The On/Offboarding Service Bus is
also an important audit check point. It must store audit records into the Offboarding Event
Audit Server for every on/offboarding event it receives and it must create an audit event for
each HR event successfully delivered to an Identity Management Server.
Given the fact that the On/Offboarding Service Bus must interact with so many different IT
systems, it is important that it is designed to support asynchronous message transfer and
message queuing.
Also, because the HR events may contain sensitive information, the storage and transmission
of the on/offboarding events through the service bus to the Identity Management Servers
should be encrypted to ensure that administrators do not see which employees have been
blocked or offboarded.
Identity management processes
The identity management processes are responsible for interacting with IT systems and
making modifications/additions/deletions to user registries and credential systems in
response to the on/offboarding events.
Identity Management Servers
Identity Management Servers are responsible for interacting with IT changes to
add/change/delete accounts and entitlements in the IT systems they manage. An Identity
Management Server may be the authoritative account change source for one or more IT
systems.
14
Using the IBM Security Blueprint to Address Business Risks for Employee Offboarding
The Identity Management Server is responsible for associating the accounts and credentials
with people and is responsible for enforcing the ownership of accounts so that any activity on
the account can be traced back to a person.
Adoption and reconciliation processes
Adoption processes refer to the ability of the Identity Management Servers to look at every
account and credential in a managed IT system and associate that account with a unique
person. In these scenarios, the Identity Management Servers must relate the account or
credential with the UID.
Given that the UID is an identifier devised by the IT organization, the managed IT systems
may be unable to associate their user registries and accounts with the UID. In these cases,
the Identity Management Servers may need to retrieve additional information about the
person by querying the recently deleted entries list.
In cases where the adoption process cannot be automated, the Identity Management Servers
must support a process to interact with IT system managers to query them about ownership
of IDs that cannot be matched up with a UID. The IT system managers use their own out of
band methods to determine the owners of the accounts.
Reconciliation processes refer to steps taken when an account is discovered on a managed
IT system that cannot be associated with a person through the adoption process. Often these
accounts are scheduled for deletion, sometimes pending approval and review by IT system
managers so that there is no account or credential on the managed IT system that cannot be
associated with a person.
Employee on/offboarding subscriber processes
When a subscriber receives an on/offboarding event from the On/Offboarding Service Bus, it
must first log receipt of the event in the Offboarding Event Audit Server and then initiate a
process for the on/offboarding event for each of the IT systems it manages. The steps in this
process are highly dependent on the capabilities of the IT system.
For example, some systems have the ability to temporarily suspend an account without
completely deleting the account. This may be an appropriate response to an Emergency
Block request.
In other cases, it may be important to notify a manager of a pending account deletion so that
entitlements for that account can be delegated to a different person before the account is
deleted.
A detailed discussion about all of the possible process steps that should be followed when an
on/offboarding event is received by the Identity Management Servers is beyond the scope of
this guide. However, there are interactions with the other directory processes and compliance
processes that should be noted.
First, by the time the subscribing Identity Management Server receives the employee
offboarding event, the Master Directory has already removed that person's record and it has
been moved to the Recently Deleted Entities Directory. The Identity Management Server
processes may need to retrieve information about the employee in order to identify the
accounts with which that person is associated. As a result, the Identity Management Server
process may need to be able to make queries into the Recently Deleted Entities Directory to
retrieve additional information about the employee.
15
Second, when the employee offboarding request has been processed, the Identity
Management Server must log an audit event in the Offboarding Event Audit Server to indicate
that the offboarding event has been appropriately processed. This event may contain a
transaction identifier or similar unit of work identifier that can be used to retrieve a detailed
description of all the activity that was performed for that offboarding event.
The employee offboarding event may also need to trigger other IT-related actions. In some
cases, the employee may have had privileged access to a particular resource. For example,
most employees have privileged administrator access to the machines they use on a day to
day basis for e-mail and other business related activity. Most people have administrator
access to their organization issued mobile computers. In other cases, the person leaving the
organization may have had privileged access to organization servers or other critical
components of the IT infrastructure. In these cases, the employee offboarding event may
need to trigger processes to remove IT systems from the organization network until they can
be assessed or, at least, the systems that the privileged user had access to need to be
scanned for malware and other malicious activity.
The Identity Management Servers may also need to use the offboarding events to trigger
audit procedures. For example, if an employee is being offboarded and their access to a
repository of highly sensitive documents is being removed, the offboarding event may need to
trigger a process that runs an audit report on the employee's recent access. This audit trail
can be reviewed with management and the departing employee to ensure that the leaving
employee knows which documents they can or (more likely) cannot take to their next job.
While the offboarding event triggers the generation of the audit report, the audit trail itself has
to be built into the access control system with the intention of generating these reports in the
future when needed.
Risk and Compliance Assessment
The processes in Risk and Compliance Assessment are used to demonstrate that the
offboarding controls are working effectively and that they are meeting their performance
objectives.
Performance indicators
The security policy for the employee offboarding control processes defines how quickly the
employee offboarding processes must be complete based on the HR process that triggered
the offboarding event and the classification of the IT system.
When the Identity Management Servers log events in the Offboarding Event Audit Server, the
time it took to complete the event can be calculated based on the time difference from when
the HR process logged the initial offboarding event in the offboarding event audit and when
the Identity Management Servers logged the completion of the offboarding processing.
The Offboarding Event Audit Server must build a database of these records, capturing the
type of HR event, IT system and its classification, and the total time it took to process the
event. From these records a dashboard or performance report can be generated to show the
performance metrics that have been met.
Process integrity and compliance records
For each employee offboarding event logged by the HR processes, the Offboarding Event
Audit Server can be queried for the corresponding completion events from the Identity
Management Servers. Because each of the audit events include the UID of the person, the
audit events can be tied together into a single logical transaction.
16
Using the IBM Security Blueprint to Address Business Risks for Employee Offboarding
The HR processes that originated the offboarding event include a logical unit of work identifier
or a transaction identifier, so that the employee offboarding activity can be traced back to the
individual who authorized the offboarding activity.
Likewise, because the Identity Management Servers can include a transaction identifier in
their completion audit events, it is possible to track down the process and all of the activities
that the Identity Management Servers performed in response to the employee-offboarding
event.
Command and Control Management
Command and Control processes monitor security incidents and the IT controls to ensure that
they are in place and effective at reducing risk.
Control effectiveness assessment process
The performance metric reports will show which parts of the employee offboarding control
processes have been working as desired and which have not. If one particular IT system is
consistently unable to manage its offboarding activities in the time frame specified by the
security policy, the IT organization can either focus on how to improve the performance of that
system's offboarding processes, or choose to accept the risk.
Accepting the risk may be an indication that the system in question can be reclassified to a
lower risk category or may be an indication that the security policy metrics are too stringent
and can be relaxed without significantly increasing the risk.
Outcomes assessment process
An outcomes assessment process can periodically look at the numbers of incidents of data
theft and other malicious incidents to determine if the employee offboarding control processes
have been effective at reducing the business risks.
Outcomes assessment would also look at the incidents from a root cause analysis
perspective to determine if any changes need to be made to the security policy. For example,
analysis of the incidents might reveal that some systems formerly classified as low risk need
to be classified as high risk.
Introducing a maturity model for employee offboarding controls
Different organizations may require different levels of rigor and oversight in their offboarding
processes, based on the level of risk they perceive when employees, contractors, and
business partners end their relationship with the company. The maturity levels described
below are designed to enable a company to tailor its offboarding processes to its level of risk;
1. Level 1: Reactive
For Level 1 maturity in employe offboarding, the organization is aware of incidents and is
collecting documentation about how the incidents are occurring. IT staff and other
employees are taking the initiative to close the opportunity window by removing accounts
and credentials that they are aware of when an employee leaves. Offboarding policies are
handled at the department or organizational unit level and are scoped to the IT systems
that are important to that organization.
17
2. Level 2: Compliant
At Level 2 maturity, the organization is aware enough of the incidents and their costs to
make a concerted effort at developing a process that is comprehensive at identifying all of
the accounts and credentials that need to be removed from IT systems. This process is
documented and implemented across the organization. The documented process and
sample audit data from the execution of the process can be used to demonstrate
compliance to the process for auditors.
3. Level 3: Consolidated
At Level 3 maturity, the processes are consolidated across the organization so that
information about the process and how well it is performing is available from a centralized
spot. Performance metrics are also available, which can demonstrate both that the
processes are being followed and that they are meeting their performance targets.
4. Level 4: Risk Aware
At Level 4 maturity, the organization is measuring the reduction in the cost of malicious
acts by former employees and is performing root cause analysis on existing incidents to
determine how the security policy needs to be changed or how the employee offboarding
processes need to be changed.
IBM solutions to address maturity levels
IBM can help you address your offboarding risks based on your organization's risk appetite. In
the following sections, we briefly describe the service and product offerings from IBM that can
be applied towards each maturity level.
Level 1: Reactive
At maturity level 1, there is effort to ensure that accounts are closed, entitlements are
removed, and access is denied to IT systems when an individual leaves the organization.
These efforts are usually managed and initiated by people who maintain the IT systems.
IBM Tivoli® Identity Manager7 is a user provisioning and role management product that can
bridge the gap between how business users view their IT resources and the actual IT
implementation. Tivoli Identity Manager enables the IT organization to put business
processes in place to provide service authorizations only to individuals with a valid business
need and remove such authorizations when access is no longer required.
Tivoli Identity Manager manages the relationship between IT accounts and users and
provides a rich workflow environment to manage the provisioning and de-provisioning of
accounts, which can include recording of management approval, notification to other systems
of activity, and interaction with the managed IT systems to make changes in their user
registries.
Tivoli Identity Manager can manage adoption and reconciliation processes as well so that
there is never an account on a managed IT system that is not associated with a responsible
individual. And through its reconciliation processes, Tivoli Identity Manager can monitor
managed systems to make sure that no account changes are made that are not reflected in
the Tivoli Identity Manager directory.
7
18
More product information about Tivoli Identity Manager can be found at the following Web site:
http://www.ibm.com/software/tivoli/products/identity-mgr/
Using the IBM Security Blueprint to Address Business Risks for Employee Offboarding
Tivoli Identity Manager provides self-service interfaces so that users can manage common
tasks, such as resetting passwords and requesting access to new systems.
More detailed information about Tivoli Identity Manager can be found in the IBM Redbooks
publication Identity Management Design Guide with IBM Tivoli Identity Manager,
SG24-69968.
The IBM ISS Identity and Access Management Services9 offerings can help you design,
implement, deploy, and maintain an integrated identity management system in your
organization as well as manage your identity processes as a managed service.
Level 2: Compliant
Maturity level 2 adds an emphasis on process transparency and managing evidence to
deliver proof to auditors that the processes are in place and effective. Tivoli Identity
Manager's audit trail and reporting capabilities provide reporting about the execution of the
Tivoli Identity Manager processes.
Tivoli Identity Manager is also integrated with the IBM Tivoli Security Information and Event
Manager10 product, which collects and manages security audit related information from a
wide variety of sources. Tivoli Security Information and Event Manager can integrate with the
Tivoli Identity Manager directory so that Tivoli Security Information and Event Manager can
be used to monitor the actions of Tivoli Identity Manager administrators. Furthermore, Tivoli
Security Information and Event Manager can compare the audit trail of activity in Tivoli
Identity Manager with audit trails from managed IT systems to detect when administrators in
managed IT systems have attempted to bypass the Tivoli Identity Manager-established
business processes for managing access to the system.
Using both the built-in Tivoli Identity Manager reporting function and the integration with Tivoli
Security Information and Event Manager, the organization can demonstrate to auditors what
the documented business process is for managing access to the IT systems, show audit trail
reports that show the process is being followed, and demonstrate that the organization has
the capability to detect when someone attempts to bypass the process.
Level 3: Consolidated
At maturity level 3, the offboarding policy is consolidated and standardized across the
organization. At this maturity level, there is also at least some common infrastructure used by
the entire organization to implement the offboarding processes.
There are several possible approaches for consolidation in offboarding processes, and each
is described in the following sections:
򐂰
򐂰
򐂰
򐂰
Master directory
On/offboarding service bus
HR systems and emergency block application
Offboarding event audit server
8
This IBM Redbooks publication can be found at the following Web site:
http://www.redbooks.ibm.com/abstracts/sg246996.html?Open
9 More information about this offering can be found at the following Web site:
http://www.ibm.com/services/us/index.wss/offerfamily/gts/a1027701
10
More product information about Tivoli Security Information and Event Manager can be found at the following Web
site: http://www.ibm.com/software/tivoli/products/security-info-event-mgr/
19
Master directory
As shown in this guide, having a master directory that combines all the trusted sources of HR
information into a single directory that represents all of the relationships with individuals
creates a single point where offboarding policies and processes can converge.
IBM Tivoli Directory Server11 is an LDAP standard based, enterprise-grade directory server
that has a proven track record in terms of scalability and performance, which can be the
foundation for a master directory for on/offboarding processes.
The IBM Tivoli Directory Integrator12 product is used to move and synchronize data from
multiple authoritative sources into and out of LDAP-based directories. It can be a key
component of the Directory Update Application described earlier in this guide by
consolidating the HR events from the trusted sources of information and transforming them
into changes for the master directory.
On/offboarding service bus
Once the on/offboarding event trigger detects offboarding events from the master directory
change log and creates a message representing the event, it needs to be delivered to a wide
variety of event subscribers. Some of these subscribing systems may be inside the
organization, and some of them may be business partners outside the organization. Some of
the subscribing systems may require a push model of delivery, while others may require a pull
model. Given the potentially sensitive nature of the events, the messages need to be
protected and authenticated.
These types of activities are ideal for an enterprise service bus and IBM has several offerings
available for managing message protection and delivery:
򐂰 WebSphere® Message Broker13
򐂰 WebSphere Enterprise Service Bus14
򐂰 Tivoli Directory Integrator
The IBM SOA Consulting Services15 can help your organization design and develop both the
service bus infrastructure needed for your organization and also help you design and deploy
the offboarding business processes.
HR systems and emergency block application
In many organizations, there are multiple trusted sources of personnel information, often due
to mergers and acquisitions that have taken place. As a result, there is no single place in the
organization to obtain information about an employee, business partner, or contractor.
The IBM Single View of Customer solution, based on the IBM InfoSphere™ Master Data
Management Server16, can be applied to internal employee directories as well. It can be used
to consolidate HR data from multiple sources into a single view of an employee.
11
More product information about Tivoli Directory Server can be found at the following Web site:
http://www.ibm.com/software/tivoli/products/directory-server/
12 More product information about Tivoli Directory Integrator can be found at the following Web site:
http://www.ibm.com/software/tivoli/products/directory-integrator/
13
More product information about WebSphere Message Broker can be found at the following Web site:
http://www.ibm.com/software/integration/wbimessagebroker/
14
More product information about WebSphere Enterprise Service Bus can be found at the following Web site:
http://www.ibm.com/software/integration/wsesb/
15 More information about the IBM SOA Consulting Services can be found at the following Web site:
http://www.ibm.com/software/solutions/soa/services.html?S_TACT=107AG01W&S_CMP=campaign
16
More information about the IBM InfoSphere Master Data Management Server can be found at the following Web
site: http://www.ibm.com/software/data/infosphere/mdm_server/
20
Using the IBM Security Blueprint to Address Business Risks for Employee Offboarding
The IBM Master Data Management Server uses the IBM InfoSphere Information Server17 to
provide information integration services for extract, transform, load (ETL) to load the hub and
to perform data quality management, such as name and address standardization. This single
view of the employee system can also be used to originate the offboarding HR events that are
sent to the directory update application.
Offboarding event audit server
As described earlier, the Tivoli Security Information and Event Manager can serve as a focal
point for collecting audit trail information from a wide variety of sources and can be the basis
for implementing the offboarding event audit server, collecting the offboarding events
generated throughout the processes described in this guide. Tivoli Security Information and
Event Manager can use the UID stored in the audit events to pull out the activity records
related to a single person for audit and forensics purposes.
For a more general purpose approach to managing the audit data, the IBM InfoSphere
Warehouse18 can provide an enterprise-grade platform for managing audit data. The
Departmental Base Edition is a small or medium business (SMB) oriented solution that can be
used to manage the audit records and implement the offboarding audit event server and the
associated compliance tracking processes.
Level 4: Risk Aware
At level 4 maturity, the organization measures the reduction in the cost of malicious acts by
former employees and compares that against the performance of the offboarding control
processes in order to determine if the offboarding processes are performing as required and
to determine if the performance of the offboarding processes is actually mitigating the
offboarding risk by reducing the costs of malicious activity when individuals leave.
This requires retrieving business data from a wide variety of sources and pulling IT
performance data from systems, such as Tivoli Security Information and Event Manager and
other repositories of IT audit trail data.
The IBM Cognos® 8 Business Intelligence19 product provides capabilities for reporting,
online analytical processing (OLAP), score-carding, and presenting dashboards.
In the case of offboarding, the Cognos offering can pull loss event information from enterprise
risk management systems, filter it to isolate losses related to offboarding related incidents to
track the ongoing costs of these incidents, and track it over time. This information can be
combined in a dashboard that also reports on the performance metrics of the offboarding
process based on the events in the offboarding event audit server to track over time the key
performance metrics, such as the average time it takes to completely process an offboarding
event.
17
More information about the IBM InfoSphere Information Server can be found at the following Web site:
http://www.ibm.com/software/data/infosphere/info-server/overview/
18 More information about the IBM InfoSphere Warehouse can be found at the following Web site:
http://www.ibm.com/software/data/infosphere/warehouse/
19
More information about the IBM Cognos 8 Business Intelligence can be found at the following Web site:
http://www.ibm.com/software/data/cognos/products/cognos-8-business-intelligence/
21
Summary
When an employee, contractor, or business partner ends their relationship with an
organization, there are many IT security concerns that must be addressed in order to reduce
the well-documented risk of possible malicious activity committed by the departing
individuals. In this guide, we have shown a set of control processes that can help mitigate
these IT security risks by reducing the time it takes to remove access to IT systems as much
as possible, and by ensuring that all of the necessary IT credentials have been removed.
Other resources for more information
To learn more details about the IBM Security Framework and the IBM Security Blueprint, refer
to the IBM Redbooks publication Introducing the IBM Security Framework and IBM Security
Blueprint to Realize Business-Driven Security, REDP-452820.
The IBM white paper Take a holistic approach to business-driven security21 provides an
overview for the IBM security approach and IBM Service Management initiatives from a
business perspective.
The processes described in this guide rely heavily on LDAP directories and related standards,
such as the LDAP Data Interchange Format LDIF (RFC 2849), the Directory Service Markup
Language (DSML), and the Service Provisioning Markup Language (SPML). Discover more
information about these standards at the following addresses:
򐂰 RFC 2849
http://tools.ietf.org/html/rfc2849
򐂰 DSML
http://www.oasis-open.org/committees/dsml/docs/DSMLv2.doc
򐂰 SPML
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=provision
If you want to learn more about LDAP and the IBM Tivoli Directory Server, refer to the IBM
Redbooks publication Understanding LDAP - Design and Implementation, SG24-498622.
The team that wrote this guide
This guide was produced by a team of specialists from around the world working at and with
the International Technical Support Organization (ITSO).
Axel Buecker is a Certified Consulting Software IT Specialist at the International Technical
Support Organization, Austin Center. He writes extensively and teaches IBM classes
worldwide on areas of Software Security Architecture and Network Computing Technologies.
He holds a degree in Computer Science from the University of Bremen, Germany. He has 23
years of experience in a variety of areas related to Workstation and Systems Management,
Network Computing, and e-business Solutions. Before joining the ITSO in March 2000, Axel
worked for IBM in Germany as a Senior IT Specialist in Software Security Architecture.
20
This guide can be found at the following Web site: http://www.redbooks.ibm.com/abstracts/redp4528.html?Open
This IBM White Paper can be obtained at the following Web site:
http://www.ibm.com/systems/cn/dynamicinfrastructure/assess_your_needs/pdf/GMW14008-USEN_4.pdf
22
This IBM Redbooks publication can be found at the following Web site:
http://www.redbooks.ibm.com/abstracts/sg244986.html?Open
21
22
Using the IBM Security Blueprint to Address Business Risks for Employee Offboarding
Gordan Greenlee is a certified IT Architect with IBM and the Open Group. He has over 25
years of experience with IBM working in various areas of the business on a wide variety of
technologies. In the past 10 years, he has focused on information security and directory
services technology. He works in IBM Global Business Service with the IBM CIO security
team on directory related infrastructure strategies. Gordan has been involved with IBM
directories and Tivoli Access Manager security solutions since their initial internal
implementations and is a co-inventor for a number of patented system methods related to
IBM directory solutions. Over the past 7 years, Gordan has consulted with numerous IBM
mergers, acquisitions, divestitures, and outsourcing engagements and has designed
processes and solutions to cut transitional cost while increasing the IBM security posture. He
was a key architect in the design of the IBM offboarding solution.
Calvin Powers is a technology project manager reporting to the IBM CTO for Security. His
current work responsibilities include the development of the IBM Security Blueprint and the
development of industry perspectives on cyber security. He is a member of the IBM risk
management community and has a special interest in risk management methods applied to
IT environments.
Thanks to the following people for their contributions to this project:
Wade Wallace
ITSO, Austin Center
Michel Bobillier, Peter Brittenham, Allen Dreibelbis, Terry Escamilla, Tim Hahn, David
Hemsath, Laura Knapp, Koos Lodewijkx, Emily Ratliff, Lee Terrell, Michael Waidner, Jim
Whitmore, Corey Williams
IBM
23
24
Using the IBM Security Blueprint to Address Business Risks for Employee Offboarding
Notices
This information was developed for products and services offered in the U.S.A.
IBM may not offer the products, services, or features discussed in this document in other countries. Consult
your local IBM representative for information on the products and services currently available in your area. Any
reference to an IBM product, program, or service is not intended to state or imply that only that IBM product,
program, or service may be used. Any functionally equivalent product, program, or service that does not
infringe any IBM intellectual property right may be used instead. However, it is the user's responsibility to
evaluate and verify the operation of any non-IBM product, program, or service.
IBM may have patents or pending patent applications covering subject matter described in this document. The
furnishing of this document does not give you any license to these patents. You can send license inquiries, in
writing, to:
IBM Director of Licensing, IBM Corporation, North Castle Drive, Armonk, NY 10504-1785 U.S.A.
The following paragraph does not apply to the United Kingdom or any other country where such
provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION
PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR
IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT,
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of
express or implied warranties in certain transactions, therefore, this statement may not apply to you.
This information could include technical inaccuracies or typographical errors. Changes are periodically made
to the information herein; these changes will be incorporated in new editions of the publication. IBM may make
improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time
without notice.
Any references in this information to non-IBM Web sites are provided for convenience only and do not in any
manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the
materials for this IBM product and use of those Web sites is at your own risk.
IBM may use or distribute any of the information you supply in any way it believes appropriate without incurring
any obligation to you.
Information concerning non-IBM products was obtained from the suppliers of those products, their published
announcements or other publicly available sources. IBM has not tested those products and cannot confirm the
accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on the
capabilities of non-IBM products should be addressed to the suppliers of those products.
This information contains examples of data and reports used in daily business operations. To illustrate them
as completely as possible, the examples include the names of individuals, companies, brands, and products.
All of these names are fictitious and any similarity to the names and addresses used by an actual business
enterprise is entirely coincidental.
COPYRIGHT LICENSE:
This information contains sample application programs in source language, which illustrate programming
techniques on various operating platforms. You may copy, modify, and distribute these sample programs in
any form without payment to IBM, for the purposes of developing, using, marketing or distributing application
programs conforming to the application programming interface for the operating platform for which the sample
programs are written. These examples have not been thoroughly tested under all conditions. IBM, therefore,
cannot guarantee or imply reliability, serviceability, or function of these programs.
© Copyright IBM Corp. 2009. All rights reserved.
25
This document, REDP-4612-00, was created or updated on October 27, 2009.
®
Trademarks
IBM, the IBM logo, and ibm.com are trademarks or registered trademarks of
International Business Machines Corporation in the United States, other countries, or
both. These and other IBM trademarked terms are marked on their first occurrence in
this information with the appropriate symbol (® or ™), indicating US registered or
common law trademarks owned by IBM at the time this information was published. Such
trademarks may also be registered or common law trademarks in other countries. A
current list of IBM trademarks is available on the Web at
http://www.ibm.com/legal/copytrade.shtml
Redbooks®
The following terms are trademarks of the International Business Machines Corporation in the United States,
other countries, or both:
Cognos®
IBM®
InfoSphere™
Redbooks®
Redguide™
Redpapers™
Redbooks (logo)
Tivoli®
WebSphere®
®
The following terms are trademarks of other companies:
Microsoft, and the Windows logo are trademarks of Microsoft Corporation in the United States, other
countries, or both.
Other company, product, or service names may be trademarks or service marks of others.
26
Using the IBM Security Blueprint to Address Business Risks for Employee Offboarding