The Squad Plan is a security testing service that allows the hacking process to begin at an early stage in the software development cycle. Its purpose is to guarantee 100% testing coverage of the application.
The Squad Plan offers Continuous Hacking, a service with the following benefits:
Minimizes the cost of remediation (repair) of a vulnerable security risk while the software is in development rather than when it is in production.
Reduces application certification time to zero because the hacking is done during development.
Provides clear and detailed information about vulnerable security risks and facilitates a coordinated effort between external project personnel (
Fluid Attacksexperts) identifying security risks and internal project personnel (client company) fixing security issues without delays.
Throughout our trajectory we have been working with companies from different sectors, such as finance, transportation, industry, consumer, communications, technology and utilities.
No. Due to the operational model behind the Squad Plan, it can only be done remotely.
No. Even if 100% of coverage is reached, we continue checking already attacked source code to identify any possible false negatives, including components developed by third parties in our hacking process.
The Squad plan is contracted for a minimum of 12 months and is renewed automatically at the end of the 12-month period. The Squad Plan ends when we receive a written request through previously defined channels to terminate the contract.
You can cancel your contract at any time after the fourth month. Cancellation can be requested through any communication channel previously defined in the contract.
Yes, it is still possible to use the Squad Plan. There are two options available:
A Health Check can be performed that tests all existing code. Then, the Squad Plan is executed as usual within the defined scope (see this question). This option is better suited for applications under development.
Start with the standard limits (see this question), increasing the coverage on a monthly basis until 100% is reached. This option is better suited for applications that are no longer in development.
We recommend that application development and the hacking process begin simultaneously. However, this is not always possible. To catch up with developers, we perform a Health Check (additional fees apply). This means all versions of the existing code are attacked up to the contracted starting point in addition to the monthly test limit. This allows us to catch up with the development team within the first three contract months. Then, we continue hacking simultaneously with the development team as development continues.
This is a risky choice. Not performing a Health Check means there will be code that is never going to be tested and, therefore, it's not possible to know what vulnerabilities may exist in it; those vulnerabilities will not be identified. We guarantee that 100% of the code change will be tested, but what cannot be reached, cannot be tested.
We have improved the Squad Plan model to now include infrastructure within the Target of Evaluation (ToE). This includes the application's ports, inputs, infrastructure, and of course the application itself.
Our ASM (Attack Surface Manager) platform runs in the cloud.
No. We use federated authentication. Google, Azure (Microsoft 360) and Bitbucket are the entities that validate your user access credentials.
Yes, you can, and we recommend you do so. Using double authentication will increase the security level of your credentials. This will help prevent unauthorized users from accessing and compromising your information. This feature is enabled through Gmail or Azure.
We store data on AWS in the cloud (mainly S3 and DynamoDB, all security enabled) and on hackers' computers with disk encryption in all partitions. On this page you can read how we ensure the confidentiality of our clients' data.
It is up to you. However, we recommend the use of HTTPS for application tests and SSH (git) for source code analysis.
According to the active authors model, it is possible to create a large cell with all the developers or to divide it into applications according to the client's needs. When managing only one cell, it is important to consider the following:
- All users in the project can see all the vulnerabilities of the application inside the same cell.
- When the same vulnerability appears in several applications, the only way to identify/locate each one in each individual application is by checking the vulnerability report under the heading "location." There, it will specify where each vulnerability can be found.
Yes, you can, under the condition that the new environment be the same branch environment where the source code is reviewed, thus allowing us to test the same version of the change both statically and dynamically.
It is possible to cause an accidental DoS during the hacking service. We recommend including only the staging phase in the scope. However, many clients decide to also include the production stage in the tests. It is unusual for us to take down environments because when we foresee a possible breakpoint, we ask the client for a special environment to carry out the test.
The service includes the environment of the reviewed code. It is possible to include different environments for an additional fee.
The analysis that groups the number of vulnerabilities has the following problems:
- Not all the vulnerabilities have the same severity (CVSS).
- A vulnerability with a severity of 10 is not equal to two vulnerabilities with a severity of 5.
Grouping vulnerabilities by ranges (low, medium, etc.) presents the same problems by segments as well as additional ones:
- A vulnerability of 9.9 is not 10% more severe than a 9.0 (i.e., critical).
- Arbitrariness in the segmentation: 8.9 is not critical, but 9.0 is?
- Increases complexity: four non-groupable data sets instead of one.
For these reasons, executive analysis based on vulnerability grouping, either without or with ranges, is not recommended.
A 4 ^ (CVSS - 4) severity adjustment is recommended to allow the grouping of vulnerabilities. It reflects the exponential nature of the severity in each vulnerability:
Reduces the severity of vulnerabilities:
a. Little severe
b. Very frequent
Increases the severity of vulnerabilities:
a. Highly severe
a. Analysis aggregated into a single data set
b. No arbitrary ranges
c. Reality-aligned prioritization
- The table shows that vulnerability 10 (row) equals 262,144 vulnerabilities 1 (column).
- A vulnerability 5 (row) equals 16 times the severity of a vulnerability 4 (column).