In the last months, we implemented a feature that forces the users to choose a deadline when they accept findings. But sometimes, accepting a finding for an indefinite time is needed because the organization has evaluated all the consequences it may have and decided they will assume the risks forever.

Considering that, Integrates now allows accepting a finding without setting a deadline at the cost of requiring an additional reviewing cycle.

If you want to request the indefinite acceptance of a finding, you must do the following:

1. Go to the finding that you want to Accept indefinitely and press the “Edit” button
2. Go to the end of the page and, from the list of treatments, select “Indefinitely accepted”
3. Enter a justification for the treatment
4. Go back to the start of the page and press the “Update” button
5. A dialog warning about the approval of the finding will pop up, and you will have to press “Proceed” to agree and set the treatment for the finding
6. A mail will be sent to all project interested users

If you are a manager, you can review the indefinite acceptance of a finding and decide whether you approve or reject the treatment:

1. In the finding, you will see a pair of new buttons to approve or reject the treatment
2. When you press any of these buttons, you will be requested for an observation about the decision
3. After you enter the observation, you can proceed, and now the finding will have one of the following treatments:
   • Indefinitely accepted if the treatment change is approved
   • New if the treatment change is rejected
     

Note:

• The finding will have the New treatment if the treatment change approval is not resolved after five days.

What happened

• Last Thursday (January 30th) at 19:44 we released a version of Integrates that caused a malfunction in authorization roles, in which “Manager” users were affected. The details of this commit can be found at https://gitlab.com/fluidattacks/integrates/commit/d1814d
• We are updating our authorization model, to give more flexibility to our current roles and create more of them in the future. This issue was a product of one of those migrations.
• No migration-related error, including this one, has jeopardized the confidentiality of our users’ information.

What we’ve done

• On January 31st at 11:29, the issue was fixed by correctly assigning the permissions to the affected role.

What’s the impact

• The issue lasted approximately 16 hours. However, access attempts only occurred from 7:50 to 11:12 on January 31st.
• Approximately 6 of our users with manager roles were unable to see the “Users” tab and to manage the information of the findings on January 31st until 11:29.

What we are doing to help

• To avoid future similar issues we are strengthening the peer review process in our development team, assuring that the changes in the authorization model are not affecting the previous ones.
• With this announcement, customers are being notified that this was an internal error caused by a set of changes we had made to the authorization model and of what we did to fix it.

Fluid Attacks main responsibility is to find vulnerabilities. Our customer's main responsibility is solving them.

Through ARM, customers can request a Reattack when a vulnerability is solved, and source code is available in the defined branch in the GIT repository.

You can select one or multiple vulnerabilities to be reattacked, and our team will do their job confirming the solution to the vulnerability.

You will get informed in the consulting tab about the reattack outcome.

Also, you can check pending to reattack vulnerabilities in locations table filtering by reattack requested vulnerabilities

What happened

• Last Tuesday (January 7th) at 12:03 PM there was an incident in which two of our customers using the Breaks service got their pipelines broken due to findings with ‘Accepted’ treatment.
• The commit with the changes that affected the pipelines was merged at 09:43 AM and its details can be found at https://gitlab.com/fluidattacks/integrates/commit/7913964
• We implemented a new functionality which restructures finding attributes so that now information concerning treatment data is stored inside a historical register. This feature allows to store and keep constancy of all treatment changes with its concrete data.
• This is a very sensible change given the number of parts of Integrates that we had to modify in order to make this new feature effective. Specifically, the change modified the API signature. The Breaks service uses the API and the signature was not updated, breaking the expected behavior.

What we’ve done

• January 7th at 4:41 PM, the issue was fixed. The affected customers confirmed that the issue was solved at 5:57PM of the same day.
• The way we solved the problem was updating Breaks service, due to the finding treatment change mentioned above, to retrieve the treatment correctly.

What’s the impact

