ENHANCING RESILIENCE THROUGH CYBER INCIDENT DATA SHARING AND ANALYSIS This document identifies perceived obstacles to voluntary cyber incident data sharing and offers potential approaches to overcoming those obstacles It is the third in a series of white papers 0 Overcoming Perceived Obstacles to Sharing into a Cyber Incident Data Repository December 2015 Table of Contents Executive Summary 2 Introduction 3 Perceived Obstacles to Voluntary Sharing of Cyber Incident Data 4 Obstacle 1 Assuring Anonymization 4 Obstacle 2 Ensuring Data Security 5 Obstacle 3 Cultural Challenges Regional Differences 6 Obstacle 4 Perceived Commercial Disadvantage 7 Obstacle 5 Internal Process Hurdles 8 Obstacle 6 Perceived Value 9 Obstacle 7 Assuring Appropriate Adequate and Equitable Participation 10 Obstacle 8 Technical Design Issues 11 Conclusion 13 1 Executive Summary This white paper is the result of a series of discussions among insurers chief information security officers CISOs and other cybersecurity professionals on perceived obstacles to the voluntary and anonymized sharing of cyber incident data into a trusted repository These deliberations were conducted within the framework of the Cyber Incident Data and Analysis Working Group CIDAWG and facilitated by the Department of Homeland Security’s DHS National Protection and Programs Directorate NPPD The CIDAWG’s findings build upon the ideas and recommendations contained in the group’s previous white papers “Enhancing Resilience Through Cyber Incident Data Sharing and Analysis the Value Proposition for a Cyber Incident Data Repository ” published in June 2015 and “Enhancing Resilience Through Cyber Incident Data Sharing and Analysis Establishing Community-Relevant Data Categories in Support of a Cyber Incident Data Repository ” published in September 2015 This white paper 1 identifies eight perceived obstacles to the voluntary sharing of cyber incident data 2 describes ways in which each obstacle might manifest in terms of questions or concerns that repository participants might have 3 suggests approaches to addressing those questions and concerns in order to overcome each obstacle and 4 identifies possible stakeholders and subject matter experts who could help develop and implement those approaches The identified obstacles focus primarily on assured privacy and anonymization data security and technical design challenges Approaches to address these issues involve process and communications strategies and technical best practices that should inform any future repository implementation This latter category includes effective input mechanisms for sharing cyber incident data into a repository – specifically mechanisms that are easy to use consistent with all applicable privacy and anonymization mandates and relevant to stakeholders who will both contribute to the repository and utilize aggregated repository data for cyber risk analysis This white paper specifically elaborates on the following eight categories of information sharing obstacles identified by the CIDAWG 1 Assuring Anonymization 2 Ensuring Data Security 3 Cultural Challenges Regional Differences 4 Perceived Commercial Disadvantage 5 Internal Process Hurdles 6 Perceived Value 7 Assuring Appropriate Adequate and Equitable Participation 8 Technical Design Issues The group’s follow-on efforts will focus on how a repository should be structured during an initial operating stage in order to support the kinds of analysis that cybersecurity stakeholders require to improve their cyber risk management practices 2 Introduction Since October 2012 the Department of Homeland Security’s DHS National Protection and Programs Directorate NPPD has convened a diverse group of private and public sector stakeholders – including insurers risk managers chief information security officers CISOs critical infrastructure owners and social scientists – to examine the state of the cybersecurity insurance market and how to best advance its capacity to incentivize better cyber risk management These stakeholders have expressed strong support for the creation of a trusted and anonymized cyber incident data repository As envisioned the repository would store aggregate and analyze cyber incident data relevant to the cyber risk management community including risk mitigation experts CISOs cybersecurity solutions providers risk transfer experts insurers and other cybersecurity subject matter experts the academic and scientific communities Enterprise risk owners could use the repository to anonymously share sensitive cyber incident data that then could be aggregated and analyzed – resulting in increased awareness about current cyber risk conditions and longer-term cyber risk trends New analytics products rooted in rich repository data in turn could help inform more effective cyber risk management investments by both private and public sector organizations An anonymized cyber incident data repository accordingly could make a major contribution to driving the Administration’s critical infrastructure protection and national resilience goals NPPD is committed to helping address the call for such a repository In February 2015 it established the CIDAWG in partnership with the Critical Manufacturing Sector Coordination Council under the auspices of the Critical Infrastructure Partnership Advisory Council CIPAC The group consists of insurers CISOs and other cybersecurity professionals representing a wide range of critical infrastructure sectors After establishing six major value propositions for a repository and identifying 16 data categories needed to attain that value the CIDAWG turned its attention to identifying and describing perceived obstacles to the voluntary sharing of cyber incident data and potential approaches to overcoming those obstacles They are the subject of this white paper As a next step in this dialogue the CIDAWG will deliberate on how a cyber incident data repository notionally should be scoped and structured during an initial operating stage in order to support the kinds of analysis that cybersecurity stakeholders across every sector need in order to enhance their cyber risk management practices Opinions expressed in this white paper are not necessarily reflective of the opinions of NPPD DHS the United States government or any specific entity or person involved in the discussions leading to this paper 3 Perceived Obstacles to Voluntary Sharing of Cyber Incident Data Obstacle 1 Assuring Anonymization This obstacle concerns challenges with assuring the privacy and anonymity of repository contributors while providing sufficient cyber incident details for effective and insightful analysis Perceived Concerns Despite assurances of specific data being “non-attributable ” the aggregation and analysis of cyber incident data as detailed in the white paper titled “Enhancing Resilience Through Cyber Incident Data Sharing and Analysis Establishing Community-Relevant Data Categories in Support of a Cyber Incident Data Repository ” could have unintended consequences in terms of sectorwide insurance rates For example aggregated data that shows the cascading consequences and total costs or impacts of certain types of incidents to certain industries could make some of the most common cyber incidents uninsurable or prohibitively expensive to insure Large scale cyber incidents might make it possible to connect a particular exploit with a contributing company or companies undermining the anonymity of the repository A robust anonymization protocol that can withstand attempts at malicious disclosure could lead to a situation where the obfuscation of the data source renders shared incident data unverifiable This “unverifiability” could undermine the repository’s value because it might complicate efforts to assure the reliability of contributed data Possible Approaches The single most effective way to address these obstacles is effective trust-building Potential mechanisms for promoting trust include Non-Disclosure Agreements Confidentiality Agreements Terms of Service Legal frameworks focused on compliance duty to defend and confidentiality with provisions that protect information from being linked in any way to a contributor and “Safe Harbor” legislation that protects repository contributors from subpoenas or liability on the basis of their anonymous contributions Beyond these policy approaches protective technical measures could include using a sequential or randomized alphanumeric identifier that ensures that shared data can only be associated with an incident and not a contributor Although the mechanism of entering data can create an association in system logs with the contributor’s IP address a two-server system with a manual transfer between them could better obfuscate data from malicious hackers to protect anonymity Using such an approach system administrators would be responsible for Securely transferring the data between the input system and the system of record Keeping an independent and separate correlation between the alphanumeric identifier and the contributing company should a reason later arise to connect them 4 Validating the legitimacy of the contributor via background check and Destroying original records as required by repository policy or by participants The success of the above policy and technical approaches would depend upon the competence and integrity of system administrators In addition a realistic balance between anonymity and verifiability will have to be carefully maintained in order to assure the value of the repository and its data to participating organizations Solution Stakeholders The CIDAWG membership could be a good starting point for engaging the appropriate mix of stakeholders and subject matter experts to develop anonymization policies and processes that maximize both trust in and value of a repository These stakeholders could include a combination of insurers CISOs other cybersecurity professionals industry sector representatives privacy experts and possibly audit firms with experience in validating policy implementation In addition any entity or organization that decides to host a future repository would be integral to the development and enforcement of its actual anonymization policies and processes Obstacle 2 Ensuring Data Security This obstacle addresses the need to assure the integrity and confidentiality of both submitted data and system contributors including the desire of contributors to retain control over their data and how it is used Perceived Concerns In addition to the importance of maximizing the security of the repository contributing organizations would need to understand who will see their data and how they will use it Specifically repository contributors would want to know That data access is limited in accordance with repository agreements policy That information is not disseminated to outside unvetted parties How the data will be protected e g will it be encrypted How the data will be managed e g record retention policies whether metadata would be retained for trending whether contributors could modify or delete their own data etc and The extent of third party e g non-contributor other contributor and government insight into the contributors’ identity and data Possible Approaches The approaches for overcoming or mitigating this obstacle generally involve cybersecurity best practice guidelines for designed-in security such as ISO 27001-like compliance requirements – including people process and technology controls – as well as governance Architecture Database Operating System Security Reviews Continuous monitoring authentication this may be at odds with the twin goal of data anonymization 5 Response plans in the event of a breach System and user behavior monitoring and analytics and Operational procedures access controls and usage monitoring Repository administrators should make judicious use of transparency mechanisms in order to reassure contributors about the security measures in place to protect the data they share They should do so moreover in a way that does not provide a roadmap for malicious actors who might want to obtain and exploit that shared data Finally to address peer contributor vetting and access concerns repository administrators should develop a pre-registration process that includes a background check based on appropriate criteria Such a check would allow a repository’s governing body such as a board to approve or disapprove the participation of particular entities Solution Stakeholders During any future repository planning effort a legal working group would need to collaborate with a technical working group to establish and review needed legal protections Both groups would need to engage subject matter experts responsible for developing the repository’s data security and access policies and processes Obstacle 3 Cultural Challenges Regional Differences This obstacle is focused on the unique aspects of various cultures countries or regions that may affect voluntary cyber incident data sharing Perceived Concerns Many U S corporations have international ownership presence or significant overseas operations which may create several challenges for a repository including the following Some countries in which participating companies operate are reluctant to expose a weakness vulnerability by reporting a problem As a result repository-identified cyber incident trends may be distorted because they may not include accurate information regarding incidents that local workforces are reluctant to report Privacy laws or other local regulations in some countries may create difficulties in reporting U S relationships or reputation in some regions or countries could affect participation For example some entities are reluctant to store data on systems in the U S based on the Snowden disclosures Companies with an international board or other stakeholders accordingly may not be comfortable sharing data within a U S -hosted repository Some sectors may be more eager reluctant to participate than others depending on their relationships with suppliers consumers and competitors which could skew data analysis by over- or under-representing incidents in certain areas Possible Approaches Contextual information about an incident such as what region the input comes from e g U S or nonU S may help analysts assess the reliability of the data Several CIDAWG members suggest however that participation in a repository should exclude non-U S entities at least during a proof-of-concept phase Not only is it legally and technically complex to address disparate information sharing laws and customs but also basing a prototype on a U S -only contributor base may help identify issues that would 6 need to be resolved prior to expanding beyond the initial implementation and participation group The CIDAWG therefore recommended using a prototype phase to develop trust and prove the concept with U S participants prior to expanding to non-U S entities Additional ideas for overcoming cultural reluctance to participation include Repository contributions from hacked U S government agencies that are legally permitted and willing to share their breach and other cyber incident data could help enhance the perceived value of shared threat information Such contributions also could help assure that information sharing between the government and the private sector is bi-directional and mutually beneficial Information Sharing and Analysis Centers ISACs and Information Sharing and Analysis Organizations ISAOs could be engaged to educate build awareness encourage participation and leverage existing trust relationships within specific sectors that are reluctant to contribute Solution Stakeholders The participation of ISAC and ISAO representatives in a repository proof-of-concept might encourage particular sectors to share cyber incident data Appropriate contributions from hacked U S government agencies as described above may also make proof-of-concept participation more attractive Obstacle 4 Perceived Commercial Disadvantage This obstacle addresses the likely concern by some companies that sharing cyber incident information could have negative business repercussions Perceived Concerns Contributors to a cyber incident data repository might find it difficult to abandon the longstanding practice of keeping company data in house – particularly incident information that either had damaging impact on a company or if it has weathered an incident well could damage competitors In addition companies may not want to devote the internal resources necessary to participate in a repository – especially if their competitors are not incurring those same overhead costs Repository contributors must be able to trust that their sharing would not open them to liability exposure and or otherwise negatively affect their business Possible Approaches Despite the overall concerns regarding information sharing of sensitive data repository developers should clearly communicate to potential contributors how repository data and resulting analysis could help illuminate the business case for particular cybersecurity investments in new technologies people and processes They should also emphasize that incident data sharing could help promote benchmarking against peer organizations that in turn would increase commercial competitiveness Appropriate safe harbor legislation that shields companies from subpoenas and or liability could help create the conditions necessary to incentivize sustained voluntary sharing into a repository Future repository developers should engage organizations that already operate voluntary information sharing systems about the kinds of legal protections that they have in place to foster trusted information sharing environments The Aviation Safety Information Analysis and 7 Sharing ASIAS database and Computer Emergency Response Team CERT are just two examples of potential models Solution Stakeholders Chief Risk Officers CISOs chief information officers CIOs company financial experts and CEOs would be key solution stakeholders to overcome this obstacle Obstacle 5 Internal Process Hurdles This obstacle concerns cultural and procedural challenges that may exist within contributing companies that could make information sharing difficult Perceived Concerns Many companies have internal processes governing the ability of their cybersecurity staff to participate in a voluntary cyber incident data sharing repository Some examples include Internal privacy regulations legal reviews and corporate information release approval processes can be prohibitive when it comes to effective information sharing They often involve the equities of many different offices whose cultural paradigms typically may not align well with an effort intended to rapidly release detailed information – albeit anonymously – regarding a cyber incident that may have serious corporate implications Companies with limited resources may not want to engage in non-mandatory activities that create overhead burdens or otherwise tie up manpower Certain sectors – for instance the health services industry – may have specific legal obligations that could conflict with voluntary sharing Possible Approaches Several strategies for overcoming these challenges include Appropriate “safe harbor” legislation that protects repository contributors from liability pertaining to the shared information could help overcome internal resistance Communities participating in a cyber incident data repository and the host operator of the repository could undertake an outreach or marketing campaign to overcome any reluctance to share One model might be the DHS “See Something Say Something ” campaign used by the Transportation Security Administration to detect and report possible criminal or terrorist activities affecting public safety at airports and other transportation nodes Incentivizing companies to incorporate incident data reporting into their standard operating procedures SOPs such as benchmarking data sharing as a best practice could help overcome this barrier Transparency with regard to security and privacy as well as demonstrated value to participating companies will be crucial to normalizing voluntary reporting Providing process tools frameworks guiding principles and or education and training about a repository and its purpose and value – in a way similar to how NIST introduced and developed the concept of its Cybersecurity Framework – may help overcome internal process hurdles particularly for small or medium-sized companies that are inexperienced at gathering or making use of cyber incident data 8 Solution Stakeholders Compliance and claims experts privacy officers general counsels risk committees and CISOs for developing SOPs are all important to overcoming likely internal hurdles to sharing Most important however is leadership buy-in Even the most entrenched internal obstacles can dissolve quickly if company leadership embraces the need for repository participation Obstacle 6 Perceived Value This obstacle concerns the return on investment ROI from participating in a trusted and anonymized cyber incident data repository Perceived Concerns Building on the internal hurdles discussion pertaining to leadership buy-in the CIDAWG discussed the need to constantly and clearly communicate the risk management advantages to companies that elect to voluntarily share cyber incident data into a trusted repository In other words repository proponents must be prepared to answer with concrete examples how repository contributors can expect to derive a return on investment ROI from their participation In particular members suggested that the specific value that a particular contributor might expect to gain from participation in the repository i e through incident data sharing must be made clear Possible Approaches The specific questions “what does a contributor gain” and “what is the return on investment” are addressed at length in the CIDAWG’s Value Proposition white paper The renewed discussion about incentivizing repository participation however highlights the need for further consideration of this question – specifically how to personalize the value of that participation so individual contributors can see a direct correlation between participation in cyber incident data sharing and received benefit In addition to the six core value propositions listed in the CIDAWG’s Value Proposition white paper therefore participation in the repository must demonstrate value specific to each company In order to clearly convey such advantages consideration should be given to several strategies Companies are more likely to adopt risk management approaches that their peers claim are useful Early adopters and or the developer of a repository accordingly could publish white papers to advertise its benefits One successful model for such “marketing” information could be the use cases developed by companies after the release of NIST’s Cybersecurity Framework that showed the value of adopting that framework Future repository developers should conduct an educational campaign that consists of executive summaries technical presentations training workshops and public statements Targeted messaging to different groups could highlight particular value that might appeal to their members Developers could offer workshops and webinars to help companies understand how to “use” a repository and why participation in a repository is valuable in a way similar to how NIST introduced the Cybersecurity Framework to industry Solution Stakeholders In addition to technical and corporate stakeholders mentioned in previous solutions marketing teams should be involved at both the developer administrator and company participant level Their participation would help ensure that repository contributors remain aware of and committed to the value gained from the voluntary sharing aggregation and analysis of cyber incident data 9 Obstacle 7 Assuring Appropriate Adequate and Equitable Participation This obstacle concerns the effect that the participation of others might have on the value of a repository There are three aspects to this obstacle 1 assuring appropriate participation which is related to access control 2 garnering adequate participation to ensure the volume and variety of data is sufficient to achieve envisioned value and 3 overcoming concerns about insufficient and inequitable participation by other contributors Perceived Concerns 1 Appropriate Participation Repository contributors will want to know that other participants in a repository are peer organizations or are in other ways comparable to their own e g members of the same industry sector This will help ensure that cyber incident data contributed by those peer organizations can support meaningful analysis when aggregated with their own Because of the specific types of information that the kind of repository envisioned here would hold some of which might have regulatory implications participants likely will insist that it not be owned operated or controlled by the Federal government In addition participants likely will seek assurances that government access to aggregate information is explicitly approved by a governing body of repository contributors 2 Adequate Participation During its initial operations a future repository might experience low participation rates occasioned by reluctance to be “first” and or potential stigma associated with early adoption 3 Equitable Participation If only a handful of companies contribute the vast majority of data into a repository they might conclude that they effectively are being “penalized” for sharing – in other words they give more than they get This “free rider” problem may lead some contributors to stop participating Possible Approaches A future repository likely will need to be developed and hosted by a non-government entity ies and or organization s with the extent and nature of Federal government engagement to be determined and approved by the repository’s governing body In order to encourage participation through benchmarking a repository could employ some kind of “tag ” recognition or other benefit to individual organizations that would accrue only after they share incident data Participation rates could be obfuscated during the early phase of implementation when participation by relatively few users might create a false impression that the repository “isn’t working” or is not valuable to its contributors Repository administrators could make data contribution the “price of admission ” which would address both the appropriate participation and “free rider” problems Only those organizations that are 1 vetted and 2 share information could take advantage of the information shared by others This would increase the perceived value of a repository by assuring contributors that their peer participants are equally invested in sharing data to inform cyber risk management practices However as some members observed such a provision would limit the ability of 10 legitimate but non-contributing entities such as researchers to take advantage of a unique opportunity to analyze aggregated cyber incident information A compromise approach might be to require that entities desiring access to repository data be vetted by the repository membership or some designated authority This would allow participants to require participation in return for access for commercial peers yet allow access on a case-by-case basis to other interested parties based on rules that a repository’s governing body determines Solution Stakeholders In developing solutions to these obstacles CIDAWG members suggested involving academic institutions Computer Emergency Response Teams CERTs Federally Funded Research and Development Centers FFRDCs legislators lobbyists and General Counsels Obstacle 8 Technical Design Issues This obstacle includes a combination of several related concerns about the actual functioning of a repository – specifically how that functioning affects voluntary information sharing These concerns are grouped under Ease of Process and Data Input and Display 1 Ease of Process Perceived Concerns A repository might add to a company’s reporting or staffing burdens – especially during the response phase of what might be a major cyber incident The following questions accordingly should be considered during a future repository design phase How easy is it for contributors to access and use repository data How easy is it for contributors to input and change data that they share into a repository What is the level of effort necessary for contributors within their own organizations to obtain and to provide data given the data may come from many different locations Possible Approaches Repository developers could Design questions for a repository input template that are relevant and easy to understand and to answer – e g with hover buttons and pull-down menus Ensure user-friendly human interfaces – e g provide parenthetical information to help users understand definitions the purpose of questions etc Consider providing data collection guidance that will allow company leadership to approve release of the information prior to sharing it into a repository A well-designed repository input template also could help users improve their root cause analysis capabilities by guiding the user to the right functional areas with the right questions and Consider integrating a common forensics reporting tool such as the STIX TAXII tool that allows the inputting of data in common formats for more effective sharing 11 2 Data Input and Display Perceived Concerns The CIDAWG also focused on how data inputs should be governed to prevent for example doublereporting and how data should be displayed or accessed after it has been entered Repository developers must consider the following questions How should a repository verify that each cyber incident has only one reporter – for instance when incidents affect multiple parties How should access be provided to shared cyber incident data How will repository guidelines or documentation ensure a common lexicon or frame of reference for data elicitation and sharing Will the information be displayed in a way that could potentially violate confidentiality and or reveal too much about the contributor How should a repository control what can be accessed downloaded by entities other than the original contributor Possible Approaches Several of these concerns reflect those expressed in Obstacle 1 Anonymization The CIDAWG agreed that the approaches identified for overcoming that obstacle should be applied as design considerations Additional approaches might include the following Multiple reports about a single cyber incident that affects several organizations are not only likely but desirable because part of the value of a repository is the ability to capture cascading effects and total costs impacts Therefore there needs to be a way to indicate when incidents are linked to a single source event like a regional incident where multiple companies are impacted e g a cloud provider that loses data for 10 companies Designers should develop a way to separate on the one hand identifiers used by organizations to track and access their own data and on the other identifiers used for the incident itself Information must be easy to understand There should be a dictionary of terms ease of access to the system fields e g through a browser and effective visualization and data mining tools – in short the kinds of built-in technical assistance that could help contributors easily conduct analysis In order to protect confidentiality there should be clear direction information and rules about appropriate repository usage such as prohibitions against downloading all its data or selling aggregated information Designers should consider adopting role-based access control for data display – i e academics insurers CISOs and other contributors could have access to different information A means of measuring how well the system is meeting the needs of participants – that is anonymized metrics assessing the performance of the repository itself – should be included in its design Solution Stakeholders Solution stakeholders should include IT systems experts including auditors Chief Data Officers data scientists and a data analytics team CISOs Chief Security Officers CSOs Directors of Security 12 governance representatives and NIST experts also should participate as security SMEs Moreover because CIOs typically own the resources through which participation in a repository would be conducted they also should be included in design discussions Their inputs will likely focus for example on the resources required to implement and use a given design effectively Finally entities with extensive experience in survey design should be included in order to ensure that the questions that a repository uses to elicit shared data do not skew the information provided Conclusion The CIDAWG discussions summarized in this paper address the third topic – Incentivizing Voluntary Data Sharing – of a four-topic dialogue about how a trusted and anonymized cyber incident data repository could be leveraged to improve the overall cybersecurity risk management practices of private and public sector organizations The CIDAWG has engaged in this dialogue over the course of several months in order to bring deep subject-matter expertise to the task of evaluating the proposition that cybersecurity incident data anonymized and shared through a repository could support analysis that informs Day-to-day risk mitigation strategies of CISOs CSOs and other cybersecurity professionals and the investments that their organizations make to address their unique cyber risk profiles Research initiatives and related product and service development plans of forward-looking cybersecurity solutions providers and Insurer efforts to scope price and deliver existing and new cybersecurity insurance policies that effectively transfer cyber risk by drawing upon new streams of actuarially relevant information As a next step in this dialogue the CIDAWG will deliberate on how a cyber incident data repository notionally should be scoped and structured during an initial operating stage in order to support the kinds of analysis that cybersecurity stakeholders across every sector need in order to enhance their cyber risk management practices 13
OCR of the Document
View the Document >>