Get Instant Access
to This Blueprint

Security icon

Develop and Implement a Security Incident Management Program

Create a scalable incident response program without breaking the bank.

  • Tracked incidents are often classified into ready-made responses that are not necessarily applicable to the organization. With so many classifications, tracking becomes inefficient and indigestible, allowing major incidents to fall through the cracks.
  • Outcomes of incident response tactics are not formally tracked or communicated, resulting in a lack of comprehensive understanding of trends and patterns regarding incidents, leading to being re-victimized by the same vector.
  • Having a formal incident response document to meet compliance requirements is not useful if no one is adhering to it.

Our Advice

Critical Insight

  • You will experience incidents. Don’t rely on ready-made responses. They’re too broad and easy to ignore. Save your organization response time and confusion by developing your own specific incident use cases.
  • Analyze, track, and review results of incident response regularly. Without a comprehensive understanding of incident trends and patterns, you can be re-victimized by the same attack vector.
  • Establish communication processes and channels well in advance of a crisis. Don’t wait until a state of panic. Collaborate and exchange information with other organizations to stay ahead of incoming threats.

Impact and Result

  • Effective and efficient management of incidents involves a formal process of preparation, detection, analysis, containment, eradication, recovery, and post-incident activities.
  • This blueprint will walk through the steps of developing a scalable and systematic incident response program relevant to your organization.

Develop and Implement a Security Incident Management Program Research & Tools

Start here – read the Executive Brief

Read our concise Executive Brief to find out why you should develop and implement a security incident management program, review Info-Tech’s methodology, and understand the four ways we can support you in completing this project.

3. Maintain and optimize

Manage and improve the incident management process by tracking metrics, testing capabilities, and leveraging best practices.


Member Testimonials

After each Info-Tech experience, we ask our members to quantify the real-time savings, monetary impact, and project improvements our research helped them achieve. See our top member experiences for this blueprint and what our clients have to say.

8.5/10


Overall Impact

$24,466


Average $ Saved

35


Average Days Saved

Client

Experience

Impact

$ Saved

Days Saved

Healthcare Excellence Canada

Guided Implementation

8/10

N/A

5

Corix Infrastructure Inc.

Guided Implementation

10/10

$37,500

20

Afreximbank

Guided Implementation

8/10

$23,500

110

Jet Support Services, Inc.

Workshop

10/10

$12,399

20

The Regional Municipality Of Niagara

Workshop

7/10

N/A

50

Saskatchewan Blue Cross

Guided Implementation

8/10

N/A

5

Hyperloop Technologies, Inc.

Workshop

10/10

$37,199

20

Massey University

Workshop

8/10

$61,999

5

OSI Group LLC

Workshop

8/10

$30,999

20

City Of Greenwood Village

Guided Implementation

10/10

$2,479

10

Interdigital Communications

Workshop

9/10

N/A

N/A

First Hope Bank

Workshop

10/10

$12,399

18

PlayPower, Inc

Guided Implementation

9/10

$30,999

10

Toronto Community Housing Corporation

Guided Implementation

10/10

N/A

N/A

Federal Home Loan Bank of New York

Guided Implementation

8/10

N/A

N/A

Centra Networks

Guided Implementation

10/10

N/A

N/A

STERIS Corporation

Workshop

10/10

N/A

N/A

British Columbia Transit

Workshop

9/10

$500K

20

County of Nevada

Guided Implementation

8/10

N/A

7

City Of Airdrie

Guided Implementation

10/10

$10,000

5

Roosevelt Management Company

Workshop

10/10

$46,499

47

Orange County Sanitation Districts

Guided Implementation

2/10

N/A

N/A

The Exploratorium

Guided Implementation

7/10

$2,555

2

GAI Consultants, Inc.

Guided Implementation

10/10

N/A

20

SIG INFORMATION TECHNOLOGY GmbH

Guided Implementation

10/10

N/A

N/A

City Of Atlanta

Guided Implementation

8/10

$7,640

10

Water District #1 of Johnson County

Workshop

10/10

$619K

120

Gwinnett County

Workshop

10/10

N/A

N/A

Financial Services Regulator Authority of Ontario

Guided Implementation

8/10

$10,000

5

Yamana Gold

Guided Implementation

10/10

N/A

N/A


Onsite Workshop: Develop and Implement a Security Incident Management Program

Onsite workshops offer an easy way to accelerate your project. If you are unable to do the project yourself, and a Guided Implementation isn't enough, we offer low-cost onsite delivery of our project workshops. We take you through every phase of your project and ensure that you have a roadmap in place to complete your project successfully.

Module 1: Prepare Your Incident Response Program

The Purpose

  • Understand the purpose of incident response.
  • Formalize the program.
  • Identify key players and escalation points.

Key Benefits Achieved

  • Common understanding of the importance of incident response.
  • Various business units becoming aware of their roles in the incident management program.
  • Formalized documentation.

Activities

Outputs

1.1

Assess the current process, obligations, scope, and boundaries of the incident management program.

  • Understanding of the incident landscape
1.2

Identify key players for the response team and for escalation points.

  • An identified incident response team
1.3

Formalize documentation.

  • A security incident management charter
  • A security incident management policy
1.4

Prioritize incidents requiring preparation.

  • A list of top-priority incidents
  • A general security incident management plan
  • A security incident response RACI chart

Module 2: Develop Incident-Specific Runbooks

The Purpose

  • Document the clear response procedures for top-priority incidents.

Key Benefits Achieved

  • As incidents occur, clear response procedures are documented for efficient and effective recovery.

Activities

Outputs

2.1

For each top-priority incident, document the workflow from detection through analysis, containment, eradication, recovery, and post-incident analysis.

  • Up to five incident-specific runbooks

Module 3: Maintain and Optimize the Program

The Purpose

  • Ensure the response procedures are realistic and effective.
  • Identify key metrics to measure the success of the program.

Key Benefits Achieved

  • Real-time run-through of security incidents to ensure roles and responsibilities are known.
  • Understanding of how to measure the success of the program.

Activities

Outputs

3.1

Limited scope tabletop exercise.

  • Completed tabletop exercise
3.2

Discuss key metrics.

  • Key success metrics identified

Develop and Implement a Security Incident Management Program

Create a scalable incident response program without breaking the bank.

ANALYST PERSPECTIVE

Security incidents are going to happen whether you’re prepared or not. Ransomware and data breaches are just a few top-of-mind threats that all organizations deal with. Taking time upfront to formalize response plans can save you significantly more time and effort down the road. When an incident strikes, don’t waste time deciding how to remediate. Rather, proactively identify your response team, optimize your response procedures, and track metrics so you can be prepared to jump to action.

Céline Gravelines,
Senior Research Analyst
Security, Risk & Compliance Info-Tech Research Group

Picture of Céline Gravelines

Céline Gravelines,
Senior Research Analyst
Security, Risk & Compliance Info-Tech Research Group

Our understanding of the problem

This Research is Designed For

  • A CISO who is dealing with the following:
    • Inefficient use of time and money when retroactively responding to incidents, negatively affecting business revenue and workflow.
    • Resistance from management to adequately develop a formal incident response plan.
    • Lack of closure of incidents, resulting in being re-victimized by the same vector.

This Research Will Help You

  • Develop a consistent, scalable, and usable incident response program that is not resource intensive.
  • Track and communicate incident response in a formal manner.
  • Reduce the overall impact of incidents over time.
  • Learn from past incidents to improve future response processes.

This Research Will Also Assist

  • Business stakeholders who are responsible for the following:
  • Improving workflow and managing operations in the event of security incidents to reduce any adverse business impacts.
  • Ensuring that incident response compliance requirements are being adhered to.

This Research Will Help Them

  • Efficiently allocate resources to improve incident response in terms of incident frequency, response time, and cost.
  • Effectively communicate expectations and responsibilities to users.

Executive Summary

Situation

  • Security incidents are inevitable, but how they’re dealt with can make or break an organization. Poor incident response negatively affects business practices, including workflow, revenue generation, and public image.
  • The incident response of most organizations is ad hoc at best. A formal management plan is rarely developed or adhered to, resulting in ineffective firefighting responses and inefficient allocation of resources.

Complication

  • Tracked incidents are often classified into ready-made responses that are not necessarily applicable to the organization. With so many classifications, tracking becomes inefficient and indigestible, allowing major incidents to fall through the cracks.
  • Outcomes of incident response tactics are not formally tracked or communicated, resulting in a lack of comprehensive understanding of trends and patterns regarding incidents, leading to being revictimized by the same vector.
  • Having a formal incident response document to meet compliance requirements is not useful if no one is adhering to it.

Resolution

  • Effective and efficient management of incidents involves a formal process of preparation, detection, analysis, containment, eradication, recovery, and post-incident activities.
  • This blueprint will walk through the steps of developing a scalable and systematic incident response program relevant to your organization.

Info-Tech Insight

  • You will experience incidents. Don’t rely on ready-made responses. They’re too broad and easy to ignore. Save your organization response time and confusion by developing your own specific incident use cases.
  • Analyze, track, and review results of incident response regularly. Without a comprehensive understanding of incident trends and patterns, you can be re-victimized by the same attack vector.
  • Establish communication processes and channels well in advance of a crisis. Don’t wait until a state of panic. Collaborate and exchange information with other organizations to stay ahead of incoming threats.

Data breaches are resulting in major costs across industries

Per capita cost by industry classification of benchmarked companies (measured in USD)

This is a bar graph showing the per capita cost by industry classification of benchmarked companies(measured in USD). the companies are, in decreasing order of cost: Health; Financial; Services; Pharmaceutical; Technology; Energy; Education; Industrial; Entertainment; Consumer; Media; Transportation; Hospitality; Retail; Research; Public

Average data breach costs per compromised record hit an all-time high of $148 (in 2018).
(Source: IBM, “2018 Cost of Data Breach Study)”

% of systems impacted by a data breach
1%
No Impact
19%
1-10% impacted
41%
11-30% impacted
24%
31-50% impacted
15%
> 50% impacted
% of customers lost from a data breach
61% Lost
< 20%
21% Lost 20-40% 8% Lost
40-60%
6% Lost
60-80%
4% Lost
80-100%
% of customers lost from a data breach
58% Lost
<20%
25% Lost
20-40%
9% Lost
40-60%
5% Lost
60-80%
4% Lost
80-100%

Source: Cisco, “Cisco 2017 Annual Cybersecurity Report”

Defining what is security incident management

IT Incident

Any event not a part of the standard operation of a service which causes, or may cause, the interruption to, or a reduction in, the quality of that service.

Security Event:

A security event is anything that happens that could potentially have information security implications.

  • A spam email is a security event because it may contain links to malware.
  • Organizations may be hit with thousands or perhaps millions of identifiable security events each day.
  • These are typically handled by automated tools or are simply logged.

Security Incident:

A security incident is a security event that results in damage such as lost data.

  • Incidents can also include events that don't involve damage but are viable risks.
  • For example, an employee clicking on a link in a spam email that made it through filters may be viewed as an incident.

It’s not a matter of if you have a security incident, but when

The increasing complexity and prevalence of threats have finally caught the attention of corporate leaders. Prepare for the inevitable with an incident response program.

  1. A formalized incident response program reduced the average cost of a data breach (per capita) from $148 to $134, while third-party involvement increased costs by $13.40.
  2. US organizations lost an average of $7.91 million per data breach as a result of increased customer attrition and diminished goodwill. Canada and the UK follow suit at $1.57 and $1.39 million, respectively.
  3. 73% of breaches are perpetrated by outsiders, 50% are the work of criminal groups, and 28% involve internal actors.
  4. 55% of companies have to manage fallout, such as reputational damage after a data breach.
  5. The average cost of a data breach increases by $1 million if left undetected for > 100 days.

(Sources: IBM, “2018 Cost of Data Breach Study”; Verizon, “2017 Data Breach Investigations Report”; Cisco, “Cisco 2018 Annual Cybersecurity Report”)

Threat Actor Examples

The proliferation of hacking techniques and commoditization of hacking tools has enabled more people to become threat actors. Examples include:
  • Organized Crime Groups
  • Lone Cyber Criminals
  • Competitors
  • Nation States
  • Hacktivists
  • Terrorists
  • Former Employees
  • Domestic Intelligence Services
  • Current Employees (malicious and accidental)

Benefits of an incident management program

Effective incident management will help you do the following:

Improve efficacy
Develop structured processes to increase process consistency across the incident response team and the program as a whole. Expose operational weak points and transition teams from firefighting to innovating.

Improve threat detection, prevention, analysis, and response
Enhance your pressure posture through a structured and intelligence-driven incident handling and remediation framework.

Improve visibility and information sharing
Promote both internal and external information sharing to enable good decision making.

Create and clarify accountability and responsibility
Establish a clear level of accountability throughout the incident response program, and ensure role responsibility for all tasks and processes involved in service delivery.

Control security costs
Effective incident management operations will provide visibility into your remediation processes, enabling cost savings from misdiagnosed issues and incident reduction.

Identify opportunities for continuous improvement
Increase visibility into current performance levels and accurately identify opportunities for continuous improvement with a holistic measurement program.

Impact

Short term:
  • Streamlined security incident management program.
  • Formalized and structured response process.
  • Comprehensive list of operational gaps and initiatives.
  • Detailed response runbooks that predefine necessary operational protocol.
  • Compliance and audit adherence.
Long term:
  • Reduced incident costs and remediation time.
  • Increased operational collaboration between prevention, detection, analysis, and response efforts.
  • Enhanced security pressure posture.
  • Improved communication with executives about relevant security risks to the business.
  • Preserved reputation and brand equity.

Incident management is essential for organizations of any size

Your incidents may differ, but a standard response ensures practical security.

Certain regulations and laws require incident response to be a mandatory process in organizations.

