running head: an incident management framework utilizing ... · many organizations, large and...

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.


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


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


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.


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.


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.


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.


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.


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.


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.


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


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.


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


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


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.


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


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 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.


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.


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


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


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


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


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


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.


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


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.


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

http://www.observeit.com/blog/2014/12/29/the-breach-landscape-is-getting-worse/

http://www.businessnewsdaily.com/692-playing-catch-up-it-departments-face-security-dilemma.html

http://www.tomsguide.com/us/biggest-data-breaches,news-19083.html

http://www.pwc.co.uk/assets/pdf/cyber-security-2014-technical-report.pdf

http://www.accountingweb.com/article/small-businesses-unprepared-data-breach/220404


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

http://www.computerworld.com/article/2538711/cybercrime-hacking/one-year-later--five-takeaways-from-the-tjx-breach.html


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.


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.


A second tab called “Description” was added. This allowed multiple free-form text boxes for analysts to keep specific notes.

running head: an incident management framework utilizing ... · many organizations, large and...

Documents