Security/InfoSec: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
mNo edit summary
Line 50: Line 50:
* Go beyond traditional SIEM systems in automating incident handling, information sharing, workflow, metrics and response automation
* Go beyond traditional SIEM systems in automating incident handling, information sharing, workflow, metrics and response automation


==== NSM: Network Security Monitor ====
==== 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.
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.

Revision as of 14:59, 15 September 2014

Operations Security Team

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.

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

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: 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 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 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.