How security incidents can be identified 

The best-case scenario when dealing with a security incident is that your organisations incident management system alerts you to an attack, or an attempted attack, immediately.

That way, the process of dealing with an incident can get to work before the damage is allowed to progress. Arguably the worst-case scenario would be to find out that there’s been an in incident from an outside source, such as the hacker themselves, a client, or a breaking news story. Can you think of any news stories with data breaches and security concerns that you’ve read about recently? Or have you worked in an organisation that suffered an incident? What happened? Think about what might have been done to amend the situation.  

Identifying security incidents

There are many ways to identify that an incident has occurred. For example, technical protective measures in the IMS process can alert the IT Team to a system virus infection, or the enterprise antivirus system recognises a virus and begins the quarantine process on infected machines. At the same time, the antivirus server sends an alert to the security operations team which initiates the incident management process. 

These types of identification measures ensure the Information Security Manager can recognise that an incident has occurred.  

The process includes the following steps: 

1. Reporting 
2. Investigation 
3. Corrective action – incident response 
4. Assessment 
5. Review 

In other cases, notification of an issue might come from an external source. For example, a data leak might be reported in a national newspaper. According to Security Magazine, 2021 was a record-breaking year for data breaches, one of which being over 100 million Android user’s data being exposed online due to several misconfigurations of cloud services. In cases like this, the incident management process begins at the investigation phase.  

However, if plans are already drawn up, it’s much easier to manage the response and limit the damage and put actions in place to stop the incident from happening again – these will be informed by the report. Time to find out more about the reporting considerations now. 

Reporting  

The incident report should contain all the relevant identification information to investigate, assess and close the incident.  

Typically, the report form would be protectively marked as Company Confidential, as it may well contain sensitive information relating to system vulnerabilities or sensitive personal information which, if in the wrong hands, could be used to do more damage to the organisation.  

The report should include: 

• All points of contact, including the investigative authority, the investigating officer, the information release officer and the security manager 
• A summary of exactly what the incident was and what impact it had on the organisation – following the who, what, where, when and how principle

Conclusions, including: 

• A root cause analysis 
• How the incident could have been prevented 
• The impact it had on the organisation 
• The estimated costs and damages 
• How the incident could be prevented from re-occurring
• What additional remedial work is being carried out to ensure the incident doesn’t happen again 

What’s next? 

Next, you’ll take a closer look at the incident management process and find out what each stage consists of, and what considerations need to be made in order to create a process you can trust.