Posted by mlhess on June 29, 2015 at 6:28pm
The security working group is proposing this policy around disclosure of private information. We are seeking community feedback.
In the past our policy has been a tad thin.
“State that you are willing to keep the confidential issues of the team confidential”
This document aims to add clarity to that sentence and some example scenarios to guide team members decision making.
We are seeking public feedback before making this a policy.
The policy is attached as a PDF.
Please provide feedback by commenting on the post
We hope to have comments open for 2 weeks before we publish this. We may wait longer depending on feedback.
| Attachment | Size |
|---|---|
| Drupal Security Team Private Information Guidelines--Draft.pdf | 112.02 KB |
Comments
One step forwards, two backwards
This is clearly a reaction to the recent security flaw, where two major hosts with staff members working on the security team were able to mitigate the flaw for their customers, even when those customers were running unpatched versions of Drupal.
It seems to be targeting two criticisms of that event:
1) These hosts were able to get a commercial advantage using confidential information from the security team. I see no issue with that - it is a small reward for the work they are putting in on the security team. If competitors want this confidential knowledge, they can get it by sponsoring a member of the security team.
2) It expanded the number of people who knew about the vulnerability, and therefore the chance that details would leak before the official announcement. The policy does help here, although there is a risk it will slow the development of a patch (e.g. if the manager refuses to sponsor the time without more details).
Had those hosts not acted how they did, many more sites would have been compromised, with potentially huge implications for those involved. It would also have been a tastier target for attackers, as unpatched sites would have been easier to find.
Proof reading: The term "COI" is used before it is defined.
Pre-notification
Implicit in this comment is the contention that pre-notifying some groups is potentially beneficial.
I agree there's a conversation to be had around this idea. But it's not the same discussion as the one we're having here.
We would need to cleanly separate what did occur in response to SA-CORE-2014-005 from what a well designed pre-notification system might look like. There's no necessary relationship, and certainly no reason to suppose that the various justifications that have been offered are a sound basis for anything.
Took the words from my mouth (keyboard)
Glad I checked before submitting my comments....basically identical to yours @ianthomas_uk.
+1
Edit: So to be clear, I agree with this clarification regarding disclosure. It's strikes a good balance between the risk of premature vulnerability disclosure and allowing team members to take appropriate measures outside of the team to benefit the Drupal community when an opportunity presents itself.
-Andre
As written, it's a bit
As written, it's a bit unclear on exactly who could be brought in on the issue. For example, in a large host there will be developers involved in implementing the solution, and an ops person involved in deploying the solution. Should ops people be added to the drupal.org issue? Are they not allowed to be told until the public disclosure? My reading of it is that ops people should not be told, which means no early protection.
IIRC Pantheon's workaround involved filtering the traffic before it even got to Drupal. Is that relevant for discussion on the issue?
Edit: Actually it's a bit more explicit than that. The policy states "We want to avoid ... creating a situation where people use still-private knowledge gained on the team to get an unfair advantage".
That basically rules out bringing anyone else in your organisation into the loop, unless they will be writing / reviewing the patch itself. You can only discuss deploying the patch once it is public.
Unclear
While not without merits, this draft reads as a compromise document, the result of a process that ultimately ducks rather than directly addressing the key issues at stake. That lack of clarity is already evident in the couple of commenters so far, who form very different conclusions.
Rather than elaborating aims that the policy will supposedly address, the policy should just do it: state directly expectations of security team members. This sentence is so ambiguous as to be useless:
Instead, the policy should cut to the quick and begin with clear, unambiguous guidelines for action. Suggested phrasing:
Just read through the document quickly ...
@ianthomas_uk I think COI means Conflict Of Interest; the term has been used earlier but the abbreviation was not introduced then.
The difficulty seems to be people on the security team are in a privileged position. Not only are they aware of a security flaw before any other 'general Drupal user', they are also in a position to patch their own installations before anyone else in the community. By their involvement in the security effort, they are in some state of preparedness for any security issue that arises.
When the advisory is issued, then the 'general Drupal user' is able to read, digest and act on that information - the security team members are already prepared to act on that information. The security team members can, under the remit of the current document, inform their teams a security patch is coming out that must be attended to.
Presumably the security team will also have knowledge of the timing of that release of information so they will literally be able to set their actions in motion the second someone in the security team hits the send button on an advisory notice.
I think this is as much privilege as the security team can allow its members and is reasonable.
Having a patch tested, ready to go and permitting security team members act on it prior to an advisory going out clearly not only leaves the 'general Drupal user' excluded from the benefits endowed by having the security team but also threatens the security of information held by the security team .
I would think the 'general Drupal user' would object to that on both counts.
Although it seems clear - from the outside of the security team - what information can necessarily be shared when and what to do to expand the team where specific expertise is required to find a solution to a security flaw I think the document could be reorganised to better effect. The marketing advice will be useful to team members.
I would drop the first two paragraphs completely. The second two paragraphs, starting with 'This document aims ...' serve as the Aims of the Document.
The main document can then start with an introduction (section 1) at 'In general, information ..' and the three scenarios could be set as sections 2, 3 and 4 with headings within the document - obtaining sponsored time, enlisting expertise from outside the team and marketing advice. Setting these as individual sections now allows any future additions to the document to be handled in the same way. It also allows people to read and find applicable scenario(s) quickly.
The three following paragraphs on how to share information and what to share then deserves its own section, section 5, so it can then be referred to in the prior enlisting expertise section or any other section that needs it.
The COI policy is already in its own section, which would become section 6, and can be referred to from any of the preceding sections.
Hope this helps
Kind regards
lesleyb
Hi folks, Just wanted to
Hi folks,
Just wanted to mention that the current accepted version of this document is posted at https://www.drupal.org/node/2544896
We can and should refine it over time.
knaddison blog | Morris Animal Foundation