Security

With regards to Security it is always better to reuse proven methods than to reinvent the wheel. Therefore these principles are based on the best practices used by the Mozilla Foundation. Where applicable these have been adapted or expanded to align with the other Coolblue Prinicples and Core Values.

The “do” and “do not” used in this document are examples of controls or implementation of these principles, but do not represent an exhaustive list of possibilities. When in doubt, verify if your application, service or product aligns with the goal of the principles.

Least Privilege

Do not expose unnecessary services

Goal: Limiting the amount of reachable or usable services to the necessary minimum.

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 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.

Do

• 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.

Do not

• 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.

Do

• 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.

Do not

• 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.

Isolate environments

Goal: Separating infrastructure and services from each other in order to limit the the impact of a security breach.

Do

• In cases where two distinct systems are used to govern access or authorization (e.g. AD and Okta), ensure that no single user or role has administrative permissions across both systems.

• Use separate sets of credentials for different environments.
  Do not

• 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.)

Patch Systems

Goal: Ensuring systems and software do not contain vulnerabilities when these are found in software over time.

Do

• 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.

Do

• Achieve A or higher on Mozilla’s Observatory. (Deviaton from Mozilla standards which require a B+ or higher rating)
• Follow the Web Security Standards.

Guarantee data integrity and confidentiality

Goal: Ensuring data confidentiality, integrity, and authenticity is respected throughout its lifecycle.

Details on confidentiality, integrity & availability can be found below at Explanations & Rationales

Do

• 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.

Do not

• 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.

Do

• 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.

Do

• Run Rapid Risk Assessments (RRA) for your services.
• Estimate what would be the impact if your service was compromised.

Do not

• Think it will never happen to you.

Inventory the Landscape

Goal: Provide an accurate, maintained catalog, or system of records for all assets.

Do

• 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).
• Never rely upon security through obscurity

Coolblue addition to Mozilla principles

No security by obscurity

Goal: To prevent substituting real security for secrecy.

Do

• Always assume an attacker with perfect knowledge

Do not

• Rely on trust as a security measure

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.

Do

• 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.
• See also Code Clean & Simple.

Authentication and authorization

Require two-factor authentication

Goal: Require 2FA (or MFA) on all services internal or external to prevent attackers from reusing or guessing a single credential such as a password.

MFA (multi-factor authentication, also called 2FA for two-factors) is method of confirming a user’s claimed identity by utilising a combination of two different components such as something you know (password) and something you have (phone).

Do

• Use an SSO (Single Sign On) solution with MFA. For services that can not support SSO, use the service’s individual MFA features (e.g. GitHub). Servers carrying secrets or widespread access (or any other potentially sensitive data) should verify the user’s identity end to end, such as by prompting for an additional MFA verification when connecting to the server, even when behind a bastion host.

Use central identity management (Single Sign-On)

Goal: Minimize credential theft and identity mismanagement by minimizing the handling of user credentials such as password, MFA to a set of dedicated systems.

Do

• Use an SSO (Single Sign-On) solution that authenticates users credentials on your service’s behalf. Within Coolblue we strongly encourage the usage of SAML.
• Servers update their user sessions from the SSO systems regularly to ensure the user is still active and valid.
• Use authorization (e.g. group membership) data from the SSO system (possibly, in addition to your own authorization data) Do not
• Accept, process, transmit or store user credentials (passwords, OTPs, keys, etc.) Let the authentication server directly handle that data.
• Use direct LDAP authentication for users.

More information about Centralized User Account Management can be found below in the Explanation & Rationales section

Require strong authentication

Goal: Use credential-based authentication and user session management to grant access.

More information about Shared Passwords & Password Reuse can be found below in the Explanation & Rationales section

Do

• Use credential-based authentication and user session management where the session information is passed by the user. More info.
• Use API keys for service authentication.
• Prefer using asymmetric API keys with request signing (e.g. x509 client certificates, AWS Signature) over symmetric API keys (e.g. HTTP header) where possible.
• Ensure that API keys can be automatically rotated in the case of a data leak.
• Use a password manager to store distinct passwords for each service a user accesses.
• Use purpose-built credential sharing mechanisms when sharing is required (1password for teams, LastPass, etc.)

Do not

• Use easy to guess passwords or vendor default passwords.
• Send your password to other individuals.
• Send shared passwords over email or communication mediums other than purpose-built credential sharing mechanisms.
• Use the same password for multiple services.
• Trust traffic from a certain network address.
• Rely on VLANs or AWS VPCs to indicate requests are safe.
• Use IP ACLs as replacement for authentication.
• Trust the office network for access to devices.
• Use TCP Wrapper for access control.
• Use machine API keys for user authentication.
• Use user credentials for machine authentication.
• Store API keys on devices that are not physically secure (e.g. laptops or mobile phones)
• Always verify, never trust

Coolblue addition to Mozilla principles

Goal: Many security problems are caused by inserting malicious intermediaries in communication paths. Zero trust is applicable to all actors and IAAA (Identification, Authentication, Authorization and Accountability).

Do

• Deny by Default
• Authenticate every transaction
• Use allow lists instead of block lists

NOTE: The “do” and “do not” used in this document are example of controls or implementation of the principles, but do not represent an exhaustive list of possibilities. When in doubt, verify if your application, service or product aligns with the goal of the principles. Suggestions for do's and don'ts can be send to security@coolblue.nl.

Explanations & Rationales

Confidentiality

