Event Response Plan

 

Introduction

Event response plan is important for making our system work well and providing great service for our client. The page cover topics like event response goal, event response team’s duty and event response detailed measures.

 

1. Event Response Goal

On the basis of reducing losses, take correct measures to restore the system;

Investigate the causes of security incidents and avoid the recurrence of similar security incidents;

Provide any legal digital evidence in cases requiring the intervention of the judiciary.

 

2. Event Response Team’s Duty

Make decision or choice when encounter exceptional attacking.

Focus on checking business data is right or wrong.

Periodically backup system and data;

Make safe network environment;

Monitor network, log data and business data;

Once system is attacked, make report in time;

Investigate the causes of security incidents and avoid the recurrence of similar security incidents;

Provide any legal digital evidence in cases requiring the intervention of the judiciary;

Take right measures to restore system and make system run correctly;

Archive and save the event handling process;

 

3. Event Response Detailed Measures

3.1 Event identification

In the whole process of event handling, this step is very important. We need to identify the real attack events and the normal network access from the huge information.

Event recognition, not only depends on the security software and the abnormal records in the logs generated by the system to make judgments, but also has a great relationship with the technical level and experience of the event recognizer. This is because, not only does the security software have the phenomenon of false alarm and omission, but also the attacker will use all means to modify these logs to cover up his whereabouts after the successful invasion, so that you cannot get some important information from the logs. At this time, an event recognizer with rich experience can determine whether it has been attacked by judging some phenomena in the network and system.

With reliable logs and various abnormal phenomena when attacked, we can determine whether we are really attacked by analyzing the entries in these log files and judging various phenomena. Therefore, if the records in the following items appear in the log, or the phenomena in the following items appear in the network and host system, it must indicate that the network or host you are monitoring has faced or is facing some kind of attack:

(1) There are abnormal audit events that are not logged in successfully recorded in the log file;

(2) There are records of unknown account successfully logged in the log file;

(3) There are abnormal records of modifying some special files in the log file;

(4) There are abnormal scanning records from the network for a certain period of time in the log file;

(5) There are records of unknown service processes started in a certain period of time in the log file;

(6) There are records in the log file where special user rights have been modified or unknown user accounts have been added;

(7) There is a record with some unknown file added in the log file;

(8) There are records of active external connection of unknown software in the log file;

(9) When viewing the log file properties, the time stamp is incorrect, or the log file size does not match your records;

(10) When viewing the contents of the log file, it is found that a certain time period in the log file does not exist or has been modified;

(11) It is found that the response speed of the system slows down, or suddenly slows down in a certain period of time, but the reason for the impact of the system hardware performance has been eliminated;

(12) It is found that the security software in the system is stopped and the normal service is stopped;

(13) It is found that the web page of the website has been tampered with or deleted and replaced;

(14) It is found that the system becomes unstable, crashes suddenly, and system resources are occupied too much, so it is restarted continuously;

(15) It is found that the network traffic suddenly increases. It is found that the unknown port is opened;

(16) It is found that the network card is set to hybrid mode;

(17) Some normal services cannot be accessed and so on

There are many abnormal records and phenomena that can be used to make judgments, and the author will not list them all here. This requires that event responders should keep learning, strive to improve their own technical level, and constantly increase the experience of identifying abnormal phenomena, and then form a suitable judgment method. With the help of log analysis tools and security monitoring software, it is not difficult to find the real attack events in these log entries and phenomena.

So far, it is still one of the most important methods to identify the nature of events by analyzing various log files. You can reset the log output format of these security software to make them easy to understand; you can also reset the filtering rules of security software in detail to reduce their false positives and omissions and increase the recognizable strength; you can also use some professional log file analysis tools, such as OSSEC HIDS, to speed up the analysis of large volume log files, improve the recognition rate, but also reduce your burden. As for the fear that the log will be deleted or modified by the attacker, you can save all the log files to the firewall protected storage system to reduce this risk. In short, in order to get the information we want from the log files, we should try to make the log files work in the way we need.

All of these require the incident response personnel to check the operation of the network and system frequently, analyze the records in the log file constantly, and check all kinds of network or system abnormalities, so as to make a correct judgment on the real attack event in time. In addition, when you operate some objects in the network system, you should record the contents and operation time of all the objects you have operated in detail, so as to have a basis for judgment in recognition. In work, it is a good habit for event responders to record these operations with notes frequently.

