Mozilla Security Principles¶
This document defines a set of security principles that all operational groups at Mozilla must follow. The principles are designed to reduce the exposure of our systems and services from attackers who could gain privileged access and compromise sensitive data.
Goal: Limiting the amount of reachable or usable services to the necessary minimum.
List all services presented to the network (Internet and Intranets). Justify the presence of each port or service.
OpenSSH Server (sshd) is running but no users ever login.
A web-application has a web accessible administration interface, but it is not used.
A database server (SQL) allows connections from any machine in the same VLAN, even though only a single machine needs to access it.
The administration login panel of the network switch for the office network is accessible by users of the office network.
Do not grant or retain permissions that are no longer needed¶
Goal: Expire user access to data or services when users no longer need them.
Use role-based access control (allows for easy granular escalation of privileges, only when necessary)
Expire access automatically when unused.
Automatically disable API keys after not having been used for a given period of time and notify the user.
Use different accounts for different role types (admin, developer, user, etc.) when no good role-based access control is available.
Routinely review user’s access permissions to ensure they’re still needed.
Grant global root access (e.g. via ‘sudo’) for all operation engineers on all systems.
Give access “just in case”.
Retain access to services that you no longer use.
Defense in Depth¶
Do not allow lateral movement¶
Goal: Make it difficult or impossible for an attacker to move from one host in the network to another host.
Prevent inbound network access to services on a host from clients that do not need access to the service through either host-based firewall rules, network firewall rules/AWS security groups, or both (which is preferred).
Clearly enforce which teams have access to which set of systems.
Alert on network flows being established between difference services.
Allow inbound OpenSSH, RDP connections from any host on any network.
Run unpatched container management services (e.g. Docker) or kernels which allow a user in one container to escape the container and affect other containers on the same host.
Goal: Separating infrastructure and services from each other in order to limit the the impact of a security breach.
In cases where two distinct systems are used to govern access or authorization (e.g. Okta and Duo), ensure that no single user or role has administrative permissions across both systems.
Use separate sets of credentials for different environments.
Have system administrators with access to every system/every service.
Establish service users with access to multiple services.
Allow tools remotely executing code on systems from a centralized location (single Puppet Master, Ansible Tower, Nagios, etc. instance) across multiple services.
Re-use functionality across services when not required (such as sharing load balancers, databases, etc.)
Goal: Ensuring systems and software do not contain vulnerabilities when these are found in software over time.
Establish regular recurring maintenance windows in which to patch software.
Ensure individual systems can be turned off and back on without affecting service availability.
Enable automatic patching where possible.
Check web application libraries and dependencies for vulnerabilities.
Meet Web Standards¶
Goal: Reduce exposure to web attacks by following the web security standards.
Guarantee data integrity and confidentiality¶
Goal: Ensuring data confidentiality, integrity, and authenticity is respected throughout its lifecycle.
Use full-disk encryption where available on systems without physical security (laptops and mobile phones).
Encrypt credentials storage databases (Ansible Vault, Credstash, etc.)
Encrypt data in transit with TLS (during transmission).
Also encrypt data in transit inside the internal network.
Terminate TLS (e.g. with a reverse proxy or load balancer) outside a system and then transmit the data in clear-text across the rest of the network.
Use STARTTLS without also disabling clear-text connections.
Know Thy System¶
Fraud detection and forensics¶
Goal: Inspect events in real-time in order to alert on suspicious behavior, and store system behavior information in order to retrace actions after a security breach.
Audit and log system calls (e.g. with auditd or Windows Audit) made by processes when running in an operating system you control (e.g. not AWS Lambda)
Send logs off the account or system (e.g. AWS CloudTrail, system logs, etc.) outside of the account or system (different AWS account, MozDef, Papertrail, etc.)
Detect and alert on anomalous changes.
Are you at risk?¶
Goal: Assessing how exposed you are to danger, harm or loss.
Run Rapid Risk Assessments (RRA) for your services.
Estimate what would be the impact if your service was compromised.
Think it will never happen to you.
Inventory the Landscape¶
Goal: Provide an accurate, maintained catalog, or system of records for all assets.
Keep an inventory of services and service owners.
Keep an inventory of machines (e.g. ServiceNow, AWS Config, Infoblox, etc.) which is updated automatically.
Ensure that the inventory contains IP addresses of systems in particular when using IPv6 (which cannot realistically be scanned).
KISS - Keep It Simple and thus Secure¶
Goal: KISS comes from ‘Keep It Simple, Stupid’. You can only secure a system that you can completely understand.
Keep things simple. Prefer simplicity over a complex and specific architecture.
Ensure others can understand the design.
Use standardized tooling that others already know how to use.
Draw high-level data flow diagrams.