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

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)

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

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

• 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

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

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

Security incident management is applicable to all verticals

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

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

Understand how incident response ties into related processes

Develop and Implement a Security Incident Management Program – project overview

Workshop overview

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

Measured value for Guided Implementations

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

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

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.

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:

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%

• Entertainment
• Professional Services
• Public

Privilege Misuse

18%

• Healthcare workers stealing PII
• Internally-driven public admin data breaches

Crimeware

16%

• Ransomware
• C2 exploits
• Worms

Web App Attacks

15%

• Stolen credentials
• SQLi
• Brute force

Physical Theft

14%

Miscellaneous Errors

6%

• Misdelivery
• Publishing error
• Disposal error

Cyber Espionage

0.7%

• Manufacturing
• Public
• Professional

Point of Sale (POS)

0.5%

• Accommodation & Food Services
• Retail

Payment Card Skimmers

0.2%

• ATMs
• Gas pumps
• POS terminals

Everything Else

2%

• Phishing
• Footprinting
• Pretexting

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.

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.

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.

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.

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

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.

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.

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.

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

2. Review grouped initiatives and identify specific initiatives that should be broken out and defined separately.
3. 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.

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

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.

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.

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.

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.

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.

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.

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

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

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

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.		Celine Gravelines Research Manager – Security, Risk & Compliance Info-Tech Research Group
		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

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.

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

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.

Insurance company specified detailed incident response process

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

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

1. historic frequency
2. expected trend

1. functional impact
2. information impact
3. recoverability effort

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.

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.

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.

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.

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:

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

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"

Explore open-source software

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

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

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

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

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

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

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

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.

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.

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.		Celine Gravelines Research Manager – Security, Risk & Compliance Info-Tech Research Group
		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

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.

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.

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.

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.

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.

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.

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.