Security/Process/Vendor Reviews

From MozillaWiki
Jump to navigation Jump to search
Status: Draft
Date: 2013.12.31
ToDo: 
* Final Sign Off

Document Purpose

The Vendor review process seeks to discover the risks that may exist by the use or installation of products and services from 3rd parties as part of regular work functions for Mozilla. This allows the business to take actions as appropriate for the business case in question.

Supporting Documents

Initiating the Process

The process may be initiated in the following ways.

  1. File a bug directly
    • direct bugzilla link
    • The vendor should respond to the questions in comment 0 (included in the direct link). In some situations particular questions may be not applicable to the vendor/system.
  1. Project Kickoff
    • Project Kick-Off Form
    • The kickoff form currently does not contain the [/Review_Questions| review questions]] that will need to be answered.

Notes:

  • Bugs will be triaged weekly by the Security Program Management team (currently Wednesdays at 2pm PST).
  • For urgent security reviews, please contact curtisk ?
  • If possible and practival the vendor may be added to the cc list of the bug as these bugs are flagged to "Confidential Mozilla Corporation Bug" group. This will allow the vendor to respond directly to any questions or followup items in a timeley manner and not be delayed by having to pass information through intermediaries. This flag should never be removed on this bug category.

Bug Lifecycle

  1. Once the questions have been responded to by the Vendor, either in an attachment to the bug or in a direct comment, the bug will be assigned work sprint(s) for the necessary work to be completed based on it's risk category.
  2. If supporting documentation is needed (ie. audit reports, other supporting documentation) that will also be requested and attached to the bug.
  3. If a penetration test by Mozilla Security Assurance staff is to be preformed a blocking bug shall be filled and assigned for that portion of the work to be tracked and scheduled.
  4. Any findings of risk shall be noted in the bug and categorized via published Security Assurance standards in either the Mozilla Wiki or Mana as appropriate.
  5. Once all review questions, follow-up questions, and required supporting documents have been supplied the bug shall be have it's status changed to RESOLVED-FIXED.