• Two of our customers got their pipelines broken because of those findings whose treatment were ‘Accepted’. The problem lasted 4 hours and 38 minutes.

What we are doing to help

• In order to avoid future similar issues we are going to implement ‘versioning’ for our API. This way, future incoming changes affecting the API will automatically activate the corresponding changes in breaks.
• With this announcement, customers are being notified that this was an internal error due to a set of changes we made in the data structure and what we did to fix it.

In every project, there was a tab called Resources, in which you could find the list of Repositories, Environments, Files and a list of tags, called Portfolio, used for analytics purposes.

This tab is now called Settings and was moved to the last position since we are implementing other functionalities that affect the whole project but are not directly related to its resources.

We also moved the Comments tab to the left in order to give more importance to this communicative feature.

Before:

Now:

Now it is possible to assign some data to vulnerabilities in findings:

• Tag: It is an arbitrary string; it can be used to identify a group of vulnerabilities.
• Severity: It can be a number between 0 and 1,000,000,000 (one billion) that represents the severity of the vulnerability for the business. It can be a quantitative or monetary value.
• Treatment manager: Is the person responsible for the treatment given to the finding for a particular vulnerability. Remember that this field depends on the treatment value: If it’s “New”, it will not be available. If it’s “In progress” and the user is a manager, it can be chosen; otherwise, it will be the user himself.

In order to ease the selection of multiple vulnerabilities, a filter is available in the first column, and you can select many vulnerabilities at the same time:

Now it is possible to assign some data to vulnerabilities in findings:

• Tag: It is an arbitrary string; it can be used to identify a group of vulnerabilities.
• Severity: It can be a number between 0 and 1,000,000,000 (one billion) that represents the severity of the vulnerability for the business. It can be a quantitative or monetary value.
• Treatment manager: Is the person responsible for the treatment given to the finding for a particular vulnerability. Remember that this field depends on the treatment value: If it’s “New”, it will not be available. If it’s “In progress” and the user is a manager, it can be chosen; otherwise, it will be the user himself.

In order to ease the selection of multiple vulnerabilities, a filter is available in the first column, and you can select many vulnerabilities at the same time:

What happened

As part of the implementation of a series of new functionalities in which we are working, yesterday morning (9:57-10:50) and afternoon (17:13-18:50) the users of Integrates experimented errors when they tried to access any tab of a project.

Both errors were caused by changes in the structure of directories and files in our repository. With new deployments, a cache was stored from previous deployments and the API endpoint was unable to respond to new requests.

What we have done

Both errors were caused by the same problem but were fixed by different means. The first one was solved with a fresh deployment of the application. The other one was solved with a purge of the server cache.

What was the impact

During approximately two and a half hours, all projects, with their indicators, findings, events, etc., were inaccessible to all Integrates users.

What we are doing to help

• We made some changes to our CI/CD in order to improve the identification of critical files that require cache invalidation during new builds.

In previous days, we released a new feature that will allow analysts to report new events directly on Integrates using the “New Event” button:

When the analyst click the button, a pop-up will emerge, requesting the information about the event:

After the analyst enters the information and presses the “Proceed” button, Integrates will create a new event and send an email to all project managers.

The “Edit” button must be pressed and the affectation value must be edited to solve the event. The affectation is the number of hours that the project was affected by the event:

Finally, the “Update” button must be pressed. After refreshing, the event will appear with a “Solved” status:

To keep track of the different resources a project needs, it is no longer possible to eliminate repositories. Instead, each of them will have a “state”. This * state * can be “Active” or “Inactive” ([optional] as explained below):

• Active: The repository is available and ready for our hackers to access.
• Inactive: The repository does not exist anymore, it was changed, or it was added by mistake.

Every time a repository is changed, a notification will be sent to all the people involved in the project (both Fluid Attacks’s and customer’s users).

Finally, the states can be changed by project users at any moment, and every change will be stored for future needs.