Who ya gonna call?
Updated: May 15, 2018
With the surge in reported breaches, a few questions could be asked...
Has there been a massive increase in the number of attacks and incidents?
Has there been an increase in the amount of organisational security diligence?
Has there been a maturity uplift in organisational attitudes to a data breach?
Whilst definitive answers may not be entirely clear, the changes to Australia's Privacy Laws have created a marked surge in demand for security incident response services.
What are common causes of a security incident?
We commonly see some recurring themes as the root cause of an incident. These include:
1) Un-patched, publicly accessible network devices and services
These are like a lightbulb in the darkness drawing in the moths (attackers).
Sadly, many of the breaches are not even human - they are malware with automated scanning and compromise abilities.
2) Default configurations and passwords
The Internet of Things has shown that TV's and other devices are trivial to compromise, as have been many consumer grade routers. To further aid attackers, these are nicely (and automatically) identified and documented on automated vulnerability search platforms.
3) Insecure, untested web applications
For a variety of reasons web applications are either poorly/quickly/incompletely designed, leading to defacement, compromise of data, bitcoin mining, malware propagation etc.
Mitre's Common Weakness Enumeration (CWE) project Top 25 is a larger list of where (and when) things can go wrong, as is the Centre for Internet Security's Critical Security Controls for tips on key security controls.
Considerations for acquiring a security incident service
1. Fitness for purpose and specialisation
Ultimately, not unlike insurance, the service should match the need (and size, nature and operations of the organisation).
Having a crack team of cyber incident warriors on 24x7x365 standby could be overkill if you are a small traditional retailer with a small number of customers, whereas if you process thousands of realtime financial transactions and your business supports most of the country it may not seem unexpected.
Some key things to understand are when your business critical time(s) are, what your appetite for loss/outage/risk is and what other controls (e.g. insurance) may be possible.
2. Breadth and depth of experience
Not all organisations and technologies are the same, and a standard local windows environment will require a very different set of skills to those needed for Cloud, UNIX or SCADA.
It is therefore important to ensure that anyone you partner with has sufficient knowledge, experience and understanding of your environment. Without this, precious minutes and potentially masses of data (or funds) can be impacted.
3. Coverage and scale of services
A security incident response service that cannot scale out or is too restricted in what it can do means managing (juggling) other vendors and involving yourself in complex inter-organisational process flow mapping (who hands off to who, will they talk to each other etc etc.)
It is far better to have a partner that can perform (or source on your behalf) most of the services required in an incident. (e.g. Vulnerability Scanning, Threat Intelligence, Data Analytics, Log Acquisition etc etc)
Consider also geography and size. A partner that is based only in one location may take a lot longer to respond, as will one with too few incident responders.
What are the gaps, gotcha's and fine print to be aware of when engaging a service?
(At the risk of being uninvited to some industry events), Here are some things to be aware of and ask before signing an agreement with an incident response service:
1) Does the service consist of security incident management, response, digital forensics, secure evidence storage, expert services, security consulting or all of the above.
As many of these will be inter-related but distinct (and with potentially significant price differences and outcomes) it is important to understand what you are getting day 1, and what (should you need it) can you draw upon.
2) Is the service suited to your most likely incidents?
A service provided by a digital forensic specialist may give a client the best possible chance to properly acquire and protect digital evidence for use in court but not have the depth of cybersecurity expertise required to analyse, manage or coordinate a complex incident.
3) As a client, what support / systems / services / access / resources / dependencies / interactions will be required from our internal teams or suppliers, and do we have access to these on the same basis (e.g. 24x7x365) to support an investigation. This could include things like: on-call arrangements for operational staff, legal, HR, Internet service providers.
Having the greatest response service available does not offer much consolation if (for example) your investigator(s) cannot access the building/datacentre or environment where the incident has occurred.
4) Are there any requirements or pre-requisites (e.g. network access, asset databases, etc) needed to actually utilise the service, e.g. software which needs to be pre-loaded onto every IT Asset. Also, are there any expected costs (in addition to the service) and what are they?
It is also important to understand the range of services offered and any specific limitations (e.g. the service only supports Microsoft Windows).
5) What other services and contact information should you have in your address book to assist in responding to an incident.
In addition to your extensive internal list, this could include contacts such as:
External Application Developer(s)
Building and Facilities Managers
Telco and ISP
Software and Hardware Vendors
Data Centre Manager
Regulator(s) and OIC
Key clients & business partners
6) Does the service offer any proactive or pre-emptive services?
As an example, will they work with your teams on simulations, walkthroughs, development of rapid response material, provide open source intelligence gathering, perform external vulnerability assessments or penetration testing etc?
7) Are there circumstances where the service provider cannot or will not provide the service?
These could include things such as legal constraints, conflicts of interest, resources being overwhelmed or unavailable, lack of skills or experience in the Technology, Language, Location, etc, etc
For these reasons, it is not uncommon to have more than one service provider on retainer.
What makes a good security incident Service?
Ideally, a good service will:
1) focus on helping you quickly and efficiently investigate and contain an incident
2) help you restore services, network / platform integrity and stakeholder confidence
3) provide a straightforward, thorough, independent and pragmatic view of the event and its impact(s)
4) provide timely and useful advice on how to improve the organisations defences to prevent issues from recurring
5) be methodical and follow a structured approach for response and coordination of an incident
6) leverage their experience of previous investigations, as well as yours and relevant partners
7) provide (or have partner access to) forensic specialists and court recognised experts
8) take an interest in your ongoing security needs, helping you to prevent security incidents
9) work with your service provider(s), insurer(s), law enforcement etc at your direction
If your organisation is interested in understanding more about eSecures incident response services please Contact us
Author: Clinton Smith