|
|
| Line 13: |
Line 13: |
| __TOC__ | | __TOC__ |
|
| |
|
| == Strategy == | | == Product Lines == |
| === 1. Improve operational security of the core infrastructure ===
| |
|
| |
|
| ==== 1.1 Implement Test Driven Security (TDS) in CI/CD ====
| | * Firefox Accounts |
| Security tests should be part of the continuous integration (CI) and continuous delivery (CD) pipelines.
| | * Addons.mozilla.org |
| * CI integration should be part of the code commit/review process, either in an existing CI (travis-ci, circleci, taskcluster) or in a security dedicated one. CI tests should include static code analysis and recommendations, docker containers testing and dependency checks (vulnerability management). | | * Browser services (sync, push, normandy, remote settings, balrog, product delivery, etc.) |
| * CD integration should be done at Jenkins' level, when stage environments are built and promoted.All services are regularly rebuilt by Jenkins. CD tests should include application vulnerability scanning (ZAProxy) and infrastructure access control tests (security groups, IAM permissions, ...). | | * Data services (telemetry, pioneer, taar, prio, etc.) |
| TDS should output directly in the build pipeline at first, and allow dev & ops to control levels that block integration & delivery. In a second phase, TDS outputs should be aggregated into a central security tracking platform.
| | * Web presence of Premium services (FxSend, FxMonitor, FPN website, etc.) |
| | * Release Engineering (taskcluster, shipit, *.build.m.o, build infra, etc.) |
| | * Developer Services (phabricator, lando, bugzilla, sentry, crash reports, etc.) |
|
| |
|
| ==== 1.2 Make use of the logging pipeline to detect fraud and anomalies ==== | | == Scope == |
| Heka, ElasticSearch and Kafka are powerful tools on top of which we can plug various pattern detection mechanisms to identify known bad actors, or unusual behavior. Fraud detection is a highly requested feature that devs don’t want to rebuild every time. Fraud detection should operate autonomously for each service, taking into account business rules set by the developers and the security team.
| |
|
| |
|
| ==== 1.3 Improve user management and authentication ==== | | === Application security === |
| We should make better use of LDAP to add and remove employees from various third party services and admin panels.
| | Responsibility for internal & external services and websites in the Firefox organization that host sensitive data or provide a mission critical service. |
| * Admin panels should rely on Mozilla's Identity Management platform provided by IT | | * Risk assessments |
| * Third-party services (datadog, pagerduty, aws) should have automated user management (userplex). | | * Security Reviews |
| secops need to facilitate integration with Mozilla's IAM with standard libraries and tools.
| | * Manual and automated testing |
| | * Review risks w/ product owners |
| | * Security incident management |
|
| |
|
| ==== 1.4 Harden the infrastructure ====
| | The application security group also owns cryptographic services (autograph, tls canary, tls observatory, etc) and appsec tooling (zap, dependency observatory, etc.). |
| All services and tools that are part of the standard infrastructure should undergo security hardening. Hardening rules should be testable in the CD pipeline (see TDS above) to prevent security regressions. Some examples:
| |
| * SSH should enforce MFA authentication
| |
| * Disabled users should be removed from all systems, particularly bastion hosts
| |
| * AWS permissions must prevent services from compromising each other
| |
| * Secrets must be provisioned encrypted
| |
| * ...
| |
|
| |
|
| === 2. Increase security maturity === | | === Operations security === |
| | Responsibility for infrastructure and hosting of Firefox services. |
| | * Covers the security of AWS and GCP infrastructure, and datacenters for the build infra |
| | * Security operations consulting for the Firefox organization at large |
|
| |
|
| ==== 2.1 Help new projects identify threats and controls (RRA, threat models,...) ====
| | The operations security group also owns the fraud pipeline (foxsec-pipeline) and secops tooling (frost, sops, etc.). |
| Risk assessment and threat modeling help people think through failure scenarios they wouldn’t evaluate otherwise. RRAs often leads to architectural changes that are best identified early. Each new project must undergo a 30/60min RRA with one of the member of secops to assess the security posture of the project.
| |
|
| |
|
| ==== 2.2 Implement baseline services security standards ==== | | === Risk Management === |
| Content Security Policy (CSP), HSTS, HPKP, data signature and encryption, input validation, XSS and SQLi protection are part of techniques developers should care about when building new services. secops defines services security standards that devs can implement and tests in TDS.
| | Responsibility for maintaining visibility into the security posture of the Firefox infrastructure. |
| | | * Rapid Risk Assessments framework & associated tooling |
| ==== 2.3 Communicate security effectively throughout the organization ====
| | * Security posture reports & leadership reporting |
| Teams need a channel to ask security questions, discuss concerns and share techniques. secops must organize information flow and broadcast to developers, ops and managers. This includes general security best practices, analyzis and actions to take on CVE vulnerabilities, response and communication on incidents.
| |
| | |
| ==== 2.4 Use Mozilla’s bug bounty program ====
| |
| The bug bounty program is a fantastic tool: for a small amount of money, we reward people worldwide for helping us improve our security posture. Most security issues identified in our services come from the bug bounty program. We must ensure that all services are part of the bug bounty program and that triaging is performed regularly. As much as possible, we must assist developers in fixing security issues that are reported through bug bounties.
| |
| | |
| === 3. Build core security services ===
| |
| | |
| ==== 3.1 Sign data that changes the configuration of user agents ====
| |
| We iterate fast, and eventually someone, either us or a partner, is bound to make a mistake and open a door that could put our users at risk. Signing the data we send to our users helps cover that risk. Digital signature for Firefox is a complex topic - not every project can implement it independently - so secops must provide the tooling and services to facilitate signing ([autograph](https://github.com/mozilla-services/autograph))
| |
| | |
| ==== 3.2 Monitor our ecosystem for external threats ====
| |
| There are many scenarios in which our users can be at risk because of the fraudulent or careless behavior of a third party. A bad certificate authority could issue a certificate that impersonates us. A careless partner could leak addon signing keys. A web startup could get hacked and leak web push endpoints. We should implement the tools needed to identify fraudulent behavior outside of our organization that impact us, so we can react in a timely manner and protect Firefox users.
| |
| | |
| ==== 3.3 Partner with external firms to monitor our security ====
| |
| We can’t do everything ourselves. External security firms can help us keep an eye on and audit our services. Some of their work may be redundant with current efforts, such as automated security testing, but would help cover the interim. We should evaluate various vendors and partner with the ones that have the best support of our technologies.
| |
|
| |
|
| == Security Checklist == | | == Security Checklist == |
Firefox Operations Security
Firefox Operations Security protects the core services and release engineering infrastructures Mozilla relies on to build, ship and run Firefox.
Contact
Email us at secops@mozilla.com.
To report a security issue on a given site, use the bug bounty form as explained here.
To tell us about a new service create a New Service issue.
Product Lines
- Firefox Accounts
- Addons.mozilla.org
- Browser services (sync, push, normandy, remote settings, balrog, product delivery, etc.)
- Data services (telemetry, pioneer, taar, prio, etc.)
- Web presence of Premium services (FxSend, FxMonitor, FPN website, etc.)
- Release Engineering (taskcluster, shipit, *.build.m.o, build infra, etc.)
- Developer Services (phabricator, lando, bugzilla, sentry, crash reports, etc.)
Scope
Application security
Responsibility for internal & external services and websites in the Firefox organization that host sensitive data or provide a mission critical service.
- Risk assessments
- Security Reviews
- Manual and automated testing
- Review risks w/ product owners
- Security incident management
The application security group also owns cryptographic services (autograph, tls canary, tls observatory, etc) and appsec tooling (zap, dependency observatory, etc.).
Operations security
Responsibility for infrastructure and hosting of Firefox services.
- Covers the security of AWS and GCP infrastructure, and datacenters for the build infra
- Security operations consulting for the Firefox organization at large
The operations security group also owns the fraud pipeline (foxsec-pipeline) and secops tooling (frost, sops, etc.).
Risk Management
Responsibility for maintaining visibility into the security posture of the Firefox infrastructure.
- Rapid Risk Assessments framework & associated tooling
- Security posture reports & leadership reporting
Security Checklist
This has moved to https://github.com/mozilla-services/websec-check
About the logo
The Firefox Operations Security logo is derived from this work by Synth Agency, and published under Creative Commons Attribution-NonCommercial 4.0 International Public License.
