As a security company, Fluid Attacks is aware of the importance of

These principles, conceived since the early days of the company, have allowed us to implement a large number of measures throughout the years. On this page, we will mention those that provide the highest value to our customers in terms of security.

1. Transparency

This section focuses on what we do to keep our clients informed about their data and our services' status.

1.1 Open Source

The source code of all our applications is available to the entire Internet. There are no backdoors or sensitive data exposed. The code is transparent and can be reviewed by anyone. All our source code can be found here.

Additionally, here is the commit history of our public repository:

1.2 Public incidents

All incidents are reported on our News Site with details like what happened, what we’ve done, what’s the impact, and what we’re doing to help.

1.3 Data leakage policy

In cases where Fluid Attacks detects a breach, emails are sent to notify the involved parties. These emails contain information on what data was leaked or compromised, when, and for how long (to the extent that this information is available). For a breach that exposes private data of a large number of users, the public will also be informed via email.

1.4 Status page

We continuously monitor our Attack Surface Manager (ASM), its API, and our website. Monitoring checks run on North American and European servers every minute for all applications. They send HTTP GET requests, and this information is real-time and available on our Status Site.

2. Confidentiality

This section provides details on what we do to keep confidential information continuously protected.

2.1 Encryption at rest

All our applications and services have industry-standard encryption at rest.

  • All the sensitive data provided by our clients (repository access keys, VPN credentials, etc.) is encrypted using the symmetric algorithm of our key management system (KMS). This algorithm is based on Advanced Encryption Standard (AES) in Galois Counter Mode (GCM) with 256-bit private keys. AES256 is the US government standard encryption algorithm used to protect top-secret information. Additionally, client data is also protected using HMAC with SHA-256 hashes.

  • All our domain names are protected with DNSSEC to ensure that DNS records received by clients are identical to the DNS records published by us.

  • All our clients' code repositories are stored in private, AES256 ciphered redundant data centers.

  • All the exploits are stored encrypted using AES256 keys.

  • All ASM data is stored in an AES256 encrypted database.

  • Most of our encrypted-at-rest secrets are only decrypted in memory, meaning that they are never stored on a hard drive when decrypted. This highly reduces the possibility of data leakage caused by leaving unprotected files with decrypted secrets stored on hard drives.

  • All our products use our KMS for both development and production secrets.

  • All our Windows laptops have their hard drives encrypted using Bitlocker. A domain controller continuously checks adherence to this policy.

  • All our Linux laptops have their hard drives encrypted from bootloader using LUKS.

2.2 Encryption in transit

All our applications and services have industry-standard encryption in transit.

  • The Fluid Attacks domain uses the latest TLSv1.3 cryptographic protocol for maximum in transit protection.

  • We maintain an SSL A+ score from SSL Labs.

  • Digital certificates for Fluid Attacks are renewed every 30 days in order to minimize leaks.

  • We use the HSTS policy to ensure that every connection to our domain goes through HTTPS.

  • We demand all conections to support at least TLSv1.2.

  • ASM’s database uses TLSv1.2 for in transit protection.

  • We possess fully dedicated network channels with some of our biggest clients, allowing us to isolate all unwanted traffic. This is especially useful for running secure dynamic application hacking.

  • For the rest of our clients, we use fully encrypted VPNs.

  • Ephemeral environments always include a digital certificate, validated with ACME protocol, and not self-signed.

2.3 Continuous hacking to our technology

We have projects focused on hacking our software. For us, it is essential to set an example of secure software, which is why today our entire technology stack goes through a process of comprehensive Continuous Hacking.

All our development projects run Continuous Integration pipelines, including exploits and strict linters, to ensure that no known vulnerabilities are released to production.

2.4 All our hired personnel must accept an NDA

Everyone within our company knows how important it is to keep our clients' information secure. We enforce this by requiring all our new employees to sign a non-disclosure agreement (NDA).

2.5 We only hire directly

All our employees have indefinite time contracts directly with the company. Due to our business nature, we never hire through contractors, freelance, or any other third parties.

2.6 Formatting and accumulation of data

Formatting of our equipment happens often, and the information does not accumulate in local storage.

3. Authentication

Authentication refers to the process of validating your identity within a service or platform. In this section, we cover how this is handled both for our services and the third-party services we use.

3.1 For clients

