Go It Alone or Share Attack Data
To share or not to share, that is the question.
When an organization is attacked, should that organization inform others of the attack, its success or failure, and how the organization responded to the attack? There are pros and cons.
The decision is both intellectual and probably emotional. Learning from others can bolster an organization's security. But sharing with others could also be used against the sharing organization to create better and more successful attacks. I have seen surveys of Session Border Controllers (SBC), where some respondents think that even simply revealing the vendor's name is a security issue.
"Time is not your friend when your information systems are under cyber-attack, but sharing threat information before, during, and after an attack with a trusted group of peers can help. Not only does it alert the other members of your community to a potential attack, it can provide critical actionable information to speed and bolster your own defenses. Participating in a formal information sharing group can greatly enhance an organization's cybersecurity capabilities."
This is a quote from a NIST press release "Cyber Security: Your Mother Was Right, Sharing is Good, And NIST Has Some Help on How."
Looking at a Sharing Site
Let's assume that sharing attack information is worthwhile. The first consideration is forming a sharing group. The open concerns are:
- Creating a trusted sharing site
- Protecting the sharing site from intrusion and attacks
- Determining who should be members of the sharing site
- Defining the qualifications of those accessing the site
- Monitoring the use of the site and what attack data is shared
- Preventing vendors from using the site to sell products or services
This is not meant to a social networking site. Be conscious that other members may not always be trustworthy. This is a site to create good relationships for the purpose of strengthening security. It is not a site to makes friends.
Who Should You Trust
Security is only as strong as the people that design, implement, and monitor the organization's security. Inside threats are still a common problem for IT security. So as a member, I would want to investigate my own employees before I submit them as site members. I would also like the other organizations to perform equally as good investigations of their employees. You may believe that there are no security problems with your staff, but you cannot say this about the other sharing site member's staff.
Many organizations use outside contractors for security. I would want and expect these contactors to accept the liabilities if their security functions are not followed properly or if the contractor's employees create a security problem whether deliberate or through ignorance or negligence. This is where the organization's CIO, CSO, and CFO need to be advised by their lawyers before signing any security contract. You may find that the liabilities accepted by the contractor are too one-sided to be worth pursuing. Do you want the contractors to be site members?
Someone authorized to share information may actually use the site to create vulnerabilities in the site's members. One approach is to severely limit those who can access and use the site. Another is to periodically review the site usage by the employee to look for unusual behavior. A third consideration is to review the employee's contributions to the site. Look for few or no contributions, determine if the contributions help others, if the employee goes beyond information sharing, and whether the employee contributes questionable attack information and doubtful attack mitigation solutions.
The highest level of trust should be with the person monitoring the security employees. This person should also be accountable for security lapses when sharing information. You may want to empower a security committee to periodically oversee the internal security operation to ensure there is no collusion among employees that can compromise security.
When I performed security checks for military intelligence, I was tasked with checking the security in other departments - not my own department. Those outside my department checked my security. It was never known when the security checks would occur, and the everyday operations would be checked without notice. This should be the same philosophy when checking on the security staff and reviewing the threat information sharing site.
Keeping Safe While Sharing
Sharing security attack and intrusion information can help others. Your organization wants to benefit and improve from the information that other organizations have. It is a two way street.
The organization has to develop and enforce policies and procedures about threat sharing. The downside of too many restrictions is that this will lessen the quantity, quality, and timeliness of the shared information. To loosen restrictions can essentially publish the organization's vulnerabilities. This is a difficult condition to balance. Too little shared information can be as harmful as too much information shared.
The NIST document strongly recommends that a full inventory of the organization's information must be established and kept rapidly and consistently updated. There should be informative annotations stored with the attack description. Needless to say, all of this requires strong and applicable security controls be produced and enforced.
The security problems will not disappear. Knowledge is a good thing. More knowledge means the better the security. Sharing can help the organization focus its security efforts on the most dangerous problems. The security staff has to be able to prioritize their efforts and become even more efficient. The security problems will not disappear. The security staff using the shared information can become more agile and respond to the attacks and intrusions faster, thereby reducing the success of security threats.