Last updated at Wed, 13 Dec 2017 19:50:25 GMT
Maintaining information sharing balance
Cybersecurity information sharing issues are a hot topic. This is because a balance must be maintained between benefits and risks of information sharing. This balance is sometimes hard to maintain, and at the same time there are currently legal requirements regarding sharing such information.
The main benefit of sharing cybersecurity information is more effective:
- incident prevention and
- incident response.
The main risks of sharing cybersecurity information are:
- sharing business-critical information with external entities and
- risks related to personal data.
There are more benefits than risks in cybersecurity information sharing. In addition, there are legal and regulatory requirements on cybersecurity information sharing that every entity (business and government) must apply.
Information sharing legal requirements
These are mainly related to Cybersecurity Information Sharing Act of 2015, which we will discuss in next article.
Information sharing relationship models in NIST SP 800-61
The NIST recommendation lists three types of possible information sharing (and coordination) relationships:
- “Team-to-team” – collaboration between incident response teams of two or more organizations;
- “Team-to-coordinating-team” – collaboration between the incident response team and a central point of coordinated incident response (e.g. US-CERT);
- “Coordinating-team-to-coordinating-team” – collaboration between multiple coordinating teams.
There is a table in NIST document that explains different types of information shared depending on the type of relationship. It is worth analyzing, to see where your incident response team currently stands in terms of these relationships. NIST stresses that it is important to build and maintain these relationships – they are of high value, especially for “team-to-team” information sharing.
It is important to remember that good relationship with external entity is not enough to share any information with that entity. Any information sharing should have contractual and legal basis, so always consult legal department.
Security considerations and granular information sharing
Incident information often contains sensitive data. Sharing of such data should be minimized, if possible. If sharing is necessary, it should always be done on “need to know” basis. If possible, data should be sanitized (leaving the data that must be shared, cutting off the most sensitive data). NIST SP 800-61 recommends also granular information sharing.
Granularity is a well-known notion in information security. It concerns e.g. access rights. It can also be directly applied to information as an approach to classify the information before it is being shared.
NIST SP 800-61 divides incident information into two types:
- technical information – these are mainly incident indicators;
- business impact information – information on the impact of the incident.
Sharing incident indicators with external parties and analyzing indicators shared by external parties with your organizations can have significant benefits. However, proper care should be taken when sharing (sensitive information protection) and when using externally obtained indicators (they might not apply to your organization).
NIST does not recommend sharing business impact information with external parties unless:
- there is a legal requirement;
- the external party can help the affected party.
So serious care should be taken when sharing business impact information.
On the other hand, business impact information can be very useful for incident response coordinating organizations. If such organization see that an incident had significant business impact, it can act accordingly with regard to other organizations it coordinates, thus limiting wider impact of such incident.
Business impact information on an incident can be reported by impact levels used for incident prioritization.
Please remember that it is not only important to secure and protect your own incident information – you should also protect any incident information you received from any external entity.
Timing of information sharing
Incident information should be shared throughout the incident response life cycle. It is not practical (nor secure and sometimes not legally acceptable) to wait with information sharing until the incident has been resolved.
Ad hoc information sharing
As NIST SP 800-61 states, even the smallest organization should be prepared to share information on the incidents it was affected with.
The simplest way to share the incident information is, as NIST recommendation defines it, “ad hoc” information sharing. This is done using “traditional” methods such as email or phone.
Such sharing, if done informally, has two significant disadvantages:
- it is often based on informal personal relationships (which will be useless if a team member leaves the organization);
- there is no clear definition of incident data that are to be passed during such sharing.
But ad hoc information sharing is still effective and helpful, it also is (and will probably be) still widely used. One just needs to remember about these two disadvantages.
Automated information sharing
NIST SP 800-61 recommends that organization should automate as much information sharing as possible (with human control in critical points of this process). It also recommends that formal, machine-processable models are constructed for this purpose.
Such approach will ensure effective, controlled, standardized information sharing, with defined data sets of incident information.
Consider using security automation for this purpose.
NIST recommendation contains remarks on two issues regarding automated (or partially automated) incident information sharing:
- data exchange model – there is a dedicated appendix that lists existing standards of data exchange that are related to incident handling;
- technical transport mechanisms – they need to be effective and secure.
Additional sections in NIST SP 800-61
NIST recommendation contains also couple of very useful additional sections. They can be very helpful for an incident response team. These are:
- list of generic questions about an incident, related to each phase of incident response life cycle – such questions can help create SOPs (standard operating procedures) for incident handling;
- example incident scenarios (e.g. DNS DoS attack).
NIST SP 800-61 review summary
In the following articles:
- Recommendations for Incident Response Team of NIST SP 800-61
- Introduction to Incident Response Life Cycle of NIST SP 800-61
- Preparation Phase of Incident Response Life Cycle of NIST SP 800-61
- Detection and Analysis Phase of Incident Response Life Cycle of NIST SP 800-61
- Containment and Eradication Phase of Incident Response Life Cycle of NIST SP 800-61
- Post-Incident Activity Phase of Incident Response Life Cycle of NIST SP 800-61
we reviewed contents of NIST SP 800-61 – Computer Security Incident Handling Guide. This was general-level introduction, its goal was to help you familiarize with NIST recommendation and learn how it can be used to improve incident handling at your organization (or how to start getting compliant with this recommendation).
Please note that besides NIST SP 800-61 there is also another, international standard on incident handling – this is ISO/IEC 27035. We will be discussing this standard soon.
(In next article in this series, we will talk more about legal requirements concerning cybersecurity information sharing, including incident information sharing, based on Cybersecurity Information Sharing Act of 2015.)