real-world practices for incident response - isaca.org practices for incident response ... scenarios...
TRANSCRIPT
Real-world Practices for Incident Response
Feb 2017
Keyaan Williams– Sr. Consultant
2
Agenda
The Presentation
• Beginning with the end.
• Terminology
• Putting it into Action
Additional resources and information
• Framework/foundations
• Building Effective Incident Response
• Testing of the incident response plans and team members
• Case Study
Beginning with the
End in Mind
1National Institute of Science and Technology Special Publication 800-61 v2, COMPUTER SECURITY INCIDENT HANDLING GUIDE, August 2012
Beginning with the End: Adopt a Framework
NIST SP 800-61r2
Beginning with the End:
Understand what you
are responding to!
Define things!
6
Beginning with the End:
Have a process
At least use a checklist!
7
Step Action Completed
Detection and analysis
1. Determine whether an incident has occurred.
1.1 Analyze the precursors and indicators
1.2 Look for correlating information
1.3 Perform research
1.4
As soon as the handler believes an incident has occurred,
begin documenting the investigation and gathering
evidence.
2. Prioritize handling the incident based on relevant factors.
3.Report the incident to the appropriate internal personnel
and external organizations
8
Step Action Completed
Containment, Eradication, and Recovery
4. Acquire, preserve, secure, and document evidence.
5. Contain the incident
6. Eradicate the incident
6.1. Identify and mitigate all vulnerabilities that were exploited.
6.2.Remove malware, inappropriate materials, and other
components.
6.3.
If more affected hosts are discovered (e.g., new malware
infections), repeat the Detection and Analysis steps (1.1., 1.2) to
identify all other affected hosts, then contain (5) and eradicate
(6) the incident for them.
9
Step Action Completed
Containment, Eradication, and Recovery
7. Recover the incident
7.1. Return affected systems to an operationally ready state.
7.2. Confirm that the affected systems are functioning normally.
7.3.If necessary, implement additional monitoring to look for future
related activity.
10
Step Action Completed
Post-incident Activity
8. Create a follow-up report
9.Hold a lessons learned meeting (mandatory for major incident,
optional otherwise).
Post incident activities are important to ensure the
organization understands how the incident occurred
and ensure the organization takes steps to prevent the
same type of incidents from occurring again.
Terminology
12
TerminologyEvents verses Incidents1
Events
An event is any observable occurrence in a system or network.
Adverse events are events with a negative consequence, such as system
crashes, packet floods, unauthorized use of system privileges, unauthorized
access to sensitive data, and execution of malware that destroys data.
Incident
A computer security incident is a violation or imminent threat of violation of
computer security policies, acceptable use policies, or standard security
practices
1 National Institute of Science and Technology Special Publication 800-61 v2, COMPUTER SECURITY INCIDENT HANDLING GUIDE, August 2012
13
TerminologyThreat: The potential source of an adverse event. Common threat
surface:
• Human Interaction
• Email (received and sent)
• Web pages visited
• Social sites
• Blogs
• Architectural
• Network interfaces (External and Internal)
• Severs and running services and applications
Vulnerability: A weakness in a system, application, or network that is
subject to exploitation or misuse.
National Institute of Science and Technology Special Publication 800-61 v2, COMPUTER SECURITY INCIDENT HANDLING GUIDE, August 2012
14
TerminologyAttack Vectors: These are the means used by the attackers to exploit
vulnerabilities. Examples are:
• External/Removable Media
• Attrition: An attack that employs brute force methods to
compromise, degrade, or destroy systems, networks, or services
• Web
• Social Engineering
• Improper Usage
Precursor: A sign that an attacker may be preparing to cause an
incident.
Indicator: A sign that an incident may have occurred or may be
currently occurring.
National Institute of Science and Technology Special Publication 800-61 v2, COMPUTER SECURITY INCIDENT HANDLING GUIDE, August 2012
Putting it into Action: Implementing this at your organization
16
Putting it into Action
Evaluate your organization to ensure that threat
modeling activities occur and the threat environment
receives continuous monitoring.
17
Putting it into Action
Based on the threat modeling processes, ensure
your organization is aware of the likely threat
scenarios from the Top down.
18
Putting it into Action
Develop a real commitment and engagement from
management. Effectiveness requires appropriate
authority, budget and capabilities to accomplish
incident response goals.
19
Putting it into Action
Implement incident response processes to address
your reality based on real threats to your business.
Are BIA, CP, DRP, etc. in place, relevant, and
adequate to support the incident response program?
20
Putting it into Action
Test, Test and retest…”Prefect Practice make
Perfect Performance”
Framework
Foundations
1National Institute of Science and Technology Special Publication 800-61 v2, COMPUTER SECURITY INCIDENT HANDLING GUIDE, August 2012
Framework/Foundations 1
24
Agile and Responsive Framework/Foundations
• Incident Response Policy and Program defined
• Incident Response Plan is drive by up-to-date information
• Threat Intelligence
• Business Impact Assessments that are current and accurate
• Asset Identification – Data, Technologies, People and Processes
• Critical contracts, customers and business partners are part of the plan
• Supported from the top down and are fully integrated within Policies, Programs
and Plans
25
Agile and Responsive Framework/Foundations
• Defined roles and responsibilities
• Based on need-to-know and value add (lean and effective)
• Built in fail-over for critical roles so there are no single failure points
• Specific Response member playbooks that are tailored to their roles and
responsibilities
• Required tools, services and documentation processes are in place for use in
near real-time
26
Agile and Responsive Framework/Foundations
• Incident Response Team Structure
• Central Incident Response Team - A single incident response team handles
incidents throughout the organization (small organizations and for
organizations with minimal geographic diversity)
• Distributed Incident Response Teams - multiple incident response teams,
each responsible for a particular logical or physical segment of the
organization (large organizations and major computing resources at distant
locations).
However, the teams should be part of a single coordinated team
National Institute of Science and Technology Special Publication 800-61 v2, COMPUTER SECURITY INCIDENT HANDLING GUIDE, August 2012
27
Understanding the Interaction of People - Organizational
Structures• Incident Response Team Structure
• Think of how we can detect both the precursors and actual incidents with a
focus on agility and responsiveness
• Helpdesk trouble calls (Our service tickets and activity type and volume)
• Network Operations Center (Anomalous Network Traffic and Log Events)
• Platform administrators (Changes in Files Permissions, Software
programs and application code)
• Physical Security personnel and intrusion detection and surveillance
(Eyes and Ears)
• System Security teams – Threat Intelligence
• End Users – (System Performance, Unusual Application Operations and
Changes)
• Vendors, Service Providers, Business Partners and Customers
Incident Response program must integrate near real-time information gathering and
analysis from all probable sources
28
Understanding the Interaction of People - Organizational
Structures• Incident Response Team Interaction
• Make response activities repeatable and checklist drive for ease of use
• Playbook for each group of responders –
• Provide overview in each section for the “Kill-Chain” for each type of
category of incident
• Tailor each group’s playbook to their roles and responsibilities – KISS
Principle
• Make simple decision trees and use Graphics to depict if possible for
ease of use – Yes there are multi-surface attacks, but you follow the
kill chain based on triage
• Forms in place for complete and accurate documentation of each
team members activities step by step from initial to Report
29
Understanding the Interaction of People - Organizational
Structures• Incident Response Team Interaction
• Make response activities repeatable and checklist drive for ease of use
• Playbook for each group of responders – (continued)
• Color coded sections for types of incidents based on decision tree –
pull the cards your need and follow the process
• Have only those numbers in each playbook that are applicable to the
team members roles and responsibilities (to include fail-over)
• Keep it current
Building Effective
Incident Response
31
Construct of Effective and Streamlined IR programs
• Supported from the Boardroom down
• Threat modeling is presented to the Board in clear concise presentation
• Risk framing and appetite clearly defined for most likely scenarios and receive
Board level acceptance
• Board directs Senior managers to develop, implement and test incident
response program(s), policies and processes and provide status reporting as
part of normal Cybersecurity briefing processes
• Senior management appoints a responsible person who has both the authority,
budgetary means and clearly defined responsibilities to enable the IR processes to
be executed in near real-time across all business groups within the organization
• Senior management ensures that ALL organization across the enterprise MUST
support the IR processes.
• The IR Executive establishes a cross functional IR command structure based on
the accepted scenarios, BIAs and related CP and DRPs
32
Construct of Effective and Streamlined IR programs
• Contracts are in place for all required services – Should be documented in the BIA
and required coordination with procurement team to ensure these lists are current
and accurate
• Forensics support contracts
• Software Escrow in support of “Trusted Recovery”
• External Legal Counsel
• Recovery services – Logical, Physical, Temporary Staffing (look at your
scenarios and this should drive criticality of these resources
• Hosting, cloud and other managed service providers
• Business partners agreements clearly define response clause responsibilities and
direct that they support your IR processes if applicable to include documentation
and document production requests
• Speaking of documentation….
33
Construct of Effective and Streamlined IR programs
• Well defined documentation and artifact gathering, retention and protected storage
processes
• Well defined methods and techniques to ensure Chain-of-Custody of all
evidentiary material in any form they could be obtained
• Document repository is identified and maintained to protect against
unauthorized access or alteration
• Use of tools such as SharePoint and/or other document management
systems
• Multifactor authentication and defined role based access control
• Securely accessible from remote locations by incident response team
members
• Public affairs and legal counsel provide rule of engagement with media,
friends and family for all employees, contractors and other affected third
parties
34
Construct of Effective and Streamlined IR programs
35
Construct of Effective and Streamlined IR programs
Testing Incident
Response
37
Testing of the Incident Response Plans
• Consider your Audience
• How do you work a test with Executive Management’s schedule?
• For progressive involved management this can be done as an overall
integrated test
• For a diverse senior management team on the move – Yes that is most of
us, try working tabletop scenarios that can be securely worked over
remote connections - Cell phones (voice and SMS) and email
• Use threat intelligence/modeling to develop test scenarios that are most likely
to occur from each category in the playbook (data breach, malware outbreak,
logical and physical intrusions, etc.)
• Tabletop scenarios that need to be completed with one hour per scenario
using full escalation as per decision trees to accurately simulate and evaluate
responses of each team member and the processes within the playbooks
38
Testing of the Incident Response Plans
• Consider your Audience
• How do you work a test with Executive Management’s schedule?
• For progressive involved management this can be done as an overall
integrated test
• For a diverse senior management team on the move – Yes that is most of
us, try working tabletop scenarios that can be securely worked over
remote connections - Cell phones (voice and SMS) and email
• Use threat intelligence/modeling to develop test scenarios that are most likely
to occur from each category in the playbook (data breach, malware outbreak,
logical and physical intrusions, etc.)
• Tabletop scenarios that need to be completed with one hour per scenario
using full escalation as per decision trees to accurately simulate and evaluate
responses of each team member and the processes within the playbooks
39
Testing of the Incident Response Plans
• Consider your Training and Testing Tools
• Where do you house the testing
• War Room
• Out-location conference rooms
• Test environments for simulation to include help desk (depends on level of
realism desired or within budget)
• How can you record electronic and person to person exchanges during testing
to evaluate effectiveness of these exchanges of information during the incident
• SMS, emails, faxes
• An employee assigned as a recorder of all minutes during testing
• Collection of manually and electronically completed incident response
forms, notes and artifacts
40
Testing of the Incident Response Plans
• Consider your Other Interrelated Plans
• Business Continuity and Disaster recover teams
• Standing up VMs to simulate recovery and test capabilities
• Third parties (based on highest criticality for each scenario) integrated with
the response plans, i.e. off site backups, recovery vendors, critical
business partners, managed service providers
• Travel and other expenses are planned for and simulated for the
deployment of critical personnel
Case Study
42
Case Study – KISS in Action
University Hospital has been receiving calls to the Help Desk electronic health
records files can not be accessed by physicians within several departments.
• Detection is being made by the Help Desk – How does the Hospital determine
they have an incident?
• By definition this is a indicator due to the volume of call?
• By definition this is an event that is causing impact to availability
• By definition after looking a production schedules there is no indication that
these systems or servers holding these data have outages that would cause
this issue - INCIDENT detected!
Is it this Simple? No not all the time but it can be just as Streamlined
Users and Help Desk personnel are “Tip of the Spear” and a great Barometers of what is
taking place within your enterprise
43
Case Study for Ease of Use
• Identification and Analysis is being made by the integrated IT and Security team –
How?
• Following their checklists they review the detailed information that the Help
Desk documented within the trouble ticket and identify:
• Current affected system, files, departments etc.
• Time first report of the events that lead to the incident being detected
• Interview of affected personnel indicates files are all inaccessible due to
being encrypted
• One states that they
• Notifications now follow escalation process for Malware Incidents
• By definition - INCIDENT identified and being Analyzed! – Who, What, Where
and a portion of how?
44
Case Study for Ease of UseCriteria for Escalation and Response
National Institute of Science and Technology Special Publication 800-61 v2, COMPUTER SECURITY INCIDENT HANDLING GUIDE, August 2012
45
Case Study for Ease of Use
National Institute of Science and Technology Special Publication 800-61 v2, COMPUTER SECURITY INCIDENT HANDLING GUIDE, August 2012
Criteria for Escalation and Response
46
Case Study for Ease of Use
National Institute of Science and Technology Special Publication 800-61 v2, COMPUTER SECURITY INCIDENT HANDLING GUIDE, August 2012
Criteria for Escalation and Response
47
Case Study for Ease of use
• Containment, Eradication and Recovery is being made by the integrated IT,
Security, Malware SMEs, CEO, CFO, CIO, Legal Counsel, Privacy Officer, head of
Medical Operations, Public Affairs, Third party Forensics, Law Enforcement,
appropriate government agencies
• Following their checklists they each apply TTPs per their discipline to:
• Contain the spread of Ransomware
• Eradicate Ransomware and based on Management risk based direction
pay ransom or recover and re-enter data
• Initiate disaster recovery and business continuity plans for affected
systems processes concurrent with incident response (concurrent with
above bullets) – Do you have software escrow in place? Trusted recovery
images?
48
Case Study for Ease of use
• Containment, Eradication and Recovery is being made by the integrated IT,
Security, Malware SMEs, CEO, CFO, CIO, Legal Counsel, Privacy Officer, head of
Medical Operations, Public Affairs, Third party Forensics, Law Enforcement,
appropriate government agencies
• Following their checklists they each apply TTPs per their discipline to:
(continued)
• Address legal and reporting requirements
• Prepare and deliver public and private communications to stakeholders
49
Case Study for Ease of use
• Post Incident Activities
• Documentation and reports from detection through recovery from all team
members are collected along with relevant artifacts from all parties involved
• Incident Response Team Owner and/or program team review what went right
and wrong and efficiencies and effectiveness throughout the response process
• Based on the analysis document lessons learned, they make
recommendations for updating:
• Policies, procedures, playbooks
• Organizational alignment for response
• Specific Tools, Techniques and Procedures
• Identification and removal of bottlenecks
• Update training for failures noted pre, during and post incident