As a security company,
Fluid Attacks is aware of the importance of
having honesty, teamwork, and discipline as immovable principles (our full manifest can be found here);
developing products that comply with the highest worldwide security standards;
acquiring only compliant services and products for internal use;
implementing best security practices within our organization;
being completely transparent with our clients, especially regarding their data: how we use it, and what we do to protect it.
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.
This section focuses on what we do to keep our clients informed about their data and our services' status.
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:
All incidents are reported on our Community Site with details like what happened, what we’ve done, what’s the impact, and what we’re doing to help.
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.
This section provides details on what we do to keep confidential information continuously protected.
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 clients' repositories are stored in private, AES256 ciphered redundant data centers.
Forces exploits are stored encrypted using AES256 keys.
All Integrates 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.
All our applications and services have industry-standard encryption in transit.
We maintain an SSL A+ score from SSL Labs.
Integrates'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.
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.
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).
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.
Formatting of our equipment happens often, and the information does not accumulate in local storage.
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.
Integrates 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)
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:
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.
In case a mobile phone supports biometric authentication, our IAM enforces its usage.
All successful sessions have a duration of 9 hours.
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.
Integrates 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.
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
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.
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.
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.
Fluid Attacks, we have a two-step process for
Deactivating IAM account: By doing this, users lose access to all the company applications and client data. This includes Integrates, Forces, mail, etc.
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.
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.
This section talks about our efforts to protect
Fluid Attacks’s and the clients' privacy.
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.
Here is what we do to reduce information leakage when delivering data to the client.
We use an information-sharing system with DLP when sending any sensitive information to our clients. This includes contracts, portfolios, and other sensitive documents.
Integrates 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.
All reports downloaded via Integrates 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.
Every report downloaded via Integrates 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 Integrates.
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.
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:
The following policies apply to all the information provided by a client in a project context.
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.
All the data related to a project can be deleted from Integrates 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.
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.
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.
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.
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 the following systems as code:
Typical logs are also essential for a non-repudiation policy to be successful. Currently, we store logs for:
Integrates's logging system: Integrates 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.
Integrates'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.
Forces executions: Whenever a client’s CI pipeline runs Forces, 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 Forces 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.
Availability refers to the capacity to keep all our systems up and running. Avoiding service interruptions is crucial here.
Integrates 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 Integrates instance running in it. Additionally, its front side is served via a region-distributed CDN, providing maximum speed and availability across the globe.
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.
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.
Integrates'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.
Integrates'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 Forces’s exploits are versioned.
By resilience, we refer to the organization’s ability to adapt to unexpected circumstances that affect the way our team usually works.
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.
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.
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.
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.
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.
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.
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.
This section describes everything we do in our development cycle to reach a high integrity level.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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:
Change the version in the source code.
Run all CI tests on the generated ephemeral environment with the new dependency version.
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.