ASM only uses SSO with Google and Microsoft Accounts. Oauth2 protocol is used. Such protocol only accepts login attempts from trusted URLs and has industry-standard 2048 bytes access tokens. We do not store any account passwords. The only personal information we store of our clients is:

  • Full name (provided by Google or Microsoft)

  • Company and cellphone (only if shared, user can decide)

It is also worth noting that if users lose their corporate email, they also lose access to their ASM account. Clients can easily manage who has and who does not have access to their projects.

3.2 Internal

3.2.1 Centralized authentication

We use a centralized authentication platform (IAM) to manage all the applications we internally use. Our employees do not know any of the passwords of the managed applications; they only know their own IAM passphrase. Once they log in to IAM, they can access applications assigned to them.

Some of our IAM specifications and requirements are listed below:

  • Passphrases instead of passwords (more information here).

  • Passphrases expire every 30 days.

  • Previous passphrases can only be reused after a 24 reset cycle.

  • Multi-factor authentication (MFA) from a mobile device must be set.

  • Our MFA uses OOB, a mechanism that transports all the MFA data through a different channel than the application’s channel itself. Text messages and emails are examples of OOB. It reduces the risk in case a communication channel becomes compromised.

  • We use both SAML and Oauth2 for logging in. These two protocols allow us to log in to external applications by only having our IAM active account. No passwords or users are needed.

  • In case a mobile phone supports biometric authentication, our IAM enforces its usage.

  • All successful sessions have a duration of 9 hours.

3.2.2 GPG signature for repository commits

In order to avoid identity hijacking, all our source code repositories require developers to use a GPG digital signature that verifies the developer’s identity on the Internet. Signatures can be found on the repository commit histories linked in the Open Source section.

4. Authorization

Authorization refers to the ability to give users within an application the minimum privileges they need to do their work. No users should be allowed to do what they should not.

4.1 For clients

Attack Surface Manager (ASM) has a set of roles that are necessary for every hacking project. Once the client decides which members of their team should be project managers, Fluid Attacks assigns the roles to them, providing them with the ability to assign the minimum required permissions to other members of their team. Some of the available roles are hacker, admin, releaser, escaper, user and project manager.

4.2 Internal

Every application we use must have user-granular authorization settings to grant minimum-privilege policy at all times. Some examples are as follows:

  • IAM and KMS: These two tools are widely used within Fluid Attacks. They allow us to ensure that hackers can only access the source code, environments, exploits, and secrets of the projects they have access to. Access can be easily removed should the need arise, with no users/passwords leaked. These tools also let us keep application production secrets hidden from developers (Production-Development secrets separation).

  • Infrastructure: Infrastructure components always provide minimum privileges only to the applications that need to use them. We never give any service full permissions over our entire infrastructure.

  • IAM: It is possible to give application access at the user level, which allows us to give employees access only to what they need to execute their tasks. Giving or removing access to applications is simple, and no users/passwords are leaked.

4.3 Secret rotation

Key rotation is essential when dealing with sensitive data. The best way to prevent a key leakage is by changing the keys regularly. Our rotation cycles are as follows:

  • KMS keys: every year or before in case it is needed.

  • JWT Tokens: daily.

  • Digital Certificates: every three months.

  • IAM passphrases: every three months.

Rotations are done in these two different ways:

  • Automatic rotation: Some secrets are stored in secret vaults. They are only accessible by administrators and are rotated daily. These secrets include JWT Tokens, IAM passphrases, and digital certificates.

  • Manual rotation: Some secrets are stored versioned and encrypted in git repositories using AES256 symmetric keys. They are treated as code, meaning that to be rotated a manual approval needs to be obtained. These secrets include KMS keys and other application credentials.

4.4 Access revocation

When employees go on vacation or leave the company, it is essential to revoke their access to the systems and information that are accessible to them. At Fluid Attacks, we have a two-step process for access revocation:

  1. Deactivating IAM account: By doing this, users lose access to all the company applications and client data. This includes ASM, mail, etc.

  2. Removing Git repository access: Users can no longer see confidential information from the repository, such as registry images, confidential issues, Merge requests, etc.

It is worth noting that ease of access revocation is fundamental when dealing with sensitive data in an organization; that is why we have put so much effort into making this process as simple as possible.

4.5 Secure policies for enrolled mobile devices

Our collaboration systems also provide security requirements that mobile devices must comply with before enrolling in the organization’s systems. This is especially useful, as personal mobile devices are common targets for malicious hackers.

5. Privacy

This section talks about our efforts to protect both Fluid Attacks’s and the clients' privacy.

5.1 Project pseudonymization

