Staging server. Your account won't work here. Build: dev@Dec/20-16:26
Hardenize has joined Red Sift! Find out more in our blog post.

About

Our Team Contact Jobs Terms of Use Terms and Conditions Data Processing Agreement Subprocessors Privacy Policy Security Policy

Security Policy

This document encompasses all aspects of security surrounding confidential company information and how we handle customer data. Information security is of great importance to all modern businesses, but even more so to us, as we exist to provide tools that help other organisations to achieve better security. We can't assist others if we are unable to follow our own advice.

17 June 2019

Our main aim with this document is to provide a concise and straightforward policy that is easy to understand and follow. Where necessary, further subpolicies will be provided to cover certain topics in more detail. Exceptions to this policy must be reported, documented, and approved by management.

This policy establishes the baseline processes that we employ to ensure security of our systems:

  • Continuously monitor our environment and ensure that we have security policies that adequately address our needs and our risks.
  • Develop and deploy secure systems, prioritising security over functionality.
  • Keep the existing systems healthy, repairing problems as they're discovered.
  • Minimise the attack surface.
  • Compartmentalise and use least privilege principle.
  • Monitor and react to incidents.

Organizational Security

  • Responsibility. Chief Security Officer is responsible for overseeing all aspects of information security. Individual employees are responsible for security within their own areas of work. Employees shall be provided the tools and training they need to support our security requirements.
  • We shall use security screening of individuals employed in environments where the security and/or safety of people, goods and services, personal data or property is important.
  • Segregation of duties. Individuals will have access to data and networks only to the extent necessary for them to perform their work.
  • Work shall be carried out exclusively using corporate equipment. There shall be no access of company networks and data from personal devices. Corporate equipment shall not be used for personal activities.
  • Asset inventory. We shall maintain an accurate and up-to-date inventory of all our networks and computer systems.
  • Change management. Changes to production networks shall be planned, documented, reviewed, and approved, in a process designed to ensure that only authorised modifications are made and in controlled fashion.
  • We shall perform periodic risk analysis and assessment to ensure that our information security policies and practices continue to meet our requirements, and that we comply with all necessary laws and regulations.
  • We shall have a business continuity and disaster recovery plan in place to enable us to recover from serious data loss, and security and availability incidents.
  • We shall be able to resume operations in case of complete failure of our primary Cloud provider, either through their unacceptable downtime or loss or compromise of our account. Our primary and secondary Cloud provider accounts shall use separate credentials.

Data Security

  • We shall use the following data classification:
    • Critical; customer data and other related information, for example the logs. All production networks fall under this category.
    • High; information that is vital to our organisation, for example financial information, trade secrets, credentials, and source code. All networks except production fall under this category.
    • Moderate; information that shouldn't be disclosed, for example details of inner operation.
    • Low; information that may not be public, but whose release would result in only minor or no impact.
    • Public; for example the contents of our web site and service data sheets.
  • Data shall not be moved or copied outside the networks they belong to. For example, critical data shall not be copied or moved outside production networks. Company data shall not be moved outside company networks.
  • Encryption must be used at rest, in transit, and for backup storage. Different encryption keys shall be used for different types of data. Encryption keys shall not be used to encrypt data belonging to different classification levels.
  • There shall be a full separation and isolation of production, staging, and development networks and environments.
  • Corporate data shall not be copied to portable storage devices (e.g., USB keys). Critical data shall not be copied to portable devices.
  • We shall minimise the amount of data we keep, record and keeping only the data we need to perform the business functions. Policies shall be put in place to continuously delete the data that is no longer needed.
  • We shall access customer data only when strictly necessary to deliver our services or otherwise when requested by our customers. Except when required by law, we shall never disclose customer data or use customer data for our own needs.
  • We shall comply with all applicable laws and regulations (e.g., GDPR).
  • Physical security. We don't operate our own data centres, but we shall work with vendors who are able to provide strong physical security guarantees.

Network Security

  • Network communication shall be encrypted and authenticated at multiple levels. Mutual authentication is mandatory for all network traffic.
  • No users or machines are automatically trusted; authentication is mandatory, even for access from known network locations.
  • Access is denied by default at network level, on all machines and resources individually. Network restrictions are lifted on a case by case basis only when necessary to establish trust relationships.
  • Only public services are exposed on the public networks. All other services will be available for access only to known company networks or via a VPN. This also applies to administrative interfaces that are part of public services (e.g., restrictions can be established at HTTP level for web interfaces).
  • Trust relationships are formed following the least privilege principle. For example, an application server may be given access to the database engine port, but not to any other ports on the database server.

Authentication

  • No account sharing; distinct users, machines, and components all have their own unique identities that are not shared. Further use of service account to enforce the principle of least privilege (e.g., separation of development and production user accounts).
  • Prefer public key authentication. Passwords must be unique, long, and generated randomly.
  • Two-factor authentication shall be used wherever it is available. SMS must not be used as the second factor.
  • Store passwords securely, using methods (e.g., BCrypt and similar, with strong factors) that don't use plaintext and make offline brute force attacks slow and impractical.
  • Frustrate online brute-force and account recovery attacks.

Cloud and Vendor Security

  • We shall work with vendors who are able to provide strong quality guarantees, supporting our network and physical security requirements, and availability, performance, and compliance guarantees.
  • Our own Cloud accounts shall be protected with two-factor authentication used wherever it is available.
  • We shall use separate Cloud accounts for different uses and data security levels.

Endpoint Security

  • Full disk encryption shall be used on all devices. The encryption keys shall not be stored elsewhere or backed up. Recovery keys shall not be used.
  • Operating system patches shall be applied [to user devices] within two days of their release.
  • Non-trivial passwords shall be used on all accounts. Guest accounts are not allowed.
  • Devices shall be locked if leaving it unattended. Additionally, inactivity timeout shall be configured to automatically lock the screen after a period of time.
  • Remote wipe capability shall be used to delete data from stolen or lost devices.

Security Practices and Monitoring

  • We shall follow industry best practices to ensure that our systems are built securely and that they are repaired if a problem is uncovered.
  • Ecosystem security awareness. We shall actively monitor the security of the ecosystems on which depend, for example, third-party Cloud providers, services, software and libraries.
  • Continuous patching; at the network and operating system level, our production systems shall be fully patched on a monthly basis, and sooner in the case of high-risk vulnerability. At the application level, we shall address the vulnerabilities (either in our own code or in our dependencies) as soon as they are discovered.
  • We shall use continuous perimeter scanning, network vulnerability scanning, and application security testing in order to ensure that our view of our system matches reality.
  • We shall use periodic external testing for network and application vulnerabilities.
  • Centralised logging shall be used to collect information, in real-time, from all machines and software components. The logs shall be monitor and relevant alerts investigated.
  • Sensitive data shall not be logged. This includes passwords and customer traffic.
  • Monitoring. We shall continuously monitor key aspects of our productions systems.
  • Incident response. We shall rely on detailed logging and monitoring to enable us to detect incidents. If an incident is detected, we will preserve as much evidence as possible, then rebuild all systems as soon as that's practically possible.