Building Best Practices for Effective Monitoring of a Third Party s Incident Event Management Program. A Shared Assessments Briefing Paper

Transcription

1 Building Best Practices for Effective Monitoring of a Third Party s Incident Event Management Program A Shared Assessments Briefing Paper

2 Abstract Just 43% of incident management professionals report their organization has a formalized incident management plan and only 9% deem their program to be very effective. 1 In addition, coordinated and active vendor involvement is generally not part of an outsourcing organization s program, even when a plan is in place. As vendors account for a significant portion of breached data, incident costs, and reputational damage, they must begin to play an active role in response planning, preparation, execution, and remediation. This paper outlines a best practices model of incident event management program creation that directly involves third party providers. Shared Assessments has examined and outlined best practice processes for outsourcing companies. The result is a robust reference tool and practical third party risk assessment and monitoring recommendations for each phase of incident event management (pre, during, and post incident). A methodology and step-by-step guideline for third party incident event management planning, policies, and procedures are presented, which can be tailored to each relationship depending on vendor type. The supplemental assessment guide published here will help organizations to: 1. Be better prepared against the now-inevitable possibility of an incident. 2. Have a coherent, coordinated plan for managing third party incident control, reporting, and remediation. Issue Landscape There is an increasing mandate for organizations to know their vendors and apply industry standards for operational, financial, and information security related risks to all outsourced vendors and their sub-vendors. The SANS Institute reports a myriad of issues that negatively affect incident event management professionals in their efforts to establish an effective program. A primary barrier identified is the lack of time to review and practice hands-on walkthroughs and mock exercises that test incident response procedures. Other significant issues include: Definitions of the term incident are often too broad and vary by service type, which places strain on incident management teams. 2 Term use spans the gamut: network breaches; malicious software; unauthorized access/ removal of sensitive data from both internal and external sources; loss of intellectual property through misuse, theft, or loss; possible compromise of insecure or fourth party data repositories; and interruption of services through network disruption due to software issues all of which can have catastrophic ramifications. Most organizations report that they lack formal collection techniques and analysis surrounding threat intelligence just 31% attempt to perform attacker attribution as part of organizational incident analysis. This prevents identification of the root cause (control lapse or newly evolved breach path) and proactive information sharing, further thwarting capacity building efforts both within the organization and within the incident response field. In response, these professionals are seeking to improve organizational analysis and reporting capacity by focusing on use of Security Information and Event Management (SIEM) tools. Scoping and remediation are the calibration points most targeted by the 68% of SANS respondents who report their main focus to be SIEM tool improvements. 3 Risk Management Approach Recommendations: Implications for Practice Effective third party due diligence demands a higher level of review than is presently being performed. It requires a more proactive approach and a thorough review of the risks involved in outsourcing each type of service to a vendor, as well as the possible disruption of service that could result from an incident. 1 Incident Response: How to Fight Back: A SANS Survey Torres, A. SANS Institute InfoSec Reading Room. August Sponsored by AccessData, AlienVault, Arbor Networks, Bit9 + Carbon Black, HP, and McAfee/Intel Security. 2 NIST defines an event as any observable occurrence in a system or network and a computer security incident as a violation or imminent threat of violation of computer security policies, acceptable use policies, or standard security practices. Computer Security Incident Handling Guide NIST SP r2. August, Incident Response: How to Fight Back: A SANS Survey Torres, A. SANS Institute InfoSec Reading Room. August Sponsored by AccessData, AlienVault, Arbor Networks, Bit9 + Carbon Black, HP, and McAfee/Intel Security Shared Assessments Program. All rights reserved. 2

