I want to talk briefly about incident management. Any cloud-based application that is exposed to the internet has a very high probability of being hacked and hence must have a very good incident management process in place. A good incident management system must clearly define the procedures to be carried out in case of a breach.

Also, we need to make sure that there is a clear-cut process for the timely reporting of information security events to the security department, so that they act on it. The internal audit team must make sure that there are processes in place that ensure the security department act on each and every event that is reported. In many cases in spite of weakness being spotted by an employee, or the beginning of a hack being reported by the monitoring system, the hack was not prevented 'till much damage had been done. This was because the security department was understaffed and was not able to handle the number of events that were being reported.

The management needs to ensure that such situations do not arise. As soon as an incident is detected and reported, the next step is to analyze and triage it. Triaging is the process by which the severity is assigned to the incident. As I have mentioned, prioritization is very critical in security. The higher the risk, the higher the attention the incident receives. Once an incident has been triaged and a severity assigned to it, it is transferred to the appropriate team to be handled. The next step is to contain the incident.

For example if the incident is one where an employee's computer has been infected by a virus, the step to contain it is to remove it from the network, so that it can do no more damage. Once contained, the next step in the incident process is the eradication and recovery. In our previous example of an employee's computer being infected, we need to either delete the malware or reinstall the computer. This is the recovery phase. The next step is to do a root cause analysis. The security group usually does this by analyzing logs and interviewing employees to find out how the employee's computer was infected and what could have been done by our security processes to prevent it. This is where we take a good look at the existing processes and see where it failed and suggest improvements to it. This is the root cause analysis document. The next step is the review process. This is where we take the suggestions laid down in the root cause document and make changes to our security processes.

These, very briefly, are the steps in the incident management process. A couple of key points while designing the incident management process. We need to make sure in case the hack is very severe and law enforcement needs to be involved then the evidence needs to be preserved. If the company is planning legal action, then it is very important that the chain of custody of the evidence is preserved, so it is very important that a chain of custody process is clearly defined, and the incident response team is aware of such a process.

Another key point to note in an incident management process is to do regular dry runs. Many good incident management processes fail, because employees as well as the incident management team do not have the steps at their fingertips. The team needs to know the steps in the incident management process by heart, and this is best to do, keep doing regular dry runs. This will also point out practical problems in the process which can be corrected without having to figure out this when the actual incident happens, so plan regular dry runs with the team.

Write out scenarios of the attack and have the team train on various situations. In one case, the server could be hacked and the home page defaced. In another scenario, there could be data stolen. This kind of variety needs to be in the various test cases, and I want to stress again the real strength of an incident management process lies in the practice that the teams have. The best thought out incident management plan will not be as effective if the teams are executing it for the first time during the incident.