Consideration of response policy

There are many vulnerabilities that remain unless they are kept up-to-date. The initial triage (selection and prioritization of those to be accepted) of vulnerabilities visualized by FutureVuls is performed.

This page describes the triage policy and how it is handled in FutureVuls. The actual on-screen work is performed on the next page.

This tutorial assumes the following users

The following user environments are assumed. For environments with advanced functions, please follow the policy accordingly.

  • The number of users in charge is small, and we would like to sort out the most urgent items as quickly as possible.
  • We assume a server that is open to the Internet and consider excluding attacks from the local area once they are in place.
    • Since we are auditing server logins and log audits, we assume that we can grasp the malicious behavior of internal logged-in users.
    • The policy is that attacks using local privilege escalation from network access can be temporarily mitigated by preventing network access attacks.

Policy

In order to rank a large number of vulnerabilities to be addressed, the following will be addressed.

  • Consider the risks to be addressed
    • Clarify criteria for acceptable/unacceptable
    • Consider each vulnerability as acceptable or unacceptable.
  • Eliminate vulnerabilities that are acceptable.
    • Hide the vulnerabilities on FutureVuls.
  • Prioritize unacceptable vulnerabilities according to the urgency of response, and respond to them
    • Update or otherwise respond to the vulnerabilities

Consider each of the above phases.

Consider the risks to be addressed

Consideration is given to “risks” that may occur due to vulnerabilities.

  • Consider whether the following measures can be taken to address the risks.
    • Mitigation: Measures to reduce the frequency of occurrence and impact. For example, use WAF to protect against unauthorized web access.
    • Avoidance: Measures to eliminate the frequency of occurrence. Uninstalling unused services, etc.
    • Transfer: Measures to transfer the impact or responsibility to another party. For example, moving from ownership to SaaS services for hardware failure.
    • Acceptance: Accepting the impact without taking action. Acceptance: Accepting the impact without taking countermeasures, e.g., assuming that login is not possible for a local privilege escalation vulnerability.
  • For those that do not fall into any of these categories, a response is required.
    • Target those that cannot be mitigated/avoided or shifted and the impact is unacceptable.

Consider whether it can be mitigated/avoided/transferred/accepted and exclude it from the response.

  • Mitigation
    • For example, consider whether it can be protected by adding WAF signatures, etc.
    • Note that this is only mitigation and does not mean that the countermeasure is completely effective.
  • Avoidance
    • For example, consider whether the vulnerable service can be stopped or migrated to another similar service.
    • Another option is to perform an update.
    • Usually, the only other option is to update, which can be difficult to do (e.g., from BIND to PowerDB to PowerDB). (For example, moving from BIND to PowerDNS.)
  • Determine “acceptable risk.”
    • For example, if the attack can only be done locally (e.g., CVSS Vector AV is A, L, P, etc.), consider accepting it because it has preconditions.
    • Consider acceptability in terms of the location where the system is deployed and what can be mitigated or avoided.
    • The acceptable scope is determined based on the “social environment in which the system is located,” such as where the attack is coming from (Internet side only, including internal networks, etc.), whether it can be mitigated or avoided, and what kind of impact it will have (service suspension due to DoS is acceptable, but data leakage or falsification is not, etc.). (e.g., whether a service outage due to DoS is acceptable, but data leakage or falsification is not, etc.).

Exclude vulnerabilities that are acceptable

Acceptable risks can be assumed to be

  • If no update patches are available, and no mitigations are available
    • If no update patches are available and no mitigations are available, there is no way to address the vulnerability. In this case, remove the package or consider again when a response becomes available.
    • Patch provided: Disabled, Mitigation/workaround: Disabled → Hide (until some changes are made to the vulnerability information)
  • Those that cannot be attacked via the network.
    • Vulnerabilities that occur locally (privilege escalation, buffer overflow, etc.) may be mitigated by other countermeasures = risk reduction.
    • In such cases, there is an option to “accept the attack categories that are local”.
    • Attackable from NW: Disable → Hide (until some changes are made to the vulnerability information)
  • Avoidable or mitigable
    • Mitigation includes “configuration changes that make the vulnerability unaffected”.
  • Consideration of the impact that may occur
    • For non-availability-critical systems, DoS vulnerabilities may be acceptable.
    • In general, remote code execution (RCE) and other vulnerabilities may not be ignored.