3 To be effective, organizations must begin to determine and address the key questions for establishing best practices, which include designating the area within the corporate structure responsible for building a coherent pre-incident plan and the area responsible for understanding root causes when they do occur. The latter is particularly important, since trust can be compromised during the incident. Determining best use of staff involves considering and validating at both the internal and vendor levels: 1. The need for an incident response team. 2. The types of expertise that team carries. 3. The documentation of each team member s roles and responsibilities. Organizations should set the goal of validating three interrelated segments of incident event management: 1. Pre-incident preparation (planning and testing). 2. Incident response that executes the plan and holds to its integrity. 3. An active response to lessons learned and retention. The following graphic shows a comprehensive overview of an incident process lifecycle that includes process repeatability. The preliminary best practices guide below was designed during this project. It leverages each of the phases and interrelated segments identified above. This outline can be utilized by organizations as a quick how to guide for effective third party incident event management. Pre Incident Framework Processes - Preparation Related Concerns for Best Practice Define Incident Types 1. Identify incident types by severity (e.g., loss of control of hard copy records vs. cyber breach). 2. Weight incident type by severity. 3. Define and weight incident handling priorities by type: Protect (human life and information). Collect (analysis of event). Prevent (damage to systems, restore). 4. Declare what response should be used based on severity rating. Does data loss require notification? 2015 Shared Assessments Program. All rights reserved. 3

4 Pre Incident Framework Processes - Preparation Related Concerns for Best Practice Planning Contract Development Evaluate Framework Controls Incident Policies and Procedures Incident Response Team Definition 1. Determine industry best practices. 2. Determine what controls are in place. 3. Be proactive on both vendor and outsourcing organization sides re: forensics investigations. 4. Develop standard of who/when/ how soon to notify, including backup protocol and information required. 5. Determine what scribe/tool rules will be used. 6. Establish an investigation playbook. 1. Set guidelines based on requirements. 2. Ensure contract includes: Service oriented architecture(s). 24x7 service level agreement(s) (SLAs). Legal representation. Cybersecurity insurance. Vendors MUST notify by incident type; specify time frame. No-fault/no-fear clause. Business continuity plan. Clearly defined escalation processes. Annual assessment allowance. Define limits of data access. 1. Define types of data and relative risk (e.g., regulated/unregulated, physical data, etc.). 2. Define potential root causes. 1. Evaluate whether third party has the people, process and technology in place to fulfill scoped requirements. 2. Determine if type of vendor insurance is appropriate to outsourcing need. 3. Meet with vendors often (monthly). 1. Define roles and responsibilities. 2. Identify incident coordinator/ quarterback and backup coordinator protocol. 3. Identify POC for data owner: IT/ legal/communications. 4. Outsourcing company should be notifying party. What is the plan? Documented/undocumented? How mature is the plan? Is it being tested and how (e.g., simulated forensics investigations)? Lessons learned from testing? How often is the plan updated? Is data shared appropriate to need? Identify prior breaches/handling by vendor? Escalation processes should be tied to industry standards. Understand vendor s standard contract needs. How to promote information sharing? How will execution be evaluated? Where can data owner step in during incident? What are consequences of failure to perform (including penalties/ termination)? Are there monitoring, control logs, evidence? Pen testing - are they performed regularly internally and externally; at what intervals; are they performed by credentialed pen testers? Which party is responsible for cybersecurity insurance and/or costs associated with investigation and/or damages? Can a repeatable incident response process be demonstrated? Structured/unstructured? Ad hoc/best practice? What is the plan? What should it include? When was last simulated incident response test? Select team by inventory and role. Regulatory requirements may determine notification channel/ medium Shared Assessments Program. All rights reserved. 4

