Caktus Security Policies

Caktus Group web security policies and best practices.

Table Of Contents

Previous topic

Application Development Considerations

Next topic

Dealing with Online Payments

This Page

Server Configurations

This document covers best practices for creating and managing server environments for Caktus projects.

User Access

Each developer should have unique access to the server. All access should be over SSH/SCP using public-key authentication. Username/password access over SSH should always be disabled. Once the server has been initially provisioned root login should be disabled.

Provisioning/Configuration

Server provision and configuration should be automated as much as possible. Developers should not need to manually edit configurations on the server and are discouraged from every doing it. Developers should instead make of use of existing tools such as Fabric or Salt. The level of automation used may vary from project to project based on the expected size/topology of the server environments.

Only the minimal required packages should be installed on each server. A firewall should be installed to default deny access on all ports (other than SSH). Services which listen on a socket should be configured to listen only on localhost or a UNIX socket unless there is an explicit need to speak to other servers. These must be added to the firewall rules.

Application Secrets

Application configurations including passwords and API keys should never be stored in the source control. When in doubt they should not be added. In general all source code should be treated as though it was open-source regardless of where the code repository lives.

These secrets should be exchanged between developers offline or in the case where that cannot be done they should only be transmitted in encrypted form using the receiving developers PGP/GPG key.

On the server, these secrets should be added to the OS environment and pulled from there. Updating them should be automated in the configuration/provisioning process. It should be clear to all developers how to rotate them in the case that they are thought to be compromised.

Webserver Specifics

Unless there is an explicit client requirement, SSL should be used for the entire site when any part of the site requires authentication. In this case the session cookie should also only be transmitted over SSL to prevent session stealing attacks.

The front-end proxy server, typically Nginx, should be configured to only respond to a white-listed set of domain names. Any requests with host headers not matching these domains should be denied before reaching the back-end application server.

In the case of a staging environment, basic HTTP authentication should be put in place to prevent bots as well as users who have stumbled onto a site which is not yet complete and/or secure.

Developer Responsibility

Developers should remember that they are often privileged users either on the server or in the application itself and should take care to keep their accounts secure. Strong passwords should always be used. Any process which might transfer production data such as database backups should be done over encrypted channels. When required by additional regulation (HIPAA) this data should also be encrypted at rest.