This is the fourth article in a series that aim to help organisations build and maintain their information security incident management and response capability.
In the previous article I provided a bird’s eye view of the standard incident handling process. As noted previously, the incident handling process is triggered either by detecting or reporting security events. A number of security professionals believe that detecting an incident means looking for failure logs such as failed login, failed resource access etc.
While these might be incident precursors, they are not the actual incident. A real incident will generate success events, if auditing success events is enabled. For example, if an attacker manages to get a foothold in an organisation, you might come across a few failed login events that are in fact proofs that your access controls work. However, it is the success login event that might have occurred outside business hours (e.g. at 3 am) that is the actual indicator that points to the incident.
Another common approach among professionals is looking for anomalies in the organisation’s ingress filtering logs (e.g. firewalls or load balancers logs) for indicators of unauthorised attempts/access. Arguably, your egress logs are more likely to show connections from compromised hosts or insiders to the outside world.
A common challenge that security teams face is the size and diversity of logs. That is why a lot of organisations tend to look to Security Information and Event Management (SIEM) solutions for answers. While correctly configured and maintained SIEM solutions should help in correlating log events and identifying incidents that come from multiple log sources, they are expensive, require time to deploy and configure, and must be maintained and tuned continuously. Threat intelligence and specialised security products that look for indicators of compromise are another option, however, these also can be expensive to obtain and maintain. Therefore, those who cannot afford the luxury need to find a “quick and dirty” way to sift through logs and other available artefacts such as service desk tickets to detect incidents. It is worth noting that manual detection of incidents is still rated among the top methods of detecting breaches, if not number one.
Given limited budgets and the limited number of capable security staff that are available to detect incidents, some organisations choose to wait for incidents to be reported. Considering the increased median time to detect incidents (several weeks as per a number of 2016 reports – e.g. Verizon 2016 DBIR), that cannot possibly be a good approach. Users are also shy on reporting incidents for a number of reasons including the concern of being blamed, lack of awareness and other equally valid reasons. So unless you really believe that you have had no incidents, or are prepared to accept the risk of being compromised for a long period of time before knowing about it, you need to start immediately considering your incident detection options.
Currently, it seems that a lot of organisations are stuck and forced to accept the risk of being compromised without detecting it, even if they do that without acknowledging it. If you are looking for a “quick and dirty” way to detect incidents, then there are a couple activities that you can do immediately to improve your incident handling capabilities. I suggest that you start by providing technical team members with some relevant incident handling training. That does not necessarily mean turning them all into seasoned incident handlers; basic incident handling training for technical staff including your service desk team members should be enough. However, upskilling a couple of your technical team members to a higher level is a good idea. It is also equally important to have a mature incident handling process. For example, it is fairly common for technical people to miscommunicate incident information with management, especially while the incident is ongoing. Providing missing information or premature conclusions on incidents could lead to incorrect management decisions. Accordingly, it is important to consider within your incident handling process how to communicate incident details with management.
Once your staff have their basic skills uplifted and your process is in place, you need to make sure that you don’t put their skills and the process through its first test run during a real incident. To hone your team and the process, a tabletop exercise is an excellent way to ensure that the process works as expected and that staff have exposure to the process without also having to deal with the fall out of a real incident. Tabletop exercises are staged incidents that help train people on the incident handling processes and provide assurance to stakeholders that the organisation is able to detect and respond to incidents.
In conclusion, incident response is a risk management activity that, amongst a few other controls (e.g. disaster recovery), attempts to manage the impact of risks. So imagine your most critical business system is compromised and think about your organisation’s capabilities in responding to that. If you think that your business is not ready to manage the impact of that risk, then developing your incident response capability should probably be a high priority.