Screen Shot 2019-10-24 at 3.42.51 PM

On the week of 7th October 2019, I attended the Australian Cyber Conference, #cybercon2019, in Melbourne, Australia, hosted by the Australian Security Industry Association in conjunction with the Australian Cyber Security Centre. I will be sharing my top lessons from the event over a series of articles in the coming days, starting with incident response.


Incident Response Lessons

1. Plan Offline / Analog Incident Response Capabilities

During cyber response incident that the internal corporate network may no longer be available and every aspect of this must be considered in relation to proper incident response planning. Craig Morris from IBM Security discussed a ransomware attack on Maersk's oil operations which resulted in a complete shut down of their international comms network and the fallback options resulted in employees using private mobile devices and WhatsApp instant messaging application to connect with business units around the world. Additionally the incident meant that many processes had to fallback to paper processes and fax machines!

  • Do you know where your nearest fax machine is?

  • Do you have sufficient pens and paper in the office if you had no digital systems?

  • Do you have a hard copy of your employee contact information?

2. People are Important to an Incident Response - Consider Them in Your Plan

    • Consider the food and beverage requirements which could be needed for the incident response team when working in the office for extended hours for multiple days.

    • Consider accommodation options near to the response site where team members can travel to get rest but avoid longer commutes to their home as well as if the team members have to travel to the response location, avoids wasting time booking hotels.

    • Set limits on how long each individual can work before having a mandatory break, the risk of burn out or making critical errors during high stress response is increased.

    • Provide transport to staff who are working extended hours so they do not have to drive while fatigued and overwhelmed with the incident at hand, reduces their risks.

3. Your IT Team is Not a PR Team

Don't let the IT team handle communications externally during an incident response or post incident. The messaging used directly impacts the brand equity and must be managed by experts in this space, engage a legal team and communications team as appropriate and seek expert advice on what to say and what to not say, leave this to the experts as the IT team may provide far more information or detail than is needed or present it in a manner which damages the brand.

The experts will ensure they use language which is open, transparent and reassuring. The aim is to avoid creation of panic and rumors, or to give the media a front page news story at the cost of your brands reputation due to a cyber incident.

4. Suppliers, Vendors & Contractors

Have you considered your supplier, vendor and contractor arrangements when building your response plan? These entities are often crucial to business operations and without looking at how they might be affected during an incident which occurs at your business, there can be a large gap in the response plan which is only apparent in a real world response situation.

  • Do they access your servers or data? How will they be affected during an incident?

  • What are your obligations to inform these entities during a cyber incident?

  • Have you considered free services which do not have a cost but are used often?

5. Isolate the Incident Response Team

An incident response team should work as a stand alone unit of the business until the incident is resolved, this avoids influence from executives in the business as well as reduces the risk that people outside of the IR team are aware of information before they need to be informed about the details of what has occurred. Limiting the flow of information in a crisis can be good if the information does not benefit the response team, and limiting influence of those on the IR team is important to ensure an efficient response to the incident occurring.

Additionally if the source of infection was through others in the organization, you will want to avoid introducing any vector for the threat actor to access the IR teams systems or give them any visibility what is occurring internally in the response, such as messaging apps.

6. Document Changes and Organization Updates

Post incident, there may be a number of changes which have been made to configurations, systems, logins and other elements inside the organization. It is important to ensure this is documented and updated where appropriate and not overlooked in the rush of response. If teams need to be informed so that documentation can be amended, ensure this information is sent to the appropriate places and recorded.

Additionally this will be a useful tool to review what the previous state of the environment was and what has been done since the incident to remediate and prevent future incidents, this can be used for the benefit of other teams, organizations and helps reduce future changes which may go back to a previous worse state of security and is often overlooked post IR.

7. Real World Testing

Often the testing of incident response plans is not real world, only covers a segment of a business, its team, its infrastructure or some other gap. Much like when a fire drill is conducted on an office building and where staff do not leave the building, the real capability to respond has not been tested and in a real incident there could be gaps which become obvious that did not show up in testing. This applies to cybersecurity and it is essential to test the plan in a real world situation, in a worst case scenario and identify any gaps which exist so they can be fixed before the real world response is needed for a real cyber incident.

  • What other vendors might need to be engaged in a real world response? Include them in your testing and don't assume that the relationship will work as planned

  • Shut down entire environment and turn off the power if required, make sure that the testing covers everything and does not skip any systems because its inconvenient.

Want to learn more about incident response and how MSPs can better protect their clients' data? Register for our next APAC Continuum Fortify Demo Day on 11/12