CSIRT Tooling: Best Practices in Developing, Maintaining and Distributing Open Source Tools

Introduction

The role of a CSIRT (Computer Security Incident Response Team) is key in information society and especially to improve cyber security in their constituencies and beyond. To achieve this, CSIRTs often have significant operational constraints such as limited budgets (in many settings, CSIRTs are considered cost centers), a bound number of resources or/and overloaded staff members. Tooling, such as software or tools used in day-to-day activities in Digital Forensic, Incident Response and Threat Intelligence, offers CSIRTs to operate more efficiently the processing of constant flow of information and act in a timely manner (such as notifying victims, reporting, information sharing at European or International level or investigating technical evidences). In this document, a set of best practices is described to help CSIRTs to develop, maintain and distribute existing or new Open Source tools.

Definition

The term CSIRT tooling will be used in this document to describe any Open Source or Open Hardware project which aims to support digital forensic or incident response, specifically in the scope of the Computer Security Incident Response Teams.

Software Development Practices

A critical element in Open Source software development is the availability of the source code in a public repository along with the history of changes. Source control management such as git allows everyone to see the development activities (such as bug fixing and updates), to grasp the inner development practices of a tool and the community behind. While developing CSIRT tooling, a publicly1 accessible source control management must be used.

A source control management repository for CSIRT tooling allows:

Another significant benefit of relying on a public source control management such as git is to keep track of all changes in the commit messages associated with related changes. This allows to understand the background of a source code change and improve the overall level of documentation of a project. Such level of transparency is an important requirement for tools and software which will be used for critical security operations. An issue tracker is also a must in order to allow users to easily report back bugs, open new features requests or ask specific question about the tool/software. It gives also insight if security vulnerabilities and assessment processes are properly implemented.

Software development methodologies also play a key role to attract new developers and contributors (from the CSIRT community or outside). CSIRTs developing tools or software should select the best methodology, fitting the project and/or their team’s approach. There are formal methodologies for software engineering and more relaxed ones with an emphasis on the collaboration such as the PMF2 model.

Recommendations

Security Vulnerabilities and Software Assessment

CSIRTs play an important role in awareness raising for security vulnerability notifications. It’s an opportunity for the CSIRTs to demonstrate the importance of security disclosure processes when producing software on their own. Having a specific section in the software documentation or main page describing the point-of-contact to report potential security vulnerabilities (with an associated PGP key) is a must.

If a vulnerability is found in the CSIRT tooling, a CVE assignment3 and publication are required to easily reach out your user base with precise information. Additional notifications to your users via different channels are often recommended (such as mailing-lists, social media or private notification to your constituency).

Regular security assessment (from manual review, automatic review or even fuzzing) of the CSIRT tooling is highly recommended to ensure a better overview of the current security state of the developed software. Documenting potential weak points with security countermeasures is a way to ensure that users operate the software in adequate conditions.

Recommendations

Open Source Software License

Choosing an open source license when publishing a CSIRT tooling is vital step and might impact the software on the long-term. A review of the CSIRT tooling might be required to ensure license compatibility:

When selecting an open source license for your CSIRT tooling, multiple parameters might be involved such as:

Recommendations

Privacy and Personal Data Processing

The aim of developing CSIRT tooling is to support Incident Response teams in their day-to-day activities. Processing incident-related or threat intelligence data might include personal information. It is strongly recommended to review the privacy implication of developing and also distributing such a tool. In order to clarify the scope and help potential users to ensure lawfulness, a review of the privacy implication might be included along with the CSIRT tooling (see AIL software privacy review6 as an example or the one for MISP called Information sharing and cooperation enabled by GDPR7).

Recommendations

Contribution and Collaboration

Attracting contributors is a key element for a CSIRT tooling to assure sustainability of the project. Contributors often start as a user of the CSIRT tooling. A welcoming environment fosters users to contribute and collaborate more in a project. In order to reach such a collaborative environment, a code-of-conduct might help to attract more contributors and collaboration within a CSIRT tooling project. One of the best practices in open source projects is the establishment of either mailing lists or chat channels (or both) in addition to the bug tracker of the source control management repository.

Recommendations

Interoperability

Another significant adoption of CSIRT tooling is the ability to integrate the tool easily in the tool-chain used by CSIRTs. Interoperability can be expressed in various ways:

The sustainability of a CSIRT tooling often depends on the ability of users to integrate the software with legacy systems or existing processes. The more options available to the users will ensure a constant usage of the CSIRT tooling. If the CSIRT tooling reaches a significant maturity, publication of the format can be submitted to standardisation process such as IETF, ITU or OASIS (such as the MISP-rfc format13).

Recommendations

Conclusion

Developing CSIRT tooling within an open source methodology allows to reach new audiences, to bring new use-cases and to ensure improved integrations with existing practices in CSIRT. The initial work to release as an open source can introduce some additional work but the benefit is often larger than the initial cost. The objective of this document is to list all the best practices in the field.

References

Existing CSIRT tooling

A tooling directory is available and maintained by the Tooling WG of the CSIRTs network.

Revision of the document

Acknowledgment

The contributors to the document are:

Contact and Collaboration

If you have any question or suggestion about this topic, feel free to contact us by opening an issue. This document is a collaborative effort where external contributors can propose changes and improvement to the document.

  1. Git is just the core free software to handle the SCM (Source Code Management) repository. A CSIRT can operate a publicly-owned collaborative platform such as gitlab, gitea or rely on an existing public service such as GitHub. ↩

  2. Programming Methodology Framework aka PMF ↩

  3. Common Vulnerabilities and Exposure ↩

  4. FSF list of license compatible with the GNU GPL ↩ ↩2

  5. Approved licenses from the open source initiative ↩

  6. AIL information leaks analysis and the GDPR in the context of collection, analysis and sharing information leaks ↩

  7. Information sharing and cooperation enabled by GDPR ↩

  8. A Code of Conduct for Open Source Projects ↩

  9. The Art of Community ↩

  10. MISP Taxonomies is a set of common classification libraries to tag, classify and organise information ↩

  11. MISP object template definition generated from specification files ↩

  12. Internet Engineering Task Force ↩

  13. The specification and formats used in the MISP project ↩