I was asked an interesting question by a consultant during a recent Pen Testing workshop. He wanted to know whether an external consultant who identifies a flaw/vulnerability should just document it or go a step further and recommend solutions.
Later I received a similar question from a friend who is part of an Incident Response Team (IRT) in a large organization — should they just document the issue, or make suggestions to the top management?
It’s an excellent question, but before we answer, we should first discuss the role of an IRT and what ‘incident’ means in this context.
What qualifies as an incident?
There are several definitions available, but generally speaking, an event is anything that occurs that’s relevant to your cybersecurity situation, whereas an incident has more malicious or negative connotations.
It might be a data breach, unauthorized access to resources (databases, application servers, and so on), a malware infection or some kind of hacking or attack. They do not have to be deliberate — an accidental data breach can count as an incident as well.
When an incident occurs repeatedly, we can call that ‘a problem’. A wise person once said, when you repeat a mistake, it is not a mistake anymore but rather a choice. Similarly, when an incident is not completely resolved and it repeats, it is considered a problem.
Naturally, if organizations need to worry about incidents (and ensuring they don’t become problems), they need people to respond to them. This is why they have IRTs.
Who should be in your IRT?
The size of your IRT depends on a lot of factors. In a small organization, there may not even be one dedicated cybersecurity specialist, and it’s something that other staff members handle as part of their duties. As the organization grows, it will eventually need dedicated cybersecurity staff.
The nature of the organization and the threat landscape it faces will also determine what the IRT looks like. Members will typically come from an IT background, but this isn’t always the case — dealing with malicious activity from internal staff might require HR specialists, for example. Legal teams may be consulted when declaring incidents to stakeholders.
There is no one-size-fits all description for an IRT.
What do IRTs actually do?
There are standard checklists and formal report templates developed by organizations that are completed, compiled and followed as standard operating procedure by their IRT while dealing with an incident.
Typically, the team will identify affected resources/assets and stop or mitigate further damage if the attack/breach is still in progress.
The specifics will vary from organization to organization. From my own experiences, they typically cordon off the affected area and make a list of all the concerned employees/staff who are associated with those assets/resources in any form.
They also speak with witnesses and gather as much information as possible about the incident to include in their standard reporting template, so it is available for easy reference. Preservation of victim resource/asset is also very important, so the team should be trained enough to know how to preserve an asset without any tampering — this is also needed in cases where the incident ends up in a courtroom and is required to be admissible as evidence.
Further investigations involve analysing the information, and sometimes calling on external support. This may involve requesting more technical documentation from the vendor, outsourcing to a specific skilled consultant or seeking opinion/help from industry experts. Help can also be obtained in some cases from state/federal authorities if your organization’s expertise level is inadequate.
And, of course, in some cases management needs to weigh in on the problem.
What about recommending solutions?
I can’t speak for everyone — this will be determined in part by the nature of the team and its relationship to the organization. But in my humble opinion and experience, the IRT has done its job once the root cause of the incident is identified and comprehensive information about the incident is acquired and compiled.
Going further, providing solutions or recommendations may cause complexities both from management and technical perspectives, and in some cases may become a conflict of interest.
Aside from the difficulties for the IRT making recommendations about work and procurement they are then likely to be tasked with carrying out, there are also potential issues associated with the fact that management may have more information than the IRT. There may be issues associated with proprietary information or trade secrets that the team is not aware of.
This means the IRT does not have a complete picture, so remedial solutions should be left to management to explore, based on the team’s incident findings.
There are also technical reasons to support this approach, however, it is not a mandatory practice followed by every organization.
Thanks for reading this blog post. Please keep learning and broaden your knowledge using APNIC resources!
Azhar Khuwaja is a Telecom/IT Trainer with over 20 years of industry and training experience.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.