5 Pre Incident Framework Processes - Preparation Related Concerns for Best Practice Crisis Management Planning 1. Identify stakeholders/escalation points: Internal (board of directors/it security/risk teams/hr/public relations/privacy/legal). Third party. 24x7 SLAs responding to data owner. Regulatory notification POC. Law enforcement. Customers. Internet/social media threat detection. Cyber insurance. Notification and credit monitoring. Investigation/ client protections. Is there a board of director s risk committee? Does the primary have contracts with the third party to ensure notification? During Incident Identification Containment Notification (if applicable) Framework Processes Identification/ Containment Eradication Recovery 1. Run pre-established plan: incident identification, escalation, investigation, and classification. 2. Determine under what classification the incident falls (use PHI/PII definition from Shared Assessments SIG). 3. Document/store incident information once scenario becomes critical (as defined based on pre-incident weighted severity by type). 1. Monitor tasks with third party. 2. Reduce impact. 3. Receive vendor containment reports. 4. Revise as necessary. 5. Suspend information sharing, if needed. 1. Reporting based on incident categories. 2. If appropriate, contact local, state, or federal law enforcement. Maintain internal/external communications. Related Concerns for Best Practice Follow pre-determined workflows by incident type based on predetermined severity of event by type. What detective controls are used to identify an incident and reduce its impact? What does each stage of the incident lifecycle process reveal? Is information collected and preserved that facilitates event forensic analysis? Was system damage prevented? Acquire, preserve, secure and document evidence, as appropriate. How do you make decisions if the vendor has deviated from their plan? What/when do you need to report to the CEO? Consider connection implications (direct/indirect). When should an incident be reported? What type of notification channels are used? How can you best maintain information sharing with external stakeholders? B2B or B2C? 2015 Shared Assessments Program. All rights reserved. 5

