Running Head: An Incident Management Framework Utilizing SIEM Technology
An Incident Management Framework Utilizing SIEM Technology
Jonathan Katz
A Capstone Presented to the Information Technology College Faculty of Western Governors University
in Partial Fulfillment of the Requirements for the Degree Master of Science in Information Security and Assurance
May, 2015
An Incident Management Framework Utilizing SIEM Technology !2
Abstract
Many corporations have implemented Security Information and Event Management
(SIEM) technology in an effort to help achieve compliance objectives and to detect anomalies.
However, even with complex tools in place to detect abnormalities, many organizations fail to
properly manage information security incidents. Organizations can build a customized incident
management framework within their SIEM tool which can be tailored to their business needs.
These customizations can also provide the functionality and reporting requirements
outlined by frameworks like the National Institute of Standards and Technology (NIST) in
Special Publication 800-61 and/or regulatory requirements like those outlined in PCI-DSS. A
simple assessment of the organizational requirements for incident management combined with
identifying any regulatory requirements for incident management reporting will dictate the
configuration and workflow for the custom configurations of the SIEM tool. A streamlined
incident management tool aligned to business and regulatory processes will allow an
organization to handle information security incidents more effectively and in a more timely
manner. Although the return on investment is difficult to calculate, having a streamlined incident
response framework reduces the amount of time required throughout incident investigation and
resolution.
An Incident Management Framework Utilizing SIEM Technology !3
Abstract 2 Introduction 5
Project Scope 5 Defense of the Solution 6 Methodology Justification 6 Organization of the Capstone Report 8
Systems and Process Audit 8 Audit Details 8 Problem Statement 9 Problem Causes 10 Business Impacts 10 Cost Analysis 10 Risk Analysis 11
Detailed and Functional Requirements 12 Functional Requirements 12 Detailed Requirements 13 Existing Gaps that a Successful Project Would Fill 13
Project Design 14 Scope 14 Assumptions 15 Project Phases 15 Timelines 16 Dependencies 17 Resource Requirements 17 Risk Factors 17 Important Milestones 18 Deliverable 18
Methodology 18 Approach Explanation and Defense 18
Project Development 19 Technical Details 19 Hardware 19 Software 19 Tech Stack 20 Architecture Details 20 Final Output 20
Quality Assurance 20 Acceptance Criteria 21
Implementation Plan 21 Strategy for Implementation 21 Implementation Phases 22 Go-Live 22 Dependencies 23
An Incident Management Framework Utilizing SIEM Technology !4
Deliverables 23 Training Plan 23
Risk Assessment 24 Qualitative and Quantitative Risks and their Mitigation 24 Cost/Benefit Analysis 25 Rollback Plan 26 Alternatives 26
Post-Implementation 26 Support and Support Resources 26 Maintenance, short and long-term 27
Conclusion 27 Outcomes and Deliverables 27 Reflection 28
References 29 Appendix A 31
An Incident Management Framework Utilizing SIEM Technology !5
Introduction
The wide-spread, pervasive nature of security breaches creates an environment for a
security practitioner which dictates the need for all enterprises to develop incident response
plans. However, in many cases, incident response plans are not tested or evaluated. By
integrating the incident response process or workflow into an existing SIEM installation
consistent and compliment incident response capabilities can be achieved.
Project Scope
The goal of this project is to build a customized incident management framework on an
existing SIEM tool which has already been deployed within the organization. Prior to this project
the SIEM will be installed and functioning with content present which detects anomalies
conditions which warrant further manual investigation. Ideally the majority of these anomalies
will be classified as incidents while the rest will be considered false positives which can
eventually be tuned out from the system.
Tuning the SIEM installation’s detection capabilities, the introduction of new security or
system event sources to the SIEM is not included within the project scope. Installing a SIEM
from scratch and outlining the organization’s business use cases for the SIEM such as detection
of insider threats, perimeter protection, fraud detection, compliance augmentation or data
exfiltration will not be included in this project; it assumed that the SIEM is already being used
for at least a portion of those business use cases. This project will focus on managing the
incidents such as those listed in the use cases above within the SIEM tool.
An Incident Management Framework Utilizing SIEM Technology !6
The introduction of a simple incident management framework, if not already present, will
be introduced. The steps in this incident management framework will align with best practices as
dictated by NIST standard 800-61. Customization of the SIEM’s ticketing or case system will
allow the SIEM to act as a repository of information through the incident handling process. The
customized incident management framework will allow tracking of an incident through all of its
stages from initial detection through regulatory reporting if required. User education of the
maintenance of the installed SIEM customizations as well as usage of the customizations will be
determined as a part of the project. The development of simple tutorials may be required.
Defense of the Solution
Many organizations, large and small, implement SIEM technology to assist in the
diagnosis and detection of security incidents. However, many organizations also fail to integrate
the SIEM’s capabilities into the incident management realm. SIEM products like
include ticketing and incident tracking subsystems which largely remain unused by many
customers. Enterprise are largely interested in tracking anomalies but do not always understand
the need to integrate this tracking with a business process for incident management.
By integrating an incident management and tracking subsystem within the SIEM tracking
and handling practices become ingrained as a part of the culture within the enterprise. When
habits surrounding incident management become practiced regularly and consistently, the
mitigation process and compliance objectives become easily achieved.
Methodology Justification
Public and private organizations are compelled by regulation and good business practices
to develop an incident management plan for when a computer security incident takes place.
An Incident Management Framework Utilizing SIEM Technology !7
Depending up on the entity in question not having an incident management plan creates a risk of
non-compliance with various standards such as FISMA and PCI-DSS. Non-compliance with
those standards can result in fines, a loss of business, or both. Additionally, many organizations
have a “paper plan” that has never been tested or used, while others have no plan at all.
According to PriceWaterhouseCoopers 20% of businesses have not carried out any kind
of risk assessment (PWC, 2014.) By integrating the steps of a NIST 800-61 complaint incident
management plan into a daily routine for managing anomalies, the duties and practices
surrounding incident management become second nature for practitioners. Moving the
technology of managing incidents from an ad hoc process to the same platform which is used for
incident discovery an economy of scale can be introduced into an organizations computer
security practices. The implementation of an ingrained incident response management system
reduces response time and increases situational awareness during an incident.
By using additional capabilities of the SIEM installation many financial and intangible
costs are abridged. The concept that a SIEM can be used to manage incidents is not intuitive;
typically IT organizations are used to stand-alone ticketing systems for problem tracking and
resolution or manually managing incidents via an ad hoc process.
Since the SIEM solution is already used by security personnel for anomaly detection,
there is no need for purchasing new software or training personnel to use a new stand-alone
system used solely for incident handling. By utilizing an existing SIEM there are no capital costs
for additional hardware or additional software licenses to procure. Additionally, because users
are familiar with the SIEM installation they can more quickly be able to utilize the case
management functions of the SIEM to handle incident management.
An Incident Management Framework Utilizing SIEM Technology !8
Organization of the Capstone Report
This capstone will be broken into the following sections, a systems and process audit, a
review of the detailed and functional requirements of a NIST-based incident management
program, a design for mapping those objectives to an SIEM, an implementation
plan, a risk assessment of the implementation, quality-assurance testing of the deployment, post-
implementation support, and a conclusion, outcome and reflection.
Systems and Process Audit
Audit Details
Across my tenure as a Professional Services consultant for I was able to
visit customer sites across many different industries and government sectors. All sites had
common themes; many had too much data and not enough people to analyze it. Others were
unsure how to analyze the data which they collected. Few organizations what data and
combinations of information could define an incident. Finally very few organizations had a
repeatable process to follow for when an incident was discovered.
After leaving and co-founding IVS, we adapted the Capability
Maturity Model (CMM) scale developed by Carnegie Melon to measure the maturity of a
customer’s SIEM implementation. The definitions of the CMM scale remained the same, with a
rating of 1 meaning an immature, ad hoc process and 5 meaning a fully mature process;
intermediate numbers dictated different capabilities regarding repeatable processes, workflow
automation, and the quality of the actionable intelligence as delivered by the SIEM product.
An Incident Management Framework Utilizing SIEM Technology !9
Very few customers reached tiers three or four, with the majority clustered around tier
one or two, reaching towards three. This meant that customers had a SIEM and were using it, but
were not necessarily using it effectively. Data collected was not as meticulously analyzed as was
possible, too few staff were available to utilize the system. Processes surrounding defining and
managing the SIEM and the information discovered were not developed.
Re-exploring these findings at a larger scale, as a degree candidate, the maturity
surrounding the SIEM implementation reflected upon the ability of an enterprise to manage an
incident overall. The highest-scoring customers we had at were the ones who best
utilized the SIEM’s capabilities for managing an incident. By utilizing these capabilities
customers had a defined and repeatable process for detecting and managing incidents.
Combining our own observations with headlines and surveys showing up to 60% of some
companies do not have incident response plans in place, I believe ingraining the response process
into the SIEM can provide value to many organizations.
Problem Statement
While preparing for audits and working to ensure their network is secure, the last thing on
an IT Security Director’s mind is the process of incident handling. By addressing incident
handling before an incident occurs an organization can be better prepared to handle that
challenge. Additionally, by utilizing existing technology and extending its capabilities, workflow
can be streamlined and the time taken for incident resolution can be decreased. Integration of the
incident handling workflow within an existing SIEM tool can further extend the capabilities of
security personnel by arranging pertinent, disparate data in the same location.
An Incident Management Framework Utilizing SIEM Technology !10
Problem Causes
Information security attacks and subsequent breaches continue to be at the forefront of
business and consumer affairs. Major headlines surrounding data security breaches at large
retailers like TJX and Target have attracted the ire of consumers and regulators. The breach of
Sony’s Playstation network resulted in a $117 Million class-action lawsuit (Palermo, 2015). The
data breach at TJX cost the retail company over $250 Million (Vijayan, 2008). The increased
deployment of new technologies increases potential attack vectors and security practitioner
workload drive a need for a simplified way of managing information security incidents (Mulvey,
2011). With more than 80% of enterprises reporting successful breaches (PWC, 2014), and those
breaches becoming increasingly expensive, managing information security incidents becomes
paramount.
Business Impacts
Information security incidents can be costly. The largest examples include TJX,
Heartland Payment Systems and Target (Palermo, 2015). However, breaches can be so costly for
smaller businesses that they can go bankrupt (Rosivach, 2012). Impacts of a security breach can
include a loss of sales due to a lack of consumer confidence, the closure of the business, as well
as financial and regulatory sanctions. None of these items are good for an enterprise’s bottom
line. Managing incidents effectively can reduce the cost of the breach by reducing reaction time.
Cost Analysis
Assuming that an enterprise has some kind of SIEM or Log Management Tool installed
the additional costs of customizing that tool to better handle incident management and response
are minimal compared to the cost and lost time of not being able to handle an incident efficiently.
An Incident Management Framework Utilizing SIEM Technology !11
Typically customization of this tool can take up to 40 hours of work by a specialized consultant
billing at $250-$300 per hour; these were my bill-rates as a former professional
services consultant. For a total outlay of $10,000 a breach which costs $1,000,000 can be more
effectively managed, and can even reduce the cost of that breach.
Risk Analysis
Implementation of the SIEM customization required for deploying an incident
management framework is a fairly straight-forward process with little overall risk to the system.
Some system restarts and interactive, iterative testing will be required to ensure the deployed
customization works and meets the customer’s needs. This testing and potential system restart
activities can potentially interrupt the business day effecting the work of security analysts.
Changing the time of these activities to occur after working hours may alleviate this potential
interruption in service.
After implementation there is a risk that the SIEM customization may not grow or meet
an enterprise’s changing demands reflecting incident management. Different business units,
changing regulatory requirements, and the use of new and different security tools can directly
effect the quality and usability of any customization implemented for a incident management
tool. As such there is a risk that once customization is implemented and the incident response
process is ingrained with the tool’s customization the environment may outgrow the tool
requiring further consulting and technical assistance. Further consulting engagements may be
required to modify the tool for changing conditions.
An Incident Management Framework Utilizing SIEM Technology !12
Detailed and Functional Requirements
Functional Requirements
One source of guidance for Incident Response Processes and Policies is NIST Standard
800-61. NIST provides guidance for what activity can constitute an incident as well as how the
incident can be described. Attributes surrounding the incident can include criteria such as time
cost, financial cost, priority, and severity. NIST also provides guidance on more practical
portions of incident management, such as cataloging the systems and software involved as well
as what personnel may be required to help remediate the issue and install safeguards from a
repeat.
Based upon NIST guidance recording the following attributes recorded in an incident
management tool should include:
• Source of Incident (internal attack, external attack, unknown, etc.)
• Attack vector (human/social engineering, human/policy violation, human/misconfiguration,
software exploit, etc.)
• Priority of Incident (high, medium, low)
• Severity of Incident (high, medium, low)
• Investigation Stage
• Tracking of notification, if required
• Status of detection and containment
• Status of attack (reconnaissance, exploitation, exfiltration)
• Information surrounding user(s) and system(s) involved
• Information surrounding how long the breach has occurred between penetration and detection
An Incident Management Framework Utilizing SIEM Technology !13
Detailed Requirements
Defining Detailed Requirements for this project requires a business requirements
mapping. The attributes presented by NIST are not specific requirements, rather, they are general
guidance based upon the experiences of various businesses and government entities. Different
organizations will have slightly different needs with what information needs to be tracked when
an incident occurs. Therefore the guidance from NIST needs to be tailored to the specific
organization. For instance, when an incident occurs, differentiating between a back-end database
and front-end web system is a natural expectation, but only specialized organizations like utilities
may need to differentiate between embedded control systems (SCADA) and general
infrastructure, whereas military environments will need to record the classification of the
environment which was breached. Regulatory concerns will also need to be considered as
specific regulations for different industries and organizations have different reporting
requirements for incidents. The development of these detailed requirements is predicated upon
the consultant meeting with various business stakeholders to develop an appropriate business
requirements mapping for incident handling.
Existing Gaps that a Successful Project Would Fill
Currently the gap presented is that an existing organization does not have a standardized
and concise way to manage information security incidents. The goal of this project is to
providing a standardized interface and methodology for managing incidents by better utilizing an
installed SIEM product. By aligning the newly-developed incident management process to the
NIST incident management framework further gaps involving regulatory compliance can also be
filled.
An Incident Management Framework Utilizing SIEM Technology !14
Project Design
Scope
The expected outcome of this project is to build a customized incident management
framework on an existing SIEM tool which has already been deployed within the organization.
Prior to this project the SIEM will be installed and functioning with content present which
detects anomalies conditions which warrant further manual investigation. Ideally the majority of
these anomalies will be classified as incidents while the rest will be considered false positives
which can eventually be tuned out from the system.
Tuning the SIEM installation’s detection capabilities, the introduction of new security or
system event sources to the SIEM is not included within the project scope. Installing a SIEM
from scratch and outlining the organization’s business use cases for the SIEM such as detection
of insider threats, perimeter protection, fraud detection, compliance augmentation or data
exfiltration will not be included in this project; it assumed that the SIEM is already being used
for at least a portion of those business use cases. This project will focus on managing the
incidents such as those listed in the use cases above within the SIEM tool.
The introduction of a simple incident management framework, if not already present, will
be introduced. The steps in this incident management framework will align with best practices as
dictated by NIST standard 800-61. Customization of the SIEM’s ticketing or case system will
allow the SIEM to act as a repository of information through the incident handling process. The
customized incident management framework will allow tracking of an incident through all of its
stages from initial detection through regulatory reporting if required. A business requirements
An Incident Management Framework Utilizing SIEM Technology !15
mapping, driven by guidance from NIST 800-61 will be used to implement a incident
management framework or workflow within the SIEM product.
Assumptions
It is safe to assume that all enterprises will be successfully attacked in some method or
another (PWC, 2014). Regulatory and compliance guidance from standards like ISO 27001,
NIST, PCI-DSS, and FISMA support and direct enterprises to implement an incident response
plan. Therefore, the next logical step would be to create and utilize an incident response process.
The assumption surrounding this project would be that making use of a new, standalone tool for
incident management would not be cost or time-effective for an organization. Instead utilizing an
existing SIEM and Log Management tool to streamline the incident response process will result
in savings in financial and time-cost.
The other assumption is that the SIEM product being utilized supports a ticketing or case
management system for tracking incidents and information security events. Not all SIEM
products have this required functionality. For purposes of this project it is assumed the SIEM
product in use is suite.
Project Phases
The phases of this project include a Requirements Gathering phase which will be used to
determine if an incident management framework already exists and/or if this framework needs to
be updated or modified. Once a determination is made about the incident management
framework either the existing framework will be updated or a new framework created. This
framework will be determined by the guidance of NIST 800-61 as well as a business
requirements mapping. This can be considered a Business Requirements Mapping Phase. Next
An Incident Management Framework Utilizing SIEM Technology !16
the business requirements will be mapped to the technical capabilities and limitations of the
SIEM product or a Technical Planning Phase. Next, technical customization will occur on the
SIEM product, which is the Implementation Phase. A Quality Assurance (QA) Phase will be used
to to allow users to test the changes to the system and ensure the customizations work as
expected.
Timelines
Depending upon the complexity and size of the environment the timeline for this
deployment may be as small as one week or as large as one month. The largest factors in the
variability of this timeline are due to the number of stakeholders who need to be surveyed, the
complexity of the incident management schema required, and the maturity of an existing incident
management plan. If a mature incident management plan exists, it may only need to be slightly
modified to fit the project goal of enhancing the SIEM for incident management. If a full
business requirements mapping is required to develop an incident management plan from scratch
the timeline can increase significantly.
The table below describes the timeline for a more simple engagement where the SIEM is
customized.
An Incident Management Framework Utilizing SIEM Technology !17
Dependencies
As presented in the Timelines section, each Phase of the deployment is dependent upon
the completion of the prior phase. A technical solution cannot be created until business
requirements are determined.
Resource Requirements
Financial resources must be committed to the consulting engagement to develop the
technical solution. However, there are many other resource requirements including the
availability of stakeholders so that they can be interviewed. Also, the availability of the
information security staff to assist in QA of the system and the availability of the system itself
are important resources that must be available.
Risk Factors
The availability of stakeholders and of the system are risks that could prolong or scuttle
the project. There is also the possibility that the customizations to the SIEM product could
trigger software bugs within the SIEM and the SIEM to become unavailable or unusable. It’s also
Phase Estimated Time
Requirements Gathering 4-16 hours
Business Requirements Mapping 8-16 hours
Technical Planning Phase 4-16 hours
Implementation 4-16 hours
Quality Assurance 4 hours
Training and/or Tutorials 0-8 hours
TOTAL 24-88 hours
An Incident Management Framework Utilizing SIEM Technology !18
possible that after the implementation is complete business requirements may change which will
render the customizations useless.
Important Milestones
Each phase of the project could be considered a milestone with relation to the
implementation of the change in SIEM configuration. However, the true milestone of a project
where a new workflow or process is developed is the widespread adoption and successful use of
the incident manage process, which may not occur until after the project itself is delivered.
Deliverable
The creation of a new process and completion of the customization of the SIEM product
could be considered a deliverable; these are tangible accomplishments who’s completion can be
determined easily. The true deliverable is the acceptance and usage of the process and tool by the
organization.
Methodology
Approach Explanation and Defense
The approach presented has been developed because of a combination of factors. Most
importantly the approach is designed to be simple and straightforward. Utilizing an existing
SIEM implementation reduces the capital outlay required and allows the continued use of an
environment that security practitioners are familiar utilizing. Aligning the tenants of incident
response from a standard like NIST 800-61 to an organization’s business keeps the process of
incident response germane to business practices and regulatory requirements.
An Incident Management Framework Utilizing SIEM Technology !19
An alternate approach to creating an incident response framework for an organization
would be counter-intuitive. Business will not change or align their practices due to the limitations
of a software tool or generalities provided by the guidance in a government standard.
The scalability and long-term success of the solution will be bolstered by what is
determined during the requirements gathering phase of the project. During the requirements
gathering phase information should be determined about how large the organization expects the
SIEM to grow and what prospective, new business challenges the organization may face in the
near future. This allows a consultant to help tailor the SIEM customization to meet these needs.
Additionally, training for the SIEM Manager will be provided so further tailoring to the system
can be provided.
Project Development
Technical Details
Hardware
This project does not include or require the addition of new hardware, just the
customization of existing software based upon business needs.
Software
No additional software is required for this project; some maintenance and changes to
configuration files will be required. Case customization within requires the alteration of
multiple property files; some are simple text files and the others are XML. After these files are
altered they must be distributed among the different components. A new console
session to the system allows an analyst and the consultant to see how the changes are manifested.
An Incident Management Framework Utilizing SIEM Technology !20
Tech Stack
This solution does not require the integration of multiple components. However, a more
complex solution if the SIEM did not support functionality like cases and workflow would be to
integrate an additional tool for incident management.
Architecture Details
Because this is an enhancement of an architecture which is already deployed, there is no
new architecture to describe. The existing SIEM architecture includes a dedicated SIEM server
and client software installed on workstations. Configuration changes for Case customization, the
core of mapping the Business Requirements to the Technical Implementation, occur on both the
client and server systems.
Final Output
The final output of this project is the development of customized screens within the
SIEM console that allow for a tailored incident management workflow which matches the
business needs of the organization.
Quality Assurance
Quality assurance of the incident management framework is split into two facets; one is
the monitoring of the SIEM back-end logs and processes to ensure there are no errors generated
from the changes made to the system configuration. The other half of the quality assurance is to
navigate through and select and test the different options and labels which have been created and
are displayed within the SIEM console. This “check” of the options configured ensures that the
customer receives what they are expecting in terms of functionality and usage.
An Incident Management Framework Utilizing SIEM Technology !21
Acceptance Criteria
Acceptance of the solution will be based upon the delivery of the implementation
compared with the criteria which were developed during the Business Requirements phase of the
project. The Business Requirements phase exists to enumerate the exact requirements which the
organization determines is necessary. Barring technical limitations of the product, if these
requirements are delivered and are functional the project should be accepted.
Implementation Plan
Strategy for Implementation
The strategy of this implementation relies heavily upon non-technical sequential phases.
Thorough discussions with practitioners and business owners to best understand organizational
needs drive the technical features that are implemented within the SIEM product. The overall
implementation is guided by the industry-standard “Plan Do Check Act” method found within
frameworks like COBIT and Six-Sigma. The project phases and timelines adhere to this
paradigm.
Plan — Meetings with stakeholders to understand business requirements, Requirements
Gathering and Business Requirements Mapping
Do — Develop and deploy the technical changes to the SIEM product, Technical
Planning and Implementation
Check — Quality Assurance that there are no errors on the system
Act — Quality Assurance that workflow is logical and fits organizational needs, tutorial
and training on how to use the system is accepted
An Incident Management Framework Utilizing SIEM Technology !22
Implementation Phases
Requirements Gathering — This phase consists of meetings with stakeholders to
understand the organization’s risk management framework as well as the review of any
documentation or artifacts surrounding existing risk management policies. The maturity of the
risk management process may be assessed at this stage.
Business Requirements Mapping — This phase determines if modifications are required
to the incident management framework based upon its maturity and completeness.
Technical Planning — This phase drives the configuration changes which will be
deployed in the next phase. A mapping of what is possible and what is not possible within the
SIEM user interface (UI) is developed.
Technical Implementation — This phase contains the actual technical steps of modifying
the SIEM configuration and implementing these changes.
Quality Assurance — This phase has multiple components; at first the operation of the
SIEM itself is verified. Secondly the workflow process itself is verified and shown to operate to
the organization’s expectations.
Training and Tutorials — This is a continuation of verifying the workflow process to
ensure it works for all users and that all users understand how to get the best use out of the
system.
Go-Live
The “go-live” of this deployment is a straightforward copying of files to both the
SIEM Manager and to clients with the thick-client Console software installed. The
An Incident Management Framework Utilizing SIEM Technology !23
back-end server does not need to be restarted for these changes to take place; only the user needs
to restart their thick client console software on their workstation.
Dependencies
Dependencies within this project are largely logistical and surround the availability of
stakeholders to be identified and interviewed by the consultant (internal or external) who is
performing the phases of the deployment. If the appropriate stakeholders cannot be identified or
are unavailable, the project is at risk of delays.
Deliverables
The final deliverable for this project is a customized user interface in the SIEM which
provides an optimized, efficient and effective incident management framework aligned with the
appropriate organizational objectives. Users of this system will understand how to use the
SIEM’s new capabilities to better execute their daily job functions.
Training Plan
Two types of training are required for successful adoption of the changes implemented by
this project. First, the SIEM administrator must understand the customizations made to the
system and how to update them if necessary. Reference materials must be provided by the
technician performing the implementation and reference manuals are provided by
for this type of engagement.
Secondly, and most importantly, the security practitioners using this implementation and
taking advantage of this revised workflow must understand the incident management process as
it has been implemented and how to utilize the changes in the product. Depending upon the size
An Incident Management Framework Utilizing SIEM Technology !24
of security group using the SIEM this may require formalized training or a simple ad hoc session
walking through the features and customizations on the system.
Risk Assessment
All projects and system changes carry risk. For this specific project technical risks can be
considered minimal. Many risks lie within the availability of stakeholders and the adoption of the
changes proposed to workflow and processes.
Qualitative and Quantitative Risks and their Mitigation
The largest risks to this project involve the inability to complete an effective
Requirements Gathering or Business Requirements Mapping. After the project is implemented
from a technical standpoint the biggest risk is the lack of adoption of new procedures and
workflow.
A poor execution of Requirements Gathering and Requirements Mapping can occur
when the person performing the implementation does not properly understand incident
management practices in general and does not understand what information security risks and
incidents are most important to the organization. Alternately, inappropriate stakeholders and
practitioners could be identified and the information that is supplied to the consultant may be
erroneous.
A lack of adoption of new procedures can occur when an organization is resistant to
change due to institutional design. This lack of flexibility can also be due to the size of the
An Incident Management Framework Utilizing SIEM Technology !25
organization, where large groups can participate in “groupthink” and declare “if we have always
performed this process a specific way in the past, why should we change now?”
These are are all large risks which can prevent the successful completion of the project
but they can be overcome when proper expectations are delivered at the beginning of the project.
Mitigation of these risks can be driven by proper project planning. Engagement by the consultant
can drive the desire for positive change among multiple stakeholders in the organization by
demonstrating the real value of the project, which is ideally creating a more effective process for
practitioners and stakeholders.
The project should be presented in a manner where “buy-in” and a willingness to
participate from all stakeholders is seen as beneficial and not a burden. If the organization
communicates the benefits of the project to stakeholders a drive for developing an optimized
process can grow interest among those effected. This new-found interest can assuage fears
surrounding changes derived from the project and when individuals are requested to follow new
procedures. The addition of more personalities to a project of this nature increases the likelihood
that there could be more detractors who are unwilling to utilize new methodologies.
Cost/Benefit Analysis
The costs of customizing a SIEM tool to better handle incident management and response
are minimal compared to the cost and lost time of not being able to handle an incident efficiently.
Typically customization of the SIEM tool can take up to 40 hours of work by a specialized
consultant billing at $250-$300 per hour. For a total outlay of $10,000 a breach which costs
$1,000,000 can be more effectively managed, and can even reduce the cost of that breach.
Additionally, a streamlined workflow package can aid in reducing the stress placed upon
An Incident Management Framework Utilizing SIEM Technology !26
information security practitioners and provide a concise and uniform method of handling
incidents.
Rollback Plan
A rollback plan for this project would be for the information security practitioners to
continue to use an older incident response model. From a technical aspect the old, default
configuration files would be replaced on the SIEM. The copying of files is a fairly trivial action.
Alternatives
Two major alternatives exist to the implementation of this project. The first would be for
no change to occur at all; this can leave the organization vulnerable to the problems associated
with ad hoc incident management which can include inconsistent incident handling and
lengthened time to resolution. The other alternative would be to implement a incident handling
system outside of the SIEM in a traditional ticketing system which is typically used for
managing IT service requests. This alternate implementation would still require many of the
same steps as outlined in this project such as the further development of an incident handling
process and then mapping that process to the new tool. Finally, the acceptance of the tool and
adherence to the new process by the user community would still be necessary.
Post-Implementation
Support and Support Resources
After project implementation support of the SIEM should be continued by the SIEM
vendor. Support of the customizations will fall to the group managing the SIEM. Revisions to the
customizations will be driven by business needs and requirements set forth by practitioners.
An Incident Management Framework Utilizing SIEM Technology !27
Upon project delivery a documentation of the customizations and how to maintain them should
be delivered to the SIEM manager.
Maintenance, short and long-term
Revisions to the SIEM customizations and incident management plan will be required as
business needs, requirements and threats change. Therefore stakeholders affected by the incident
management plan should plan recurring meetings to reassess the validity of the plan and
effectiveness of the current workflow. Directives surrounding the revision of these plans is
provided by NIST 800-61.
Conclusion
Streamlining and simplifying the incident management plan of multiple organizations has
provided in the ability of these organizations to handle information security incidents in a timely
and consistent manner across many different industries. Providing relevant and accurate data in a
consistent format is important for information security practitioners. By keeping data relevant
and accurate, only events that are deemed necessary for analysis are present. By keeping data
consistent, trends of security incidents can be analyzed over time.
Outcomes and Deliverables
Appendix A displays some deliverables from this project and includes screenshots and
explanations of some of the custom case and incident handling procedures which have been
developed for differing customers. Overall outcomes across multiple customers have been
positive; by having a simplified interface to manage incidents more stakeholders can take part in
the incident handling process. Incident resolution times have decreased for some customers and
An Incident Management Framework Utilizing SIEM Technology !28
trends surrounding groups of users who have received poor education regarding IT security
policy have been identified.
Reflection
As mentioned in my original prospectus, this project is really an amalgam of multiple
projects which I deployed and maintained while working as a consultant for both
and as a consultant and co-founder at Different customers would always have
different requirements and corporate cultures. These differences directed us as consultants (and
later as our own company) to manage the customers in a method which respected their core
business and how they practiced information security. Bringing stakeholders and information
security practitioners together to simplify their daily tasks was a rewarding experience and aided
in many security investigations.
An Incident Management Framework Utilizing SIEM Technology !29
References
Barton, David (2014, August 10) “What to do When a Data Breach Occurs”. CIO Insight.
Retrieved 30 March 2015 from:
http://www.observeit.com/blog/2014/12/29/the-breach-landscape-is-getting-worse/
Fox-IT (2015, February 3) “Cyber security: 60 percent of oil and gas companies do not have an
Incident Response Plan in place.” Fox-IT Blog. Retrieved 5 May 2015 from: https://
www.fox-it.com/en/news/cyber-security-60-percent-oil-gas-companies-incident-response-plan-
place/
Mulvey, Jeanette (2011, February 18) “Playing Catch-Up: IT Departments Face Security
Dilemma”. Business News Daily. Retrieved 1 May 2015 from:
http://www.businessnewsdaily.com/692-playing-catch-up-it-departments-face-security-
dilemma.html
Palermo, Elisabeth (2015, February 6) “10 Worst Data Breaches of All Time”. Tom’s Hardware
Guide. Retrieved 30 March 2015 from:
http://www.tomsguide.com/us/biggest-data-breaches,news-19083.html
PriceWaterhouseCoopers PWC (2014) “2014 Information Security Breaches Survey.”
Department for Business Innovation and Skills. Retrieved 30 March 2015 from:
http://www.pwc.co.uk/assets/pdf/cyber-security-2014-technical-report.pdf
Rosivach, Anne (2012, December 4) “Small Businesses Unprepared for Data Breach.”
AccountingWeb. Retrieved 30 March 2015 from:
http://www.accountingweb.com/article/small-businesses-unprepared-data-breach/220404
An Incident Management Framework Utilizing SIEM Technology !30
Vijayan, Jaikumar (2008, January 17) “One year later: Five takeaways from the TJX Breach.”
Computerworld. Retrieved 05 May 2015 from: http://www.computerworld.com/article/
2538711/cybercrime-hacking/one-year-later--five-takeaways-from-the-tjx-breach.html
An Incident Management Framework Utilizing SIEM Technology !31
Appendix A
This example is from a large enterprise customer. Their case schema for incident handling closely aligns with NIST 800-61 but includes attributes that are specific for their organization such as the region affected by the breach.
This customer had multiple stages for their incidents including Pending (not yet reviewed) In-Progress (review ongoing) Completed (reviewed and solved) Cancelled (for false positives) and Transferred (if another group was responsible for analysis)
A responsible analyst was defined by the “owner” field.
Multiple timestamps were available to track the progression of both the attack and investigation.
Specific infrastructure details were recorded in a standardized format.
Other attributes were available from drop-down boxes including the region that was effected (this was for a global customer) as well as the phase of the attack, the criticality of the resource, ability to restore service and the “best guess” as to what was responsible in the Suspected Actor field.
Not shown is the “Notes” field which allows practitioners to keep a journal of their investigative actions.
An Incident Management Framework Utilizing SIEM Technology !32
This example is from a smaller enterprise customer who had less attributes to maintain.
Here there were less attributes. The values for Impact only allowed choices for 0 (no impact) through 4 (catastrophic outage.) Vulnerability Type only had two values; Accidental and Intentional.
An Incident Management Framework Utilizing SIEM Technology !33
A second tab called “Description” was added. This allowed multiple free-form text boxes for analysts to keep specific notes.