Real-world Practices for Incident Response Feb 2017 Keyaan Williams Sr. Consultant

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 2

Beginning with the End in Mind

Beginning with the End: Adopt a Framework NIST SP 800-61r2 1 National Institute of Science and Technology Special Publication 800-61 v2, COMPUTER SECURITY INCIDENT HANDLING GUIDE, August 2012

Beginning with the End: Understand what you are responding to! Define things!

Beginning with the End: Have a process At least use a checklist! 6

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 7

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. 6.3. Remove malware, inappropriate materials, and other components. 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. 8

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

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

Terminology

Terminology Events verses Incidents 1 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 12

Terminology Threat: 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 13

Terminology Attack 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 Email 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 14

Putting it into Action: Implementing this at your organization

Putting it into Action Evaluate your organization to ensure that threat modeling activities occur and the threat environment receives continuous monitoring. 16

Putting it into Action Based on the threat modeling processes, ensure your organization is aware of the likely threat scenarios from the Top down. 17

Putting it into Action Develop a real commitment and engagement from management. Effectiveness requires appropriate authority, budget and capabilities to accomplish incident response goals. 18

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? 19

Putting it into Action Test, Test and retest Prefect Practice make Perfect Performance 20

Thank You Keyaan Williams Keyaan.Williams@nccgroup.trust

Framework Foundations

Framework/Foundations 1 1 National Institute of Science and Technology Special Publication 800-61 v2, COMPUTER SECURITY INCIDENT HANDLING GUIDE, August 2012

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 24

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 25

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 26

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 analysis from (Changes all probable in Files sources 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 27

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 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 (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 29

Building Effective Incident Response

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 31

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

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 33

Construct of Effective and Streamlined IR programs 34

Construct of Effective and Streamlined IR programs 35

Testing Incident Response

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 37

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 39

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 40

Case Study

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 42

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? 43

Case Study for Ease of Use Criteria for Escalation and Response National Institute of Science and Technology Special Publication 800-61 v2, COMPUTER SECURITY INCIDENT HANDLING GUIDE, August 2012 44

Case Study for Ease of Use Criteria 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 Criteria for Escalation and Response National Institute of Science and Technology Special Publication 800-61 v2, COMPUTER SECURITY INCIDENT HANDLING GUIDE, August 2012 46

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? 47

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 49