Much has been made of the need to share information among companies since President Clinton signed Presidential Directive 63 exactly 20 years ago today, on May 22, 1998. Commonly referred to as PDD-63, the directive called for the creation of information sharing and analysis centers (ISACs) for critical sectors of the economy. President Obama widened the aperture to include other constituencies that desired to work together, including small businesses, sports organizations, and Internet of Things communities. Congress stepped up and passed the Cyber Security Act of 2015, which clarified what information can (and cannot) be shared and relieved concerns about liability and antitrust.
But even with all of this activity, progress has been very slow. Robust organizations like the FS-ISAC have been established to address sharing within the financial sector, but most organizations would agree that we have struggled with the "what, when, and how" of information sharing. In fact, the use of the word "sharing" in cybersecurity has almost become pejorative. Very basic questions have surfaced within in small and large organizations, such as, "How do I decide what to share?" "Do I only need to share information after a breach?" "How do I share securely?" and perhaps most importantly, "What value will I receive in return?"
Prior to the anniversary of PDD-63, the Cloud Security Alliance (CSA) with little fanfare made a significant contribution to enabling the free flow of sharing by releasing a research paper on its experiences in operating the Cloud Cyber Incident Sharing Center (C-CISC). The organization's work started nearly two years ago when Jim Reavis, CEO of CSA, started a voluntary exchange among member companies to exchange data. CSA member experiences yielded some straightforward lessons that can be adopted by ISACs and individual organizations alike.
Fixing a Broken Information Sharing Process
First, we must acknowledge there are vast differences between legacy information sharing systems and what organizations should look for today. The working group discovered that many organizations would hold data until after a breach was confirmed, which is of little value to others seeking to prevent a similar attack. Most data was being shared through noisy email listservs, and the review and approval process for sharing data was burdensome, resulting in reports that lacked proper context.
Through trial and error, CSA discovered what to share and how to share and identified key technologies to automate redaction and protect privacy.
The Hardest Part Is Getting Started
CSA's working group also found the majority of enterprises it encountered wanted to participate in a threat intelligence exchange, but they didn't know where to start. Enterprises begin by leveraging events generated by security information and event management systems or other tools that require review by an analyst. Then they gather event data with context into a secure repository, and, finally, exchange data with others using automated redaction tools.
CSA learned that most organizations did not have the means to see all of their suspicious event data in a common repository. In some cases, organizations were using multiple case management or orchestration tools that did not allow for easy correlation or real-time chronology of event data. The CSA guidance advises to select a system that allows the user to receive immediate feedback and is extensible, allowing you to choose what you want to share and with whom.
CSA's research paper includes other useful guidance around developing supporting security knowledge management policies and helps shape organizations that are thinking about evolving to mature cyber intelligence knowledge management, rather than thinking about purely reactionary threat intelligence as we did in the wake of breaches against Target and others several years ago.
Twenty years is far too long to wait for such guidance, but it has arrived just in time. You can download the paper here.