Security Incident Handling for Companies
An Information Security Incident is an adverse event in an information system and/or a network that poses a threat to computer or network security in respect of confidentiality, integrity, availability, non-repudiation and authentication. Examples of adverse events are:
What is Information Security Incident Handling?
Security incident handling is a set of continuous processes governing the activities that take place before, during and after a security incident occurs.
Security incident handling begins with planning and preparing the right resources, then developing the proper procedures to be followed, such as the escalation and security incident response procedures.
When a security incident is detected, a security incident response is set in motion by the responsible parties, following predefined procedures. When the incident is over, follow up action is taken to evaluate the incident, strengthen security protection and prevent a recurrence.
The major objectives are to:
Some information security incidents may involve criminal offenses and some may not. For example, defacing a website, compromising a vulnerable server, spamming and stealing information on a compromised server are offenses under Hong Kong law, while port scanning is not an offense in Hong Kong. You should also note that different countries have different laws regarding cyber crime. If the incident is an offense, it should be reported to any relevant law enforcement agency. If you are not sure, you should consult the law enforcement agencies in that country
The Dilemma in Prosecuting an Attacker
Do you want to prosecute an attacker? If so, should you leave the network connection on to track an attacker's activity? But will this allow the attacker to do more harm? What should you do if there is a conflict between resumption of business and tracking and prosecuting the attacker?
No matter what your answer is. You should:
Considerations in the Collection of Evidence
Incident response team (or IRT) staff are in contact with first-hand evidence, such as log files and system status information (e.g. system time, current running processes and connecting machines). It is essential to know how to handle this evidence.
Here are some guidelines:
Incident response team staff should take good note of the Actions and Results. Applying the guidelines of evidence collection, they should:
Considerations in Tracking a Hacking Source
Malicious attacks can provoke strong reactions among technical staff. Do not let emotion drive you towards catching an attacker become a priority over minimising the impact.
Follow this advice:
The six-step model is a generalised process cycle for security incident response. The best tip for success is being prepared.
Proper and advanced planning ensures that all response procedures are known, coordinated and systematically carried out. It also facilitates management in making appropriate and effective decisions when tackling security incidents, and in turn minimises any possible damage. The plan includes strengthening security protection, taking an appropriate response to address the incident, recovery of the system and other follow up activities.
Planning allows a top down approach to incident response management to provide an assurance of quality and response time.
Detection and Identification
Activities in this stage may include:
One of the important decisions to be made is whether to continue or suspend the operation and service of the compromised system. This will very much depend on the type and severity of the incident, the system requirement and the impact on the image of the company, as well as the predefined goals and priorities in the incident handling plan of the system.
Actions to be taken may include:
The goal of eradication is to eliminate or mitigate the cause of the security incident. During this stage, the following actions may need to be performed depending on the type and nature of the incidents as well as the system requirement:
The purpose of this stage is to restore the system to its normal operation. Examples of tasks include:
The goal of Aftermath is to learn from the lesson of the incident. The Aftermath should start as soon as possible after the incidents. Management, users and the on-site IRT should be involved.
The next step of Aftermath is going back to the first step "Preparation" for implementation of selected recommendations and starts another cycle of continuous improvement.