Compliance Standard Examples Description
Federal Information Security Modernization Act (FISMA)
  • Organizations must have “procedures for detecting, reporting, and responding to security incidents” (2002).
  • They must also “inform operators of agency information systems about current and potential information security threats and vulnerabilities.”
Federal Information Processing Standards (FIPS)
  • “Organizations must: (i) establish an operational incident handling capability for organizational information systems that includes adequate preparation, detection, analysis, containment, recovery, and user response activities.”
Payment Card Industry Data Security Standard (PCI DSS v3)
  • 12.5.3: “Establish, document, and distribute security incident response and escalation procedures to ensure timely and effective handling of all situations.”
Health Insurance Portability and Accountability Act (HIPAA)
  • 164.308: Response and Reporting – “Identify and respond to suspected or known security incidents; mitigate, to the extent practicable, harmful effects of security incidents that are known to the covered entity; and document security incidents and their outcomes.”

Security incident management is applicable to all verticals

Examples:
  • Finance
  • Insurance
  • Healthcare
  • Public administration
  • Education services
  • Professional services
  • Scientific and technical services

Maintain a holistic security operations program

Legacy security operations centers (SOCs) fail to address gaps between data sources, network controls, and human capital. There is limited visibility and collaboration between departments, resulting in siloed decisions that do not support the best interests of the organization.

Security operations is part of what Info-Tech calls a threat collaboration environment, where members must actively collaborate to address cyberthreats affecting the organization’s brand, business operation, and technology infrastructure on a daily basis.

Prevent: Defense in depth is the best approach to protect against unknown and unpredictable attacks. Diligent patching and vulnerability management, endpoint protection, and strong human-centric security (amongst other tactics) are essential. Detect: There are two types of companies – those who have been breached and know it, and those who have been breached and don’t know it. Ensure that monitoring, logging, and event detection tools are in place and appropriate to your organizational needs.
Analyze: Raw data without interpretation cannot improve security and is a waste of time, money, and effort. Establish a tiered operational process that not only enriches data but also provides visibility into your threat landscape. Respond: Organizations can’t rely on an ad hoc response anymore – don’t wait until a state of panic. Formalize your response processes in a detailed incident runbook to reduce incident remediation time and effort.

Info-Tech’s incident response blueprint is one of four security operations initiatives

Design and Implement a Vulnerability Management Program Vulnerability Management
Vulnerability management revolves around the identification, prioritization, and remediation of vulnerabilities. Vulnerability management teams hunt to identify which vulnerabilities need patching and remediating.
  • Vulnerability Tracking Tool
  • Vulnerability Scanning Tool RFP Template
  • Penetration Test RFP Template
  • Vulnerability Mitigation Process Template
Integrate Threat Intelligence Into Your Security Operations Vulnerability Management
Vulnerability management revolves around the identification, prioritization, and remediation of vulnerabilities. Vulnerability management teams hunt to identify which vulnerabilities need patching and remediating.
  • Threat Intelligence Maturity Assessment Tool
  • Threat Intelligence RACI Tool
  • Threat Intelligence Management Plan Template
  • Threat Intelligence Policy Template
  • Threat Intelligence Alert Template
  • Threat Intelligence Alert and Briefing Cadence Schedule Template
Develop Foundational Security Operations Processes Operations
Security operations include the real-time monitoring and analysis of events based on the correlation of internal and external data sources. This also includes incident escalation based on impact. These analysts are constantly tuning and tweaking rules and reporting thresholds to further help identify which indicators are most impactful during the analysis phase of operations.
  • Security Operations Maturity Assessment Tool
  • Security Operations Event Prioritization Tool
  • Security Operations Efficiency Calculator
  • Security Operations Policy
  • In-House vs. Outsourcing Decision-Making Tool
  • Seccrimewareurity Operations RACI Tool
  • Security Operations TCO & ROI Comparison Calculator
Develop and Implement a Security Incident Management Program Incident Response (IR)
Effective and efficient management of incidents involves a formal process of analysis, containment, eradication, recovery, and post-incident activities. Incident response teams coordinate root cause and incident gathering while facilitating post-incident lessons learned. Incident response can provide valuable threat data that ties specific indicators to threat actors or campaigns.
Security Incident Management Policy
  • Security Incident Management Plan
  • Incident Response Maturity Assessment Tool
  • Security Incident Runbook Prioritization Tool
  • Security Incident Management RACI Tool
  • Various Incident Management Runbooks

Understand how incident response ties into related processes

Info-Tech Resources:
Business Continuity Plan Develop a Business Continuity Plan
Disaster Recovery Plan Create a Right-Sized Disaster Recovery Plan
Security Incident Management Develop and Implement a Security Incident Management Program
Incident Management Incident and Problem Management
Service Desk Standardize the Service Desk

Develop and Implement a Security Incident Management Program – project overview

1. Prepare 2. Operate 3. Maintain and Optimize
Best-Practice Toolkit 1.1 Establish the Drivers, Challenges, and Benefits.

1.2 Examine the Security Incident Landscape and Trends.

1.3 Understand Your Security Obligations, Scope, and Boundaries.

1.4 Gauge Your Current Process to Identify Gaps.

1.5 Formalize the Security Incident Management Charter.

1.6 Identify Key Players and Develop a Call Escalation Tree.

1.7 Develop a Security Incident Management Policy.

2.1 Understand the Incident Response Framework.

2.2 Understand the Purpose of Runbooks.

2.3 Prioritize the Development of Incident-Specific Runbooks.

2.4 Develop Top-Priority Runbooks.

2.5 Fill Out the Root-Cause Analysis Template.

2.6 Customize the Post-Incident Review Questions Tracking Tool to Standardize Useful Questions for Lessons-Learned Meetings.

2.7 Complete the Security Incident Report Template.

3.1 Conduct Tabletop Exercises.

3.2 Initialize a Security Incident Management Metrics Program.

3.3 Leverage Best Practices for Continuous Improvement.

Guided Implementations Understand the incident response process, and define your security obligations, scope, and boundaries.

Formalize the incident management charter, RACI, and incident management policy.
Use the framework to develop a general incident management plan.

Prioritize and develop top-priority runbooks.
Develop and facilitate tabletop exercises.