Every project has a pseudonym within our systems, which brings advantages such as the following:

  • Employees without direct access to the project do not know the client’s name or any other information that can help them to connect the project with the client.

  • Internal analytics charts and other documents never use the client’s name; they use the project’s pseudonym.

Generally speaking, only the people who need to know who the client of a project is, are the people who actually know it.

5.2 Email Obfuscation

  • All emails contained in our websites are obfuscated for bots by using Email Obfuscation.

5.3 Secure delivery of sensitive data

Here is what we do to reduce information leakage when delivering data to the client.

5.3.1 Secure information sharing system

We use an information-sharing system with DLP when sending any sensitive information to our clients. This includes contracts, portfolios, and other sensitive documents.

5.3.2 Signed URLs

ASM has the feature of creating signed download URLs with an expiration date when downloading reports, meaning that links expire and can only be used by the user who requested the download.

5.3.3 Onion Routing

The Fluid Attacks domain supports Onion Routing, improving privacy of the users and enabling more fine-grained protection.

5.3.4 Passphrase protected reports

All reports downloaded via ASM have a randomly generated four-word passphrase. This passphrase is sent to the email of the user who requested the download. This applies to both XLS and PDF formats.

5.3.5 Watermarked reports

Every report downloaded via ASM comes with a watermark on all its pages, specifying that only the individual who generated it is allowed to read it. This is used as a measure to identify who generated the report in the first place and discourage its distribution through channels other than ASM.

5.4 Unsubscribe email

To be respectful to users regarding what information they want to receive, for all commercial and informative emails, recipients can stop getting them by clicking on the "unsubscribe from this list" link. By doing so, their emails are placed on a list of unsubscribed emails, and no new emails will be sent to them.

Both ASM and Web use a GDPR module that

  • informs the user about every cookie the site creates; and

  • lets users specify which ones to allow, thus giving them full control over what information we are creating and manipulating within their browser.

By doing this, we become compliant with security rules such as the following:

5.6 Data policies

The following policies apply to all the information provided by a client in a project context.

5.6.1 Data use policy

We are committed to using our clients' data exclusively for vulnerability scanning in the context of the service we are providing. No other activities will be executed over the provided information.

5.6.2 Data retention policy

All the data related to a project can be deleted from our Attack Surface Manager (ASM) by a user with a project manager role. Once this action is performed, a 30-day deletion window begins. Any project manager can undo the deletion action. After the 30-day waiting period, the project source code, secrets, metadata and other project-related data are completely removed from all our systems.

5.7 OTR Messaging

We use a messaging system with OTR and E2EE for communication within the organization. Also, all chat histories are reset every week as an extra measure to avoid leaks.

5.8 Employee time tracking software

We use a time tracking system that periodically takes screenshots of laptop screens while employees are working. Only managers have access to these screenshots in case an incident happens. Employees have control over the software, which means that no screenshots are taken once they stop working.

5.9 Polygraph tests

We regularly run polygraph tests on all employees with access to sensitive information. Tests fully focus on identifying whether an employee has disclosed confidential information to a third party. Personal questions are never asked.

6. Non-repudiation

Non-repudiation refers to the capability of keeping a log of every action performed on a system. What was done, who did it, and when. Knowing this, no one can deny their actions.

We implement this in several ways depending on the context.

6.1 Everything as code

At Fluid Attacks, we try to keep as much as possible versioned in a Git repository. By doing so, we are able to have comprehensive logs of

  • what exactly was changed;

  • who changed it;

  • when it was changed; and

  • who approved a change.

Currently, we keep all our systems as code:

6.2 Extensive logs

Typical logs are also essential for a non-repudiation policy to be successful. Currently, we store logs for:

  • ASM’s logging system: ASM stores a historical status of projects, findings, vulnerabilities, and other critical components. Changes made to these components are always tied to a user and a date. The historical status never expires.

  • ASM’s error tracking system: It provides real-time logging of errors that occur in its production environments. It is especially useful for quickly detecting new errors and hacking attempts. These logs never expire.

  • Redundant data centers: These store comprehensive logs of all our infrastructure components. Logs here never expire.

  • DevSecOps execution: Whenever a client’s CI pipeline runs DevSecOps, logs containing information like who ran it, vulnerability status, and other relevant data are uploaded to our data centers, allowing us to always know the current status of our client’s DevSecOps service. These logs never expire.

  • IAM authentication: Our IAM stores logs of login attempts made by users, accessed applications, and possible threats. Logs here expire after seven (7) days.

  • Collaboration systems activity: Our collaboration systems such as email, calendar, etc., store comprehensive logs of employee activity, spam, phishing and malware emails, suspicious login attempts, and other potential threats. Employee activity logs never expire. Other security logs expire after 30 days.

  • CI job logs: All our CI pipelines provide a full record of who triggered them, when, and the console output. These logs never expire.

