generated from ossf/project-template
-
Notifications
You must be signed in to change notification settings - Fork 41
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge pull request #147 from ossf/siren-addition
Commit of the Siren FAQ from the previous working document
- Loading branch information
Showing
1 changed file
with
79 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,79 @@ | ||
# Siren OSS-Threat-Intel Mailing List FAQ | ||
|
||
## What is this mailing list? | ||
|
||
Recent attacks upon open source developers and the open source software supply chain have highlighted the increased interest of developers, consumers, and attackers. With its unique, globally-distributed development community and its world of downstream consumers, effectively communicating changes upstream and vulnerability disclosures downstream can be challenging. To that end, the OpenSSF is proposing the creation of a new facility to empower better communication among those incident disclosures and active exploits. | ||
|
||
The FOSS community has many existing facilities for handling the triage and disclosure of security vulnerabilities (e.g. the OSS-Security and OSS-distros list at OpenWall). This has served traditional community members exceptionally well over the lists’ lives. With the explosion of use and downstream consumption of open source software, new communication paths need to be forged to assist all the interested parties in this vibrant ecosystem. | ||
|
||
In the model of an ISAC (Information Sharing and Analysis Center)*, the OpenSSF proposes the creation of a new mailing list among individuals from all parts of the Open Source Software ecosystem to ensure useful and timely information is shared to the broader community. | ||
|
||
* - Note that this is only in that model when considering target membership and logical function. At this time, we are not proposing the creation of a new, fully-formed legal entity, only that the ISACs be looked upon as a successful model, and be similarly focused on a sector, in this case, the Open Source community. | ||
|
||
|
||
## What is the difference between this list and OSS-Security (OpenWall)? (and other, similar lists/message boards/chat rooms) | ||
|
||
The OpenWall lists are primarily focused on the disclosure and coordination of vulnerabilities, both privately within a trusted community and publicly for broader dissemination and discussion of the vulnerability. | ||
|
||
This new list will be focused on the operational impact and response to exploits and incidents, including threat actors exploiting vulnerabilities against the Open Source community.. Information such as attacker Tactics, Techniques, and Processes (TTPs), Indicators of Compromise (IoCs), and broader communication around actively exploited exploits within open source software would complement the existing vulnerability coordination feeds. Hypothetically, if a vulnerability is disclosed publicly on OSS-Security (the public OpenWall list), the discussion there is largely about the details of the vulnerability and proposed generic mitigation procedures for any given implementation. SIREN is intended to help provide that ISAC-like forum where information about exploited vulnerabilities can be more broadly shared with downstream, especially with people that historically have not been directly engaged with the upstream community, such as enterprise operators or entities responsible for managing critical infrastructure, | ||
Who is this list for? | ||
|
||
The list is intended for anyone who has operational responsibility for software or infrastructure critical to the Open Source community, or who is concerned with the process and ongoing progress of the response to a security incident (including post-disclosure response to a vulnerability) in the Open Source Software community. | ||
|
||
Membership in this list is open to anyone, developers, security researchers, and OSS consumers of all types. | ||
|
||
## How do I subscribe to this list? | ||
|
||
Can subscribe at https://lists.openssf-vuln.org/g/siren, or by emailing to [email protected]. | ||
|
||
|
||
## Who can post messages to this list? | ||
|
||
Anyone who has registered for the list can post to the list. | ||
|
||
## What types of information will be shared on this list? | ||
Nothing non-public, no new disclosure info, no sensitive data/pii/yada yada yada | ||
|
||
## Who can access / read messages sent to this list? | ||
|
||
Anyone who has registered / subscribed to this list will receive messages. Additionally, the messages will be accessible via web archives. | ||
What level of sensitivity will the messages be held to? | ||
|
||
This list will be for publicly shareable information. For those familiar with the [Traffic Light Protocol](https://www.first.org/tlp/), it is limited to TLP:Clear. We would like to include TLP:Green, which would include those things shareable to the community, but as this is publicly accessible to any who subscribe, it is limited to TLP:Clear. | ||
|
||
Q: Could we allow TLP:Green if the web archives were not publicly accessible – e.g. require login by registered member of list? Is registration enough to qualify as “members of a defined community”? Do we also need to have people attest to understanding TLP and specifically TLP:Green limitations? | ||
|
||
## Who is operating this list? Why should I trust them to run it? | ||
|
||
Linux Foundation / OpenSSF Staff, with governance from the OpenSSF Vulnerability Disclosure Working group. The list is hosted by groups.io. More information about groups.io can be found here: https://groups.io/static/about | ||
|
||
|
||
## Can I see who else is subscribed to this list? | ||
No, this would be classified as PII (Personally Identifiable Information) and cannot be shared for a list like this. | ||
How do I trust that they will respect the sensitivity of the information shared? | ||
As this is a public list with no expectation of confidentiality, information shared to this list should be considered public or of the TLP:CLEAR designation. There are alternate means to share sensitive information with the community outside the scope of this list. | ||
|
||
## If there is objectionable content posted to the list, how do I report it or ask that it be taken down? | ||
If there is something objectionable posted, is in violation of a law, or incorrect, you can submit a request for a review / takedown to the list owners at this address: [email protected]. The owners will attempt to respond within 24 hours. | ||
|
||
If, after review it is determined that the post should be removed, it will be removed from the archive, and a post will be sent out noting that the post was removed or corrected (without reposting the objectionable content) | ||
|
||
## Who benefits from the proposed OSS Siren mailing list? Aren’t there already tools out there that provide this information, making this more noise, distraction / pointless alerts? | ||
|
||
For many people, especially those associated with a corporate entity, much of this cyber threat intelligence information and the feeds are available. To this group, the proposed OSS-CTI mailing list may seem like just another threat feed. However, for OSS projects and maintainers that do not have access to corporate cyber threat intelligence tools, this fills an important gap in the OSS community. When there are threats and attacks affecting those underserved communities, they may have no ability to share this information in a way that gets to the well-known feeds. | ||
|
||
## Can you give an example of how this could be useful? | ||
|
||
In the early days of the xz/liblzma vulnerability, there was no central place for the OSS community to share IOCs and TTPs. The community shared their own observations in various isolated forums, but there was a lack of a central convening point. | ||
|
||
In this scenario,the proposed mailing list could have been used as a public community led forum in which to distribute information about the threat actors. | ||
|
||
## Why an email list? Why not <insert collaboration tool>? | ||
|
||
Email is being chosen as a starting point for this for a few reasons: | ||
Universal access – we want to ensure that we can get the highest accessibility to members. The ubiquity of email and tooling for email makes it the easiest way to ensure people have access. | ||
Security – well-known and well-trusted technology exists for establishing trusted and secure communication via email. | ||
As the program matures and we receive feedback, additional capabilities may be added in the future. | ||
|
||
|
||
|