Create an incident management metrics program, and assess the success of the incident management program.
Onsite Workshop Module 1:
Prepare for Incident Response
Module 2:
Handle Incidents
Module 3:
Review and Communicate Security Incidents
Phase 1 Outcome:
  • Formalized stakeholder support
  • Security Incident Management Policy
  • Security Incident Management Charter
  • Call Escalation Tree
  • Phase 2 Outcome:
    • A generalized incident management plan
    • A prioritized list of incidents
    • Detailed runbooks for top-priority incidents
    Phase 3 Outcome:
    • A formalized tracking system for benchmarking security incident metrics.
    • Recommendations for optimizing your security incident management processes.

    Workshop overview

    Contact your account representative or email Workshops@InfoTech.com for more information.

    Workshop Day 1 Workshop Day 2 Workshop Day 3 Workshop Day 4 Workshop Day 5
    Activities
    • Kick off and introductions.
    • High-level overview of weekly activities and outcomes.
    • Understand the benefits of security incident response management.
    • Formalize stakeholder support.
    • Assess your current process, obligations, and scope.
    • Develop RACI chart.
    • Define impact and scope.
    • Identify key players for the threat escalation protocol.
    • Develop a security incident response policy.
    • Develop a general security incident response plan.
    • Prioritize incident-specific runbook development.
    • Understand the incident response process.
    • Develop general and incident-specific call escalation trees.
    • Develop specific runbooks for your top-priority incidents (e.g. ransomware).
      • Detect the incident.
      • Analyze the incident.
      • Contain the incident.
      • Eradicate the root cause.
      • Recover from the incident.
      • Conduct post-incident analysis and communication.
    • Develop specific runbooks for your next top-priority incidents:
      • Detect the incident.
      • Analyze the incident.
      • Contain the incident.
      • Eradicate the root cause.
      • Recover from the incident.
      • Conduct post-incident analysis and communication.
    • Determine key metrics to track and report.
    • Develop post-incident activity documentation.
    • Understand best practices for both internal and external communication.
    • Finalize key deliverables created during the workshop.
    • Present the security incident response program to key stakeholders.
    • Workshop executive presentation and debrief.
    • Finalize main deliverables.
    • Schedule subsequent Analyst Calls.
    • Schedule feedback call.
    Deliverables
    • Security Incident Management Maturity Checklist ‒ Preliminary
    • Security Incident Management RACI Tool
    • Security Incident Management Policy
    • General incident management plan
    • Security Incident Management Runbook
    • Development prioritization
    • Prioritized list of runbooks
    • Understanding of incident handling process
    • Incident-specific runbooks for two incidents (including threat escalation criteria and Visio workflow)
    • Discussion points for review with response team
    • Incident-specific runbooks for two incidents (including threat escalation criteria and Visio workflow)
    • Discussion points for review with response team
    • Security Incident Metrics Tool
    • Post-Incident Review Questions Tracking Tool
    • Post-Incident Report Analysis Template
    • Root Cause Analysis Template
    • Post-Incident Review Questions Tracking Tool
    • Communication plans
    • Workshop summary documentation
  • All final deliverables
  • Measured value for Guided Implementations

    Engaging in GIs doesn’t just offer valuable project advice – it also results in significant cost savings.

    GI Purpose Measured Value
    Section 1: Prepare

    Understand the need for an incident response program.
    Develop your incident response policy and plan.
    Develop classifications around incidents.
    Establish your program implementation roadmap.

    Time, value, and resources saved using our classification guidance and templates: 2 FTEs*2 days*$80,000/year = $1,280
    Time, value, and resources saved using our classification guidance and templates:
    2 FTEs*5 days*$80,000/year = $3,200

    Section 2: Operate

    Prioritize runbooks and develop the processes to create your own incident response program:

  • Detect
  • Analyze
  • Contain
  • Eradicate
  • Recover
  • Post-Incident Activity
  • Time, value, and resources saved using our guidance:
    4 FTEs*10 days*$80,000/year = $12,800 (if done internally)

    Time, value, and resources saved using our guidance:
    1 consultant*15 days*$2,000/day = $30,000 (if done by third party)
    Section 3: Maintain and Optimize Develop methods of proper reporting and create templates for communicating incident response to key parties. Time, value, and resources saved using our guidance, templates, and tabletop exercises:
    2 FTEs*3 days*$80,000/year = $1,920
    Total Costs To just get an incident response program off the ground. $49,200

    Insurance company put incident response aside; executives were unhappy

    Organization implemented ITIL, but formal program design became less of a priority and turned more ad hoc.

    Situation

    • Ad hoc processes created management dissatisfaction around the organization’s ineffective responses to data breaches.
    • Because of the lack of formal process, an entirely new security team needed to be developed, costing people their positions.

    Challenges

    • Lack of criteria to categorize and classify security incidents.
    • Need to overhaul the long-standing but ineffective program means attempting to change mindsets, which can be time consuming.
    • Help desk is not very knowledgeable on security.
    • New incident response program needs to be in alignment with data classification policy and business continuity.
    • Lack of integration with MSSP’s ticketing system.

    Next steps:

    • Need to get stakeholder buy-in for a new program.
    • Begin to establish classification/reporting procedures.

    Follow this case study to Phase 1

    Phase 1

    Prepare

    Develop and Implement a Security Incident Management Program

    Phase 1: Prepare

    PHASE 1 PHASE 2 PHASE 3
    Prepare Operate Optimize

    This phase walks you through the following activities:

    1.1 Establish the drivers, challenges, and benefits.
    1.2 Examine the security incident landscape and trends.
    1.3 Understand your security obligations, scope, and boundaries.
    1.4 Gauge your current process to identify gaps.
    1.5 Formalize a security incident management charter.
    1.6 Identify key players and develop a call escalation tree.
    1.7 Develop a security incident management policy.

    This phase involves the following participants:

    • CISO
    • Security team
    • IT staff
    • Business leaders

    Outcomes of this phase

    • Formalized stakeholder support.
    • Security incident management policy.
    • Security incident management charter.
    • Call escalation tree.

    Phase 1 outline

    Call 1-888-670-8889 or email GuidedImplementations@InfoTech.com for more information.

    Complete these steps on your own, or call us to complete a guided implementation. A guided implementation is a series of 2-3 advisory calls that help you execute each phase of a project. They are included in most advisory memberships.

    Guided Implementation 1: Prepare for Incident Response
    Proposed Time to Completion: 3 Weeks
    Step 1.1-1.3 Understand Incident Response Step 1.4-1.7 Begin Developing Your Program
    Start with an analyst kick-off call:
  • Discuss your current incident management status.
  • Review findings with analyst:
  • Review documents.
  • Then complete these activities…
    • Establish your security obligations, scope, and boundaries.
    • Identify the drivers, challenges, and benefits of formalized incident response.
    • Review any existing documentation.
    Then complete these activities…
    • Discuss further incident response requirements.
    • Identify key players for escalation and notifications.
    • Develop the policy.
    • Develop the plan.

    With these tools & templates:
    Security Incident Management Maturity Checklist ‒ Preliminary Information Security Requirements Gathering Tool

    With these tools & templates:
    Security Incident Management Policy
    Security Incident Management Plan
    Phase 1 Results & Insights:

    Ready-made incident response solutions often contain too much coverage: too many irrelevant cases that are not applicable to the organization are accounted for, making it difficult to sift through all the incidents to find the ones you care about. Develop specific incident use cases that correspond with relevant incidents to quickly identify the response process and eliminate ambiguity when handled by different individuals.

    Ice breaker: What is a security incident for your organization?

    1.1 Whiteboard Exercise – 60 minutes

    How do you classify various incident types between service desk, IT/infrastructure, and security?

    • Populate sticky notes with various incidents and assign them to the appropriate team.
      • Who owns the remediation? When are other groups involved? What is the triage/escalation process?
      • What other groups need to be notified (e.g. cyber insurance, Legal, HR, PR)?
      • Are there dependencies among incidents?
      • What are we covering in the scope of this project?

    1.1 Establish the drivers, challenges, and benefits of completing this project

    Don’t let your pain points and blockers keep you from the many benefits of security incident management.

    Drivers

    What problems and threats are you currently facing because you don’t follow a formal process for incident management?

    Challenges

    Why hasn’t this new project been started yet? What is stopping management from getting on board?

    Benefits

    What will the business gain from developing and following an incident response plan? The benefits must outweigh the blockers to be worthwhile.

    Typical pain points include:

    • High susceptibility to risk
    • Costly repairs to damaged and lost assets
    • Downtime of resources
    • Time and effort wasted retroactively patching preventable security issues
    • Legal and compliance ramifications
    • Reputational damage

    Typical challenges include:

  • Time constraints
  • Budget constraints
  • Operational disruption
  • A lack of explicit ROI
  • Overconfidence: “We have the best technical defenses; we won’t face harmful incidents.”
  • Typical benefits include:

    • ↓ Outages and downtime
    • ↓ Repeated/recurring incidents
    • ↓ Reputation damage
    • ↑ Protection of assets
    • ↑ Productivity
    • ↑ Regulatory compliance
    • ↑ Preparedness
    • ↑ User satisfaction

    1.2 There is a wide gamut of threat vectors and attack types

    Denial of Service

    27%

    A compromise of the availability of networks and systems. Most targeted industries include:
    • Entertainment
    • Professional Services
    • Public

    Privilege Misuse

    18%

    Malicious use of internal resources. Common use cases include:
    • Healthcare workers stealing PII
    • Internally-driven public admin data breaches

    Crimeware

    16%

    Malware with predominantly email-based delivery:
    • Ransomware
    • C2 exploits
    • Worms

    Web App Attacks

    15%

    Exploits of code-level vulnerabilities as well as thwarting application mechanisms. Actor tactics include:
    • Stolen credentials
    • SQLi
    • Brute force

    Physical Theft

    14%

    An information asset goes missing (through misplacement or malice). Most frequently targeted industries include:
  • Public
  • Healthcare
  • Miscellaneous Errors

    6%

    Unintentional actions compromising an attribute of a security asset. Examples include:
    • Misdelivery
    • Publishing error
    • Disposal error

    Cyber Espionage

    0.7%

    Unauthorized and malicious network access. Most targeted industries include:
    • Manufacturing
    • Public
    • Professional

    Point of Sale (POS)

    0.5%

    Remote attacks on POS terminals and controllers. Most frequently targeted industries include:
    • Accommodation & Food Services
    • Retail

    Payment Card Skimmers

    0.2%

    Skimming devices that are implanted on an asset to read payment cards. Devices include:
    • ATMs
    • Gas pumps
    • POS terminals

    Everything Else

    2%

    Any incident that does not classify as one of the other categories:
    • Phishing
    • Footprinting
    • Pretexting
    (Source: Verizon, “2017 Data Breach Investigations Report”)

    88% of attacks fall under ten areas according to Verizon’s “2017 Data Breach Investigations Report.”

    Understand why your organization should focus on security incident management

    An ineffective incident management process can lead to lost productivity, more downtime, and higher support costs.

    This image shows the various costs associated with poor incident management. The headlines are: Incident resolution takes too long; Incidents don’t get fixed properly initially; Incidents get escalated too quickly; Incidents are not prioritized correctly at intake.

    Understand how a security incident of any type affects your security program resourcing

    Security resourcing today is being treated like any other IT project resourcing.

    You have an annual budget allotment, you look at the projects you have to do, you look at what you think your security posture should be, and you allocate time, money, and resources to deal with those issues.

    Understand what constitutes a security incident:

    • Traditional security incidents include malware detection, system availability loss, or data compromise.
    • Security incidents can also be IT expansion or growth that the security program has not planned for. If the business or IT makes some IT systems change that has not been proactively secured, it can have the same effect on security program resourcing.
    this image contains a line graph showing mitigation and control expenditure over time, comparing the higher cost of a reactive mitigation posture and the lower cost of a proactive Mitigation Posture

    Establish a unified threat collaboration environment

    Security operations is part of what Info-Tech calls a threat collaboration environment, where members must actively collaborate to address threats impacting the organization’s brand, operations, and technology infrastructure.

    Incident Response
    • Managing incident escalation and response.
    • Coordinating root cause and incident gathering.
    • Facilitating post-incident lessons learned.
    Develop and Implement a Security Incident Management Program
    Vulnerability Management
    • Managing system patching and risk acceptance.
    • Conducting vulnerability assessment and penetration testing.
    Design and Implement a Vulnerability Management Program
    Threat Intelligence
    • Gathering and analyzing external threat data.
    • Liaising with peers, industry, and government.
    • Publishing threat alerts, reports, and briefings.
    Integrate Threat Intelligence Into Your Security Operations
    Security Operations
    • Monitoring in real-time and triaging events.
    • Escalating events to incident management team.
    • Tuning and tweaking rules and reporting thresholds.
    Develop Foundational Security Operations Processes

    Info-Tech Best Practice

    Ensure that information flows freely throughout the threat collaboration environment – each function should serve to feed and enhance the next.

    Quickly gauge your current process with a security incident management checklist

    While not every measure is essential to a successful incident management process, substantial gaps indicate where improvements to incident management are required.

    1. Prepare

    • The incident management initiative has senior management support.
    • A formal incident response policy is included in corporate security policies.
    • A designated team is established to respond to security incidents.
    • A formal incident response process is documented.
    • Employees/users are aware of their roles and responsibilities.
    • Employees know when and to whom to escalate incidents.

    2. Operate

    • Controls are in place for incident detection (e.g. IDPS, antivirus software).
    • All evidence of incidents is preserved, secured, and documented.
    • Incidents are classified after they are detected.
    • Analysis is performed on the incident information.
    • Controls are in place to contain the incident (e.g. sandboxing).
    • Vulnerability assessments are conducted as causes of incidents are eliminated.
    • Confirmation that regular operations are restored is included after recovery.
    • Inter-organizational information sharing/collaboration is practiced.
    • A post-mortem review of incidents is conducted.
    • A lessons-learned meeting is held after significant incidents.

    3. Maintain and Optimize

    • The incident response program is updated regularly.
    • Security incident metrics are tracked and used as benchmarks for future improvements.
    • Relevant incident-related issues are regularly communicated with management.
    • A public relations communication plan is developed in the event of a major security incident.
    • Tabletop exercises and simulations are performed regularly.

    Complete the Security Incident Management Maturity Checklist ‒ Preliminary regularly to visualize your progress

    1.2 Security Incident Management Maturity Checklist ‒ Preliminary – 20 minutes

    Leverage Info-Tech’s Security Incident Management Maturity Checklist ‒ Preliminary.

    this image contains a screenshot of the Security Incident Management Maturity Checklist tool

    1.3 Align your program with corporate goals and obligations

    A common challenge for security leaders is learning to express their initiatives in terms that are meaningful to business executives.

    Frame the importance of your security operations program to align with that of the decision makers’ overarching strategy.

    Often resourcing and funding is dependent on the alignment of security initiatives to business objectives.

    Corporate goals and objectives can be categorized into three major buckets:

    1. BUSINESS OBLIGATIONS
      The primary goals and functions of the organization at large. Examples include customer retention, growth, innovation, and customer experience.
    2. CONSUMER OBLIGATIONS
      The needs and demands of internal and external stakeholders. Examples include ease of use (external), data protection (external), and offsite access (internal).
    3. COMPLIANCE OBLIGATIONS
      The requirements of the organization to comply with mandatory and/or voluntary standards. Examples include HIPAA, PIPEDA, and ISO27001.

    Do not approach the above list with a security mindset – take a business perspective and align your security efforts accordingly.

    Info-Tech Best Practice

    Developing a security operations strategy is a proactive activity that enables you to get in front of any upcoming business projects or industry trends, rather than having to respond reactively later on. Consider as many foreseeable variables as possible!

    Determine your program scope and boundaries

    You must define all security-related areas of responsibility. When complete, you should clearly understand what you are trying to secure.

    Ask yourself:
    Where does the onus of responsibility stop?

    The organizational scope and boundaries can be categorized into four major buckets:

    1. PHYSICAL SCOPE
      The physical locations that the security operations program is responsible for. Examples include office locations, remote access, and clients/vendors.
    2. IT SYSTEMS
      The network systems that must be protected by the security operations program. Examples include fully owned systems, IaaS, PaaS, and remotely hosted SaaS.
    3. ORGANIZATIONAL SCOPE
      The business units/departments/divisions that will be affected by the security operations program. Examples include user groups, departments, and subsidiaries.
    4. DATA SCOPE
      The data types that the business handles, and the privacy/criticality level of each. Examples include top-secret, confidential, private, and public.

    This also includes what is not within scope. For some outsourced services or locations, you may not be responsible for security. In some business departments, you may not have control of security processes. Ensure that you clearly state at the outset what will be included and what will be excluded from security considerations.

    Reference Info-Tech’s security strategy: goals, obligations, and scope activities

    Explicitly understanding how security aligns with the core business mission is critical for having a strategic plan and fulfilling the role of business enabler.

    Download and complete the information security goals, obligations, and scope activities (Section 1.3) within the Info-Tech security strategy research publication. If previously completed, take the time to review your results.

    GOALS & OBLIGATIONS
    Proceed through each slide and brainstorm the ways that security operations supports business, customer, and compliance needs.

    PROGRAM SCOPE & BOUNDARIES
    Assess your current organizational environment. Document current IT systems, critical data, physical environments, and departmental divisions.

    If a well-defined corporate strategy does not exist, the following questions can help pinpoint objectives:

    • What is the message being delivered by the CEO?
    • What are the main themes of investments and projects?
    • What are the senior leaders measured on?

    Info-Tech Opportunity

    For more information on how to complete the goals and obligations activity, please reference Section 1.3 of Info-Tech’s blueprint, Build an Information Security Strategy.

    Complete the Information Security Requirements Gathering Tool

    Fill out the following tabs of the Information Security Requirements Gathering Tool.

    On Tab 1. Goals and Obligations:
  • Document all business, customer, and compliance obligations. Ensure that each item is reflective of the overarching business strategy and is not security-focused.
  • In the second column, identify the corresponding security initiative that supports the obligation.
  • This image contains a screenshot of tab 1 of the Information Security Requirements Gathering Tool, which prompts the user to record business obligations in one column, and the security obligations to support the business.
    On Tab 2. Scope and Boundaries:
  • Record all details for what is in/out of scope from a physical, IT, organizational, and data perspective.
  • Complete the affiliated columns for a comprehensive scope assessment.
  • As a discussion guide, refer to the considerations slides prior to this in Phase 1.3.
  • This image contains a screenshot of tab 2 of the Information Security Requirements Gathering Tool.

    For the purpose of the incident response initiative, please ignore the risk tolerance activities on Tab 3.

    Info-Tech Best Practice

    A common challenge for security leaders is how to express their initiatives in terms that are meaningful to business executives. This exercise helps to make explicit the link between what the business cares about and what the security team is trying to do.

    1.4 Conduct a comprehensive incident response maturity assessment

    The following slides will walk you through the process below.

    Build a Gantt chart for your upcoming initiatives
    The final output will be a Gantt to action your prioritized initiatives.
    Define your current & target state
    Self-assess your current security operations capabilities and determine your intended state.
    Create your gap initiatives
    Determine the operational processes that must be completed to achieve the target state.
    Prioritize your initiatives
    Define your prioritization criteria (cost, effort, alignment, security benefit) based on your organization.

    Info-Tech Insight

    Progressive improvements provide the most value to IT and your organization. Leaping from pre-foundation to complete optimization is an ineffective goal. Systematic improvements to your security performance deliver value to your organization each step along the way.

    Assign each security capability a reflective and desired maturity score

    Your current and target state maturity will be determined using the Capability Maturity Model Integration (CMMI) scale. Ensure that all participants understand the 1-5 scaling (where 1 is ad hoc and 5 is optimized).

    1. Initial/Ad Hoc: Activity is not well defined and is ad hoc. For example, no formal roles and responsibilities exist, de facto standards are followed on an individual-by-individual basis.
    2. Developing: Activity is established and there is moderate adherence to its execution. For example, while no formal policies have been documented, content management is occurring implicitly or on an individual-by-individual basis.
    3. Defined: Activity is formally established, documented, repeatable, and integrated with other phases of the process. For example, roles and responsibilities have been defined and documented in an accessible policy, but metrics are not actively monitored and managed.
    4. Managed and Measurable: Activity execution is tracked by gathering qualitative and quantitative feedback. For example, metrics have been established to monitor the effectiveness of tier 1 SOC analysts.
    5. Optimized: Qualitative and quantitative feedback is used to continually improve the execution of the activity. For example, the organization is an industry leader in the respective field and research and development efforts are allocated to continuously explore more efficient methods of accomplishing the task at hand.

    Note

    Info-Tech seldom sees a client achieve a CMMI score of 4 or 5.

    To achieve a state of optimization, there must be a subsequent trade-off elsewhere.

    We recommend that organizations strive for a CMMI score of 3-4.

    Assess your current state capabilities and determine the appropriate target state

    Leverage Info-Tech’s Incident Response Maturity Assessment Tool.

    this is an image of a table used to determine current capabilities, and identify target maturity levels

    Info-Tech Best Practice

    When customizing your gap initiatives, consider your organizational requirements and scope while remaining realistic. Below is an example of realistic vs. lofty initiatives:
    Lofty: Perform thorough, manual security analysis.
    Realistic: Leverage our SIEM platform to perform more automated security analysis through the use of logs information.

    Consolidate related gap initiatives to simplify and streamline your roadmap

    Identify areas of commonality between gap initiatives to effectively and efficiently implement your new initiatives using Info-Tech’s Incident Response Maturity Assessment Tool.

    Steps:

    1. After reviewing and documenting initiatives for each security control, begin sorting controls by commonality, where resources can be shared, or similar end goals and actions. Begin by copying all initiatives from Tab 2. Current State Assessment into Tab 4. Initiative List of the Incident Response Maturity Assessment Tool and then consolidate them.
    2. Initiatives Consolidated Initiatives
      Document data classification and handling in Acceptable Use Policy (AUP) Document data classification and handling in AUP Keep urgent/exceptional initiatives separate so they can be addressed appropriately
      Document removable media in AUP Define and document an AUP Other similar/related initiatives can be consolidated into one item
      Document BYOD and mobile devices in AUP
      Document company assets in AUP
    3. Review grouped initiatives and identify specific initiatives that should be broken out and defined separately.
    4. Record your consolidated gap initiatives in the Incident Response Maturity Assessment Tool, Tab 5. Initiative Prioritization.

    Understand your organizational maturity gap

    After inputting your current and target scores and defining your gap initiatives in Tab 2, review Tab 3. Maturity Gap in Info-Tech’s Incident Response Maturity Assessment Tool.

    Automatically built charts and tables for your current maturity state assessment provide a clear visualization of your current maturity.

    Presenting these figures to stakeholders and management can help to visually draw attention to high priority areas, and help to contextualize the gap initiatives for which you will be seeking support.

    this image contains two bar graphs comparing target values and current values. the top graph compares planning and direction, and the bottom graph compares security maturity level.

    Info-Tech Best Practice

    Communicate the value of future security projects to stakeholders by copying relevant charts and tables into a stakeholder communication presentation.

    Define cost, effort, alignment, and security benefit

    Define low, medium, and high resource allocation and other variables for your gap initiatives in the Incident Response Maturity Assessment Tool. These variables include:

    1. Define initial cost. One time, upfront capital investments. The low cut-off would be a project that can be approved with little to no oversight. The high would require a major approval or a formal capital investment request. Initial cost covers items such as appliance cost, installation, and project-based consulting fees.
    2. Define ongoing cost. This is any annually recurring operating expenses that are new budgetary costs (e.g. licensing or rental costs). Do not account for FTE employee costs. Generally speaking, you can take 20-25% of initial cost as ongoing cost for maintenance and service.
    3. Define initial staffing in hours. This is total time in hours required to complete a project. Note: it is not total elapsed time, but dedicated time. Consider time required to research, document, implement, review, set up, fine-tune, etc. Consider all staff hours required (2 staff at 8 hours means 16 hours total).
    4. Define ongoing staffing in hours. This is the ongoing average hours per week required to support the initiative. This covers all operations, maintenance, review, and support for the initiative. Some initiatives will have a week time commitment (e.g. perform a vulnerability scan using our tool once a week) versus others that may have monthly/quarterly/annual time commitments that need to averaged out per week (e.g. perform annual security review requiring 0.4 hours/week [0 hours total/50 working weeks/year]).
    Initial Cost High
    Medium
    Low
    Zero
    Ongoing Cost
    (annual)
    High
    Medium
    Low
    Zero
    Initial Staffing in Hours High
    Medium
    Low
    Zero
    Ongoing Staffing in Hours/Week High
    Medium
    Low
    Zero

    Info-Tech Best Practice

    When considering these parameters, aim to use already existing resource allocations.

    For example, if there is a dollar value that would require you to seek approval for an expense, this might be the difference between a medium and a high cost category.

    Define cost, effort, alignment, and security benefit

    1. Define alignment with the business. This variable is meant to capture how well the gap initiative aligns with organizational goals and objectives. E.g. something with high alignment usually can be tied to a specific organization initiative and will receive senior management support. You can either:
      • Set low, medium, and high by levels of support the organization will provide (e.g. high – senior management support; medium – VP/business unit head support; low – IT support only).
      • Attribute specific corporate goals or initiatives to the gap initiative (e.g. high – directly supports a customer requirement/key contract requirement; medium – indirectly supports customer requirement/key contract or enables remote workforce; low – security best practice).
    2. Define security benefit. This variable is meant to capture the relative security benefit or risk reduction being provided by the gap initiative. This can be represented through a variety of factors, such as:
      • Reduces compliance/regulatory risk by meeting a control requirement.
      • Reduces availability and operational risk.
      • Implements a nonexistent control.
      • Secures high criticality data.
      • Secures at-risk end users.
    Alignment With Business High
    Medium
    Low
    Security Benefit High
    Medium
    Low

    Info-Tech Best Practice

    Make sure you consider the value of AND/OR. For either alignment with business or security benefit, AND/OR can become a useful threshold to rank similar importance but different value initiatives.
    Example: for alignment with business, an initiative can indirectly support a key compliance requirement OR meet a key corporate goal.

    Info-Tech Insight

    You cannot do everything – and you probably wouldn’t want to. Make educated decisions about which projects are most important and why.

    Apply your variable criteria to your initiatives

    Identify easy-win tasks and high-value projects worth fighting for using the Incident Response Maturity Assessment Tool.

    Categorize the Initiative
    Select the gap initiative type from the drop-down list. Each category (Must do, Should do, Could do, and Won’t do) is considered to be an execution wave. There is also a specific order of operations within each wave. Based on dependencies and order of importance, you will execute on some must-do items before others.
    Assign Criteria
    For each gap initiative, evaluate the initiative based on your previously defined parameters for each variable.
    • Cost: initial and ongoing
    • Staffing: initial and ongoing
    • Alignment with business
    • Security benefit
    Overall Cost/Effort Rating
    An automatically generated score between 0 and 12. The higher the score attached to the initiative, the more effort required. The must-do, low scoring items are quick wins and must be prioritized first.
    This is a screenshot of the Incident Response Maturity Assessment Tool.

    Review your prioritized security roadmap

    Review the final Gantt chart in the Incident Response Maturity Assessment Tool to plan the expected start and end dates for your security initiatives as part of your roadmap.

    In the Gantt chart, go through each wave in sequence and determine the planned start date and planned duration for each gap initiative. As you populate the planned start dates, take into consideration the resource constraints or dependencies for each project. Go back and revise the granular execution wave to resolve any conflicts you find.

    this is a screenshot of the Gantt Chart for Initiatives, found in the Incident Response Maturity Assessment Tool

    Review considerations

    • Does this roadmap make sense for our organization?
    • Do we focus too much on one quarter over the others?
    • Will the business be going through any significant changes during the upcoming years that will directly impact this project?

    This is a living management document

    • You can use the same process on a per-case basis to decide where a new project falls in the priority list, and then add it to your Gantt chart.
    • As you make progress, check items off the list here, and periodically use the chart to retroactively update progress toward achieving your overall target state.

    Insurance company drives engagement through stakeholder communication

    The organization recognized value in obtaining stakeholder support at the outset of the new incident management program.

    The security team ensured that it communicated the following points to stakeholders to demonstrate that, as a newly formed team, it had anticipated concerns:

    • The interface between the security team and ITIL processes.
    • Roles and responsibilities within the security team.
    • Procedure to analyze the root cause of security incidents.
    • The approach to integrate security incident management with ITIL incident process.
    • Reporting procedure when communicating with leadership.
    • Relationship among security incident, problem, risk management, and other existing processes.
    • Alignment with and leveraging corporate ITIL incident and problem management processes.
    • Methodology used: leverage ITIL v3, NIST SP800-83, ISO 27005, and PCI DSS as the primary source.

    Next Steps

    • Define how the team will rate the severity of security incidents.
    • Define the incident management process.

    Follow this case study through Phase 1 into Phase 2 for next steps.

    1.5 Identify key players for security incident management

    Incident response should follow a fairly standard process, but each incident will have its own escalation process or call tree that identifies key participants.

    Develop a Security Incident Response Team (SIRT) Horizontal Escalation Vendor Escalation
    Members may include:
    • Chief information security officer
    • Senior management
    • Security team staff
    • Help desk
    • Information owner
    • Information systems staff
    • Building and/or facilities management staff
    • Public affairs
    • Legal/compliance
    • Internal audit/risk management
    • Contractors and/or SIRT contacts at key service
    • providers
    Engage additional resources, not senior-level management, when:
    • Analyst might not have skillset required to resolve the incident.
    • Escalation time frame has been exceeded.
    Don’t forget to leverage vendors, but don’t depend on them.
    • Identify how vendors fit into your IT support structure and build vendor engagement and support into your organization’s escalation path.
    • If an investigation is stalled, don’t hesitate to engage vendors with issues requiring specialized or deep skills/expertise.
    • Ensure that the vendor provides a detailed report of the investigation and diagnosis for the service issue.
    • Don’t overuse vendor contracts. Vendor engagement can be the most expensive part of your support structure. Whenever possible, use in-house expertise to investigate and solve service problems.
    Recommendations Vertical Escalation
    • Evaluate the readiness of SIRT regularly.
    • Clearly define all roles and responsibilities.
    • Track metrics to assess the effectiveness of SIRT.
    • Involve various areas of the organization.
    • Define when outside help will be required and pre-emptively have contractors on retainer.
    Engage senior-level management when:
    • Incident is beyond the scope and skillset of most staff.
    • Resources are not available to escalate horizontally.
    • Break in horizontal escalation path.
    • More authority needed for key decisions.

    Assign responsibilities for the threat management process (RACI)

    1.3 Define Roles and Responsibilities – 1 hour

    Complete the Security Incident Management RACI Tool and document your results.

    How to customize

    • Customize the header fields with applicable stakeholders.
    • Identify stakeholders that are:
      • Responsible: The person(s) who does the work to accomplish the activity; they have been tasked with completing the activity and/or getting a decision made.
      • Accountable: The person(s) who is accountable for the completion of the activity. Ideally, this is a single person and is often an executive or program sponsor.
      • Consulted: The person(s) who provides information. This is usually several people, typically called subject matter experts (SMEs).
      • Informed: The person(s) who is updated on progress. These are resources that are affected by the outcome of the activities and need to be kept up to date.
    this is a screenshot of the Responsible, Accountable, Consulted, Informed (RACI) Chart, found in the Security Incident Management RACI Tool

    Record the results from the RACI tool in Info-Tech’s Security Incident Management Plan.

    Formalize the general incident assessment to define the threat escalation protocol

    The threat escalation protocol is used to define the type of stakeholders needed during the incident management process. The combination of impact and scope provides the tiers to help prioritize incidents and determine which stakeholders need to be involved.

    Impact

    Incident impact refers to the evaluation of impact on a business function, data, and recovery efforts. Incident impacts should be prioritized based on the below factors:

    • Functional: Impact to any business functions or operations.
    • Informational: Impact as it relates to the confidentiality, integrity, and availability of the organization’s data.
    • Recoverability: The time and required resources needed to recover from the incident.

    Scope

    Incident scope refers to the evaluation of IT systems involved and magnitude of the incident.

    this image contains the Threat Escalation Protocol.

    Record in Info-Tech’s Security Incident Management Plan.

    Info-Tech Insight

    Define what the impact and scope of incidents can look like for your organization. That will help create a tiered escalation process specific to your organization, as opposed to what other companies need.

    Review the threat escalation protocol example below

    Threat Escalation Protocol Criteria Stakeholders
    Tier 1
    • High impact, high scope
    • High impact, medium scope
    • Medium impact, high scope
    • End User
    • Help Desk
    • Cybersecurity
    • IT Operations
    • CISO
    • Legal, HR, PR
    • Senior Management
    • External Third Parties
    Tier 2
    • High impact, low scope
    • Medium impact, medium scope
    • Medium impact, low scope
    • Low impact, high scope
    • Low impact, medium scope
    • End User
    • Help Desk
    • Cybersecurity
    • IT Operations
    • CISO
    Tier 3
    • Low impact, medium scope
    • Low impact, low scope
    • End User
    • Help Desk
    • Cybersecurity

    Customize the impact/scope definitions and the threat escalation protocol in the Security Incident Management Plan to ensure that it is specific to your organization.

    1.6 Develop a security incident management policy

    1.4 Security Incident Management Policy – 60 minutes

    The policy will serve as the high-level foundation for the incident management initiative.

    How to customize

    • Establish your organization’s security requirements and expectations that support business requirements while ensuring consistency across all security initiatives.
    • Formalize the approach to incident response by outlining the following sections:
      • Purpose
      • Scope
      • Policy
      • Procedures
      • Consequences of Non-Compliance
      • Revision History

    this image contains a screenshot of the Security Incident Management Policy page, which can be found online at https://www.infotech.com/research/security-incident-management-policy

    Download Info-Tech’s Security Incident Management Policy.

    1.7 Develop a security incident management plan

    1.5 Develop a security incident management plan

    The Security Incident Management Plan serves as the central high-level document that describes goals, roles, and responsibilities, and provides evidence to auditors that a process has been developed and formalized.

    How to customize

    Customize the following sections in the template:

    • Purpose and Mission
    • Definitions
    • Organizational Approach of Incident Response
    • Roles and Responsibilities
    • Response Procedures
    • Including detection, analysis, containment, eradication, recovery, and post-incident phases
    • Appendix

    This image contains a screenshot of two pages of the Introduction section of the Security Incident Management Plan

    Don’t forget to address internal and external communications during the incident. Check out Info-Tech’s Master Your Security Incident Response Communications Program blueprint.

    If you want additional support, have our analysts guide you through this phase as part of an Info-Tech workshop

    To accelerate this project, engage your IT team in an Info-Tech workshop with an Info-Tech analyst team

    Onsite workshops offer an easy way to accelerate your project. If a Guided Implementation isn’t enough, we offer low-cost onsite delivery of our project workshops.

    Info-Tech analysts will join you and your team onsite at your location or welcome you to Info-Tech’s historic Toronto office.

    We take you through every phase of your project and ensure that you have a roadmap in place to successfully complete your project.

    This is a picture of Celine Gravelines, an Info-Tech Research Manager

    Celine Gravelines


    Research Manager – Security, Risk & Compliance
    Info-Tech Research Group
    This is a picture of Logan Rohde, an Info-Tech Consulting Analyst.

    Logan Rohde


    Consulting Analyst – Security, Risk & Compliance
    Info-Tech Research Group

    Call 1-888-670-8889 or email workshops@infotech.com for more information.

    Are you ready to move on to the next phase?

    Self-Assessment Questions

    • Have you clearly defined the rationale, goals, and outcomes for refining your incident management program?
    • Have you identified your organization’s corporate goals along with your obligations?
    • Have you defined the scope and boundaries of your security program?
    • Have you considered threat types your organization may face?
    • Are the above answers documented in the Information Security
    • Strategy Requirements Gathering Tool?
    • Have you defined your maturity for both your current and target state?
    • Do you have clearly defined initiatives that would bridge the gap between your current and target state?
    • Are each of the initiatives independent, specific, and relevant to the associated control?
    • Have you indicated any dependencies between your initiatives?
    • Have you consolidated your gap initiatives?
    • Have you defined the parameters for each of the prioritization variables (cost, effort, alignment, and security benefit)?
    • Have you applied prioritization parameters to each consolidated initiative?
    • Have you recorded your final prioritized roadmap in the Gantt chart tab?
    • Have you reviewed your final Gantt chart to ensure it aligns to your security requirements?
    • Have you assigned program responsibilities in a detailed RACI chart?
    • Have you formalized a security incident management charter?
    • Have you defined and documented your threat escalation protocol, including impact and scope levels?

    If you answered “yes” to the questions, then you are ready to move on to Phase 2: Operate

    PHASE 2

    Operate

    Develop and Implement a Security Incident Management Program

    Phase 2: Operate

    PHASE 1 PHASE 2 PHASE 3
    Prepare Operate Optimize

    This phase walks you through the following activities:

    2.1 Understand the incident response framework.
    2.2 Understand the purpose of runbooks.
    2.3 Prioritize the development of incident-specific runbooks.
    2.4 Develop top-priority runbooks.
    2.5 Fill out the Root-Cause Analysis Template
    2.6 Customize the Post-Incident Review Questions Tracking Tool to standardize useful questions for lessons-learned meetings.
    2.7 Complete the Security Incident Report Template.

    This phase involves the following participants:

    • CISO
    • Security team
    • IT staff
    • Business leaders

    Outcomes of this phase

    • A generalized incident management plan.
    • A prioritized list of incidents.
    • Detailed runbooks for top-priority incidents
    • Root-cause analysis procedure.
    • Post-Incident Review Questions Tracking Tool.
    • Security Incident Report Template.

    Phase 2 outline

    Call 1-888-670-8889 or email GuidedImplementations@InfoTech.com for more information.

    Complete these steps on your own, or call us to complete a guided implementation. A guided implementation is a series of 2-3 advisory calls that help you execute each phase of a project. They are included in most advisory memberships.

    Guided Implementation 2: Handle Incidents
    Proposed Time to Completion: 4 Weeks
    Step 2.1-2.3 Use the Framework to Develop a General Plan Step 2.4-2.7 Develop Incident-Specific Runbooks and Post-Incident Activities
    Start with an analyst kick-off call:
    • Discuss current issues and incidents being experienced.
    • Understand the incident response framework.
    • Prioritize the development of runbooks.
    Discuss with analyst:
    • Understand the runbook methodology.
    • Discuss the importance of post-incident review activities.
    Then complete these activities…
    • Based on current incidents, discuss the response process to optimize handling techniques.
    • Customize a general incident management plan.
    • Evaluate the frequency and impact of incidents to prioritize incident runbook development
    Then complete these activities…
    • Develop top-priority runbooks based on the incident response framework.
    • Formalize post-incident activities.
    With these templates:
    Security Incident Runbook Prioritization Tool
    With these tools & templates:
    Incident-Specific Runbooks
    Root-Cause Analysis Template
    Post-Incident Review Questions Tracking Tool
    Security Incident Report Template
    Phase 2 Results & Insights:
    Not all incidents of the same type are handled the same way. A virus detected on a general user’s computer may be handled differently than a virus detected on the CEO’s computer. Make response processes specific.

    2.1 Understand the security incident management framework

    Phase 2 describes the process during incident handling, including detection, analysis, containment, eradication, recovery, and post-incident activity.

    1. PREPARE
      Ensure the appropriate resources are available to best handle an incident.
    2. DETECT
      Leverage monitoring controls to actively detect threats.
    3. ANALYSIS
      Distill real events from false positives and investigate that nature of the incident.
    4. CONTAIN
      Isolate the threat before it can cause additional damage.
    5. ERADICATE
      Eliminate the threat from your operating environment.
    6. RECOVER
      Restore impacted systems to a normal state of operations.
    7. POST-INCIDENT ACTIVITIES
      Conduct a lessons-learned post-mortem analysis.

    (Process adapted from NIST SP 800-61 Rev. 2)

    Info-Tech Best Practice

    Document each step of the incident lifecycle. A thorough, comprehensive record will assist in understanding the root cause and allow for faster remediation of any future reoccurrences of the incident, as well as support any legal escalation. Tracking the cost of work hours helps in determining the overall impact to the organization.

    Incident management falls into Tier 2 of the security operations analysis framework

    TIER 1 TIER 2 TIER 3
    Analysts focus on more standardized and prescriptive tasks like the real-time monitoring and triage of events. Train analysts on how to identify problem areas, generate tickets, and escalate anything out of the ordinary. Analysts focus on in-depth analysis to understand the extent of the problem and to determine if further action is necessary. Tier 2 analysts are more technically competent and work to contextualize threat data using advanced techniques such as log analysis, forensic analysis, and eDiscovery. Analysts perform advanced threat hunting, malware analysis, and reverse engineering to actively seek out anomalies in data.
    Security Operations

    These tiers can be outsourced to an MSSP – they do not need to be completed by the organization alone. For Tier 3’s deep forensic analysis, it is often necessary to look to a third party to assist. However, for this project, we will only concern ourselves with Tier 2 as it is the typical level of analysis required for incident response.

    Insurance company security team made incident response part of the ITIL process so it became a natural step

    Instead of just checking a box, the team ensured incident management was a key step in the overall ITIL process and solidified its detailed procedures.

    The security team ensured it communicated the following points to stakeholders to demonstrate that, as a newly formed team, it had anticipated concerns.

    This is an image of the ITIL process. It includes the following steps: Report incident; Help desk records incident; Help desk assesses incident. If it is a security incident, then the severity is assessed. If it is not, then proceed to the Incident management process. If it is a security incident, assess whether it is a severity 1-2, or a severity 3-4. If it is a severity 1-2 security incident, proceed to the Incident management process. If it is a severity 3-4, then proceed to the IT security incident response process, then proceed to the Incident Management process.

    Insurance company specified detailed incident response process

    Using best-practice incident management standards, the team drilled deeper and created a workflow for specific incidents.

    this is the workflow that the team created for specific incidents. The order is: Identification and classification confirmation; Containment; Analysis/Investigation, from there, the workflow splits into Escalation, and Recommendation/Resolution. the Recommendation/Resolution step is followed by Closure.

    See Phase 3 for post-incident processes

    2.2 Understand the purpose of runbooks

    Develop runbooks to formalize the response process for key incidents.

    Consider three key questions as you develop each runbook:

    1. What are the facts about the incident?
      • Incident source
      • Frequency
      • Accidental or malicious
      • Impact
      • Affected data
      • Failed controls
    2. What (potential) impact does this have?
      • Affects revenue-generating units
      • Affects productivity
      • Number of users impacted
      • Tolerance
      • Timing
    3. What action should be taken and by whom to move this through investigation and containment to resolution?

    Benefits of documenting incident-specific procedures with runbooks:

    • Efficiently identify solutions to incidents (workarounds/fixes).
    • Eliminate or reduce guesswork and ambiguity when handling an incident by streamlining incident response and change management.
    • Properly escalate incidents to the correct support group.
    • Effectively allocate resources to handle the incident.
    • Collect data quickly to expedite the diagnoses of incidents.
    • Increase user productivity as incidents are handled efficiently.
    • Establish maturity of the incident management program.

    For each top-priority incident, develop a detailed runbook, documenting the response process – from detection through recovery and post-incident activity – for each role involved.

    2.3 Prioritize the development of incident-specific runbooks

    The prioritization of incident handling depends on incident impact and frequency.

    Prioritization based on frequency and impact

    Frequency:
    1. historic frequency
    2. expected trend
    Impact:
    1. functional impact
    2. information impact
    3. recoverability effort
    Functional Definition (example)
    None No effect on the organization’s ability to provide all services to all users.
    Low Minimal effect; the organization can still provide all critical services to all users but has lost efficiency.
    Medium The organization has lost the ability to provide a critical service to a subset of system users.
    High The organization is no longer able to provide some critical services to any users.
    Information Definition (example)
    None No meaningful information is exfiltrated or lost.
    Low Publicly available information is affected.
    Medium Internal private/confidential information is compromised.
    High Regulated data (e.g. personal data, credit card data) or highly confidential organizational material (e.g. trade secret) is breached.
    Recoverability Definition (example)
    None No significant time/cost to recovery is necessary.
    Low Recoverable through standard service desk or response process.
    Medium Recoverable through extended effort that can be achieved with additional existing resources.
    High External support is required for recoverability OR not recoverable.

    Determine which runbooks to develop with the Security Incident Runbook Prioritization Tool

    2.1 Security Incident Runbook Prioritization Tool – 60 minutes

    In the Security Incident Runbook Prioritization Tool:

    • Using the list of 15+ incidents, prioritize which to focus preparations on based on frequency and impact.
    • Enter your specific frequency, trend, and function/informational/recoverability effort impacts, as well as the state of any current document to get a prioritized list of incidents.
    • Weight your relative importance of factors, including impacts and frequencies.
    this is a screenshot of the Security Incident Runbook Prioritization tool.

    2.4 Develop top-priority runbooks

    2.2 Use Info-Tech’s Runbook Templates – 2 days

    Document your security incident management processes using Info-Tech’s runbook templates.

    How to customize

    • Use these templates to develop runbooks for specific incidents relevant to your organization.
    • Base new runbooks on the highest-priority incidents discovered from the Security Incident Runbook Prioritization Tool.
    • Draft a summary of the incident based on the key questions:
      • What is the incident?
      • Why should we care?
      • How do we respond?
    • Customize the escalation process and detailed response procedures.
    • Use Visio or a similar tool to visualize the workflow processes.
    • Update the revision history.
    • Assign the document to an owner.

    this image contains a screenshot of the Info-Tech runbook templates to be used in developing runbooks for specific incidents relevant to your organization.

    Use operational flowcharts to illustrate your response procedures

    Remember to assign an owner to each runbook. A runbook owner is responsible for ensuring that processes documented under each runbook are fully operational.

    this is an example of a user-created Incident Management flowchart. It contains annotations which point to where you will: Identify and list the relevant stakeholders involved based on the respective incident tier level; Define your threat escalation protocol. Define the respective impact and scope criteria for your organization; On a whiteboard, draw the unique process flow. Refer to Info-Tech’s incident response library for various operational starting points; Fully flesh out the operational procedures required for various activities.

    Incorporate Info-Tech’s Data Breach Reporting Requirements Summary

    2.3 Data Breach Reporting Requirements Summary

    Use the Data Breach Reporting Requirements Summary template to familiarize yourself with the essential details for four common compliance standards so that you can streamline your reporting process.

    This template makes a great companion to a data breach runbook or a general security strategy.

    How to customize

    To customize, simply review the reporting procedure and then add or remove details as needed to meet your organization’s needs. Be sure to remove any regulations that are not relevant to your organization.

    this image contains screenshots of the data breach reporting requirements summary, for PCI DSS, GDPR, HIPPA, and PIPEDA

    Includes the essential details for:

    • PCI DSS
    • GDPR
    • PIPEDA
    • HIPPA

    Detect the incident

    To determine if an incident has occurred, you must detect the signs of an incident.

    Recognize signs of an incident:

    1. Precursor: a sign that an incident may occur in the future (less common).
      • Server log entries that indicate usage of a vulnerability scanner.
      • A released statement of a new exploit that targets a vulnerability of the organization’s mail server.
      • A threat of attack to the organization.
    2. Indicator: a sign that an incident may have occurred or is currently occurring (more common).
      • Antivirus software alert that has detected a malware-infected host.
      • A log reports several failed login attempts from an unfamiliar remote system.
      • A network administrator notices suspicious deviation from regular network traffic flows.

    Begin to maintain a log of evidence:

    When an incident is detected, gather as much information as possible, including:
    • Contact name and number of the person reporting.
    • Type of data, information, or equipment.
    • Whether the loss of the data puts any person or other data at risk.
    • Location of the incident.
    • Inventory numbers of any equipment affected.
    • Date and time the security incident occurred.
    • Location of the data or equipment affected.
    • Type and circumstances of the incident.

    Source: NIST SP 600-61 Rev. 2

    INFO-TECH OPPORTUNITY

    Proper use of monitoring capabilities can resolve incidents before they occur. Leverage Info-Tech’s Integrate Threat Intelligence Into Your Security Operations blueprint to start up a formal intelligence program and actively detect threats before they target your organization.

    Analyze the incident

    Not every precursor or indicator sign is accurate (e.g. false positives), which makes thorough investigation a crucial step after incident detection.

    Leverage diagnostic data to analyze your incidents using tools often found directly on the operating system or application:

    Memory dumps
    Copy the contents of memory to a file for review and analysis following an incident.

    Screen captures
    “Take a picture” of a computer desktop and store in a file for later examination.

    Logs
    Information on errors and other events are stored in files on a desktop or server. Logging capabilities often come with the operating system or application.

    Traces
    Record information about the communication between two machines or components. Network traces are the most common type of trace.

    Perform analysis on the information collected using these suggestions.

    • Investigate correlating information:
      • Gather evidence from several sources to validate incidents and cross-reference the occurrence of other events with the incident. Look for trends.
      • Ensure all host clocks are synchronized to eliminate discrepancies in incident tracking logs.
    • Conduct and maintain research:
      • Learn from past analyses by centralizing data in a searchable knowledgebase for efficient and consistent investigation. Stay up to date with types of threats and vulnerabilities affecting your system.
    • Analyze near-misses to help identify gaps in security:
      • An indicator does not necessarily indicate an incident, but it provides valuable visibility.
    • Document all steps of the analysis and the evidence gathered:
      • Gather lists of network connections, processes, login sessions, open files, network interface configurations, and contents of memory.

    Source: NIST SP 600-61 Rev. 2

    "To reduce data breach risks, a CISO needs to look at the incidents that might have been data breaches."
    – NIST SP 600-61 Rev. 2

    Preserve evidence and document analysis efforts in a ticketing system

    Whether manually or through dedicated software, incident details must be recorded in a consistent process.

    Once an analyst has determined that an event has occurred, the next logical step is to aggregate, normalize, and document information in an operational ticket. Ensure your tickets include:

    Time, date, and location – Basic information to organize, track, and query tickets. Such features should include a unique ticket ID, the status of the ticket, assigned analysts, the date the ticket was created, the date the event was triggered, etc.
    Additional context – Information regarding the security control(s) that the event originated from, as well as the type of threat it may result in.
    Description and notes – Analysts must be able to create new descriptions and entries, and document ticket findings such as source and destination IP, UDP or TCP port, and signature ID.
    Relevant use cases – Information on resolutions to common problems. This can include indicators of compromise or ticket numbers that have been solved as actual references.
    Next steps – Recommendations and next steps that should be undertaken.

    For other examples, see the SANS Institute Sample Incident Handling Forms.

    Ticket #: ____________

    General Information (name, role, department, contact information, signature)

    Incident Information
  • Time and date, location
  • Type of incident (social engineering, phishing, etc.)
  • Description of incident
  • Notification (who needs to be notified, their role and contact information)
    Actions (identification/detection, analysis, containment, etc.)

    Document incident details in an accessible web portal

    Whether manually or through an automated process, all operational documents must be stored in a standardized format.

    A web portal enables incident responders to document and share data throughout the threat collaboration environment. There are several drivers behind the implementation of a web portal:

    1. Learning. Web portals aggregate information from disparate sources, enabling organizations to organically expand their knowledgebase. This central portal of learning can facilitate training exercises and is useful in the knowledge transfer between employees.
    2. Collaboration and communication. Sharing information in a centrally-accessible portal will facilitate collaboration between operational functions and influence group decision making. Similarly, a web portal can act as a standardized push notification platform from which employees can escalate, disseminate, and share threat information with relevant stakeholders.
    3. Task management and workflow visualization. Portals further improve operations management through process automation, dashboard visualization, and notification prompts when a process needs attention.

    "Consolidating reports from all security devices into a coherent visual closes windows of risk."
    – Diana Kelley and Ron Moritz, "Best Practices for Building a Security Operations Center"

    this is a chart showing prevention, detection, analysis, and Response, and their relation to the Knowledge portal.

    Explore open-source software

    Software can ease some of the resource burden involved with incident response, but it should still be supported with process.

    this is the logo for the SNORT intrusion prevention system
    Snort
    • Intrusion prevention system that gives real-time alerts for packet analysis and network traffic.
    • Uses a flexible rules system so it can be configured for your organization’s environment while reducing false positives, and it offers protection against a wide variety of attack types.
    • Works across Windows, MacOS, and Linux.
    this is the logo for the OSSEC intrusion detection system
    OSSEC (Open Source HIDS SECurity)
    • Scalable, multi-platform, open-source host-based intrusion detection system (HIDS).
    • It has a powerful correlation and analysis engine, integrating log analysis, file integrity checking, Windows registry monitoring, centralized policy enforcement, rootkit detection, real-time alerting, and active response.
    • It runs on most operating systems, including Linux, OpenBSD, FreeBSD, MacOS, Solaris, and Windows.
    this is the logo for the OpenVAS vulnerability scanner
    OpenVAS (Vulnerability Assessment System)
    • Vulnerability scanner and manager that runs in Linux.
    • Scans using a database of over 50,000 network vulnerability tests that is updated daily.
    • Can also be used as a complete vulnerability management platform.

    Consider investing in security orchestration tools

    Software can ease some of the resource burden involved with incident response, but it should still be supported with process.

    This is the logo for the Demisto security orchestration tool.
    Demisto
    • Coordinates various security tools to simplify use.
    • Ingests alerts from multiple sources across the network.
    • Automates established workflows so that incidents can be dealt efficiently and uniformly.
    • Blends automation and human-controls processes to provide the best of both words.
    This is the logo for the RAPID7 security orchestration tool.
    Rapid 7 IDR
    • Curates security events so they can be reviewed if an incident is discovered.
    • Uses machine learning to detect anomalies and unusual behavior on your network.
    • Incorporates research and security team’s experience into its threat detection system.
    • Records behavior before and after an incident to simply log review.
    This is the logo for the Alien Vault security orchestration tool.
    Alien Vault USM
    • Offers its own set of tools and integrates well with third-party tools.
    • Allows for users to create their own unique apps to be used within the USM (Universal Security Management) system to help with process automation.
    • Provides in-depth threat intelligence.
    • Noted for being easier to use than other security orchestration tools.

    Contain the incident

    Contain the incident and affected systems before it overwhelms resources or increases damage.

    The average cost to contain an incident increases by US$1 million if containment spans longer than 30 days.

    Containment is dependent on decision making:

    • Should this system be shut down?
    • Should we disable a certain function?
    • Should we disconnect from the network?

    Simplify decisions by forming predetermined strategies and procedures regarding containment.

    Consider various factors:

    • Potential damage and/or theft of resources.
    • Need for evidence preservation.
    • Service availability (e.g. network connectivity).
    • Time and resources required for strategy.
    • Effectiveness of the strategy (e.g. partial vs. full containment).
    • Duration of the solution (e.g. short-term workaround vs. permanent solution).

    Source: IBM, “2018 Cost of Data Breach Study”

    Monitor only while attacker is contained

    • To monitor the attacker’s activity, redirect to a sandbox (a contained environment) to gather evidence.
    • Otherwise, do NOT monitor activity. If your organization is aware of a compromise and allows it to continue, you may be liable for the attack of other systems.
    • Be sure you have everything you need. Containment involves changes to the system that tip off the adversary.

    Info-Tech Insight

    Don’t confuse containment with recovery. Containment stops a threat while recovery fixes the vulnerabilities. When responding to a house fire, you douse the flames before repairing the roof.

    Eradicate the root cause of the incident

    Remove the cause of the incident and the resulting security exposures that exist on the affected systems.

    1. Determine the root cause.
      Identify all affected hosts within the organization to be remediated.
    2. Eliminate components of the incident.
      Delete malware, disable breached user accounts, etc.
    3. Strengthen defenses.
      Increase network perimeter defenses and system monitoring.
    4. Conduct a vulnerability assessment.
      Verify that the exploitable gaps have been addressed.

    Eliminate components of the incident

    • Software solutions are available to help eradicate the cause of the incident, such as spyware removal utilities (e.g. Malwarebytes, HijackThis).
    • If an infection is malicious, clean and reformat any hard drives containing the infected files.
    • Eradicating issues resulting from network intrusions is often more difficult as the attacks may have originated from any system on the network before attacks were launched on other addressable systems.
      • These exploits may require patches to the operating system or routers on the network.
    • Focus eradication on malignant artifacts (e.g. Trojan horses), then benign artifacts if they are worth the cost and effort.

    Info-Tech Opportunity

    Leverage Info-Tech's Design and Implement a Vulnerability Management Program blueprint to formalize a patch and vulnerability management program.

    Recover from the incident

    Restoring and monitoring the affected systems is essential to ensure eradication was successful.

    Goals of recovery

    • Restore systems to normal operations.
    • Confirm systems are functioning properly.
    • Remediate vulnerabilities to prevent similar incidents.

    Recovery may involve

    • Installing patches.
    • Rebuilding systems.
    • Changing passwords.
    • Restoring systems from clean backups.
    • Replacing affected files with clean versions.
    • Establishing high levels of system logging or network monitoring.

    Remember, security incidents can also damage an organization’s reputation. Containment and recovery may require a communications strategy. See Info-Tech’s Master Your Security Incident Response Communications Program blueprint for more information.

    Acquire change management approval

    • Often, the emergency change must be approved by IT and the business.
    • The fix needs to be clearly understood and the risk needs to be identified and accepted.
    • Sign-off must be obtained by the change manager before the fix is applied.
    • Weigh the risk of deploying the emergency change versus the risk of not deploying.
    • Ensure a member of SIRT has emergency CM approval.
    • Simple incidents may only require assurance that the incident did not adversely affect resources.

    Thorough testing will allow you to avoid a domino effect where your fix to the problem creates a multitude of other service issues.

    Info-Tech Insight

    Balance the pressure to restore service with the requirements of conducting due diligence. Don’t attempt fixes without adequate testing as it can exacerbate the problem.

    Conduct post-incident activity: communicate the incident

    Awareness leads to cooperation of stakeholders, which is fundamental to the security incident management process.

    1. Internal Collaboration
      Collaborate internally to assess the impact of the incident, to determine future preventative measures, and to develop situational awareness.
    2. External Collaboration
      Leverage trusted communication channels to safeguard your organization against reputational damage. Develop a formal public relations plan or contribute to informal third-party information sharing and analysis centers (ISACs) to anonymize and distribute intelligence.

    Info-Tech Best Practice

    Define your audience before presenting information. Various stakeholders will interpret information differently, so you must present it in a format that appeals to their interests.

    Conduct post-incident activity: internal collaboration

    Collaborate with stakeholders to review the cause, effect, remediation process, and plans to reduce future incidents.

    Before

    Leverage internal awareness and training programs to create situational awareness on:

    • How the incident response program works, how it affects workflow, program expectations.
    • How to report incidents and who to contact.
    • Controls on confidential information.
    • Any constraints imposed by non-disclosure agreements.

    During

    Document incident details in an accessible knowledge/web portal and comprehensive ticketing platform.

    After

    Aggregate documentation from the post-mortem reviews and discussions of lessons learned into a formal report to share with management and IT. The post-mortem discussion should cover:

    • What happened and when? Develop a timeline of the incident.
    • The root cause of the incident.
    • The gaps and weaknesses in the critical incident process.
    • Steps that should be taken to fix the gaps in the process.
    • Ways to prevent and avoid similar incidents in the future.

    Establish a feedback loop with the general employee base to educate them on future mitigation and prevention tactics.

    Key Outcomes of Post-Mortem Documentation:

    Assessment of how the organization was impacted.

    • Productivity or revenue losses.
    • Number of impacted users.
    • Length of the outage/disruption.
    • Actions taken by technical staff.
    • Parties involved in resolving the incident.

    Include relevant metrics to indicate the impact of the incident and to outline the pain points for future security investments. Examples include:

    • Types of incidents.
    • Volume of incidents.
    • Costs incurred during the incidents.

    Info-Tech Best Practice

    Post-mortems can get emotional as blame tends to be passed around. Minimize finger pointing by steering the discussion toward gathering relevant information rather than assigning fault.

    Conduct post-incident activity: external information sharing

    Participate in information sharing

    Intelligence collaboration allows organizations to band together to decrease risk and protect one another from threat actors.

    • Participate in external information-sharing groups such as ISACs. Intelligence collaboration allows organizations to band together to decrease risk and protect one another from threat actors.
    • Disseminate relevant information in clear and succinct alerts, reports, or briefings.
    When publicly disclosing information about the security breach, consider:
    • Was customer data compromised?
    • Were legal and contractual obligations invoked by the incident?
    • What is the organization’s strategy moving forward?

    Create a structured media relations plan

    The impact to an organization’s reputation is one of the most significant consequences of a security breach. Minimize the damage from the media by quickly and professionally taking control of communication early in the course of the event. Media relations tactics include:

    • Designating a credible, trained, informed spokesperson to address the media.
    • Determining appropriate clearance and approval processes for the media.
    • Ensuring that your organization is accessible by the media so they don’t resort to other (less credible) sources for information.
    • Disclosing essential issues yourself so you don’t appear to be hiding information.
    • Emphasizing the steps being taken to address the breach.
    • Telling the story quickly, openly, and honestly to avoid false facts, rumors, or suspicion.

    64% of respondents do not agree that their company would know how to deal with negative public opinion, blog posts, and media reports.

    Only 36% of respondents agree that their organizations are effective at preventing negative public opinion, blog posts, or media reports.

    Source: Ponemon Institute, “Fifth Annual Study: Is Your Company Ready for a Big Data Breach?”

    Leverage additional supporting resources for communication

    US-CERT
    In the event of a crisis, we recommend you review this site for alerts on issues and to notify other workgroups of issues. Additionally, this is a great education site for technical and non-technical articles from configuration guides to political policy that could assist you in dealing with a crisis.

    SANS
    SANS Institute offers immersive training and resources across a variety of information security topics, including incident handling and response. Sample incident handling forms are available for consistent and effective documentation and communication while handling incidents.

    FBI
    At the FBI site, the goal is not really crisis management, but the ability to report a direct or suspected issue (via the Internet Crime Complaint Center).

    McAfee
    For the latest malware and APT information as well as support in dealing with an incident.

    ISACA
    The COSO and COBIT control frameworks are good resources to be aware of and can help you identify gaps in protection prior to an incident. The fraud prevention topics ISACA highlights are sound reading to help you understand how others have to deal with and disclose issues.

    US Secret Service
    The reason for this site is to direct you to the National Electronic Crimes Task Force in a regional city. They may know of local resources and agencies that could assist with investigations.

    InfraGard
    As an outreach program between the FBI and the private sector in the United States, this organization is excellent for networking and discussion with special interest groups or verticals that can help you hone your crisis management plan.

    Foundstone
    For incident management, forensics, and response.

    Kroll Ontrack
    For incident management, forensics, and response.

    (Reprinted from Security Battleground: An Executive Field Manual)

    Conduct post-incident activity: discuss lessons learned

    Formally discuss the lessons learned to discover areas of improvement, taking advantage of the experience before facing future incidents.

    Document Incident Response Quality:

    • Was the incident preparation sufficient?
    • Was detection prompt? Why or why not?
    • Were formal procedures followed? How useful were those procedures?
    • What information and resources were needed sooner?
    • What should be done differently if this incident were to reoccur?
    • How can we improve information sharing with other organizations regarding this incident?
    • What corrective actions can we implement to prevent reoccurrence of this incident?
    • What signs (precursors or indicators) should we watch for to detect future reoccurrences?
    • Did staff adequately deal with the incident with respect to their assigned roles and responsibilities?
    • What tools and resources are essential to detect, analyze, and mitigate future incidents of this nature?

    Encourage honesty. Remember, the goal is to learn from incidents to improve future performance and have reference materials prepared should a similar incident occur.

    Document Incident Costs:

    • What is the associated monetary cost of the incident?
    • To what extent did the incident disrupt normal operations?
    • Was any data permanently lost? If so, what is the value of that data?
    • Was any hardware damaged? If so, what is the value of that damage?
    • Did the incident cause reputational damage to the business?

    Use the financial costs associated with the incidents to justify future security budget requests.

    Conduct the post-mortem shortly after the incident, ideally within two weeks of recovery.

    2.5 Fill out the Root-Cause Analysis Template

    2.4 Root-Cause Analysis Template – 30 minutes

    Use the Root-Cause Analysis Template to help you determine the root-cause of your security incidents.

    Completing this exercise helps you to gain insight into the areas of your incident response procedures that need to be improved, and your security program more generally.

    Keep these entries brief, as they can be expanded in the Post-Incident Review Questions Tracking Tool.

    this image contains two screenshots of the Root-Cause Analysis Template.

    2.6 Customize the Post-Incident Review Questions Tracking Tool

    2.5 Post-Incident Review Questions Tracking Tool – 45 minutes

    • Customize the questions to ensure efficient and insightful lessons-learned meetings.
    • Dedicate an individual to facilitate the lessons-learned meetings and another individual to document all observations.
    • Use observations and findings from this document to populate a formal incident report.
    This is an image of the table found in the post-incident review questions tracking tool. It contains a column heading for the question, with instructions to customize the questions to capture information that will lead to continuous improvement of your incident management program, a column heading for the answer, with instructions to provide an answer to the corresponding questions. If applicable, select the appropriate answer from the drop-down menu.

    2.7 Complete the Security Incident Report Template

    2.6 Security Incident Report Template – 30 minutes

    Use the Security Incident Report Template to create a high-level summary of the incident, the remediation process, and any changes that need to be made to the existing incident management procedures.

    Keep these entries brief; this document is meant to summarize the contents of the Post-Incident Review Questions Tracking Tool.

    this image contains two screenshots of the security incident report template

    If you want additional support, have our analysts guide you through this phase as part of an Info-Tech workshop

    To accelerate this project, engage your IT team in an Info-Tech workshop with an Info-Tech analyst team

    Onsite workshops offer an easy way to accelerate your project. If a Guided Implementation isn’t enough, we offer low-cost onsite delivery of our project workshops.

    Info-Tech analysts will join you and your team onsite at your location or welcome you to Info-Tech’s historic Toronto office.

    We take you through every phase of your project and ensure that you have a roadmap in place to successfully complete your project.

    This is a picture of Celine Gravelines, an Info-Tech Research Manager

    Celine Gravelines


    Research Manager – Security, Risk & Compliance
    Info-Tech Research Group
    This is a picture of Logan Rohde, an Info-Tech Consulting Analyst

    Logan Rohde


    Consulting Analyst – Security, Risk & Compliance

    Info-Tech Research Group

    Call 1-888-670-8889 or email workshops@infotech.com for more information.

    Are you ready to move on to the next phase?

    Self-Assessment Questions

    • Have you defined and socialized the incident response framework?
    • Are there adequate detection methods in place to preemptively identify a threat?
    • Are there standardized operational procedures in place to actively assess potential threats?
    • Does your organization have a ticketing platform in place to document and share incident details?
    • Are incident details stored in a centrally accessible knowledgebase?
    • (Optional) Is incident software leveraged to automate the
    • response process?
    • Are there established operational processes and guidelines to support the containment, eradication, and recovery of detected threats?
    • Does your organization conduct internal post-incident activities such as a post-mortem analysis meeting or end-user awareness and training?
    • Is a post-mortem report created and communicated to management following each incident?
    • Does your organization conduct external post-incident activities such as sharing indicators to trusted ISACs or proactively engaging the media through a public relations program?
    • Has your organization identified and prioritized all relevant threats?
    • Has your organization documented and formalized relevant response procedures in operational runbooks?
    • Are runbooks stored in a centralized location and communicated to new hires during the onboarding process?

    If you answered “yes” to the questions, then you are ready to move on to Phase 3: Maintain and Optimize

    PHASE 3

    Maintain and Optimize

    Develop and Implement a Security Incident Management Program

    Phase 3: Maintain and Optimize

    PHASE 1 PHASE 2 PHASE 3
    Prepare Operate Maintain and Optimize

    This phase walks you through the following activities:

    3.1 Conduct tabletop exercises.
    3.2 Initialize a security incident management metrics program.
    3.3 Leverage best practices for continuous improvement.

    This phase involves the following participants:

    • CISO
    • Security team
    • IT staff
    • Business leaders

    Outcomes of this phase

    • A formalized tracking system for documenting and benchmarking security incident metrics.
    • Considerations for communicating security incidents both internally and externally.
    • Recommendations for optimizing your security incident management processes for maximum effectiveness based on tabletop exercises.

    Phase 3 outline

    Call 1-888-670-8889 or email GuidedImplementations@InfoTech.com for more information.

    Complete these steps on your own, or call us to complete a guided implementation. A guided implementation is a series of 2-3 advisory calls that help you execute each phase of a project. They are included in most advisory memberships.

    Guided Implementation 3: Review and Communicate Security Incidents
    Proposed Time to Completion: 2 weeks
    Step 3.1 Facilitate Tabletop Exercises Step 3.2-3.3 Assess the Success of the Incident Management Program
    Start with an analyst kick-off call:
    • Discuss what processes have been implemented so far for response to incident management.
    Start with an analyst kick-off call:
    • Discuss what processes have been implemented so far for incident management.
    • Discuss tabletop exercise results.
    Then complete these activities…
    • Prepare a team for simulated incidents during a tabletop exercise.
    • Facilitate a tabletop exercise with key responders.
    Then complete these activities…
    • Discuss which metrics are relevant and worth tracking.
    • Determine how they will be tracked and updated.
    With these tools & templates:
    Tabletop Exercise Template (workshop only)
    With these tools & templates:
    Security Incident Metrics Tool
    Phase 3 Results & Insights:

    Optimize the incident management process by working collaboratively, both within the organization and outside of it. Reserve multiple secure channels of communication to guarantee uncompromised communication methods during response. Work mutually with other organizations for information sharing to take advantage of intel gathered against incoming threats in the industry. Effective communication can be a fundamental instrument for successful incident management.

    3.1 Conduct simulated exercises to ensure the SIRT and staff know how to execute the incident response process

    Improve response and resolution times by simulating critical incidents in a test environment to prepare staff for a real-world crisis.

    Before you begin:

    • Document the procedures for handling specific types of critical incidents and communicate this information to process stakeholders.
    • Train staff accordingly so they have a firm grasp of the process and their specific roles and responsibilities. Ensure proper authorization has been provided.

    How to choose a sample incident:

    • Look at critical incident reports and post-mortems to find incidents that have occurred in the past with high impact.
    • Use other companies’ failures as a learning tool.
    • Conduct a fire drill for the most common critical incidents to practice investigation and diagnosis procedures for those scenarios.

    Fire-drill exercise:

    • Select a test environment that is isolated from customer-facing production. Choose the staff that are going to carry out the fire drill. This can be Level 2 or 3 support. Follow the steps from the Operate phase to detect, analyze, contain, eradicate, recover, and document a brief post-mortem review.

    Establish teams to deal with specific categories of critical incidents:

    • Give technical staff predefined roles and responsibilities.
    • Example: Level 2 is tasked with checking specific logs and monitoring history. Level 3 is designated as the team lead during the investigation.

    Conduct tabletop exercises with Info-Tech’s onsite workshop

    3.1 Tabletop Exercises Workshop – 90 minutes

    Leverage Info-Tech’s Security Incident Management Tabletop Exercise to guide incident simulations and validate your response procedures.

    How to customize

    • Use this template to document incident response actions and actors.
    • For each new inject, spend three minutes discussing the response as a group. Then spend two minutes documenting each role’s contribution to the response. After the time limit, proceed to the following inject scenario.
    • Review the responses only after completing the entire exercise.

    this image contains a screenshot of the tabletop exercise template for documenting incident response actions and actors.

    Available for customization: Design a Tabletop Exercise to Support Your Security Operation

    3.2 Assess your security incident management program

    Take a critical look at your program in terms of people, processes, and technology. A stale, ineffective process is as useful as no process.

    • Review the security incident management program in terms of people, processes, and technology:
      • Are users adhering to the process and meeting basic expectations?
      • Are incidents being handled effectively and efficiently?
      • Are the technical controls up to date and being used properly?
      • What are the trends of incidents by security area?
    • Info-Tech’s Security Incident Runbook Prioritization Tool (introduced in Step 2.3) offers benchmarking capabilities to record and assess the trends and improvements of your security incident management over time. Use the tool for the following:
      • Trends: Measure incident and root-cause trends over time to assess the impact of security changes (e.g. process improvements) or vulnerabilities (e.g. an increase in mobility).
      • Risk and Impact of Potential Future Incidents: Balance your assessment of past incidents with future risks. For example, if the use of mobile devices is increasing, the potential security risks for those devices need to be on your radar even if this has previously been a non-issue.
    26% of respondents say they haven’t reviewed their incident response plan since it was developed.
    40% have no time frame established for reviewing it.
    Only 27% say they review it annually.
    Be sure to update relevant policies and procedures in light of new knowledge, insights, and experience.
    Source: Ponemon Institute, “Fifth Annual Study: Is Your Company Ready for a Big Data Breach?”

    Data &rt; Information &rt; Metrics &rt; Analysis &rt; Action

    Security Incident Metrics Tool

    Metrics are merely a means to an action. Leverage Info-Tech’s Security Incident Metrics Tool.

    Know your audience
    Identify key stakeholders and understand what exactly they are expecting from the metrics.

    Be S.M.A.R.T.
    To provide practical value to your organization, metrics should be specific, measurable, attainable, repeatable, and time-dependent.

    Ensure quality and validity
    The quality and validity of the data is key to driving meaningful metrics to your organization.

    Standardize data collection
    Consider standardizing and automating the data collection process for consistency and effectiveness.

    this image contains a screenshot of the Security Incident Metrics Tool

    Master your security incident response communications program

    Effectively communicating a security incident can be a challenge in and of itself.

    Communication is a key part of the remediation process, but it is often an afterthought for many organizations.

    However, there are many challenges associated with incident response communications, and to be done well prior planning is needed.

    Leverage Info-Tech’s Master Your Security Incident Response Communications Program blueprint to help you:

    • Understand the difference between internal and external communications.
    • Determine who needs to be included on the security incident response communications team.
    • Define communication roles and responsibilities.
    • Develop a communications strategy.
    • Draft an incident response communications team policy.
    • Craft your message to the public.
    • Streamline interdepartmental communication.
    • Appreciate the value of a post-mortem review.
    this image contains three screenshots from the Master Your Security Incident Response Communications Program. The page titles are: Security Incident Response Communications Policy; Security incident Response Interdepartmental Communications template and; Communications Roles and Responsibilities.

    Leverage best practices and recommendations to optimize your security incident management

    • Incorporate a variety of skills into your incident response processes:
      • Departments such as IT security, legal and compliance, and public relations should be involved when making key decisions to minimize the impact of the incident.
    • Use predictive analysis to pre-emptively address incidents:
      • Don’t wait for something to happen. Analyze trends and patterns to anticipate attacks and incidents.
      • For example, if tax season is approaching, distribute a brief awareness reminder on avoiding phishing scams. Don’t wait for an attempt to be made before addressing it.
    • Apply for cyber liability insurance coverage (CLIC):
      • An effective risk transfer option for organizations with costly, mandatory data breach notification laws (46 of 50 US states).
      • Similar to an insurance policy for fire, flood, or theft, CLIC is a vital instrument for security risk management.
      • 45% of respondents in the Ponemon Institute Report on Breach Preparedness (2018) indicated that they had a security insurance policy.
    • Prepare an emergency jump bag filled with the following items:
      • Journal for documenting details (who, what, where, why, how) during an incident.
      • Contact information of all SIRT members.
      • USB flash drives.
      • Bootable USB flash drive with anti-malware and other software tools that can read/write to the affected file system.
      • Laptop with forensic software, anti-malware software, and internet access.
      • Computer and network toolkits to add/remove components, wire network cables, etc.
      • Hard duplicators with write-block capabilities to create forensically sound copies of hard drive images.
      • A durable bag or container to store all the contents of the jump bag.

    Source: SANS Institute, “Incident Handler's Handbook”

    Insurance company closes loop with incident response process by initiating post-incident processes

    The team established a schedule for post-incident reporting based on the severity of their security incidents.

    Deliverables/Evidence Frequency Accountable Communication With
    Security Incident Summary (Sev1) Two business days following publication of security incident report Security manager IT leadership
    Risk and privacy
    Security Incident Report (Sev1 & 2) For Severity 1 incident: 5 business days
    For Severity 2 incident: 7 business days
    Security analyst IT leadership
    Monthly Report The second Friday every month
    When a quarterly report is provided, the monthly memo will not be generated
    Security manager IT leadership
    Quarterly Report The second Friday of the month after each quarter
    Ad Hoc/Status Report As required Security manager As required

    Results:
    After implementing the new security incident response process, this company effectively reduced the security incident response time, minimized the incident impact, and increased transparency among key stakeholders.

    Insight Breakdown

    Save your organization response time and confusion by developing your own incident use cases.

    • Out-of-the-box incident classifications often offer too much coverage. Too many irrelevant cases that are not applicable to the organization are accounted for, making it difficult to sift through all the incidents to find the ones you care about. Develop specific incident use cases to correspond with relevant incidents to quickly identify the response process and to eliminate ambiguity when handled by different individuals.
    • Know when incidents are beyond the scope of your use cases. Identify when to seek third-party assistance and have contractors on retainer so you aren’t shopping around during a crisis. Prepare as much as possible before issues arise.

    Document and track each step of incident handling through the Operate phase.

    • A thorough and comprehensive record of an incident’s lifecycle will assist in understanding the root cause and allow for faster remediation of any future reoccurrence of the incident, as well as supporting any legal escalation. Tracking the cost of work hours helps in determining the overall impact on the organization.
    • Results of incident response must be analyzed, tracked, and reviewed regularly. Otherwise a lack of comprehensive understanding of incident trends and patterns leads to being revictimized by the same vector.

    Work collaboratively and maintain consistent communication both internally and externally.

    • Pre-emptively reserve multiple secure channels of communication to guarantee uncompromised methods of communication during incident response.
    • Work mutually with other organizations to share information and to take advantage of intel gathered against incoming threats in the industry. Effective communication is a fundamental instrument for successful incident management.
    • Don’t wait until a state of panic to try to organize communication tactics. Have public relations plans and third-party contracts with minimal update requirements established prior to experiencing an incident.

    Bibliography

    Accuvant. “Incident Response.” Optiv Security. 2015. Web.

    Alberts, C., et al. “Defining Incident Management Processes for CSIRTs: A Work in Progress.” Software Engineering Institute. 2004. Web.

    Allen, M. Incident Response Plan. 2003. Web.

    Bailey, T., and J. Brandley. “Ten Steps to Planning an Effective Cyber-Incident Response.” HBR. 1 July 2013. Web.

    Bejtlich, R. “Incident Detection, Response, and Forensics: The Basics.” CSO. 2 April 2008. Web.

    Bizeul, D., and V. Ferran-Lacome. “Incident Response Methodology: Malicious Network Behaviour.” CERT-SG. 2005. Web.

    Brown, D. “Incident Response: Communication is Key.” Security Magazine. 1 Jan. 2008. Web.

    CERT. “Action List for Developing a Computer Security Incident Response Team (CSIRT).” CERT. 2006. Web.

    Chapple, M. “How to Comply With Updated NIST Incident Response Guidelines.” TechTarget. Oct. 2012. Web.

    Chubb Group of Insurance Companies. “Why Your Organization Needs an Incident Response Plan.” Chubb Group. 2013. Web.

    Cisco. “Cisco 2018 Annual Cybersecurity Report.” Feb. 2018. Web. Cooper, K. J. “The Day After: Your First Response To A Security Breach.” TechNet. 2008. Web.

    Crest. “The Crest Cyber Security Incident Response Maturity Assessment Tool.” Crest. 2014. Web.

    Dell Secure Works. “10 Tips to Help You Minimize the Duration and Impact of a Security Breach.” Secure Works. 2013. Web.

    DigitalGlobe. “Predictive Analytics for Security & Law Enforcement.” DigitalGlobe. 2013. Web.

    Dorofee, A., et al. “Incident Management Capability Metrics Version 0.1.” Software Engineering Institute. 2007. Web.

    Eisner, R. S. “Stay a Step Ahead of State Data Breach Laws.” Law360. 12 Aug. 2014. Web.

    Everbridge. “Incident Management & Communications: Top 8 Focus Areas to Mitigate Risk.” Everbridge. 2013. Web.

    Federal Communications Commission. “Computer Security Incident Response Guide.” FCC. Dec. 2001. Web.

    Fey, Michael, et al. Security Battleground An Executive Field Manual. Intel Press, 2012. Print.

    Foundstone. “Corporate Incident Response.” Foundstone Professional Services. 2005. Web.

    Government of Canada. “Cyber Incident Management Framework for Canada.” Public Safety Canada. 15 Dec. 2014. Web.

    Hatchimonji, G. “RSAC 2014: Experts Discuss the Harsh Realities of Incident Response.” CSO. 27 Feb. 2014. Web.

    IBM. “2018 Cost of Data Breach Study: Global Overview.” IBM. 19 June 2017. Web.

    InfoSecurity Magazine. “CISO Roles Expanding to Encompass Risk Management Approach for Enterprise Security.” Reed Exhibitions Ltd. 17 Apr. 2013. Web.

    ISACA. “Incident Management and Response.” ISACA. 2012. Web. ISO/IEC 27035:2011. “Information Technology - Security Techniques - Information Security Incident Management.” ISO. 2011. Web.

    Kelley, Diana, and Ron Moritz. “Best Practices for Building a Security Operations Center.” Taylor & Francis. 11 Nov. 2017. Web. Kennedy, G. “Security Incident Handling in Small Organizations.” SANS. 2008. Web.

    Killcrece, G., and R. Rueflue. “Creating and Managing Computer Security Incident Response Teams (CSIRTS).” Software Engineering Institute. 2008. Web.

    Killcrece, G., et al. “State of the Practice of Computer Security Incident Response Teams (CSIRTs).” Software Engineering Institute. Oct. 2003. Web.

    Kral, P. “Incident Handler's Handbook.” SANS Institute. 2011. Web. Krutz, R. L., and R.D. Vines. The CISSP Prep Guide. Wiley Publishing, Inc., 2003. Print.

    Lecky, M., and D. Millier. “Re-Thinking Security Operations.” SecTor Security Education Conference. Toronto, 21 Oct. 2014.

    Linux Security. “Incident Response: Before, During, and After.” Linux Security, 2010. Web.

    Mandia, K., et al. Incident Response & Computer Forensics. The McGraw-Hill Companies, Inc., 2003. Print.

    Marquis, H. “9 Steps to Better Incident Classification.” itSM Solutions. 26 Feb. 2010. Web.

    Mell, P., et al. “Guide to Malware Incident Prevention and Handling.” National Institute of Standards and Technology. Nov. 2005. Web.

    Mundie, D., et al. “An Incident Management Ontology.” SEI Digital Library. 2014. Web.

    National Institute of Standards and Technology. “SP 800-61 Revision 2: Computer Security Incident Handling Guide.” NIST. 2012. Web.

    National Institute of Standards and Technology. “SP 800-83 Revision 1.” NIST. 2013. Web.

    National Institute of Standards and Technology. “SP 800-86: Guide to Integrating Forensic Techniques Into Incident Response.” NIST. 2006. Web.

    Nolan, R., et al. “First Responders Guide to Computer Forensics.” SEI Digital Library. 2005. Web.

    Osiatis. “Incident Management: Introduction and Objectives.” Econocom. 2010. Web.

    Pokladnik, M. “An Incident Handling Process for Small and Medium Businesses.” SANS Institute Reading Room. 2007. Web.

    Ponemon Institute LLC. “Fifth Annual Study: Is Your Company Ready for a Big Data Breach?” Experian. July 2017. Web.

    Proffitt, T. “Creating and Managing an Incident Response Team for a Large Company.” SANS Institute Reading Room. 2007. Web.

    Ragan, S. “Understanding Incident Response: 5 Tips to Make IT Work for You.” CSO. 1 Apr. 2014. Web.

    Rogers, B., et al. Security Battleground. Intel Press, 2012. Print.

    Rouse, M. “Data Breach.” TechTarget. May 2010. Web.

    Rouse, M. “Endpoint Security.” TechTarget. June 2011. Web.

    Sambhi, S. “An Introduction to Cyber Liability Insurance Cover.” ComputerWeekly. July 2013. Web.

    Sanders, T. “Information Security Program, Part 1: Building an Effective Incident Response Plan.” Information Intersection. Sept. 2012. Web.

    Schultz, E., and R. Shumway. A Six-Stage Methodology for Incident Response. Sams Publishing, 2001. Print.

    Shackleford, D. “Security Incident Management in the Cloud: Tackling the Challenges.” TechTarget. Sept. 2012. Web.

    Spohn, M. G. “Emergency Incident Response: 10 Common Mistakes of Incident Responders.” McAfee. 2012. Web.

    Tcherchian, S. “Breaching Bad and the Cost of Incident Response.” XYPRO. 22 Sept. 2014. Web.

    Tcherchian, S. “Incident Response Planning: Expect the Best, Plan for the Worst and Prepare to be Surprised.” XYPRO. 9 Nov. 2014. Web.

    The Network: Cisco. “Cisco 2017 Annual Cybersecurity Report: Chief Security Officers Reveal True Cost of Breaches and the Actions Organizations Are Taking.” The Network: Cisco. 11 Nov. 2017. Web.

    The University of Winnipeg. “Incident Response Procedures.” The University of Winnipeg IT Resource Security Standards. 2014. Web.

    Torres, A. “Incident Response: How to Fight Back.” SANS Institute. 2014. Web.

    Trickey, F. “Issues to Address in Your Incident Management Policy.” TechTarget. Jan. 2004. Web.

    US-CERT. “Federal Incident Reporting Guidelines.” United States Computer Emergency Readiness Team. 2014. Web.

    US-CERT. “The Center for Internet Security Metrics.” United States Computer Emergency Readiness Team. 2009. Web.

    US-CERT. “US-CERT Federal Incident Notification Guidelines.” United States Computer Emergency Readiness Team. 2014. Web.

    Valladares, C. “20 Critical Security Controls: Control 18 - Incident Response.” Tripwire. 18 Sept. 2013. Web.

    Verizon. “2017 Data Breach Investigations Report.” Verizon Enterprise Solutions. 2017. Web.

    Warrier, R. “Incident Management 103: Communications.” eBRP Solutions. 17 June 2013. Web.

    West-Brown, M., et al. “Handbook for Computer Security Incident Response Teams (CSIRTS).” Carnegie Mellon Software Engineering Institute. 2003. Web.

    Zeltser, L. “Initial Security Incident Questionnaire for Responders.” Zeltser.com. 30 Jan. 2015. Web.

    Zimmerman, Carson. “Ten Strategies of World-Class Cybersecurity Operations Center.” The MITRE Corporate Communications and Public Affairs. 2014. Web.

    About Info-Tech

    Info-Tech Research Group is the world’s fastest-growing information technology research and advisory company, proudly serving over 30,000 IT professionals.

    We produce unbiased and highly relevant research to help CIOs and IT leaders make strategic, timely, and well-informed decisions. We partner closely with IT teams to provide everything they need, from actionable tools to analyst guidance, ensuring they deliver measurable results for their organizations.

    Member Rating

    8.5/10
    Overall Impact

    $24,466
    Average $ Saved

    35
    Average Days Saved

    After each Info-Tech experience, we ask our members to quantify the real-time savings, monetary impact, and project improvements our research helped them achieve.

    Read what our members are saying

    What Is a Blueprint?

    A blueprint is designed to be a roadmap, containing a methodology and the tools and templates you need to solve your IT problems.

    Each blueprint can be accompanied by a Guided Implementation that provides you access to our world-class analysts to help you get through the project.

    Need Extra Help?
    Speak With An Analyst

    Get the help you need in this 3-phase advisory process. You'll receive 6 touchpoints with our researchers, all included in your membership.

    Guided Implementation #1 - Prepare
    • Call #1 - Understand the incident response process, and define your security obligations, scope, and boundaries.
    • Call #2 - Formalize the incident management charter, RACI, and incident management policy.

    Guided Implementation #2 - Operate
    • Call #1 - Use the framework to develop a general incident management plan.
    • Call #2 - Prioritize and develop top-priority runbooks.

    Guided Implementation #3 - Maintain and optimize
    • Call #1 - Develop and facilitate tabletop exercises.
    • Call #2 - Create an incident management metrics program, and assess the success of the incident management program.

    Authors

    Logan Rohde

    Celine Gravelines

    Contributors

    • Dave Millier, CEO, Uzado Inc.
    • Mahmood Sher-Jan, EVP & General Manager, RADAR Product Unit
    • Matt Anthony, VP, Security Remediation Services,The Herjavec Group
    • Jason Bareiszis, CSIRT Manager & Principal Security Architect, Tetra Tech
    • Malcolm Brown, Industry Analyst Relations, Trend Micro
    • Mark Bernard, CISO, Government, Financial Services, Manufacturing, Pharma, Legal
    • Wayne Chung, Senior Consultant, Information Assurance, Eosensa
    • Ali Shahidi, Chief Cyber Security & Computer Forensics, InfoTransec Inc.
    • Ian Parker, Head of Corporate System Information Security, Risk, and Compliance, Fujitsu Services
    • Joey LaCour, CISO, Colonial Savings, F.A.
    • Ron Kirkland, Manager ICT Security, Crawford and Company
    • Vincent di Giambattista, Director IT Security and Compliance, Alliance Healthcare Ltd.
    • Five anonymous contributors
    Visit our COVID-19 Resource Center and our Cost Management Center
    Over 100 analysts waiting to take your call right now: 1-519-432-3550 x2019