When the above abnormal records or phenomena are found, the attack event has occurred, so it can immediately enter the next link, that is, the severity of the attack event is classified.

3.2 Event classification

When it is confirmed that an attack has been found, it is necessary to immediately make a judgment on the severity of the attack that has occurred, so as to make clear the extent of the attack, so as to decide what kind of response measures to take next. For example, if the attack event involves some confidential data in the server, which is certainly a very serious attack event, the network connection of the attacked server should be immediately disconnected and isolated to prevent the situation from further deterioration and affect other important hosts in the network.

For a long time, there is no uniform standard for classifying attacks. Every security manufacturer has its own set of classification methods. Therefore, you can also classify the severity of attacks by yourself. Generally speaking, the attack events can be classified by confirming the development and consequences of the attack events. In this way, the attack events can be divided into the following categories:

(1) Exploratory events;

(2) General events;

(3) Control system events;

(4) Denial of service;

(5) Access to confidential data.

The exploratory scanning of hosts in the network can be considered as exploratory events. These are the most basic work for attackers to confirm whether there are hosts that can be attacked in the network. When the attacker confirms the target to be attacked, he will further scan the target in more detail and purposefully. At this time, the scanning method used will be more advanced and unrecognizable, such as semi connected scanning and fin scanning. After this scanning is completed, we can find some vulnerability information that can be exploited. Since the current one Some integrated firewalls and IDS can also recognize these scanning methods, so if the corresponding record is found in the log file, it indicates that the attack has developed to the level of general events. When the attacker gets the exploitable vulnerability information, he will use various means to penetrate the target. At this time, if you don’t find it in time, the success of penetration is very great. There are too many such penetration tools in the network. It’s easy to use these tools to penetrate. After the success of penetration, the attacker will try to improve himself In order to control the infiltrated target at will, the system has developed to the point of control system. Here, if you haven’t found the attack, then the confidential information you protect may be completely obtained by the attacker, and the seriousness of the situation can be imagined. After the attacker controls the attack target, sometimes he may not be able to obtain confidential data, resulting in some retaliatory behaviors, such as some DOS or DDOS attacks, which make other normal users unable to access, or the purpose of the attacker controlling the system is to carry out DOS or DDOS attacks on other systems.

At this time, we should quickly make a clear judgment on the extent of the attack from the log file entries, report it to the team leader in time, and report it to other team members, so that all members of the whole team can know the severity of the attack. And then decide what kind of response method to take to respond, so as to prevent the incident, in order to find the attacker, we should try our best to reduce the loss, repair the vulnerability in time, resume the normal operation of the network system, and collect all the evidences as soon as possible.

3.3 Evidence collection of attack events

In order to analyze the cause of the attack and the damage caused by the attack, as well as to find the attacker and provide evidence to bring him to justice, all the data that can provide evidence should be collected and properly preserved before the system that has been attacked is restored to normal.

As for how to collect, it depends on the amount and size of evidence you need to collect and the speed of collection. If only a small amount of data is collected, you can save the data to other safe storage media through simple replication method; if the amount of data to be collected is large and large, and it is required to be completed in a very short time, you can collect it through some professional software. For what kind of storage media these collected data are stored in, it also depends on the requirements of the data to be collected. It also depends on what kind of storage media you have now. Generally, it’s better to save them to CD or tape.

For specific data collection, we can collect all the data that we think can provide evidence for the attack event, or only the most important part. Here are some data lists that should be collected:

(1) Operating system event log;

(2) Operating system audit log;

(3) Network application log;

(4) Firewall log;

(5) Intrusion detection log;

(6) Damaged system and software image.

Before this step, if our first task is to restore the network or system to normal, in order to prevent the loss of these evidence files when restoring the system backup, or you just want to leave a memorial for these attacks, you should first use some system image software to save the whole system as an image, and then restore the system.

The collected data is not only used as evidence to prove the attacker, but also, after the event response is completed, they should be recorded and reported to the relevant leaders and other partners, such as security software providers, partners, and local legal institutions, which can also be used for post analysis and learning. Therefore, this event response operation step is also essential, and the collected data should also be saved completely.

