SECURITY INFORMATION MANAGEMENT—
THE FOUNDATION OF ENTERPRISE SECURITY
All organizations must be concerned about incidents and loss—a
knowledge-based security program provides the best defense.
Contents
Executive Summary 5
Introduction 7
Finding Information in a Big Corporate World of Data 8
The World of Security Data 9
The Roles of Incident Management & Risk Assessment 10
The Deming Cycle 11
The Six Questions 14
Documenting the Right Data 15
Transforming Data into Information 20
Generating the Right Reports 20
A New Age of Security Incident & Information Management 23
The ROI of Data-Driven Security 25
Conclusion 26
About the Author 28
About PPM 2000 Inc. 29
Incident Management from Every Angle Featuring Perspective by PPM 2000™ 30
PPM 2000 Inc. 10088 ‑ 102 Avenue, Suite 1307 • Edmonton, Alberta • T5J 2Z1 1‑888‑776‑9776 • information@ppm2000.com • www.ppm2000.com
Security Information Management—
The Foundation of Enterprise Security
All organizations must be concerned about incidents and loss—a
knowledge-based security program provides the best defense.
By Brian McIlravey, CPP
Executive Summary
The management of ongoing incident activity is an inevitable reality for all organizations. Detailed information about what is going on within and across an organization’s operations enables deployment of effective security safeguards that help reduce incidents and losses, and provide a built-in defense against accusations of negligence or inadequate security. However, gathering and extracting the right information from the mountains of data available is one of the most common challenges facing organizations today. This challenge can be easily overcome with the aid of powerful and sophisticated incident reporting and investigation management software solutions.
Introduction
All organizations face potentially serious consequences from incidents of all nature. These include losses and disruptions caused by the events themselves, as well as subsequent litigation and lost opportunity costs. The chronic occurrence of even relatively minor incidents can undermine an organization’s culture, cohesiveness and reputation. And in the extreme, major incidents can bring literal ruin to an organization. For instance, in 1995, fraudulent trading to the tune of $1.4 billion by rogue trader Nick Leeson forced the renowned British Barings Bank into bankruptcy. This cost 4,000 employees their jobs and huge losses for investors. Leeson, who worked out of the bank’s Singapore office, was later convicted and sentenced to six and a half years in prison.
While incidents and losses can never be totally prevented, an organization’s visible commitment to knowing what is happening on its premises, in its surrounding neighborhoods, and across its operations is critical.
Using information about actual and prevented incidents is essential to the development of effective security safeguards for each workplace environment, and a demonstrable commitment to collecting and constructively acting on this information is at the heart of successful litigation outcomes when the prosecution argues that the defending organization could have foreseen and prevented incidents from occurring.
Unfortunately, the collection, analysis and management of incident data does not happen by itself; it is the Achilles heel of most security programs. This weakness includes failure to:
• Collect incident data in a consistent and accurate manner.
• Store and proactively manage this data.
• Secure the data from unauthorized access and potential corruption.
• Analyze the data to derive useful information about security issues, as well as to educate upper management about the variety and intensity of threats that their organizations face.
• Act on the analytical information gleaned from the data in order to reduce or prevent incidents and loss.
While the scene is changing dramatically in the age of the CSO (Chief Security Officer) and numerous management programs dedicated to security, it is surprising that many security
EXTRACTING
THE TERMS
The following terms appear
throughout this whitepaper and are listed here in alphabetical order for your reference.
Annual Loss Expectancy
The expected total loss value attributed to a particular type of event for one year. Calculated by multiplying the expected frequency of the event for a one-year period (the number of times it will likely occur in a year) by the event’s single loss expectancy (the loss value of the event occurring once). Annual Loss Expectancy = Frequency X
Single Loss Expectancy
Benchmark
A point of reference against which something can be measured. Also referred to as a baseline measurement.
Countermeasure
A protective measure (physical or procedural) put in place to either minimize the frequency of an event or its impact.
operations still depend on inefficient office automation and reporting practices for incident management. For example, a number of corporate security departments have abandoned paper-based incident reports and conventional filing systems in favor of home-grown electronic incident reporting systems. While more efficient than paper reports, these electronic flat files are no more effective than traditional filing cabinets. They are searchable only with great effort, and they make finding specific information, doing analysis and generating reports very time-consuming. This is quite remarkable—and fast becoming unacceptable—with the need for immediate information and business intelligence in this day and age of fast-paced commerce and powerful threats and vulnerabilities.
Most organizations would say that they are, quite literally, drowning in data—while still suffering from a chronic lack of information on which to base decisions. This picture is not acceptable and it must change in order to maintain an effective risk management program.
Finding Information in a Big Corporate World of Data
The business world today is a data-centric world. Decisions based on carefully analyzed data are not only more likely to be correct and bring results, they are also more readily accepted and trusted. The term “knowledge-based decisions” is gaining currency. It refers to the knowledge and insights that are gleaned from raw data. As stated earlier, most corporations today are flooded with data, so much so that virtually no one in a typical corporation has the “big picture” of what is really going on. Ironically, that has become the convenient defense of executives involved in some recent high-profile corporate scandals. Yet, there is a recognizable truth lurking in and around their arguments; it should be understandable that there was much they did not know. One hears the same argument from all directions. Much data, but not enough clear information. Too many issues to track and understand, and not enough
confidence that the grounds for action are valid or, if valid, an unwillingness to incur the expense of correcting the situation. There is an obvious need for reliable business intelligence to drive actions. The challenge—and the obvious, if daunting, opportunity—is that our world of data is growing exponentially and becoming even more complex.
It is only over the last two decades or so that organizations and
Deming Cycle
A cyclical management process designed to solve issues and improve procedures and responses. Also referred to as the PDCA cycle (Plan, Do, Check, Act).
Event
An occurrence, either accidental or purposeful, caused by human or natural factors.
Frequency
The number of times an event has occurred over a span of time. Also referred to as the likelihood or probability of the event’s occurrence.
Impact
The measured effect of an event on an organization. Also referred to as the consequence of the event. May be tangible or intangible, with or without an associated dollar loss value.
Incident Management
The process of identifying and analyzing incident activity and determining the best course of action for handling it, presently as well as in the future.
EXTRACTING
THE TERMS
EXTRACTING
THE TERMS
their software suppliers have begun to focus on the challenge of how to make sense and use of the mountains of data available to them. Data storage, data management and data mining are now huge businesses for IT suppliers and consulting firms. Likewise, the emerging field of data and business analytics is providing sophisticated tools, algorithms and modeling techniques to draw from raw data meaningful analysis, knowledge and predictive studies that provide guidance on strategy and future investment.
The World of Security Data
Progress must still be made in the practical integration of data management technology into daily security operations. Industry surveys show that security managers rank “office management” and paperwork as one of their most serious time consumers and sources of inefficiency. Budget preparation and justification is also a predictably large, and mostly unpleasant, time consumer. Even worse are one-off requests from upper management that invariably wreak havoc on a normal work week. The new trends of performance measurement and performance management now add an even greater degree of required reporting from pre-determined metrics and measures.
The world of security data is fundamentally disorderly, primarily because there is no obvious—let alone easy and convenient—way to organize a substantial variety of seemingly disparate data. It is for this reason that so little security department data is well utilized, even if it is routinely collected and archived. Some security directors will admit that very little of their data is routinely scrutinized for the identification of patterns and trends and for making decisions about logical corrective action. This, of course, changes decidedly in the days and weeks following a high-visibility incident when 20/20 hindsight becomes very apparent. Security directors explain that the lack of qualified data analysts and the time demands placed on management result in reactive “management by red flags”—which means responding to crises rather than developing proactive, data-based security strategies. It is absolutely critical for security departments to realize that the amount and variety of security data flowing into their information systems is only going to grow—day-by-day and year-by-year—both as their corporations grow and as new technology-based security systems come on line. The corresponding need to store and organize this data for meaningful use will thus become an ever more pressing issue that will almost certainly command more upper management interest and scrutiny.
Loss
The resulting impact of an event. Losses are usually measured in dollars, though intangible losses may also result from incident activity (e.g., loss of corporate reputation).
Risk
“The likelihood of damage or loss [associated with an event’s occurrence] multiplied by the potential magnitude of the loss.”1 Risk Management
“The process of determining whether or how much of the risk [associated with an event’s occurrence] is acceptable and what action should be taken.”2
Security Information Management
The collection, storage and management of security data for analysis of patterns, trends, potential risks and other intelligence.
Single Loss Expectancy
The expected loss value of an event occurring once.
Threat
An event that can potentially occur.
EXTRACTING
THE TERMS
1 Garcia, Mary Lynn. (2001).
The Design and Evaluation of Physical Protection Systems. Woburn, MA: Butterworth-Heinemann.
2 McNamee, David. (1998). Business
Risk Assessment. Altamonte Springs, FL: The Institute of Internal Auditors.
The Roles of Incident Management & Risk Assessment
With an overwhelming volume of security data available, it is crucial for organizations to closely examine the integral roles that incident management and risk assessment play in a successful security information management program. Understanding how they interact can aid organizations in identifying the data that is most useful in mitigating risk, as well as how this data may be used to proactively prevent incident activity and its related loss. Indeed, awareness of the common operations of these processes is key to better managing incident activity, risk and security. Of course, it is obvious that incident activity is the necessary pre-condition of both security management and risk management. Without incidents, there would be no risk and there would be no need for security. If it were possible to guarantee that incident activity would not occur, corporations and businesses would have no need to employ security staff. Clearly, this is not the case.
Incident activity is widespread and affects organizations around the world; it cannot be fully prevented. So, the goal then is not so much to eliminate incidents as to manage them and reduce their associated loss. In effect, this is the function of security—to manage the risk of incident activity.
The risk management process provides security with a systematic framework to achieve this. Risk management can be defined as an organized approach through which uncertain events can be identified, measured and controlled to minimize loss and optimize the return on investment for security operations. It plays a central role in security’s ability to reduce incident activity and its impact. Since security’s main purpose is to minimize the effects
of incident activity on corporate assets (people, property or information), any security force’s first duty in protecting these assets is to put in place a countermeasure or safeguard against incident activity. Then, to identify whether or not the countermeasure is effective, it is necessary for the organization to measure any potential impact on their corporate assets since deploying the safeguard. (In other words, the organization must determine whether or not an incident has occurred since implementing the countermeasure.) If incidents have occurred and assets have been impacted, then the organization can perform a more thorough analysis of the effectiveness of the countermeasure in relation to the incident, and determine if further action is required.
Risk management
can be defined
as an organized
approach through
which uncertain
events can be
identified, measured
and controlled to
minimize loss and
optimize the return
on investment for
security operations.
It plays a central
role in security’s
ability to reduce
incident activity
and its impact.
This continuous cycle of managing incidents, risk and security can best be described by the Deming cycle, otherwise known as the PDCA cycle (Plan, Do, Check, Act). After planning and implementing a countermeasure, an organization monitors incident activity and measures the effectiveness of the countermeasure. The organization may then begin planning the next mitigating step that should be taken to improve protection of corporate assets. The cycle repeats, and the interplay of the incident management, risk management and security information management processes continues.
Throughout these cycles, six questions must be asked and answered:
1. Has the incident happened before?
2. If so, what was the impact on the organization?
3. Is the incident likely to happen again? If so, how often? 4. What would the impact be?
5. What countermeasures are currently in place to prevent the incident from happening again?
6. What further steps can be taken to mitigate the risk of the incident’s recurrence?
Answering each of these questions, in turn, provides information needed to approach the following question, facilitating the continuation of the incident management, risk management and security information management cycles.
The Deming Cycle
To better answer the six questions integral to the incident management, risk management and security information
management cycles, and to comprehend their dynamic interaction, it is useful to have a thorough understanding of the common process underlying them all—the Deming cycle.
When the adjacent Deming cycle graphic is applied to an organization’s security program, the open space inside the ring represents the organization’s assets (including people, property and data). The ring surrounding this space represents not only the various protective countermeasures the organization employs to mitigate the risk of incident activity (including physical and process-oriented countermeasures), but also the organization’s entire security information management program.
The Deming Cycle
Set Goals Monitor Metrics Analyze Decide
Act
Formulate
Strategy
Formulate Strategy
The first step involves an initial assessment of the organization’s assets, their values and what countermeasures are currently required to protect them. In many cases, this information is contained in the organization’s 1, 3 and 5 year security master plans.
Set Goals
This step requires the organization to set benchmarks for
measuring the effectiveness of its countermeasures. Generally, an organization employs countermeasures to either reduce the number of incidents occurring or to reduce incident losses. Once a baseline has been selected, incident numbers and losses can be measured against it, and the organization will know whether or not their short and long term strategies are working.
Usually, the baseline measurement, or benchmark, that an
organization sets is derived from measurements of past incidents or threats. An organization can look to historical data to determine the various threats that exist for a particular asset, the impact of each of these threats if they were to manifest and the frequency of the threats. In this instance, the asset’s threats would be the various types of incidents that could occur. The impact of each threat would be the loss value associated with the threat occurring once. And the frequency of each threat would be its expected number of occurrences.
Threat X Impact = Single Loss Expectancy (Risk) Risk X Frequency = Annual Loss Expectancy
In theory, a perfect security program would reduce all threats, impact, frequency, risk and loss expectancy to zero. However, in reality, an organization will set realistic goals for incident reduction and loss reduction based on the conclusions drawn from its
historical data. For example, if an organization had an average of 18 internal thefts per year over the last three years with a total loss value of $50,000, potential goals for the upcoming year may be: 1. A reduction of incidents by 50%; the baseline measurement
would then be 9 incidents.
2. A loss reduction of 70%; the baseline measurement would then be $15,000.
In addition to aiding incident, risk and security information management, setting benchmarks provides a means of measuring and managing performance.
Threat
X Impact
Single Loss Expectancy
(Risk)
Risk
X Frequency
Annual Loss Expectancy
Monitor Metrics
Once an organization’s countermeasures are in place and their goals for incident reduction have been set, the next step is to monitor the number of incidents that have occurred since countermeasures were implemented, as well as the incidents’ associated loss values. Simply put, the monitoring stage of the Deming cycle often consists of measuring the number of incidents, their impact, frequency, risk and losses against the baseline values selected in the previous goal setting stage.
Analyze
As an organization monitors what incidents are occurring, where, when and why they occurred, and how much was lost, they can begin to analyze these metrics against the baselines that have been set to determine whether or not their protective countermeasures are effective. For example, a decrease in incident numbers or loss values would allow the organization to infer that their countermeasures are effective, and an increase in incidents or loss values would suggest that more countermeasures are required or that processes must be re-worked. The analyzing stage allows an organization to put a subjective measure on the actions they will need to take.
Decide and Act
In the final phase of the Deming cycle, the process of monitoring and analyzing incident metrics leads to the making of decisions and the taking of actions. Once an organization analyzes their benchmark goals against the number of incidents, their frequency and their impact, they can decide what actions should be taken to minimize the risk of incident activity occurring. Depending on the level of risk an organization attributes to incident activity, the organization may decide to increase, decrease or maintain existing countermeasures, or even to put entirely new countermeasures in place. In other words, the organization’s reaction to the risk of incident activity may be designed to:
• Accept the risk.
• Avoid the risk.
• Reduce the risk.
• Transfer the risk.
After an organization has taken action, they can once again begin setting new goals and benchmarks, monitoring incident activity, analyzing metrics, making decisions and taking new actions. The Deming cycle continues in an endless loop, powered by an organization’s ongoing need to mitigate the risk of incident activity and its resultant impact.
As an organization
monitors what
incidents are
occurring, where,
when and why they
occurred, and how
much was lost,
they can begin
to analyze these
metrics against
the baselines that
have been set to
determine whether or
not their protective
countermeasures are
effective.
The Six Questions
Throughout the Deming cycle, organizations are faced with the six questions integral to their security information management program. The Deming cycle allows organizations to better answer these questions, and in turn, answering these questions facilitates the operation of the Deming cycle. The six questions again are: Has the incident happened before?
Has the incident occurred one or more times since implementing the countermeasure? What was the benchmark for acceptable recurrence of incidents?
If so, what was the impact on the organization?
Impact can be measured in various ways, but it is generally measured as the loss value attributed to the incident. A major incident occurring once over a span of time may have a larger impact than numerous minor incidents with a higher frequency. Is the incident likely to happen again? If so, how often?
What is the estimated frequency of the incident? What would the impact be?
Once frequency is estimated, what is the potential impact of the incident occurring once or several times?
What countermeasures are currently in place to prevent the incident from happening again?
Once an organization has determined the frequency and impact of an incident occurring, they can then evaluate the effectiveness of their current countermeasures. Are the countermeasures appropriate given the level of risk associated with the incident’s recurrence?
What further steps can be taken to mitigate the risk of the incident’s recurrence?
If the level of risk associated with an incident’s recurrence is acceptable, an organization may simply maintain their current countermeasures. However, if they have determined that further mitigating steps are necessary, they must then either increase the intensity of their current countermeasures or put additional ones in place. These decisions are based on the effectiveness of the current countermeasures, as well as on the incident’s criticality
1. Has the incident
happened before?
2. What was the
impact?
3. Is it likely to
happen again?
4. What would the
impact be?
5. What
countermeasures
are currently in
place?
6. What further steps
can be taken to
mitigate the risk
of the incident’s
recurrence?
(frequency X impact); the higher an incident’s criticality, the more likely that an organization will choose to take additional mitigating steps against the incident.
The answers to these six questions, and the systematic management approach of the Deming cycle, provide organizations with powerful tools for making knowledge-based, data-driven decisions—key factors in the success of any incident management, risk management or security information management program. However, while the Deming cycle provides an organized approach for utilizing this information, organizations must still ensure that the metrics used are accurate and truly informative. Herein lies the most common challenge for most organizations’ security information management programs—gathering the right data from the start and then extracting truly insightful information from this data on demand.
Documenting the Right Data
The first step in ensuring that quality data is available for analysis and decision-making involves collecting the right data from the outset. And the right data, the most indispensable data, is quite simply the incident basics: What, Where, When, Who, Why, How
and How Much. With these incident basics (the 5 Ws and the 2
Hs) at hand, an organization can generate an astounding array of analyses and reports.
So what exactly should be documented? What happened?
• Nature of the Event
The type of incident (theft, fraud, accident, etc.). Depending on how advanced an organization’s incident reporting system is, the type of incident may be tracked in detail or in more generic terms.
• Incident Synopsis or Summary
A brief description of the incident.
• Incident Narratives
Detailed descriptions of the incident. Incident narratives may include investigative summaries, statements or follow-up reports.
• Reference Number
A unique identifying number for the incident. It is sometimes referred to as the incident, occurrence or event number.
The answers to these
six questions, and
the systematic
management approach
of the Deming
cycle, provide
organizations with
powerful tools for
making
knowledge-based, data-driven
decisions
—
key
factors in the
success of any
incident management,
risk management or
security information
management program.
Where did it happen?
• Physical Location
A detailed description of the location of the incident. This is usually pulled from the location’s hierarchical listing in an organization’s corporate site index or building index (e.g., Tampa Campus > Glessing Building > Main Floor > Lobby).
• Operational Business Unit (OBU)
The business unit affected by or involved in the incident. The OBU, along with the physical location, provides a complete picture of where the incident happened. It is especially important to note for organizations with subsidiaries, alliance partners or multi-level organizational or geographical structures (e.g., North America > Acme Inc. Subsidiary > Manufacturing Division). When did it happen?
• Occurred On Date and Time
The date and time the incident occurred.
• Occurred To Date and Time
The date and time the incident ended. The span of time between the occurred on date and time and the occurred to date and time indicates the incident’s duration.
• Reported Date and Time
The date and time the incident was reported to the appropriate authority (e.g., when someone called security to report a theft).
• Report Entered Date and Time
The date and time the incident report was entered into the system. This is often done by an investigator when an investigation is opened.
• Report Closed Date and Time
The date and time the incident or investigation was closed. Who was involved?
• Involved Persons
Persons who were involved in the incident in some way. Information tracked includes:
○ Person Details
Last name, first name and other supplemental details (date of birth, contact information, identification numbers, unique features and descriptors, etc.).
Note: Privacy laws may govern what information can and
cannot be collected about an involved person, as well as the use of such information (particularly with respect to its dissemination or sharing).
Incident Location
○ Involvement Type
The nature of the person’s involvement in the incident (e.g., complainant, victim, witness, suspect, subject of interest). Since the same person may have been involved in multiple incidents in different ways, this information is tracked separately for each incident.
• Involved Organizations
Organizations that were involved in the incident in some way. An incident’s involved organizations are often involved or associated with its involved persons. As with involved persons, involved organization details are tracked (such as the organization name, reference number and contact information), as well as the organization’s involvement type. Involved
organizations may be described by the following designations:
○ Responding Agencies
Organizations that actively respond to incidents and provide a service (e.g., police, fire, EMS, tow companies, etc.).
○ External Organizations or Groups
A number of different types of organizations may fit this description. They may or may not be unofficial organizations, such as organized crime groups or activist groups.
○ Nature of Involvement
Organizations may simply be described by their involvement type (e.g., complainant, victim, witness, suspect, subject of interest).
• Involved Vehicles
Vehicles that were involved in the incident in some way, including motor vehicles, boats, ships, aircraft, etc. An incident’s involved vehicles are often involved or associated with its involved persons or organizations. Although some may consider an involved vehicle a What rather than a Who, they are designated here as Who data because of the unique identities they may be referenced by. For example, beyond such details as the vehicle’s year, make, model and style, an involved vehicle is often identified by its unique license plate number or VIN (Vehicle Identification Number).
• Involved Items
Items that were involved in the incident in some way, including lost, stolen or damaged items (both tangible and intangible). An incident’s involved items are often involved or associated with its involved persons or organizations. As with involved vehicles, although some may consider an involved item a What rather than a Who, they are designated here as Who data because of the unique identities they may be referenced by (e.g., serial number).
1. What happened?
2. Where did it
happen?
3. When did it
happen?
4. Who was involved?
5. Why did it happen?
6. How did it happen?
7. How much was lost?
Why did it happen?
• Cause or Root Cause
The factor or factors (both primary and secondary) that led to the incident’s occurrence. In major events, such as airline crashes or coroner inquests, this information may be used to allow or support liability or negligence claims.
• Outcome or Result
The actions that an organization has taken to mitigate the impact of a similar incident in the future or to prevent the incident’s recurrence. This may include corrective actions taken to rectify the incident’s cause.
• Descriptors for causes and outcomes may be organization, industry or legislation specific. Some examples are:
○ Deliberate or Intentional Act
○ Unintentional Act
○ Intentional Failure to Act
○ Unintentional Failure to Act
○ Mechanical Failure ○ Policy Violation ○ Careless Actions ○ Tampering ○ Unsafe Conditions ○ Undetermined How did it happen?
• While the Why of an incident generally refers to its root cause, the How of an incident can be thought of as the unfolding story or chain of events that led to the incident’s occurrence.
• For example, the Why of a plane crash (its root cause) may be mechanical failure. In this case, the How of the incident would be the actual description of the mechanical failure—the chain of events that led to the failure itself (the incident’s occurrence).
• For some incidents, it may be helpful to think of the How as the incident’s M.O. (Modus Operandi or Method of Operation).
• Combined with the incident’s Why, the How can be very useful in determining what corrective actions are necessary to prevent the incident’s recurrence.
How much was lost?
• In other words, what was the incident’s impact or loss value?
• May be attributed to tangible items and vehicles (e.g., a lost wallet, a stolen car, a damaged building), or other intangible loss factors (e.g., system downtime, stolen information, damaged reputation).
• After noting the details of any involved items, vehicles and other loss factors (e.g., name, serial number, license plate number, etc.), the next step in incident loss tracking is to record key metrics:
○ Loss Status - Lost - Stolen - Damaged ○ Loss Type - Direct Loss
The loss value directly associated with the lost, stolen or damaged item or vehicle (e.g., the value of the stolen laptop).
- Indirect Loss
Any loss value indirectly associated with the lost, stolen or damaged item or vehicle (e.g., the insurance deductible or other associated replacement costs, a loss in company reputation, etc.).
○ Loss Cause
The cause of the lost, stolen or damaged item or vehicle. This cause is not necessarily the same as the overall cause of the incident (the Why of the incident). Some sample loss cause options are:
- Intentional or Unintentional
- Criminal, Procedural or Safety/Environmental - Human Error or Mechanical Failure
○ Loss Values
- Loss Per Unit
The loss value for each lost, stolen or damaged item and vehicle.
- Total Loss
The total loss value for all lost, stolen or damaged items and vehicles.
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
- Recovered Amount
The loss value recouped on recovered items or
vehicles. Recoveries could include the actual recovery of the item or vehicle (e.g., finding a missing PDA) or amounts recovered through formal processes (e.g., civil recoveries, amounts awarded in litigation).
- Net Loss
The loss value remaining after the recovered amount is subtracted from the total loss.
• From these key metrics, particularly an incident’s loss values, and data on the type and frequency of the incident, a Loss Event Profile can be generated. This report is very useful in assessing and managing the risk associated with the incident’s potential recurrence.
Transforming Data into Information
Once the incident basics (the 5 Ws and the 2 Hs) have been accurately recorded, meaningful data, including statistical analyses and reports, may be extracted. At this point,
organizations move from the data collection or incident reporting phase to incident data management. When data is properly managed, it is transformed into information—accurate qualitative and quantitative results. Qualitative results refer to graphs, charts or other depictions that allow organizations to identify patterns and trends at a glance. Quantitative results refer to the hard numbers and statistics that support the qualitative results. For example, the adjacent bar chart depicts incident frequency over a span of 4 years. Qualitatively, a decrease in incident frequency over time can be observed; the bars get shorter and shorter with each passing year. Quantitatively, the numbers on the bottom (x) axis provide statistical support for this qualitative observation.
In the pie charts that follow, the qualitative observation of which building had the most incidents, or which incident category was more often recorded, is easily apparent. The statistical numbers surrounding the pie charts supply the quantitative support for these observations.
Generating the Right Reports
While there is no single set of reports that meets every
organization’s needs, the following provide a wealth of valuable
Year Number of Incidents 2005 0 20 40 60 80 2004 2003 2002 Building A
Incidents by Site: YTD Incident Frequency 82 26 27 52 Building B Building C Building D Accident Policy Violation
Incidents by Category: YTD 62 21 33 21 16 10 24 Assault Theft Fire Vandalism/Mischief Medical Assistance
and insightful information for highly effective security information management. Every security program generally extracts data from two types of reports: pre-defined reports (sometimes called canned reports) and dynamic query reports.
Pre-defined (or canned) reports are generated by organizations on a recurring basis. They may be used on a weekly, monthly, quarterly or yearly basis, or intermittently. These reports are often built into an incident management software system, but they may also be custom-made by an organization and then saved for repeated use. They may include any combination of metrics (What, Where, When, Who, Why, How and How Much), but they most often include data on incident frequency and loss values. Some examples follow:
• Incident/Event Profile
Measures incident frequency by a particular metric, such as:
○ # of incidents across the organization
○ # of incidents by singular type (e.g., thefts only)
○ # of incidents by multiple types (e.g., thefts plus frauds)
○ # of incidents by date range
○ # of incidents by site
○ # of incidents across the organization, and associated loss data
○ # of incidents by singular type (e.g., thefts only), and associated loss data
○ # of incidents by multiple types (e.g., thefts plus frauds), and associated loss data
○ # of incidents by date range, and associated loss data
○ # of incidents by site, and associated loss data
• Incident Frequency Distribution Report
Compares incident frequency and loss data for two separate time periods (e.g., two different years, quarters, months, weeks, days, hours). Other metrics may also be included, such as:
○ # of incidents by date range, and - by site - by group or division - by type
Pre-defined (or
canned) reports
are generated by
organizations
on a recurring
basis. They may be
used on a weekly,
monthly, quarterly
or yearly basis,
or intermittently.
These reports are
often built into an
incident management
software system.
○ loss data (in dollars) by date range, and - by site
- by group or division - by type
• Incident Classification Report
Measures incident frequency by classification (e.g., theft, fire, fraud, etc.), and may provide further information on incident location, loss values and dates of occurrence. This report is useful for viewing incident totals and identifying areas of concern (e.g., thefts occurring in the western region).
• Incident Loss Report
Cross-references incident loss values (total, recovered and net losses) with loss statuses (lost, stolen, damaged, direct and indirect). This report may also include any combination of additional metrics (e.g., total and net losses for all stolen items and vehicles in the western region).
• Incident Items Report
Measures loss values for involved items. This report is most useful in attributing loss values to particular items or item types (e.g., laptop thefts where the total loss is greater than $1000).
• Incident Yearly/Quarterly/Monthly Report
Provides statistics on incident activity to date. This report differs from the Incident Frequency Distribution Report in that there is no comparison made to a second date range. Other metrics may also be included, such as:
○ # of incidents to date - by site
- by group or division - by type
• Outcome/Root Cause Report
Reports on incident causes (e.g., all incidents in the western region where the cause was identified as Intentional Failure to Act).
Dynamic query reports are reports that an organization generates to search their incident management database for metrics that are not included in any of their pre-defined (canned) reports. They may be used on a one-off basis or they may be saved and eventually integrated into the organization’s set of pre-defined reports. Since the search criteria for pre-defined reports are set, dynamic query reports allow organizations to run custom queries combining
Dynamic query
reports are reports
that an organization
generates to search
their incident
management database
for metrics that are
not included in any
of their pre-defined
(canned) reports.
25,000
Incident Losses by Site
20,000
15,000
5,000
0 Site A
Total Loss Net Loss Recovered
Incident Loss
Loss Amount ($)
Site B Site C Site D
10,000
any number of variable metrics. Usually, these queries fall into one of two categories:
• Statistical Reporting
Reports focusing on frequency and loss values combined with another metric (What, Where, When, Who, Why, How or How Much).
• Investigative Reporting
Reports focusing on investigative metrics (most often When and Who), designed to help solve investigations.
Data extraction tools used to generate dynamic query reports should give users the ability to:
• Tailor the report design (e.g., headers and titles).
• Customize the search criteria to include any combination of data tracked in the system.
• Manipulate the data to meet specific reporting needs (e.g., total, group or chart data).
Armed with the incident basics (the 5 Ws and the 2 Hs) and a solid set of analytical and reporting options (both pre-defined and custom-made on the fly), an organization is equipped with the right information to better manage incident activity, risk and security. Incident hotspots are revealed, and security initiatives that have proven effective are identified. With this data on hand and the management process of the Deming cycle in motion, organizations are able to make knowledge-based decisions and take informed action to mitigate risk and minimize threats. Gone are the days when this could be achieved with paper, pen and carbon copies of incident reports. As the number and complexity of incident threats to organizations have grown, so have the demands on security departments to counter these threats quickly and efficiently. The time has come for change.
A New Age of Security Incident & Information Management
There is a strong trend in security management to strengthen and make more consistent the management of security information across the enterprise. This trend is driven, in no small measure, by the much broader corporate interest in data analysis and knowledge-based decision-making. There is also relentless pressure to improve the speed and quality of decision-making, reduce costs, improve productivity and demonstrate
Armed with the
incident basics
(the 5 Ws and the
2 Hs) and a solid
set of analytical
and reporting
options (both
pre-defined and
custom-made on the fly),
an organization is
equipped with the
right information
to better manage
incident activity,
risk and security.
a commitment to best practices. As new generations of well-educated and technology-literate professionals take leadership positions in corporate security departments, automation, commitment to innovation and collegial collaboration across management functions will become more the rule rather than the exception.
Today, security departments, and consultants who work with them, are recognizing the need for a “security information architecture” that can handle the explosive growth in security data and raise security department efficiency and responsiveness to higher levels in the face of increased management interest and apprehension about security. For some years now, security personnel have addressed this growing need by developing their own “automated” security incident management systems. Typically, these are either simple word processing documents or spreadsheets. While an improvement over index cards or incident log books, they are cumbersome to use and virtually impossible to search—particularly at fast-growing, fast-moving organizations. So it is no surprise that more powerful and technologically sophisticated COTS (Commercial Off the Shelf) incident reporting systems are coming into their own, replacing antiquated home-grown systems.
Incident reporting and investigation management software solutions like Perspective by PPM 2000™ are becoming the keystone of a
well thought-out and executed security information management program, playing a key role in the risk management and decision-making process. At the front end, users can easily input incident data (users range from security managers, to investigators, to security officers, to employees in other departments), and user-friendly screens can easily be configured based on an organization’s unique operations and facilities. At the back end are robust tools that make it easy to search and analyze the data in a multitude of ways and to generate graphically powerful reports in qualitative and quantitative format. And, of course, at the heart of a system like Perspective is a relational database that can store virtually unlimited quantities of incident data in a secure environment. When deployed across a company’s global sites, the system can provide a true enterprise-wide view of security incident activity.
Further, security incident management software systems play an important role in addressing the pressing corporate trends of enterprise-level information management and convergence. This is particularly true of corporations with national and international operations, but it is also true of larger educational, health care
Today, security
departments, and
consultants who
work with them,
are recognizing
the need for a
“security information
architecture” that
can handle the
explosive growth
in security data
and raise security
department efficiency
and government organizations. Even today, for example, within some progressive companies, increasing demands on security departments are driving the positioning and practical use of incident management systems as an “information hub” for an overall integrated security program—including access control, alarm monitoring and so on, all of which are at the forefront of detecting incidents.
The ROI of Data-Driven Security
Security incident and information management is the keystone in the architecture of a data-driven security program. Without this capability, security programs will remain mired in the conventional model of intuitive and reactionary management decisions and erratic operations practices. Security managers will continue to struggle to deliver management reports on time that look professional. Budget development and justification will continue to be a nightmare.
Today’s security incident and information management practices make possible a “closed loop” of security program design,
budgeting, implementation, measurement and improvement. Rather than intuitive and anecdotal assessments of security program effectiveness, security executives can generate crisp management reports that capture specific reductions or increases in all incident categories. Security incident management systems also capture the ultimate resolution of incidents and their accumulated costs—both cash outlays and staff time. Based on this visibility into what is really happening:
• Security resources can be more effectively deployed thereby maximizing ROI.
• The relative effectiveness of individual security safeguards and a mix of safeguards can be tracked and measured, allowing for cost-effective improvements over time and across locations.
• Return on a company’s investment in its security program can be discussed in more precise business, financial and risk management terms.
• Security program effectiveness and budgeting can be discussed using the same logical, organizational and analytical techniques used by other corporate departments.
Rather than
intuitive
and anecdotal
assessments of
security program
effectiveness,
security executives
can generate crisp
management reports
that capture specific
reductions or
increases in all
incident categories.
Conclusion
Security information management is a critical element of protecting businesses and other organizations against incidents and the losses they cause. In security management, as in any other business management function, data-based (or knowledge-based) decisions are the most likely to work and be seen as credible within the organization. The challenge to security management is to adopt a data-driven mindset, acquire the necessary software tools to manage their data, and galvanize their departments around the principles, practices and disciplines of security information management.
Security information
management is a
critical element of
protecting businesses
against incidents and
the losses they cause.
About the Author
Brian McIlravey, CPP
Vice-President, Professional Services & Business Development PPM 2000 Inc.
Brian McIlravey, CPP, is the Vice-President of Professional Services & Business Development for PPM 2000 Inc. Prior to joining PPM 2000, Brian McIlravey was a police officer in Ontario, Canada and an investigator at one of Canada’s largest private investigation firms. Brian is Board Certified in Security Management and an active member of ASIS International where he serves as one of the Assistant Regional Vice-Presidents for Canada and as Canada’s National Certification Representative. As PPM’s Vice-President of Professional Services & Business Development, Brian leads a team of specialists who guide organizations in the creation of data-driven security programs and the deployment of Perspective, PPM 2000’s enterprise-level Incident Reporting & Investigation Management software.
By combining extensive security experience with an in-depth knowledge of security management software, Brian is a leading authority on security information management and the technology that drives it.
1Somerson, Ira. (2009).The Art and Science of Security Risk Assessment. Alexandria, VA: ASIS International.
About PPM 2000 Inc.
PPM 2000 Inc. was established in 1988 to develop Incident Reporting & Investigation Management software for the corporate security industry. The company’s enterprise-level solutions help organizations accomplish their security, risk management and compliance objectives through data-driven decision-making and knowledge management. Thousands of organizations have implemented a PPM solution, and the company’s clients span all industries and include many of the Fortune 1000. PPM 2000 is a Microsoft Gold Certified Partner. For more information, visit www.ppm2000.com or call 1-888-776-9776.
PPM 2000 would like to thank ASIS International and Ira Somerson, CPP, for the use of material from their recent book, The Art and Science of Security Risk Assessment1. Also, PPM 2000 would
like to acknowledge Denis O’Sullivan, CPP, for his contributions to this paper, including allowing the reproduction of portions of a white paper he authored for PPM in February 2003.
Incident Management from
Every Angle…
Where your ability to focus on a specific incident is
complemented by your ability to look at the big picture.
Featuring Perspective by PPM 2000™
Perspective offers a single enterprise platform to capture and report data relative to incidents, investigations and cases. Organizations can intelligently action and query their data for trending, risk mitigation and planning activities. Then, with the ability to
accurately assess what is happening and its potential impact, they can make informed decisions that optimize performance, mitigate liability and protect their assets.
With Perspective, incidents, investigations and cases are entered and interactively managed from beginning to end. User dashboards and email integration encourage collaboration, and procedural consistency is emphasized through well-designed data entry forms and an intuitive user interface.
For advanced incident analysis and investigative reporting,
Perspective offers pre-defined queries, custom searching, free-form text searching and impressive charting. Users can search on any information in their database, and they can present their findings in a variety of ways. From routine searches to complex queries, Perspective turns raw data into actionable intelligence.
For a high level of information security and the ability to share intelligence across all locations, departments and employees, Perspective’s unique business layer provides the flexibility to segregate and consolidate vast amounts of data. It’s all about visibility, and a sophisticated system of workgroups, organizational rollups and access levels offers complete control over each user and what they can see and do within the system.
Perspective was built on the .NET Framework. It is a centrally managed Web services application that is easy to deploy, update and maintain throughout an enterprise and across multiple sites.
Perspective is an end-to-end, total solution that incorporates:
• Incident reporting, investigation management and case management.
• Supervisor review and task management.
• Collaboration and productivity.
• In-depth analysis and statistical reporting.
• Predictive analysis and modeling.
• Enterprise-level scalability and deployment.
Depending on the structure of an organization and its incident and investigation management mandate, the scope of Perspective can easily be expanded to include:
• Web-based incident data collection. Perspective e-Reporting™
gives everyone the opportunity to report incidents—from anywhere, at anytime.
• Visual link analysis. Perspective Visual Analysis™, developed in
partnership with i2®, brings clarity to complex investigations.
• Computer-aided dispatching. Perspective DispatchLog® automates
the dispatching process from initiation, to deployment, to response.
• Application integration. Perspective’s built-in Import Manager saves time and ensures consistency by integrating data from other applications.
• Mobile incident data capture. Capture incident data remotely from any PDA or smartphone running on Windows Mobile® Pro.* *Requires third party software.
In the end, it is about knowledge. It is about having access to the information required to analyze activity and produce reports. And, it is about using this intelligence to proactively prevent future incidents.
It’s about incident
management from every angle.
It’s about putting incident
activity in Perspective.
With Perspective, organizations can:
• Standardize their incident
reporting, investigation management and case management process.
• Consolidate data and reporting
to present a complete picture of security risks.
• Intelligently action and query
data for trending, risk mitigation and planning activities.
• Use knowledge about what’s
happening—and where—to deploy effective safeguards that reduce incidents and loss.
• Make informed decisions that
optimize performance and illustrate the effectiveness of their security operation.
• Capture the data needed to
make knowledge-based decisions and to illustrate Return on Investment (ROI).
Copyright © 2009 PPM 2000 Inc. All rights reserved.
Based on a white paper first published by PPM 2000 in February 2003 (portions have been reproduced with the permission of Denis O’Sullivan), as well as material contributed by Brian McIlravey for Ira Somerson’s book, The Art and Science of Security Risk Assessment (used with the permission of ASIS International and Ira Somerson).
PPM 2000, the PPM 2000 logo and DispatchLog are registered trademarks of PPM 2000 Inc. Perspective by PPM 2000, the Perspective by PPM 2000 logo, Perspective e-Reporting, Perspective Visual Analysis and the Incident management from every angle logo are trademarks of PPM 2000 Inc. Microsoft, Windows Mobile and the Microsoft Gold Certified Partner logo are trademarks or registered trademarks of Microsoft Corporation in the United States and other countries. i2 is a registered trademark of i2 Inc. Printed in Canada 07/09.
PPM 2000 Inc. 10088 - 102 Avenue, Suite 1307 Edmonton, Alberta T5J 2Z1 1-888-776-9776 information@ppm2000.com www.ppm2000.com