7. Availability

Availability refers to the capacity to keep all our systems up and running. Avoiding service interruptions is crucial here.

7.1 Distributed applications

ASM is hosted in an application cluster with autoscaling policies and distributed replicas. This ensures high availability, as there is always one instance ready to receive user requests if another stops working. Every cluster node has at least one ASM instance running in it. Additionally, its front side is served via a region-distributed CDN, providing maximum speed and availability across the globe.

7.2 Distributed firewall

The Fluid Attacks domain is protected behind a distributed firewall that implements:

  • Dynamic firewall rules managed by top cybersecurity experts.

  • OWASP Core rules

  • Rate limiting.

  • Full DDoS protection.

  • Browser integrity checking.

  • Hotlink protection.

  • Anti-bot challenges.

7.3 Forever-lasting backups

As all our backups are stored in decentralized data centers, problems like hard drive lifespans are not a concern. The backups exist seamlessly for as long as we want, giving us full traceability and recoverability.

7.4 Everything is backed up

As data is likely our most valuable asset, we have strong backup policies for everything, for example:

  • Our redundant data centers are fully versioned, meaning that any file can be recovered or returned to a previous version.

  • ASM’s database has daily, weekly, quarterly, and annual full backup schedules. The daily backups last one week, the weekly ones twelve weeks, the quarterly ones three years, and the annual ones fifteen years.

  • ASM’s database has point-in-time recovery with the ability to recover the database to the state it was in at a specific date and time (hours, minutes and seconds) during the last 35 days.

  • All the exploits are versioned.

8. Resilience

By resilience, we refer to the organization’s ability to adapt to unexpected circumstances that affect the way our team usually works.

8.1 Redundant roles

Every role within the organization has a minimum of two different employees executing its tasks. This allows us to be able to fill the gap in case an employee goes on sick leave, vacation, etc.

8.2 Everything is decentralized

All our infrastructure is decentralized, meaning that we have independent data centers spread across multiple regions. No hardware maintenance is needed as it is done by a third party. No local networks are used. We only use Wifi connections with strong random generated passwords and with the sole purpose of accessing the Internet. Connections are always encrypted using WPA2-AES.

8.3 Own equipment and possibility of telecommuting

BYOD is not allowed. Every employee receives a computer with a password-secured BIOS, TPM hardware, and biometric fingerprint reader. Going to the office is the rule, but employees can always fill out an exception form to telework in case they need to. In case our offices close (e.g., due to COVID-19 pandemic), everyone can still do their job seamlessly.

9. Integrity

Integrity refers to the ability to

  • avoid data loss or corruption;

  • have clear definitions of all technological components within the organization and make sure such definitions are followed; and

  • have a clear development cycle that ensures applications are secure and true to their source code.

9.1 Certified hackers

We continuously encourage our hackers to certify their knowledge. Usually, hackers start applying for certificates after spending six (6) months in the company. Here you can find a comprehensive list of certifications that our team of hackers currently holds.

9.2 Extensive hiring process

All job applicants must undergo an extensive testing process to prove their technical capabilities and human values.

The technical part of the testing process involves solving programming and hacking challenges, uploading them to a Git repository with highly strict linters and compilers, and ascending in an organizational ranking.

The human values section of the testing process includes creating a portfolio with the five most important achievements of the candidate, going to the office during a training phase to work alongside the team, and job interviews, among other things.

9.3 Secure emails

The Fluid Attacks domain has DKIM, and SPF protocols enabled. Additionally, it has the DMARCv1 protocol enabled in verbose mode for running advanced diagnostics. These protocols help email recipients verify if an email comes from a trusted source, thus helping them avoid phishing and fake emails.

9.4 Developing for integrity

This section describes everything we do in our development cycle to reach a high integrity level.

9.4.1 Monorepo

We have a Git repository for all our applications. By taking this approach instead of dividing applications into smaller repositories, we get the following:

  • Centralized source of truth: Everything regarding the application can be found in a single place.

  • Centralized knowledge: Teams have an all-inclusive knowledge of the application, as they spend their time working in the same repository.

  • Standardization: Standardizing a project (folder structure, naming conventions, etc.) is easier when there is only one repo where everyone works, as there is no need to duplicate efforts or synchronize repositories.

