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:

Theft and burglary

Natural disasters, e.g. floods, typhoons, rainstorms

Possible hazards from the surroundings

Data line failure

System crashes

Packet flooding

Unauthorised access or use of system resources

Unauthorised use of another user's account

Unauthorised use of system privileges

Web Defacement

System penetration / intrusion

Massive malware attacks

However, adverse events such as natural disaster, hardware/software breakdown, data line failure, power disruption etc. should be addressed by a system maintenance and disaster recovery plan instead of an information security incident plan.

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.

Objectives of a Security Incident Response

The major objectives are to:

Minimise business losses and subsequent liabilities to the company;

Minimise the possible impact of the incident in terms of information leakage, corruption and system disruption, etc.;

Ensure that the response is systematic and efficient and that there is prompt recovery for the compromised system;

Ensure that the required resources are available to deal with incidents, including manpower, technology, etc.;

Ensure that all responsible parties have a clear understanding regarding the tasks they need to perform during an incident by following predefined procedures;

Ensure that all response activities are recognised and coordinated;

Prevent further attacks and damage; and

Deal with related legal issues.

No matter how good the risk mitigation measures may be in reducing the impact of a security incident and the probability of incidents, an incident may hit you unexpectedly! You must be prepared.

Legal and Contractual Considerations

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?

Identify the command structure of the decision-making process, and notify the relevant law enforcement authorities.

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:

A piece of Evidence is considered fact and the truth.

Electronic Evidence must be captured as soon as possible.

A proper chain of custody for the evidence should be maintained. A chain of custody is a history that shows how the evidence was collected, analysed, transported and preserved in order to present it as evidence in court. A clearly defined chain of custody demonstrates that the evidence is trustworthy.

Evidence should be collected with proper (un-contaminated) tools under pre-defined procedures.

Evidence should be protected from unauthorised access and from modification or damage. Transfers or Copies of Evidence should be approved and witnessed.

Incident response team staff should take good note of the Actions and Results. Applying the guidelines of evidence collection, they should:

Log down events clearly and tidily in chronological order with a time stamp for each event. Use a preprinted form if possible to keep the format consistent. Use other effective media like audio and video taping when necessary.

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:

Should you strike back? DO NOT consider this strategy. The system being used for the attack might just be another victim whose system has fallen under control of the attacker. Secondly, spoofing can cause mis-interpretation of the source of the attacker. Last of all, there are no legal grounds for an attack carried out for revenge.

Keep a low profile. Be careful not to act in a way that makes the attacker aware of your action. The attacker might react by erasing their footprints or causing more damage to your whole system.

Be familiar with the technical processes and tools available that can make tracking efficient and discreet.

Six Steps for a Security Incident Response

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.

Preparation

Planning allows a top down approach to incident response management to provide an assurance of quality and response time.

Determine the local policies.

Make sure the incident response strategy is consistent with the company security policy and sufficient authority is granted to the incident response team to take specified actions, e.g. switch off company web services in the critical moment.

Define roles and responsibilities of incident response team and parties participating in the security incident handling process.

Define the roles and responsibilities of other company staffs. Communicate this to functional management.

Develop Reporting Procedure, Escalation Procedure and Security Incident Response Procedure. These procedures should be communicated to all employees, including management personnel, for their reference and compliance.

Facilitate early detection, e.g. by building a simple technical environment sufficient for job function and a user-friendly help desk.

Develop and maintain good backup strategy.

Develop and maintain the Call List.

Update with guideline, checklist and tools of HKCERT and other CERT centers.

Develop knowledge and skills of incident response team by training and sharing.

Handle information with reference to the guideline on evidence collection.

Make a full backup of compromised system as soon as you find it a real incident and store it in secure place.

Capture records of incidents, e.g. auditing log, accounting log, etc.

Inform the management and other "Right" people using the call list (IRT, ISP, network service provider…) and call tree (system owner notification). Enforce the "Need to Know" policy and use secure out-of-band communication channel when necessary.

Containment

Activities in this stage may include:

Conducting impact assessment of the incident on data and information of the system to confirm if the concerned data or information had already been damaged by or infected in the incident;

Protecting sensitive or critical information and system. For instance, move the critical information to other media (or other systems) which are separated from the compromised system or network;

Deciding on the operation status of the compromised system;

Building an image of the compromised system for investigation purpose and as evidence for subsequent follow up action;

Keeping a record of all actions taken during this stage; and

Checking any systems associated with the compromised system through shared network-based services or through any trusting relationship.

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:

Shutting down or isolating the compromised host or system temporarily to prevent further damage to other interconnected systems, in particular for incidents that will spread rapidly, for machines with sensitive information, or to prevent the compromised system from being used to launch attack on other connected systems;

Stopping operation of the compromised server;

Disabling some of the system's functions;

Removing user access or login to the system;

Continuing the operation to collect evidence for the incident. This may only be applied to non mission-critical system that could accept some risks in service interruption or data damage, and it must be handled with extreme care and under close monitoring.

Protect computer evidence by moving people out of reach of computer, electric switches, storage media and telephone

Assess the risk of continuing operation and if the downtime might exceed the acceptable level. Management should make the decision based on the recommendation of the IRT on whether the activation to disaster recovery site if necessary.

Keep system owner informed of the status to get their trust and make them feel comfortable.

Eradication

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:

Stop or kill all active processes of the attacker to force the attacker out.

Delete all the fake files created by the attacker. System operators may need also to archive the fake files before deleting to aid case investigation.

Eliminate all the backdoors and malicious programs installed by the attacker.

Apply patches and fixes to vulnerabilities found on all operating systems, server and network devices etc. Patches or fixes applied should also be tested thoroughly before the system is restored to normal operation.

Correct any improper settings in the system and network e.g. mis-configuration in firewall and router.

In case of a malware infection incident, inoculate the malware from all infected systems and media following anti-malware software vendor advisories.

Provide assurance that the backups are also clean to prevent the system from being re-infected at a later stage when system recovery from backup is needed.

Make use of some other security tools to aid in the eradication process, for instance, security scanning tools to detect any intrusion, and apply the recommended solution. These tools should be kept up-to-date with the latest intrusion patterns.

Update the access passwords of all login accounts that may have been accessed by the attacker.

In some cases, the supporting staff may need to reformat all the infected media and reinstall the system and data from backup, especially when they are not certain about the extent of the damage in a critical system or it is difficult to completely clean up the system.

Recovery

The purpose of this stage is to restore the system to its normal operation. Examples of tasks include:

Perform damage assessment.

Re-install the deleted / damaged files or the whole system, whenever required, from the trusted source.

Bring up function / service by stages, in a controlled manner, and in order of demand, e.g. the most essential services or those serving the majority may resume first.

Verify that the restoring operation was successful and the system is back to its normal operation.

Prior notification to all related parties on resumption of system operation, e.g. operators, administrators, senior management, and other parties involved in the escalation procedure.

Disable unnecessary services.

Keep a record of all actions performed.

Aftermath

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.

A post mortem analysis should be conducted to find out areas of improvement, for example:

Checking if the current configuration and procedure are sufficient.

Checking if more user education is required.

Determining if an external security audit is required.

Determining if the incident should require any legal action.

All parties involved should be invited to give comment to the draft of the post mortem analysis.

An executive summary with recommendations for improvement should be sent to management.

The management should assess the report and select the recommendations for improvement to be implemented. Those who report incidents and those who helped to make the incident response successful should be acknowledged or rewarded.

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.