Feeds

Jun 29 2015
Jun 29
ianthomas_uk's picture

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.

nedjo's picture

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.

opratr's picture

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.

ianthomas_uk's picture

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.

nedjo's picture

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:

Creating a situation where people use stillĀ­-private knowledge gained on the team to get an unfair advantage with no regard for the health of the Drupal ecosystem.

Instead, the policy should cut to the quick and begin with clear, unambiguous guidelines for action. Suggested phrasing:

As a security team member:
* Minimize risk that issues will be leaked beyond the team and posted to the public, outside of the release window and before a patch is released.
* Do not use still-private knowledge gained on the team to get an advantage or benefit.

lesleyb's picture

@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

About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web