Kaspersky Anti Targeted Attack Platform

Implementation scenario for a continuous risk management process

The risk detection functionality allows implementing continuous (cyclical) risk management in your information system. To help you manage risks, Kaspersky Anti Targeted Attack Platform provides information about detected risks, which you can use to take the necessary remediation or mitigation measures.

The implementation scenario for the continuous risk management process involves the following steps:

  1. Taking a device inventory

    This step is performed using the Device Activity Detection and Device Information Detection methods (the methods must be enabled). At this step, the application automatically detects new devices and updates the device information. If some devices on the network were not detected automatically, you need to add them manually or import them from external projects.

    You must enable automatic update in the device settings for all information that determines the classification and operational characteristics of devices (for example, model and software version). If automatic update of such information is for some reason impossible, this information must be kept up to date manually.

  2. Risk detection while scanning passively or actively

    The application passively scans devices for risks using the available information about the devices. The application also analyzes network interactions in corporate LAN traffic to detect risks. Risk detection is implemented by the Risk Detection method (the method must be enabled).

    You can also actively poll devices to quickly get their information. When performing active polling of devices, you also can detect specific types of risks if the corresponding risk analysis methods are selected. To actively poll devices, you need to add one or more Active poll connectors to the application.

    Risks of the Vulnerability category are automatically detected after updating the database of known vulnerabilities in the application or after adding or updating the device information that is used for matching (for example, after saving software model and version information).

  3. Scoring and classifying detected risks

    For each detected risk, the application calculates a score. The score reflects the severity of the risk. Depending on the score, the severity of the risk can be Low (score 0.0–3.9), Medium (score 4.0–7.9), or High (score 8.0–10.0).

    Based on the severity levels and scores, and factoring in the special ways in which devices are used in your information system, you can classify detected risks in accordance with their importance. If you assess the risk as insignificant, you can manually change its status from the Active status (assigned by default after detection) to the Accepted status, for example, if the prerequisites for exploiting the vulnerability cannot be reproduced. When changing the status of a risk, we recommend adding or editing a comment.

    All risks that need something to be done about them should be left with the Active status.

  4. Remediation

    At this step, you must undertake remediation or mitigation of the detected risks. To do this, check all Active detected risks, starting with the risks with the highest scores. Do what is necessary in your information system (for example, to remedy the vulnerability of a device, install the software update that fixes it, and if this is not possible, isolate this device from external networks). For some risks (for example, vulnerabilities), information on recommended actions is provided.

    Kaspersky Anti Targeted Attack Platform is not involved in the remediation of detected risks.

  5. Verifying remediation

    This step is similar to risk detection while scanning. As a result of this step, no Active risks should remain in the risk table.

    For most risks that the application detects during passive scanning (for example, vulnerabilities), the application automatically assigns the Remediated status if the conditions for detecting these risks are no longer satisfied. For example, after the software version is changed for a device, the application assigns the Remediated status to the Vulnerability risk that was registered because of a vulnerable software version that had been specified previously. The Remediated status is also assigned to risks that no longer have a description in the database of known vulnerabilities (if the description is removed from the database after downloading updates).

    When devices are removed, the application also removes the risks associated with these devices.

    If, after remediation, the conditions for detecting the risk have not changed (for example, the vulnerable device is isolated from external networks, but the information about this device has not changed), you can manually assign the Accepted status to this risk. When changing the status of a risk, we recommend adding or editing a comment.

    Some risks cannot be automatically assigned a status of Remediated (for example, Remediated cannot be automatically assigned to risks that are detected during active polling of devices). For such risks, you must also manually assign the Accepted status after the risk remediation is complete.

    If a risk is associated with an event, you can assign the Accepted status to this risk at the same time when you change the event status to Resolved.