No matter how much money and time you spend on trying to avoid and prevent a cybersecurity incident, it is inevitable that one will occur. Our mindset must be “when” and not “if” because it really is just a matter of time before something happens, whether it is our fault or not. When I was learning to ride motorcycles, I learned that there are only two types of riders: those that have crashed and those that are going to crash.
The difference is preparedness, and we tend to spend too much time and money focusing on the “before” of an incident and precious little on the “during” and “after” an incident occurs. Hoping for the best but preparing for the worst is just good practice, and like my investment in a great helmet, boots, gloves, and leathers, your investment in “when it all goes wrong” can limit the extent of damage during a cyber event.
Every business is different, so I emphasise getting the right people involved and asking the right questions to align your incident response with the objectives and requirements of your organisation. You may already have a Disaster Recovery (DR) plan and may even have a Business Continuity (BC) plan (often known as DR/BCP), but an Incident Response (IR) plan should be a broad, end-to-end investment that covers the who, what, when, where, why, and how you fix the inevitable situation you will one day find yourself in.
A good IR plan is not a one-size-fits-all solution because your incident could be anything from a nuisance to a catastrophic system failure and loss of business. Instead, we play the odds and probabilities game to consider what could happen to us and what we can do when it does.
The Australian Cyber Security Centre (ACSC) Information Security Manual (ISM) contains a wealth of valuable information you can leverage, and controls and advice for IR is certainly part of it. As part of the ISM and available as a separate publication, I recommend reviewing the “Guidelines for Cyber Security Incidents” as a starting point. In this article, I’ll cover some of the key controls with commentary and encourage you to reach out to me any time with questions, comments, and concerns.
Before we start, there are three sections, and each contains a series of controls anyone can adapt to their specific business or enterprise, or even government department. The sections are broken down into Detecting, Managing, and Reporting cybersecurity incidents. Let’s begin, shall we?
Detecting Cyber Security Incidents
Before we can solve a problem, we must be able to discover what it is and what it involves. In my decades of experience performing vulnerability assessments for organisations, a lack of visibility became a recurring theme. The ISM contains four controls that assist with detecting incidents.
Control 0120, Revision 5, August 2019: Cybersecurity personnel have access to sufficient data sources and tools to ensure that systems can be monitored for key indicators of compromise.
This is a loaded statement, but when you unpack it, it makes perfect sense. You must equip your business and personnel with the tools, experience, training, and support to defend against cyber incidents. Invest wisely, review regularly, and always watch for gaps and overlaps. As it stands, we have too many layers, technology that doesn’t integrate, and disjointed processes. An assessment from a trusted advisor that focuses on your state of readiness is a good start. Indicators or compromise shift and change, but they exist, and having the tools and talent to find them is a wise investment.
Control 0576, Revision 7, August 2019: An intrusion detection and prevention policy is developed and implemented.
This control can quickly lead you to assume you need an actual Intrusion Detection / Intrusion Prevention System (IDS/IPS), as we commonly find on next-generation firewalls and security appliances. Be that as it may, it only addresses part of the issue because we mistakenly consider products as “solutions” without a policy to explain why and how point solutions are useless. In short, figure out what we’re looking for first and how to do it, then find a best-fit product to complete the solution. The operative words here are “policy”, “developed”, and “implemented”. Think of it like talking the talk and then walking the walk.
Control 1625, Revision 0, November 2020: A trusted insider program is developed and implemented.
This control speaks more to secure administration of your greatest assets and biggest liabilities: people. A trusted insider program is developed in conjunction with your leadership, human resources, and legal teams to define roles, responsibilities, and governance of “who is doing what / what they are accessing and why / who is trusted” and the usual enforcement / consequences / support needed. Trusted Insider means more than just having access to the system; it’s also about responsibility and accountability with checks and balances along the way.
Control 1626, Revision 0, November 2020: Legal advice is sought regarding the development and implementation of a trusted insider program.
Following on from control 1625, it is imperative that you have legal input for these types of policies. I am not able to offer any kind of legal advice, and I rely heavily on legal teams so we can get policies right. After all, we are dealing with often sensitive and private information, and there are plenty of laws and regulations around its use, so be kind to your legal team as they can save your bacon — often without you realising it!
Managing Cyber Security Incidents
The ISM provides seven handy controls you can implement in your organisation to help deal with the inevitable security incident you will one day face. How you implement them is up to you, but I strongly recommend getting advice and consultation from an experienced cybersecurity advisor and their team on how to manage the governance of the following items.
Control 0125, Revision 4, August 2019: A cyber security incident register is maintained with the following information:
· The date the cyber security incident occurred
· The date the cyber security incident was discovered
· A description of the cyber security incident
· Any actions taken in response to the cyber security incident
· To whom the cyber security incident was reported.
Keeping track of everything you can is crucial in the “during” and “after” phases of an incident so you can respond to and recover from the event. The five bullet points are by no means a complete set of the data you will capture, but the more information you have at hand, the better. People get focused on the minute details of the moment and often overlook the bigger picture, so capturing these details as a matter or priority can provide insight to anyone assisting and can come in handy for forensics or legal review after the fact.
Control 0133, Revision 1, September 2018: When a data spill occurs, information owners are advised and access to the information is restricted.
I often speak about the three types of threat actors being malicious outsiders, malicious insiders, and well-intended insiders. During incident identification and containment, you want to keep the channels of communication controlled, secure, and accurate. It’s at this point that a malicious insider may seek to alter data and cover up their tracks or exploit volatile information, and well-intended insiders may seek to “help” or inadvertently interfere in the handling of an incident. Keep stakeholders informed, but limit the data and access to a small but trusted group.
Control 0137, Revision 2, September 2018: Legal advice is sought before allowing targeted cyber intrusion activity to continue on a system for the purpose of collecting further information or evidence.
It’s tempting to close the door as soon as you find out about an incident, and that is often the first course of action, but it can also be a premature activity. When you discover an active incident, often the damage is already done — we’re almost always late to the party. If we slam the door shut, we may tip off the attacker, and they’ll go to the ground, but if we permit the activity to continue in a limited scope, we may gain insight into who it is and what they’re doing as well as how. That said, it’s a risky move to leave the door open, so always check with legal about the possible implications.
It may be a valuable exercise to gather forensic details, but it also may allow the incident to escalate and cause irreparable damage. As part of your planning and policy, may I recommend this very activity as a crucial decision point — risk versus reward.
Control 0138, Revision 4, August 2020: The integrity of evidence gathered during an investigation is maintained by investigators:
· Recording all of their actions
· Creating checksums for all evidence
· Copying evidence onto media for archiving
· Maintaining a proper chain of custody.
Preservation of evidence in cyber forensics is a crucial step in incident response, and that includes the actions taken by the people responding. The information must be accurate and non-corruptible because even something as incorrect as log file data or the date and time an action was taken can ruin the entire timeline. Keeping copies as well as originals can allow investigators to run analysis and tests on evidence without corrupting it, and backing everything us is paramount. Really, if you ask me, this level of meticulous detail should be no different than any other type of criminal or civil case.
Control 0917, Revision 7, October 2019: When malicious code is detected, the following steps are taken to handle the infection:
· The infected systems are isolated
· All previously connected media used in the period leading up to the infection are scanned for signs of infection and isolated if necessary
· Antivirus software is used to remove the infection from infected systems and media
· If the infection cannot be reliably removed, systems are restored from a known good backup or rebuilt.
This control assumes you have capabilities in detection, and the sooner malicious code is detected, the better. Just the same, if malicious code is detected after the fact during analysis, the same steps should be taken to prevent dormant code from being activated in the future by another exploit or an automated “time bomb” process.
Isolation of the system is a good first step, and that usually means just shutting down any communications capability, wired or wireless, they have. Don’t overlook things like mobile data sims or Bluetooth, either, as there are more connections than Ethernet cables and Wi-Fi networks. Looking at media previously connected, whether shared drives, cloud storage, or portable media like USB sticks, portable hard drives, memory cards, and more, makes sense as they may have become infected, and this can prevent spreading malicious code. In some cases, this media may have been the source, so it becomes a race to find the origin working our way backwards.
Antivirus software, or in this era, Endpoint Detection and Response, is the go-to for cleaning up some elements, but they may not catch everything. Threat hunting and other specialised tools can help sanitise your system. And finally, if all else fails, wipe and restore the infected systems. You DO have a reliable backup and a tested process, right? Right?
Control 1213, Revision 1, September 2018: Post-incident analysis is performed for successful targeted cyber intrusions; this includes storing full network traffic for at least seven days after a targeted cyber intrusion.
It makes sense to keep an eye on things once an incident has “passed”, so keeping a log of events and capturing traffic is a good way to gain some comfort that you’re in the clear. This control also assumes you have accurate information on the targets and that the threat has been neutralised because if you monitor one system only to find another playing “silly buggers”, you’re still in the thick of it.
Post-incident analysis is a must-do because, as the old expression goes, those that don’t learn from the past are doomed to repeat it. Or words to that effect, as long as you properly clean up, analyse, and learn from an event.
Control 1609, Revision 0, August 2020: System owners are consulted before allowing targeted cyber intrusion activity to continue on a system for the purpose of collecting further information or evidence.
As tempting as it is to let an incident continue for the purpose of forensic evidence gathering, some system owners are not very understanding. I get their point, though. System owners don’t give a hoot about learning; they just want the incident to be over and to be secure. Honey pots are a good choice, but truly skilled cybercriminals can detect them. Whichever course of action you choose, make sure stakeholders are on board. Allowing an incident to continue for evidence gathering without support or knowledge of system owners is not an acceptable interpretation of “it’s better to seek forgiveness than ask permission”.
Reporting Cyber Security Incidents
With increased scrutiny, public awareness, and laws in place, reporting incidents is now just as important as detecting and responding to them. It is foolish to believe that an incident occurs in isolation as it likely impacts others directly or indirectly. Also, consider the General Data Protection Regulation (GDPR) in the European Union since May 2018, and the Notifiable Data Breaches amendment to the Privacy Act in Australia since February 2018.
Some businesses and individuals are more concerned about damage from reporting an incident when they should be more concerned about damages from NOT reporting an incident. Too often, we focus on playing the blame game before resolving a problem, and the fear of what can happen from reporting an incident is very real. We just need to do the right thing and be upfront, reporting incidents no matter how insignificant we think they may be. Unless you understand the full scope and impact (which nobody ever does), then it’s time to raise your hand and ask for help.
Control 0123, Revision 3, September 2018: Cyber security incidents are reported to an organisation’s CISO, or one of their delegates, as soon as possible after they occur or are discovered.
“If you see something, say something” is a long-running expression for awareness campaigns, and for cyber incidents, it has merit. As soon as you get a whiff that something is funky, report it. Many organisations may not have a CISO as a position, but they usually have it as a role with the responsibilities spread among several individuals. As part of your onboarding and planning, everyone in the business should know their reporting chain and, if not, just tell someone they trust to take it onwards. The sooner the business is made aware, the sooner it can respond because time is critical.
Control 0140, Revision 6, May 2019: Cyber security incidents are reported to the ACSC.
No matter how small or big an incident maybe, I would encourage you to report it. Remember that what you report may not be the incident itself but could be a side-effect or even probing by a threat actor testing an organisation’s defences. Think of it like “where there’s smoke; there’s fire”. The ACSC may be able to quickly respond and assist if it has the information needed and every bit count. Report every cyber incident.
Control 0141, Revision 4, July 2020: Service providers report all cybersecurity incidents to the organisation’s CISO, or one of their delegates, as soon as possible after they occur or are discovered.
Service providers, in this case, can be a subjective term but treat them as associates or connections of other organisations they have a responsibility to protect. It could be an Internet Services Provider (ISP) and Managed Security Services Provider (MSSP), a vendor, a consultant, or a government agency. If they provide a service, they should report incidents. It may not be a CISO per se, but it will be the role and the responsibilities. I cannot emphasise enough how important incident reporting is.
Control 1433, Revision 2, July 2020: Organisations and service providers maintain 24x7 contact details for each other in order to report cyber security incidents.
Knowing who to call in order to report a cybersecurity incident is critical when time is of the essence. As an individual or as a business, you and all other stakeholders should keep a list of who can be contacted when an incident occurs. A contact list on your mobile, a physical printed list that is regularly updated, or even a hotline or help desk is important information that must be kept handy.
Control 1434, Revision 2, July 2020: Organisations and service providers provide each other with additional out-of-band contact details for use when normal communication channels fail.
Always have a backup plan, and that includes your channels of communication. If you rely on email, have an alternate method to message people, and that could be Microsoft Teams, Mobile SMS, Facebook Messenger, anything at all that can be reasonably secure. Landline telephones, anyone? Yes, they still exist — even multiple devices on multiple networks from multiple providers. Always have a backup, and that includes your communications. Imagine being in the middle of an incident and being unable to call for help. Scary thought, isn’t it?
Incident response is an intimidating subject because we never want to be caught in the middle of an incident, let alone be forced to respond, but reality does not provide alternatives. Having a proper plan in place supported by the right people and systems can make all the difference in the world. If you’re unsure where to start or if it’s time to review your plan to make sure it’s up to snuff, let me know, and I’ll do my best to help or at least point you in the right direction.
Stay safe out there.
Disclaimer: The thoughts and opinions presented on this blog are my own and not those of any associated third party. The content is provided for general information, educational, and entertainment purposes and does not constitute legal advice or recommendations; do not rely upon it as such. Obtain appropriate legal advice in actual situations. All images, unless otherwise credited, are licensed through Shutterstock.