User:Gdestuynder/principles

STATUS: READY The goal of this document is to help operational teams agree on a basic set of principles to set expectations and give overall guidance to secure a service. The Enterprise Information Security team maintains this document as a reference guide for operational teams. Updates to this page should be submitted to the source repository on github. Changes are detailed in the commit history.

Least Privilege

Do not present unnecessary services

Do

• List all services presented to the network (Internet and Intranets). Justify the presence of each port or service.

Do not

• OpenSSH Server (sshd) is running but is never used.
• A DNS resolution caching server (dnsmasqd) is running locally but only upstream DNS nameservers are used by clients.
• A file sharing server (samba/smbd) is running but no files are stored or exchanged on the server.
• A web-application propose an administration service that you can login to through the website, but it is not being used.
• A database server (SQL) allows connections from any machine in the same VLAN, even thus only a single machine needs to connect to it.
• The administration login panel of the network switch for the office network is accessible by regular office users.

Do not grant or retain permissions if they're not actively used

Do

• Use role-based access control (allows for easy granular escalation of privileges, only when necessary)
• Expire access automatically when unused.
• Use different accounts for different role types (admin, developer, user, etc.) when no good role-based access control is available.

Do not

• Allow root access (e.g. via 'sudo') to all systems for all operation engineers, regardless of the actual services they maintain.
• Give access "just in case".
• Never revisit access rules for users.

Defense in Depth

Do not allow lateral movement

Do

• Use host-based firewall rules that self-protect the system regardless of the rules from the network equipment, or the location of the system.
• Avoid usage of firewall rules that allow any inbound connection to connect to a listening port (such as OpenSSH, RDP).
• Clearly enforce which team has access to which set of systems.
• Clearly assign administrative roles of different authentication & authorization services to different people.

Do not

• Have system administrators with access to every system/every service.
• Share administrative user access to authentication & authorization systems.
• Allow OpenSSH, RDP connections from any host on any network.
• Allow tools remotely executing code on every system from a centralized location (single Puppet Master, Ansible Tower, Nagios, etc. instance).

Patch Systems

Do

• Establish regular patching time windows.
• Ensure systems can be turned off and back on without affecting availability.
• Turn on automatic patching where possible.

Meet Web Standards

Do

• Achieve B+ or higher on Mozilla's Observatory
• Follow the Security/Guidelines/Web_Security recommendations.

Encrypt sensitive data

Do

• Encrypt data at rest when not actively used by the system.
• Use full-disk encryption where available.
• Encrypt credentials storage databases (Ansible Vault, CredStash, etc.)
• Encrypt traffic in transit (TLS)

Know Thy System

Audit and Logging

Do

• Send logs to a centralized service (MozDef, Papertrail, S3, etc.)
• Audit processes at the system level (Auditd, Windows Audit)
• Run MIG

Are you at risk?

Do

• Run rapid risk assessments Security/Risk management/Rapid Risk Assessment for your services.
• Estimate what would happen if your service was compromised.

Do not

• Think it will never happen to you.

Inventory

Do

• Keep an automatic inventory of machines, services, responsible parties.

KISS - Keep It Simple and thus Secure

Do

• Keep things simple. Privilege simplicity over complex-satisfies-obscure-requirements architecture.
• Ensure others understand your design.
• Use standardized tooling that others already know how to use.
• Draw high-level data flow diagrams.

Authentication and authorization

No authentication that isn't 2FA

Do

• Enable service-specific 2FA (GitHub, Google, etc.)
• Add 2FA to your applications, or use an SSO (Single Sign On) solution with 2FA.

No direct handling of user credentials

Do

• Use an SSO (Single Sign On) solution that authenticate users on your behalf.

Do not

• Process, transmit or store user credentials (passwords, OTPs, keys, etc.) Let the authentication server directly handle it.
• Use direct LDAP authentication for users.

Centralize authentication and authorization

Do

• Use an SSO (Single Sign On) solution that authenticate users on your behalf.
• Use the same SSO to pass on authorization rules.

No reuse or sharing of credentials

Do

• Use password managers.
• Use purpose-build credential sharing mechanisms when sharing is required (1password for teams, LastPass, etc.)

Do not

• Send your password to others.
• Send shared passwords over email or other communication mediums.
• Use the same password for several services.

Network identity is not authentication

Do

• Use credentials-based authentication and user session management where the session information is passed by the user (https://research.google.com/pubs/pub44860.html)

Do not

• Trust traffic from a certain network address.
• Use IP ACLs to control access to systems.
• Trust the office network for access to devices.