Triage Operations

Hides acceptable vulnerabilities and prioritizes unacceptable vulnerabilities.

• Hide acceptable vulnerabilities and prioritize unacceptable vulnerabilities.
• Unacceptable vulnerabilities are prioritized.

Since the acceptance details vary from organization to organization, a relatively loose triage method is described below as an example.

• Acceptable Situations
  • Non-network attack source
  • Unpatched vulnerabilities
  • Attacks that require authorization

Screen Operations

Hiding Acceptable Vulnerabilities

Hide vulnerabilities that are not classified as “network”.

• Filter the “Vulnerability” item “Attackable from NW” with “Disabled”.
• Check the relevant vulnerabilities using the checkboxes on the left side (use the box on the upper left to check all vulnerabilities at once).
• Press “Hide Related Tasks”, select “Until any changes are made to the vulnerability information”, and press “Submit”.

Similarly, select those that do not provide patches and hide them.

• Those that are not “○” in terms of patch provision may not be updated by package updates, so they are not hidden.
• As with “Attackable from NW”, filter, check all and hide them.

Depending on the organization’s policy, filtering may be done by “Warning information: ○,” “Attack code: ○,” “Mitigation/workaround: Disable,” “Attack possible without authorization: ○,” and so on.

By hiding risk-acceptable items on the screen, only vulnerabilities that must be addressed will be displayed on the screen.

Addressing Unacceptable Vulnerabilities

After the aforementioned “hide acceptable vulnerabilities,” only vulnerabilities that need to be addressed will remain. The remaining vulnerabilities will be prioritized and addressed.

• The order of priority is first based on the score.
  • Basically, we look at the CVSS v3 BaseScore in that order.
  • If there is no information on v3, we will refer to the v2 score.
  • In the case of Red Hat Enterprise Linux, we do not refer to NVD or CVSS, but to Red Hat’s score (because there are considerations such as backports).
• Judgment is made by looking at the other indicators in order from the one with the highest score.
  • For example, for a group with a score of 9.5 or higher, if the “alert information/attack code/no workaround/attackable without privileges” is valid, priority is given to the group to be addressed.
• When you open the details of the vulnerability, you can see “how it is affected” from the summary and so on.
  • For example, it is possible to determine that “remote code execution should be given priority” or “if it only affects availability, the priority should be reduced a little”.

Based on the above information, priorities are assigned and actions are taken according to the priority level.

About the screen display

The items can be replaced, so for example, if you are using only Red Hat Enterprise server, it is easy to check by replacing them in the following order.

• Red Hat (provided by RedHat, score)
• CVSS v3/v2 scores
• Summary
• Attack code present
• Warning Information
• Attackable from NW
• Attack possible without authorization

Mitigation measures to address

To respond with mitigation measures such as changing settings, set the status of the task to WORKAROUND.

• Check the left side of the target task and press “Update Related Tasks”.
  • If you are going to respond to the task, set the TASK STATUS to ONGOING and enter the scheduled response date and the primary person in charge of the task, so that it will appear in the list of TASKS of the person in charge. After the response is completed, change the status to WORKAROUND.
  • When the response is completed, the “Task Status” is set to WORKAROUND.

Tasks that have been set to WORKAROUND status will no longer appear in the Unsupported list, but in the Supported list.

Respond by patching, etc.

When responding by applying a patch, there is no need to change the status when the application is completed.

• If you are going to respond to the problem, set the “Task Status” to ONGOING in the “Update Related Tasks”.
• After the response is completed, the task status will automatically change to PATCH_APPLIED in the scan and the vulnerability will disappear from the vulnerability list.

Please use FutureVuls’ patching support feature.

• Select a task in the “Tasks” tab and press the “Update Commands” button to display the commands for updates to be issued on the selected server. Manual
• Select a task in the “Task” tab and click the “ANSIBLE PLAYBOOK” button to download the Ansible Playbook. Manual
• Once the AWS integration is set up, you can actually update the package on FutureVuls. Select the task to be updated in the “Tasks” tab and click the “SSM Update” button. Manual

Confirmation after completion of response

After the response to the vulnerability is completed, confirm that the vulnerability is hidden from the list of vulnerabilities that need to be addressed.

• They are hidden when the task status becomes WORKAROUND or PATCH_APPLIED.
• Vulnerabilities that have been risk-accepted should also be hidden.
• Thereafter, unaddressed vulnerabilities should be treated in the same way, periodically.

Share information and alert other operators in the organization

The topic function can be used to share information to other group operators in the same organization. Since information can be shared in units of CVE-IDs within an organization or group, information can be consolidated and stored in one place compared to information sharing via Slack or email.

• Our group has updated.
• We tried to update, but API incompatibility problems were found during testing.
• There have been many attacks on the Internet, so be careful!

Be aware that there are many attacks on the Internet, so be careful.

In addition, the [Danger function] (/en/manual/topic/#Enables alerting of particularly dangerous vulnerabilities) can be used to alert other operators. Dangerous CVEs are highlighted in red. Operators in other groups will be aware of the alerted vulnerability and can view the topic for more information about the alert.