DOCS-79: Draft work of security document

Author: Sam Kleinman

draft/administration/security.txt

@@ -2,7 +2,96 @@
 Authentication and Security
 ===========================
 
-.. _replica-set-security:
+.. default-domain:: mongodb
 
-Replica Set Security
---------------------
+As with all software running in a networked environment,
+administrators of MongoDB must consider security risks and risk
+exposures for the MongoDB deployment. There are no cure-alls for risk
+mitigation, and maintaining a secure MongoDB deployment is an ongoing
+process. This document takes a *Defense in Depth* approach to securing
+MongoDB deployments, and addresses a number of different methods for
+managing risk and reducing risk exposure
+
+The intent of *Defense In Depth* approaches is to ensure there are no
+exploitable points of failure in your deployment that could allow an
+intruder or un-trusted party to access the data stored in the MongoDB
+database. The easiest and most effective way to reduce the risk of
+exploitation is to run MongoDB in a trusted environment, limit access,
+follow a system of least privilege, and follow best development and
+deployment practices. See the :ref:`security-reduce-risk` section for
+more information.
+
+Strategies for Reducing Risk
+----------------------------
+
+The most effective way to reduce risk for MongoDB deployments is to
+run your entire MongoDB deployment, including all MongoDB components
+(i.e. :program:`mongod`, :program:`mongos` and application instances)
+in a *trusted environment*. Trusted environments use the following
+strategies to control access:
+
+- network filter (i.e. firewall) rules that block all connections
+  from unknown systems to MongoDB components.
+
+- bind :program:`mongod` and :program:`mongos` instances to specific
+  interfaces to limit accessibility.
+
+- limit MongoDB programs to non-public local networks, and virtual
+  private networks.
+
+You may further reduce risk by: 
+
+- requiring authentication for access to MongoDB accesses.
+
+- requiring strong, complex, single purpose authentication credentials.
+
+- deploying a model of least privilege, where all users have *only* the
+  amount of access they need to accomplish required tasks, and no
+  more.
+
+- following the best application development and deployment practices,
+  which includes: validating all inputs, managing sessions, and
+  application-level access control.
+
+Continue reading this document for more information on specific
+strategies and configurations to help reduce the risk exposure of
+your application.
+
+Vulnerability Notification
+--------------------------
+
+10gen takes the security of MongoDB and associated products very
+seriously. If you discover a vulnerability in MongoDB or another
+10gen product, or would like to know more about our vulnerability
+reporting and response process, see the
+:doc:`/vulnerability-notification` document.
+
+Networking Risk Exposure
+------------------------
+
+Port Numbers
+~~~~~~~~~~~~
+
+Network Interface Limitation
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Firewall
+~~~~~~~~
+
+Authentication
+--------------
+
+Interfaces
+----------
+
+JavaScript
+~~~~~~~~~~
+
+HTTP Interface
+~~~~~~~~~~~~~~
+
+REST API
+~~~~~~~~
+
+Data at Rest
+------------

draft/administration/vulnerability-notification.txt

@@ -0,0 +1,92 @@
+==========================
+Vulnerability Notification
+==========================
+
+10gen values the privacy and security of all users of MongoDB, and we
+work very hard to ensure that MongoDB and related tools minimize risk
+exposure and increase the security and integrity of data and
+environments using MongoDB.
+
+Notification
+------------
+
+If you believe you've discovered a vulnerability in MongoDB or a
+related product, have experienced a security incident related to
+MongoDB, please report these issues so that 10gen can respond
+appropriately and work to prevent additional issues in the
+future. All vulnerability reports should contain as much information
+as possible so that we can move easily to resolve the issue, in
+particular, include the following: 
+
+- The name of the product. 
+
+- *Common Vulnerability* information, if applicable, including: 
+
+  - CVSS (Commong Vulnerability Scoring System) Score
+
+  - CVE (Common Vulnerability and Exposures) Identifier.
+
+- Contact information, including an email address and/or phone number,
+  if applicable.
+
+10gen guarantees a response to all vulnerability notifications within
+48 hours.
+
+Jira
+~~~~
+
+10gen prefers `jira.mongodb.org <https://jira.mongodb.org>`_ for all
+communication regarding MongoDB and related products. 
+
+Submit a ticket in the "`Core Server Security
+<https://jira.mongodb.org/SECURITY/>`_" project, at:
+<https://jira.mongodb.org/SECURITY/>. The ticket number will become
+reference identification for the issue for the lifetime of the issue,
+and you can use this identifier for tracking purposes.
+
+10gen will respond to any vulnerability notification received in a
+Jira case posted to the `SECURITY
+<https://jira.mongodb.org/SECURITY/>`_ project.
+
+Email
+~~~~~
+
+While Jira is the preferred communication vector, you may also report
+vulnerabilities via email to <[email protected]>.
+
+You may encrypt email using our `public key
+<http://docs.mongodb.org/10gen-gpg-key.asc>`_, to ensure the privacy
+of a any sensitive information in your vulnerability report.
+
+10gen will respond to any vulnerability notification received via
+email via email which will contain a reference number (i.e. a ticket
+from the SECURITY project,) Jira case posted to the `SECURITY
+<https://jira.mongodb.org/SECURITY/>`_ project.
+
+Evaluation
+~~~~~~~~~~
+
+10gen will validate all submitted vulnerabilities. 10gen will use Jira
+to track all communication regarding the vulnerability, which may
+include requests for clarification and additional information. If
+needed 10gen representatives can set up a conference call to exchange
+information regaining the vulnerability.
+
+Disclosure
+~~~~~~~~~~
+
+10gen requests that you do *not* publicly disclose any information
+regarding the vulnerability or exploit, until 10gen has had the
+opportunity to analyze the vulnerability, respond to the notification,
+and if needed to notify key users, customers, and partners.
+
+The amount of time required to validate a reported vulnerability
+depends on the complexity and severity of the issue. 10gen takes all
+required vulnerabilities very seriously, and will always ensure that
+there is a clear and open channel of communication with the reporter
+of the vulnerability.
+
+After validating the issue, 10gen will coordinate public disclosure of
+the issue with the reporter in a mutually agreed timeframe and
+format. If required or requested, the reporter of a vulnerability will
+receive credit in the published security bulletin.