Playbook Overview

Background

An attack link is an important concept in the cyber security field. It refers to a series of attack steps and paths taken by an attacker on a target network or system to achieve an attack purpose. Using these steps and paths, an attacker can sneakingly penetrate into the target system and do what they want.

The attack link has great harm to the target network or system. Once an attacker successfully constructs an attack link and breaks through the defense measures of the target system, the attacker can perform any operation on the target system, including stealing sensitive information, damaging system data, and paralyzing system services. These hazards not only cause economic losses, but also may have a serious impact on national security and social stability.

Response Solution

If a domain name is attacked, the attacker usually further hacks into backend servers. This playbook analyzes attack chains and generates alerts. Once this playbook discovers that attacks are approaching servers, it notifies operations personnel.

The Attack link analysis alert notification playbook has been matched the Attack link analysis alert notification workflow. This workflow needs to use Simple Message Notification (SMN) to send notifications. So you need to create and subscribe to a notification topic in SMN.

The Attack link analysis alert notification workflow queries the list of website assets associated with affected assets that are marked by HSS alerts through asset associations. By default, a maximum of three website assets can be queried.

• If there are associated website assets, the workflow queries WAF alerts generated for each website asset from 3 hours ago to the current time. A maximum of three alerts can be queried. The alert types include XSS, SQL injection, command injection, local file inclusion, remote file inclusion, web shell, and vulnerability exploits.
• If there is an alert generated in WAF, the workflow associates the WAF alert with the corresponding HSS alert and sends a notification the email box you specified through SMN.

Incident Response

1. Obtain, store, and record evidence.
   1. Based on the configurations of your Huawei cloud environment, use HSS and WAF to detect alerts.
   2. Access affected ECSs over SSH and check the instance status and monitoring information to see if there are any exceptions. Alerts you receive from other channels are supported.
   3. Once an attack is confirmed as an incident, the affected scope, attacked machines, affected services, and data information need to be assessed.
   4. Use SecMaster to convert alerts into incidents and continue to monitor and record incident details. For details, see Converting Alerts to Incidents.
   5. In addition, log information can be traced. All related log information can be reviewed through security analysis, and recorded in the incident management module for subsequent operation tracing.

2. Contain incidents.
   1. Determine the attack type, affected servers, and service processes based on alerts and logs.
   2. Use scripts, such as isolation, killing, and policy blocking scripts, to kill processes, isolate software, and taken other actions to reduce subsequent impacts.
   3. Check the infection scope. If there is an infection risk, check and handle it in a timely manner.
   4. Other playbooks and workflows can also be used for risk control, such as host isolation. Security group access control policies can be used to isolate infected machines and contain risks from further spreading.

3. Eradicate incidents.
   1. Evaluate whether the affected servers need to be hardened and restored. If the server has been compromised, you need to harden and restore it based on the source tracing result. If attacks are caused by security credential leakage, delete any unauthorized IAM users, roles, and policies, and revoke credentials to improve host security.
   2. Check affected hosts for vulnerabilities, outdated software, and unpatched vulnerabilities. These may cause more hosts to be affected. You can go to the Vulnerabilities page and fix the vulnerabilities for the affected hosts. Check for risky configurations. You can go to the Baseline Inspection and rectify risky configurations in a timely manner.
   3. Evaluate the impact scope. If other hosts have been affected, handle all affected hosts.

4. Recover from incidents.
   1. Determine the restoration points of all restoration operations performed from the backup.
   2. Check the backup policy to see whether all objects and files can be restored. This depends on the lifecycle policy applied to the resources.
   3. Use the forensic method to confirm that the data is secure before the restoration, and then restore the data from the backup or restore the data to an earlier snapshot of the ECS instance.
   4. If you have successfully restored data using any open-source decryption tool, delete the data from the instance and perform necessary analysis to confirm that the data is secure. Then, restore the instance. Alternatively, you can terminate or isolate the instance, create an instance, and restore the data to the new instance.
   5. If neither restoring data from backups nor decrypting data is feasible, evaluate the possibility of restarting in a new environment.

5. Perform post-incident activities.
   1. Analyze alert details in the entire alert handling process, continuously operate and optimize the model, and improve the model alarm accuracy. If an alert is related to a service but there is no risk, the alert can be filtered by a model.
   2. Deeply analyze why the alert is generated and continuously optimize asset protection policies to reduce resource risks and the attack surface.
   3. Optimize the automated response playbooks and workflows based on the actual service scenario. For example, you can replace the manual review policy with the automated review policy to improve the response efficiency and handle risks more quickly.
   4. Analyze risk and attack links to enable pre-event risk control.