3.4 Network, system and application data recovery

After all the evidences are collected, all the objects affected by the attack can be restored to normal operation for normal use. Whether or not the system can be restored to normal state in time depends on another security means, which is backup recovery plan. For some large enterprises, it is sometimes called disaster recovery plan. Anyway, it is necessary to make a safe backup of the protected important data in advance, which directly affects the timeliness and possibility of recovery in the event response process.

After recovering the system, you should make sure that the system vulnerability has been patched, the system has updated the latest patch package, and the repaired system has been backed up again, so that these attacked systems can be connected to the network again. If you do not have the latest security patch at that time, and you need to restore the system immediately, you can first implement some targeted security measures, and then connect the system to the network, but pay attention to it all the time, update it as soon as there is a patch, and then back it up again.

The method and content of recovery depends on the damage of your system. For example, if only some abnormal ports are opened in the system, it is not necessary to recover the whole system. Just close these ports and plug the loopholes that generate attacks. If the important files in the system have been modified or deleted, the system cannot operate normally, and these files cannot be repaired, the whole system can only be restored. In the process of recovery, the recovery can be achieved by manual operation, or by some professional backup recovery software. Even in some large and medium-sized enterprises, due to the large amount of data, which is very important, there is a high demand for system stability and continuity. For example, some website enterprises will use a backup system to provide redundancy After a system is attacked and shut down, another system will automatically replace it, so that the event response team members can have enough time to carry out various operations, and will not affect the normal access of the network system.

Recovery is unique in the whole event processing step. You should decide which step to put it in. For example, when the primary goal of your protection is to recover the normal access of network system or service as soon as possible, if there is a backup system, because the backup system has taken over the operation of the attacked system, you can follow the above steps If you want to restore the system to normal operation as quickly as possible, you can first make a mirror image of the whole damaged system, then you can quickly restore the backup and put it into operation.

In fact, any processing step, to put it bluntly, is just to let you develop a kind of general habitual thinking and workflow for some event processing process.

4.5 Archive and save the event handling process

After all the events have been investigated and the system has returned to normal operation, you should make a detailed record of all the events related to this event. The purpose of filing is to report the cause of the incident and the handling method to the superior leaders, and to do learning examples to analyze the attacker’s attack methods, so as to prevent such attacks from happening more effectively in the future. Specifically, the content to be recorded and saved involves the whole event response process. There are many contents to be recorded, and sometimes the response process is relatively long. Therefore, it requires the security event responders to record the dots and all operation events found in the response process at any time in the event processing process, so that they can use them when creating a file.

The filing format can be defined by you. There is no specific standard, as long as you can clearly record all the contents that should be recorded. You can also make the document in triplicate, one for reporting to the leader, one for saving, and one for analysis and learning. These documents can also be handed over to some professional security companies and system and application software providers, so that they can understand the attack method in time, release corresponding prevention products and security patches, and inform some partners, so that they can also strengthen the prevention in this regard.

The specific contents to be filed are as follows:

(1) When did the attack take place, when was it discovered, and who was the discoverer?

(2) What kind of vulnerability is used by the attacker to attack? This vulnerability has been found and is only happening now. What are the specific types and numbers of vulnerabilities?

(3) What are the aspects of the attacker’s operations in the system, and what data or files are attacked by the attacker?

(4) How is the general order of attack development?

(5) What are the key factors causing this incident?

(6) What is the specific process to solve this incident?

(7) What are the consequences and severity of the attack, and what permissions and data have the attacker obtained?

(8) How does the attacker break through the security line?

(9) What tools and software are used to solve this problem?

(10)Which personnel participated in the discovery and handling of this incident and which departments and personnel were reported to?

(11) What is the recovery of the loss after the incident?

(12)What new changes have taken place in this attack, and can they be prevented and dealt with?

(13) How to deal with this kind of security incident in the future, and give a specific scheme attached, etc.

All listed above are the contents that should be recorded when filing. The archivists are free to arrange the order of records, but they should correspond to the order of event handling so that other personnel can better understand and learn. Of course, you can also record other contents that are not mentioned in the above items, as long as you think it is necessary to record these contents, or as required by your response team leader.