6 During Incident Eradication and Recovery Framework Processes Identification/ Containment Eradication Recovery 1. Remove the cause. 2. Acquire, preserve, secure and document evidence as appropriate for incident type and severity (for litigation, prosecution, regulatory review. 3. Monitoring. 4. Continue documenting due dilligence. Related Concerns for Best Practice Ensure systems/processes were recovered. Validate that the recovery action implemented by third party remains in place. Post-Incident Business Resumption Remediation Management Post-Incident Contract Response Framework Processes Lessons Learned 1. Follow plan definitions for return to normal ops. 2. Confirm normal function. Vendor and outsourcing company s response: 1. Document lessons learned and apply them. 2. Update policies and procedures per identified gaps. 3. Update incident response processes to reflect findings. 4. Recording and trending analysis of incidents and outcomes in the vendor population. 5. Review viability issues surrounding the vendor. 6. Update relevant contract language and/or terminate contract. 7. Update roles and responsibilities to involve the correct people in the process(es). 8. Include media reported incidents in future testing. 9. Education of consumers and retraining of staff. 10. Ensure continued dialogue with vendor. 1. Perform analysis to determine the root cause of incident. 2. Wind down, off boarding. 3. Rebuild trust. 4. Contract termination (if appropriate). Related Concerns for Best Practice How do we know we are not sending good data into a still-broken process? Hold and document a lessonslearned meeting. How was the incident recognized? Were the correct people involved in each process? Did communications channels work as designed? Was the vendor correctly rated as a critical vendor? When gaps are identified with a provider s plan, what corrective actionable measures are established to remediate these issues? How is this monitored? Do we need to add additional resources? Was the vendor properly scoped/ tiered? Was an unknown fourth party involved? What controls failed to protect sensitive information and systems? Did the data breach impact organizational trust to the point of requiring contract exit? Determine if vendor diversity is warranted to add resiliency to process(es) Shared Assessments Program. All rights reserved. 6

7 Post-Incident Post-Incident Evaluation Framework Processes Lessons Learned 1. Data ownership, destruction, and return. 2. Ongoing monitoring. 3. Post-incident client support. 4. In case of identity theft, provide credit monitoring, as per contract. 5. Financial evaluation of incident cost. 6. Recover breach costs (insurance, third party, legal). 7. Determine any cost gaps for future coverage. 8. Meet with vendors often (monthly). Related Concerns for Best Practice Ensure systems/processes were recovered. Validate third party recovery action remains in place. How are we communicating to clients impacted? Is this communication a shared responsibility? Do outsourcing company contracts require revisions? Return on Investment/Benefits of Best Practice Use This risk management guide provides a clean, consistent methodology for the assessment of incident preparedness, incident management, and post incident recovery. The assessment best practices guidance tool can be utilized: 1. To create a robust assessment process of third party vendors. 2. To build an effective third party incident event management program. Benefits that organizations may expect from using the guide as a tool include: Improved maturity in an organization s program. A defined means for protecting data, consumers, and the outsourcing relationship. Improved outcomes through a higher level of preparation. Raised awareness through development of best practices issues on this topic. Defined effective mechanisms for incident resolution and/or remediation. Conclusion This project has provided a guide organizations can use to understand and evaluate the best approach to assessing third party incident event management programs and using the information garnered through the preparation, assessment, management, and mitigation processes. When conducting due diligence around a third party s plan, it is critical to ensure that: A mature response process is intact. Key internal/external stakeholders are recognized. Points of escalation and notification are established and set well in advance of a potential incident or cyberattack. It is also important to ensure that the program is running as intended, remediation is performed in a timely fashion to close control gaps, and lessons are integrated into the program at the conclusion of the incident. The Shared Assessments Program will continue to enhance guidance in the area to better interpret what controls constitute sufficiency for data being accessed and transmitted and to inform use of a maturity driven model as a possible option in the 2016 Standardized Information Gathering (SIG) questionnaire ( bundle/). Other items under consideration during that process will include the feasibility and use of vendor diversity and ongoing monitoring as a best practice to add resiliency to incident response processes. This work will serve to bring a higher level of agreement on best practices among top-level management and inform the evolution of each industry s standards surrounding incident response and management across enterprises Shared Assessments Program. All rights reserved. 7

8 About the Shared Assessments Program The Shared Assessments Program is the trusted source in third-party risk management, with resources to effectively manage the critical components of the vendor risk management lifecycle; creating efficiencies and lowering costs for all participants; kept current with regulations, industry standards and guidelines, and the current threat environment; adopted globally across a broad range of industries both by service providers and their customers. Through membership and use of the Shared Assessments Program Tools (the Shared Assessments Agreed Upon Procedures (AUP), Standardized Information Gathering (SIG) questionnaire, and Vendor Risk Management Maturity Model (VRMMM)), Shared Assessments offers companies and their service providers a faster, more efficient and less costly means of conducting rigorous assessments of controls for IT and data security, privacy and business continuity. The Shared Assessments Program is managed by The Santa Fe Group ( a strategic consulting company based in Santa Fe, New Mexico. Thank You to Our Contributors We d like to thank the Shared Assessments SIG Committee for being champions for our ongoing work in the Shared Assessments Program. Their assistance and expertise is invaluable and serves all of our members, and their respective industries. Our SIG Committee members and Shared Assessments contributors are: Jonathan E. Dambrot, CEO, Prevalent, Inc., Shared Assessments Steering Committee Chair 2015, Shared Assessments SIG Committee Chair Brenda Ferraro, Director of Global Security, Aetna, Shared Assessments Steering Committee member. Rocco Grillo, Managing Director & Global Incident Response & Forensics Investigations, Protiviti, Shared Assessments Steering Committee member. Andrew Hout, 3rd Party Risk & Compliance, Prevalent, Inc. Ted Julian, Vice President, Product Management & Co-Founder, Resilient Systems. Dina Letteri, Corporate Information Security Senior Associate, New York Life Insurance Company. Tanya Montrose, Risk Manager, PCI Compliance, FIS, Shared Assessments Steering Committee member. Shared Assessments staff contributors: Angela Dogan, Senior Project Manager, The Santa Fe Group and Shared Assessments Program. Sarah Perry, Senior Marketing Manager, The Santa Fe Group and Shared Assessments Program. Marya Roddis, Senior Consultant, The Santa Fe Group and Shared Assessments Program Shared Assessments Program. All rights reserved. 8