9.4.2 Everything as code

As mentioned in the "Everything as code" previous section, we try to keep as much as possible versioned in a Git repository. The application integrity becomes a matter of keeping a healthy source code, after making the source code the only variable affecting an application.

9.4.3 Infrastructure as Code (IaC)

Our entire infrastructure is versioned in a Git repository written as code. Such code can be deployed anywhere and has all the properties of any other source code, such as auditability, history, revert capabilities, etc.

9.4.4 Regenerative infrastructure

By having our infrastructure written as code, we can recreate it on a daily basis. Regenerating our infrastructure every day brings the following advantages:

  • Any injected trojans or malicious scripts are removed.

  • Having fresh new servers every 24 hours lets us avoid availability and performance issues generated by memory leaks and not released resources.

  • Having the capability of deploying our infrastructure from zero (0) to production in an automated process.

9.4.5 Immutable infrastructure

The infrastructure code can be audited, and changes can only be made by changing such code. This provides full transparency on what was changed, when, and who did it. Also, no administrative protocols like ssh or administrative accounts are needed.

9.4.6 Continuous Integration

We run an Application Build Process for every change a developer wants to introduce to the source code of the application via Merge Request. The Application Build Process includes steps like the following:

By always building and testing everything, we can guarantee that every change is compliant with the application’s quality standards.

9.4.7 Peer review

We recognize that not all the steps of a building process can be automatized, especially some tests. That is why developers also need to ask a peer to review their code changes before their Merge Requests can go to production. Reviewers usually evaluate code quality, commit message coherence, and other semantic properties of the change.

Peer reviewing also becomes an activity where product teams discuss philosophies, standards, and future plans for the application. This space is ideal for senior developers to guide juniors on the right path.

9.4.8 Continuous Deployment (CD)

In addition to running an automated building process for every change, we also run an automatic deployment process. Once a Merge Request is accepted, an additional Continuous Deployment pipeline is triggered, automatically deploying a new production version based on the new source code.

9.4.9 Ephemeral environments

Instead of having long-term development environments like staging, we use testing environments that are created during a CI pipeline. We call them ephemeral environments, as they only exist in pipeline time. These environments are created on demand when a developer triggers a CI pipeline. They are also written as code, regenerable and immutable, allowing us to certify that a new version of an application is stable and secure before it reaches production environments. Once a change reaches production, its ephemeral environment is destroyed forever.

9.4.10 Trunk based development

We use Trunk based development to keep only one long-term master branch. That branch is the source of truth regarding what code is running in the production environments.

9.4.11 Micro-changes

Merge requests made by developers cannot be bigger than 200 deltas of code. A delta consists of either a removed or an added line of code. The following are some advantages of working with micro-changes:

  • Merge requests are small and easy to review by peer reviewers.

  • Introducing critical bugs to production becomes harder as changes are smaller.

  • In case something goes wrong with a deployment, identifying the error within those 200 deltas is easier.

  • Developers go to production multiple times a day, so no code goes stale.

  • Users of the application see it evolve on a daily basis.

9.4.12 One branch per developer

Developers can only have one short-term branch with their names (employeeatfluid) for every application. Once they develop a portion of code (200 deltas maximum), they run the Continuous Integration phase, create a Merge Request, and ask for peer review. If everything goes well, their branch is merged to the master branch, their changes are deployed to production, and their short-term branch is deleted.

9.4.13 Isolated and sudo-less dependencies

Some of our dependencies do not require OS libraries like libc. Instead, they are completely built from scratch, thus guaranteeing total reproducibility.

Additionally, these dependencies do not require any administrative privileges like sudo. They are entirely built on user space, considerably reducing the possibility of compromising OS core files.

9.4.14 No dependency auto-update

All external dependencies are pinned to a specific version (this is highly related to the immutability property), meaning that to update a dependency, a developer must do the following:

  1. Change the version in the source code.

  2. Run all CI tests on the generated ephemeral environment with the new dependency version.

  3. Get the change approved by a colleague after running a peer review.

In case all tests and peer review pass, a new production version with the updated dependency will be automatically deployed.

9.5 Static website

Our Website is a static website, meaning that it only serves plain HTML files. As it does not have any complex functionality that would require an application server, it cannot be hacked.

Copyright © 2021 Fluid Attacks, We hack your software. All rights reserved.