The confidentiality of the data depends on the type of data that needs to be protected. Personally Identifiable Information (PII) such as Names, Addresses or E-mail need a high level of protection than Publicly Available data (e.g. product information). Within Coolblue we use 4 levels of confidentiality:

Secret Data should only be accessible by a very limited amount of users. Examples of secret data are Admin / Root passwords, Business Strategy Plans, API-keys or our password databases such as Active Directory or PasswordState.

Confidential Data should only be viewed by authorized persons. Examples of confidential data are Personally Identifiable Information, order history or contracts.

Restricted Data can be freely shared within the company but not outside Examples of Restricted data are the VVV, internal processes or Demo's

Public Data can be accessed by the whole world Examples of Public data are the product information on our website, marketing ads or our vacancies.

Integrity

The integrity of data is the assurance of accuracy and consistency of the data over its entire lifecycle. A high level of integrity indicates that changes to this data should be verified and the correctness is very important. A low level of integrity indicates that changes to this data don't matter for the outcome of a process. Within Coolblue we use 3 levels of Integrity:

High Integrity data is data that should always be subjected to a 4-eye principle before a change can be made. If technically feasible, integrity checks (e.g. hashes or checksums) should be implemented to verify the data after a transaction took place. Examples of high integrity data are our source code, product pricing or financial reporting data.

Medium Integrity data is data that should only be changed by an authorized person. An authentication mechanism should be in place before changes to this type of data can be made. Examples of Medium Integrity data are our processes, Google Drive documents or data on our website.

Low Integrity data is data of which it really doesn't matter if it is changed by an unauthorized person. Examples are an order list for coffee for your team or other volatile information.

It is important to state that Data Integrity is not the same as Data Quality. Data quality in general refers to whether data is useful. Data integrity, by contrast, refers to whether data is trustworthy.

Availability

The availability of data is important to ensure timely and reliable access to information and systems. For example, the website of Coolblue requires a high availability because our customers want to be able to place an order 24/7. Next to that, we want to upkeep our promise of next day delivery. So the systems & data needed for these processes also need to have a high availability.

To determine the required availability of dta or systems, the following parameters need to be determined:

• Recovery Point Objective (RPO) - The amount of data, as a measure of time, we are willing to lose during a recovery event.

• Maximum Tolerable Downtime (MTD) - The amount of time we can be without the asset that is unavailable before we have to declare a disaster and call into effect our DR plan

• Recovery Time Objective (RTO) - The Earliest Possible Time that we can restore/recover the asset to full functionality IF everything goes as planned, and nothing else goes wrong.

• Work Recovery Time (WRT) - Determines the maximum amount of time needed to verify files, services or processes have been restored correctly and are available for use.

Because an image is better than a thousand (or in this case 107) words:

It is important to be very critical when determining these parameters. Does the system really need to be restored within 2 hours, or can business be resumed without the system fully functional (e.g. in a limited capacity or with manual workarounds).

Based on the outcome of these parameters, measures should be taken to ensure that in a case of a disaster the determined timelines can be met.

Multi-Factor Authentication (MFA)

Multi-factor authentication (MFA) is a security system that requires more than one method of authentication from independent categories of credentials to verify the user's identity for a login or other transaction.

Requiring the use of MFA for internet accessible endpoints is encouraged because by requiring not only something the user knows (a knowledge factor like a memorized password) but also something that the user has (a possession factor like a smartcard, yubikey or mobile phone) the field of threat actors that could compromise the account is reduced to actors with physical access to the user.

In cases where the possession factor is digital (a secret stored in your mobile phone) instead of physical (a smartcard or yubikey), the effect of MFA is not to reduce the field of threat actors to only those that have physical access to the user, because a secret can be remotely copied off of a compromised mobile phone. Instead, in this case, the possession factor merely makes it more difficult for the threat actor since they now need to brute force/guess your password and compromise your mobile phone. This is, however, still possible to do entirely from a remote location. In particular, storing both first and second factor on the same device (for example: mobile phone) is strongly discouraged.

Shared Passwords & Accounts

Shared passwords are passwords or/and accounts that more than one person knows or has access to.

Usage of these type of accounts is discouraged because they make auditing access difficult:

• multiple users appear in audit logs as one user and different users actions are difficult to differentiate. the number of audit logs that need to be searched increases. correlation of events across different systems is impossible
• if multiple people are creating event records with a single shared account across multiple systems at the same time.

Furthermore, revoking access to a subset of the users of a shared password requires a password change that affects all users.

Password Reuse

Password reuse is the practice of a single user using the same password across multiple different accounts/sites. This is contrasted with creating a different, distinct password for every account/site. Users often employ hybrid forms of password reuse like:

• Using the same password for a class of accounts/sites, for example, using one single password for multiple high value financial accounts, but a different single password for multiple low value forums and wikis.
• Using a consistent reproducible method of password generation for each site, for example, every account/site has a password which begins with the same characters and ends with name of the site ("rosebud0facebook", "rosebud0linkedin")

Password reuse is discouraged because:

When a site is compromised by an attacker, the attacker can easily take the user's password that has been reused on other sites and gain access to those other sites. For example if a user uses the same password on a car forum website as they use on Facebook, when that car website gets compromised, the attackers can then takeover the user's Facebook account.
Unethical administrators of any sites where a password is reused may/can gain access to accounts using the reused password.

Note that it is dangerous for a user to rely on a site being able to effectively prevent an attacker from obtaining that user's password once an attacker has compromised the site.

Since it's difficult/impossible for a user to memorize a distinct password for every account/site, a common solution is to use a password manager.