The data classification is intended to allow Mozilla to operate effectively in the open while protecting sensitive information.
If you think there is information that is improperly classified, we encourage you to work with the document owner, using this mana page as a reference. If you are unable to resolve this directly, we encourage you to complete the form at http://mzl.la/reclassify
The Enterprise Information Security team maintains this document.
Mozilla Data Classification
When sharing or distributing data, documents, etc. you are responsible for setting and changing a classification label. It is strongly advised that you use them with any tools and communications systems where Mozillians may share information (e.g.: Google docs, text documents, presentations, attachments to emails, IRC topics, and other digital media documents).
| Data that can be shared with the world.
The information would have no negative effect if made public (Low risk data).
| Data that can be shared with all of Mozilla staff and NDA’d contributors.
This information is potentially sensitive and could have a negative impact on Mozilla if made public (Medium risk data).
| Data that can be shared with a specific group of people, like a specific team.
This information, if disclosed beyond the group, would expose information that is not necessary and/or should not be available to the rest of the company (e.g. "employee salary info") (High risk data).
| Data that can be shared only with specific individuals who have been granted access by the data owner.
This information, if disclosed beyond the individuals, would have a significant negative effect on Mozilla or its users (Maximum risk data).
Examples of data classification
The list of examples is not an exhaustive list.
- Firefox source code.
- Public brown bags on AirMozilla.
- Bugzilla bugs without any security/restricted flags.
- Documentation on a wiki or the MDN page.
- Test or expired credentials.
- Information shared in the weekly MoCo/MoFo project meeting.
- Information shared in the monthly MoCo/MoFo internal meeting.
- Bugzilla bugs with the "Moco confidential" or "infrastructure" flags.
- Mozilla's employe phonebook.
- Aggregate survey data about Mozilla employees.
- Employee's street address, SSNs, performance data.
- Service passwords/credentials.
- Bugzilla bugs with security or restricted flags.
- Proprietary or protected information, code, libraries from Mozilla partners.
- Contracts or legal documents.
- Unannounced communication materials (dates, visuals, plans) for campaigns, product launches, etc.
- Firefox release signing keys.
- Specify partner conversations.
- Employee bank account information.
- User/personal passwords/credentials.
Help to label data in emails, gdocs, presentations, wiki, code, videos, etc.
The list of example to label data is not an exhaustive list and serves an an indication on how to ensure the data classification labels are clearly communicated.
There are always two people involved with exchanging Confidential information:
- The Discloser is the person who provides the information to the Recipient.
- The Recipient is the person who receives the information.
Keynote/Powerpoints, box.com, etc.
Label every document with its appropriate classification at the top of the document. When possible, we recommend using the header feature of the document.
Label every document (Docs, Spreadsheet, Slides, Drawings, etc.) with its appropriate classification at the top of the document.
- For Docs, we recommend including the label in the header of the document.
- For Slides, we recommend including the label in the master slide so that it shows on all slides.
- When setting sharing options in the Google documents:
- documents should be set so that "anyone at Mozilla " have access.
- documents should be set so that only "specific people" have access.
- documents should be set so that only "specific people" have access and only the owner can add people.
Wikimo (mediawiki), Etherpad lite
- All documentation is by default https://wiki.mozilla.org on
- No confidential information may be hosted on the wiki.
Email subject lines
- information must be labeled in the subject line and should not be forwarded without the original senders express permission.
- For other emails, optionally label subjects with the appropriate classification. This one is up to you, but we encourage you to label emails when the subject is sensitive and it is important to alert recipients.
Set your IRC channel topic to start with the classification label. This is also recommended for public channels.
Also ensure that non-public channels are protected by password or channel access control.
Remember thatand may not be shared on IRC.
Ex: "PUBLIC | This is a channel to discuss anything you like about Firefox".
Vidyo, Hello, Hangouts, Skype and other video conference tools
- When using video conferencing, if this is not a public call - ensure that only the people who need to know the information have access to the video conference and chat.
- Verify the list of participants and verbally announce if you're going to share any non-public information.
Code and configuration deployments
When committing or deploying code that handles credentials:
- Ensure that the credentials are stored in a separate file (if possible encrypted).
- Optionally label the file with a comment mentioning it's data classification label (either inside the file or as a file attribute, or even in the file name if it makes sense)