Of the acceptable vulnerabilities, those that are “not directly addressed” are excluded (hidden) on FutureVuls.

  • Treat vulnerabilities that are currently displayed as “not to be addressed until updates are made”.
    • Occasionally, CVSS Vector or BaseScore may be updated, in which case we will reconsider.
    • For example, we will hide all unpatched and non-networked attacks in one lump sum.
  • For those that can be avoided or mitigated, change the task to “WORKAROUND” when the response is complete.
    • Record the fact that the risk has been made acceptable through avoidance and mitigation.

Prioritize and address unacceptable vulnerabilities according to the urgency of response

Unacceptable vulnerabilities are individually prioritized and addressed according to their urgency. Prioritize countermeasures based on multiple indicators, not just the CVSS score, and address them one by one.

  • Priority of countermeasures will be determined based on the following items.

    • Attackable from NW.
    • Mitigation/avoidance measures None
    • Attackable with attack code None
    • Attackable without authorization Yes
    • Warning information Yes

  • Here is an example of the order of importance.

    1. alert information is released by JPCERT/CC and other organizations when there is a high possibility of attack or high impact.
    2. Attackable from NW indicates a high possibility of being attacked by access from the Internet side. 3.
    3. with attack code means the possibility of attack based on the disclosed code is high. 4. mitigation/workaround
    4. attackable without mitigation/workaround and without authorization affects the ease of attack.

  • As an example, the following priority order determines the response. 0. ordered by CVSS v3/v2 or Red Hat score

    1. with warning information, with attack code, without `mitigation/workaround
    2. with warning information and `attack code
      • Those for which attack codes have already been disclosed and alert reports from CISA-KEVC, JPCERT/CC, etc. have been issued are given the highest priority because there is a high possibility that attacks will start immediately (or have already started). 3. 3.Attack possible from NW, `attack code exists
    3. Attack possible from NW.

After the priority is determined, the application is discussed.

  • Can it be applied immediately?
    • If validation is required, a plan for staging validation is needed.
    • If the priority is low, a plan is needed for whether to apply it at the same time as a high priority one or separately by periodic update, etc.
  • When updating, which version should be used?
    • Basically, it is desirable to use the latest version. In many cases, other vulnerabilities are resolved at the same time.
    • In addition, when an updated version is released in the future, it is often provided after checking the operation from one previous version. Therefore, it is considered possible to omit some of the operation checks by using the newest version possible.

Remarks

Although the above describes a rough coping flow, it may not be appropriate depending on the organization’s policy or operational policy. The following responses should also be considered.

  • Even in an environment where patch provision:Disabled and mitigation/workaround:Disabled, if attack code exists:○, caution is required.
    • There are cases where the attack code is present, but there are no defenses.
    • However, there are cases where the response is “We have confirmed that it cannot be exploited, so the impact is considered low” or “We plan to address this issue in a future update”. (This is often seen in RHEL and other systems that use backports.)
    • If you have sufficient resources for vulnerability handling, it is better to check this far, but if not, it is better to accept the risk based on the vendor’s judgment at once.

Notes on FutureVuls

  • Use not supported in the Vulnerability tab to check for omissions.
    • Vulnerabilities with status NEW and not not hidden = vulnerabilities that have not been addressed after detection.
  • Vulnerabilities that need to be determined on a per-server basis are checked on the Server, Role, and Task tabs, not the Vulnerability tab.
    • There may be cases where a vulnerability can be ignored on a public server, but not on an internal server.
    • In this case, you need to specify the target CVE-ID in the Server tab, Role tab, and Task tab, and change the status or hide settings for each server.