|
|
| (58 intermediate revisions by 7 users not shown) |
| Line 1: |
Line 1: |
| ==Operations Security Team== | | =Infosec= |
| OpSec is a strategic group focused on information security. We articulate a vision for the operations of services that support the Mozilla mission and Manifesto.
| |
|
| |
|
| Our goal is to help groups inside and outside of Mozilla operate services and manage data in a way that respects the principles of the Mozilla Manifesto.
| | {{note|This page has been moved to https://infosec.mozilla.org/|error}} |
| | |
| OpSec operates as a consulting team. We do not mandate security requirements. We support operational teams in the design, implementation and maintenance of systems that guarantee the security of information Mozilla is entrusted with.
| |
| | |
| We offer security services, described in our service catalog. In addition to security engineering, we specialize in Incident Response and Risk Assessment. OpSec is typically the goto team when a compromise is detected in the Mozilla network.
| |
| === Who we are ===
| |
| | |
| * [https://mozillians.org/en-US/u/joes/ Joe Stevensen] [:joes]
| |
| * [https://mozillians.org/en-US/u/kang/ Guillaume Destuynder] [:kang]
| |
| * [https://mozillians.org/en-US/u/jvehent/ Julien Vehent] [:ulfr]
| |
| * [https://mozillians.org/en-US/u/jbryner/ Jeff Bryner] [:jeff]
| |
| * [https://mozillians.org/en-US/u/gene/ Gene Wood] [:gene]
| |
| * [https://mozillians.org/en-US/u/michalpurzynski/ Michal Purzynski] [:michal`]
| |
| | |
| === What we do ===
| |
| | |
| * Incident detection
| |
| * Incident response
| |
| * System security
| |
| * Network security
| |
| * Risk analysis
| |
| * Controls, practices, standards development and checking conformance to these
| |
| | |
| === Contacts ===
| |
| Email us at opsec [at] mozilla.com. For confidential information, encrypt your email using our public PGP: [http://gpg.mozilla.org/pks/lookup?op=get&search=0xBC17301B491B3F21 Operations Security (Mozilla Security Assurance)].
| |
| | |
| For security incidents, file a bug in Bugzilla under the component mozilla.org :: Security Assurance: Incident .
| |
| | |
| Our public mailing list is [https://lists.mozilla.org/listinfo/opsec opsec [at] lists.mozilla.org].
| |
| | |
| === Services Catalog ===
| |
| The services listed below are available to everyone working on the Mozilla project. Contact us directly for more details on any of the services listed below.
| |
| | |
| To subscribe to OpSec's services, please file a bug under component [https://bugzilla.mozilla.org/enter_bug.cgi?product=mozilla.org&component=Security%20Assurance%3A%20Operations mozilla.org :: Security Assurance: Operations].
| |
| | |
| ==== MozDef: Mozilla Defense Platform ====
| |
| | |
| The Mozilla Defense Platform (MozDef) seeks to automate the security incident handling process and facilitate the real-time activities of incident handlers.
| |
| | |
| Goals:
| |
| | |
| * Provide a platform for use by defenders to rapidly discover and respond to security incidents.
| |
| * Automate interfaces to other systems like bunker, banhammer, mig
| |
| * Provide metrics for security events and incidents
| |
| * Facilitate real-time collaboration amongst incident handlers
| |
| * Facilitate repeatable, predictable processes for incident handling
| |
| * Go beyond traditional SIEM systems in automating incident handling, information sharing, workflow, metrics and response automation
| |
| | |
| ==== NSM: Network Security Monitoring ====
| |
| | |
| The goal of the NSM project is to gain visibility into a network at the packet level. Environments that control their own network can implement NSM and benefit from its security monitoring capabilities.
| |
| | |
| Goals:
| |
| | |
| * Coverage of traffic at the entry point and key routing points of Mozilla's datacenters.
| |
| * Coverage of traffic crossing firewalls
| |
| * Full packet capture
| |
| * Centralized management
| |
| * Provide interfaces and utilities to facilitate and accelerate Incident Response
| |
| | |
| ==== MIG: Mozilla InvestiGator ====
| |
| | |
| MIG is OpSec's platform for investigative surgery of remote endpoints. MIG is composed of agents installed on all systems of an infrastructure. The agents can be queried in real-time using a messenging protocol implemented in the MIG Scheduler. MIG has an API, a database, RabbitMQ relays and a console client. It allows investigators to send actions to pools of agents, and check for indicator of compromision, verify the state of a configuration, block an account, create a firewall rule, update a blacklist and so on.
| |
| | |
| Goals:
| |
| | |
| * Query a pool of endpoints to verify the presence of a specific indicators
| |
| * Provide response mechanisms to lock down compromised endpoints
| |
| * Periodically verify endpoint's conformance with the security requirements
| |
| | |
| ==== Audisp-json: System Auditing ====
| |
| | |
| Auditd is the Linux auditing system that reliably collects information about any security-relevant event. Audisp-json is a plugin that correlates messages coming from the kernel's audit (and through audisp) into a single JSON message that is sent directly to a log server (it doesn't use syslog). The JSON format used is MozDef message format.
| |
| | |
| Audisp-json coupled with MozDef provide a strong solution to monitor and correlate security event on linux systems.
| |
| | |
| ==== Trophy Store (beta) ====
| |
| | |
| Trophy Store seeks to simplify the process that Mozillians go through when requesting new or renewing existing SSL certificates by automating the process from request through to deployment.
| |
| | |
| ==== RRA: Rapid Risk Assessment ====
| |
| | |
| The Rapid Risk Assessment is a quick, 30 minutes or less, discussion about the potential risks of a project. It's a way for project managers and engineer to discuss high level security issues with the OpSec team. The output of a RRA is a matrix of security risks and recommended security levels.
| |
| | |
| The RRA is designed to be lightweight and easy to run at the very beginning of a project. OpSec records the results of all RRA into its risk database, and uses that information to categorize security risks at Mozilla.
| |
| | |
| ==== Security Review ====
| |
| | |
| Security reviews are complete reviews of the security of a project. They are long and time consuming, so OpSec reserves them to high risk projects. Projects managers can request that a member of OpSec performs a security review of her project, which typically means that said member will become an active member of the project for the duration of the review.
| |
| | |
| Ideally, security reviews should start as early as possible. OpSec prefers to be involved during the design phases in order to discuss architectural choices and security requirements before systems are implemented.
| |
| | |
| In most cases, security reviews become a quarterly goal of the OpSec member it is assigned to. After the project manager performs a RRA of the project, and if the risk levels requires it, a security review can become an OpSec goal.
| |