In light of the continuing stream of high-profile and public cyber incidents, including alleged breaches of companies that have been making the rounds within the cybersecurity and broader media ecosystem, we wanted to take a moment and talk about SpyCloud’s approach to responsibly disclosing breach and malware data to victims.
SpyCloud has designed our disclosure program to be supportive of victim organizations and help minimize the costs and impacts of data breaches and malware infections, and we believe strongly that organizations like us – those with access to non-public breached data – have an obligation to communicate this information to victim organizations in a way that is separate from sales or marketing activities.
What is Responsible Disclosure?
We define Responsible Disclosure (RD) as providing critical security information to a victim organization in the spirit of being a good internet citizen. Our RD team, which is a part of SpyCloud’s in-house research team SpyCloud Labs, regularly proactively engages with victimized organizations to make sure they have access to the data that was allegedly stolen from them so they have an opportunity to remediate any potential user or employee exposure due to the release of the information.
What is the role of the security community in Responsible Disclosure? Why SpyCloud has a Responsible Disclosure program
There are a lot of reasons we believe in having a strong RD program, including:
To be good internet citizens:
First and foremost, RD is part of our overarching philosophy of being good internet citizens and making the internet safer, which is core to our mission. SpyCloud collects breached, leaked, and stolen data by monitoring threat actor operations across the clearnet, deep web, and dark web. This means that we often have greater insight into the communications and operations of cybercriminals than most organizations are able to continuously maintain. RD allows us to ensure that when we come across data that suggests an organization has experienced a significant cyber incident that they may not yet know about, SpyCloud has a defined process in which to let them know. We do this irrespective of whether they are a customer and prioritize organizations that provide public service, are part of critical infrastructure, or whose compromise may have further downstream impacts, such as significant supply chain risk.
To foster collaboration:
One positive byproduct of conducting Responsible Disclosures to cybersecurity teams at other companies is that it opens the door to collaboration with that organization’s cybersecurity team. Often, we find that security teams at the affected organizations have very interesting insights into the threat actors, the data, or trends in the criminal and fraudulent threat activity targeting their industries that we never would have discovered without talking to them. RD can help give us greater insight into the data that we disclose and foster ongoing collaboration with cybersecurity and anti-fraud teams at a wide range of different organizations. Importantly, we never use information learned in this way for commercial purposes, unless the victim organizations specifically authorize us to do so.
To align with law enforcement guidelines:
A robust RD program also ensures we follow the Department of Justice (DOJ) guidelines on the collection and recovery of stolen data for cybersecurity purposes. In the United States, the recovery of stolen data should not violate the Computer Fraud & Abuse Act (chiefly by not gaining unauthorized access to third-party systems), and cybersecurity practitioners who recover stolen data for cybersecurity purposes should make an effort to inform “the actual data owner, to the extent it can be determined, that it is in possession of its data.” The guidelines also stipulate that cybersecurity researchers “should avoid making the return of stolen data dependent on purchasing the practitioner’s services or satisfying a demand for anything else of value.” SpyCloud’s RD program follows these guidelines by doing proactive outreach to affected organizations that we can identify, regardless of whether they are customers.
Responsible Disclosure guidelines: The dos and don’ts of RD for stolen data
We’ve defined some best practices – as well as practices to avoid – that we’ve found to be helpful along the way in building SpyCloud’s RD program.
Don’t - Take cybercriminals at their word
Before SpyCloud conducts a notification, we do some initial vetting of the information and try and make sure that:
- We are reasonably confident that the information appears to belong to the entity that we are attempting to notify. Cybercriminals often misrepresent the origin of stolen data both intentionally (to make the data seem more concerning than it really is and generate buzz and internet clout) and unintentionally (due to poor data analysis).
- The data appears to be “real” and doesn’t have clear signs of data fabrication.
- The data leak, breach, or theft appears to be publicly unknown. We will not attempt to do RD if a data breach has already been very prominently covered in the news and has been posted in a public place (such as a popular hacking forum with no barriers to entry) or if the victim entity has already made a public statement about the data. In these cases, we assume that companies are already very aware of the incident and able to obtain the data themselves
- The data is not intentionally publicly available data. Often threat actors will repost databases that are intentionally publicly available in an attempt to pass them off as sensitive or breached data. For example, it is very common for threat actors to post US voter registration data and attempt to pass it off as breached. However, most US voter registration data is publicly accessible by law (with some state-by-state differences in how it can be accessed). Another example of a dataset that gets reposted often is INTERPOL’s ‘Red Notice’ data on wanted persons, much of which is intentionally publicly available.
Do - Include as much information as possible in the notification
When conducting a notification, our team generally tries to include a few key pieces of information:
- A concise summary of the data. This might include the types of files included, the number of records, file size, and data types contained.
- The raw data itself. We always encrypt sensitive data such as credentials and PII before sharing the data with the affected organizations.
- As much information as we can possibly provide about the data’s source. When possible, we will include exact URLs for where threat actors hosted data such as forum posts, messaging application channels, or file sharing links so that the victim organization can investigate directly. Additionally, we might include any other insights we have about the threat actor. For leaked data, we might share reproducible steps that one can take to access the unintentionally exposed data. In instances where the source of the data is sensitive, we try to give as much context as we can (e.g. a Chinese-speaking cyber threat actor privately shared this data). For data that appears to be derived from malware infections, we might also share detection signatures or other hunting guidance to assist network defenders in finding the malware infection.
- Any information-sharing restrictions. Generally, the data we share with victim organizations is their own, so we don’t try to dictate what they do with that data. However, if we want to request that organizations keep any context around that data – or how SpyCloud obtained it – close hold, we use the Traffic Light Protocol (TLP) to portion mark any sensitive information.
Do - Reach out privately via a trusted contact
In an ideal disclosure, our RD team reaches out to a member of the cybersecurity team of the affected organization who is already in our professional network or who we can connect with through a trusted mutual contact. If this isn’t possible, we often leverage trusted membership organizations such as Information Sharing and Analysis Centers or National CSIRTs to connect with organizations in other countries. Finally, after exhausting these other avenues, we will attempt to reach out “cold” either to the security contact listed on an organization’s website or to members of the organization’s cybersecurity team that we find on LinkedIn. When “cold” contacting organizations, we might provide slightly less data up front until we can validate that the contact mechanism is actively checked, or, on LinkedIn or this organization’s site, that the individual is still affiliated with the affected organization.
Reaching out via trusted points of contact can help ensure that our message is seen and addressed as quickly as possible. This also helps the victim organizations who don’t have to waste time verifying our identities before responding to the security issue. Additionally, reaching out directly to the cybersecurity or IT teams at the affected organization also eliminates time for internally routing the disclosure to the appropriate team, also helping to make sure the issue gets addressed as quickly as possible.
Don’t - Make RD a sales or marketing function
At SpyCloud, the RD function is a part of our in-house research and innovation team – SpyCloud Labs – and not a part of either the sales or marketing teams at SpyCloud. This has a few benefits. For one, disclosures are conducted by security researchers who understand the data as well as SpyCloud’s collections techniques and the broader cybercrime ecosystem. This means notifications are informative and have appropriate context and levels of urgency.
Another benefit is that RDs are less likely to be construed as attempts to sell SpyCloud products and services, which can make victim organizations ignore communications attempts and see claims of heightened urgency as sales tactics. As we highlighted above, this also allows us to align with DOJ guidelines on gathering cyber threat intelligence.
Questions about our RD program?
As we continue to grow our RD program, our priority is to work collaboratively with other researchers and the security community to support victims. If you have questions, contact us and a member of our team will be in touch.
More about our mission
SpyCloud automates identity threat protection for more than 4+ billion employee and consumer accounts using insights from 600+ billion assets recaptured from the dark web. Our focus is on making darknet data actionable to protect businesses from cyberattacks, safeguard employee and consumer identities, and streamline cybercrime investigations. Customers globally – including half of the Fortune 10 – count on SpyCloud to thwart identity-based attacks including ransomware, account takeover, session hijacking, and online fraud. SpyCloud Labs is our focused cybercrime research group dedicated to uncovering and analyzing the most intricate patterns from the criminal underground.
Keep reading
