Attack Resistance Management
Fluid Attacks'
Attack Resistance Management (ARM)
comes with all functions you need
to manage all your applications
and vulnerabilities effectively.
To access this platform you can click here.
Requirements
We support the web browsers listed below and, in general, any browser that supports ECMAScript 2019 standard.
Browser | Version | |
---|---|---|
Firefox | 60, 68, 78, 81, 82, 83, 88, 89, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105 | |
Chrome | 71, 75, 80, 81, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 98, 99, 100, 101, 102, 103, 104, 105, 106 | |
Edge | 84, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105 | |
Safari | 12.1, 13.1, 14, 14.1, 15, 15.1, 15.2, 15.3, 15.4, 15.5, 15.6,16 | |
Opera | 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90 | |
Chrome iOS | 90, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 105 |
Login
To authenticate in the ARM, you need a valid user in at least one of these providers:
- Azure
- Bitbucket
For added security, we do not manage users, credentials or MFA (multi-factor authentication). We adopt our customers' policies.
Organizations
All customer data is consolidated in this ARM's section. Each organization has a data bucket that only users of that organization can access.
In this section, you will find the following subsections (see the right-hand menu):
Analytics
Charts and indicators will help you know what is happening with your applications. Information presented, among others, includes the following:
- Exposure over time
- Vulnerability status
- Vulnerability treatment
- Open vulnerabilities
- Exposure management over time
Groups
You may have multiple apps in your organization, and you probably want to keep their vulnerabilities separate.
You can have as many groups as you want. One group for each application or several groups for one application, it is your choice.
In Groups section, you will find:
Vulnerabilities
One of the main sections on the platforms is where you find all the confirmed security issues of your application.
Vulnerabilities section is divided as follows:
Locations
Here you find the list of all vulnerabilities with their specific locations: File and LoC, URL and input or IP and port.
You can ask for a reattack or change the treatment for one or many vulnerabilities as you want.
Also, you can add tag or define a qualitative risk level.
Reattack
When a vulnerability is remediated,
you need to request the Fluid Attacks
team
to reattack
it and confirm
if it was indeed remediated.
You can check in the
Locations table
which vulnerabilities were requested
to reattack and verify their remediation.
After verification,
the Fluid Attacks
team
will inform you through the
Consulting
tab about the results.
Treatments
Risk management is an essential part of vulnerabilities management. You can define different treatments in the Locations tab:
- Untreated: The vulnerability was reported, and there is no treatment defined.
- In progress: The vulnerability is going to be remediated and has a user responsible for that remediation.
- Temporarily accepted: You may not resolve the vulnerability and decide to coexist with the risk for some time. The platform accepts by default a maximum of six months. You can control this setting in the Organization Policies section.
- Permanently accepted: You may not resolve the vulnerability and decide to coexist with the risk forever.
Description
In this section you can discover all required information to understand reported vulnerabilities.
Severity
For the calculation of the severity of vulnerabilities, we use the Common Vulnerability Scoring System (CVSS) version 3.1.
Evidence
In evidence we provide video examples and screenshots to help you understand the context of the vulnerabilities.
Tracking
Here you find the history of each Vulnerability. What has happened to the vulnerabilities since the first one was reported. When and by whom the treatment was closed or changed.
Records
Some vulnerabilities can expose customer information; for context, we share the disclosed information in this section.
Consulting in the vulnerability
Consulting should be used to communicate with us when a problem is related to any of the reported vulnerabilities or to validate the executed reattacks.
Note: This section is for Squad plan only.
Group analytics
As in the case of Organization Analytics, Group Analytics have all the information about your group.
DevSecOps
Fluid Attacks'
ARM
includes an agent
that present in the CI pipelines
can break the build for open vulnerabilities.
This section shows
the result of recent executions
and more information such as the following:
- Execution date
- Execution status (secure or vulnerable)
- Checked vulnerabilities
- Strictness (Tolerant/Strict)
- Type (SAST/DAST)
Events
In the service execution, many things can and will happen. In the events, our analysts can report any situation that affects the service. It can be a full or partial disruption or merely a request for information.
Consulting
Communication is essential
to achieve the remediation goal.
You can post any doubt,
comment, or thought
you want to share
with the Fluid Attacks
team
or your team in the
Consulting tab.
This section works like a forum
where anyone can post and reply.
Note: This section is only for the Squad plan.
Group stakeholders
You have group access control here to define who and what they can do. When you give access to the group, there are four role options available:
- User
- User manager
- Vulnerability Manager
To get more information about it, check the Roles section.
Authors
The authors section gives you a list of git users that commit code to checked repositories.
Surface
The surface tab gives more information about the Target of Evaluation (ToE). This ToE is the result of repositories, environments and languages specified in the scope roots section.
Scope
For an ARM,
you need to define the surface
that the Fluid Attacks
team will check.
The following information
is required to enable
the testing service:
- Roots: Git repositories where you version the application’s source code.
- Environments: URLs where applications are deployed.
- Files: Any information that could help the service.
- Tags: Keywords to build portfolios and get information and analytics for groups that share the tag.
- Services: Active services for the group.
- Deletion: Function to safely delete all group data.
If you want to see more of this section of scope, you can enter it here
Portfolios
In the Analytics subsection, you have the data of all your groups. But if you want analytics for only a subset, you can go to the Portfolios subsection (we employ the same charts and indicators).
Please check the tags in Scope for more information.
Organization Stakeholders
Some users can access your organization's data, but this permission does not guarantee access to groups or vulnerabilities, only access to organization-level analytics and policies.
Explore more of this section by clicking on this link.
Policies
You can use vulnerability treatments to plan remediation. To control the correct use of them, you can define rules that will apply to all groups in your organization.
Policies to define:
- Temporal acceptance: maximum number of days for assignment.
- Temporal acceptance: maximum number of assignments for a single vulnerability.
- Temporal acceptance: minimum CVSS 3.1 score allowed for assignment.
- Temporal acceptance: maximum CVSS 3.1 score allowed for assignment.
- DevSecOps: Days before agent starts breaking the build for new vulnerabilities.
- DevSecOps: Minimum CVSS 3.1 score from which agent breaks the build for open vulnerabilities.
Outside
This section refers to repositories that are not yet associated with any group on the ARM platform, which can consult with the credentials available in the Credentials tab. to learn more about this section, you can enter here.
Credentials
In this section, you can create, edit and delete credentials at the Organization level and use them in all the groups that compose that. These credentials help us to have access to the ToE
Compliance
Compliance
shows the compliance of all
standards validated by Fluid Attacks
at the Organization and group level.
ARM Update
When the ARM was last deployed, be it because of new features or improvements to old features, is not top secret information we are keeping from our clients. You can see this information by clicking on the icon with the letter i on the ARM’s top-right menu.
Upon clicking, you will see the commit hash ID (a commit’s unique identifier) that corresponds to the update. Below, you will see the update deployment date and time. You can click on the commit hash to see on GitLab the specific lines of code that were changed, the developer who made the change, what was removed and added, and on what file.
Search for vulnerabilities in your apps for free with our automated security testing! Start your 21-day free trial and discover the benefits of our Continuous Hacking Machine Plan. If you prefer a full service that includes the expertise of our ethical hackers, don't hesitate to contact us for our Continuous Hacking Squad Plan.