Despite the efforts of the architects, engineers and defenders in the cybersecurity department within an organization, something will make it through. Whether it be a phishing email, malware or other malicious or unwanted outcome, it is imperative that cybersecurity professionals and business leaders prepare appropriately. This is a time where the adage of "not 'if' but 'when'" is most applicable.
Pragmatically, defensive security is more difficult than the offensive counterpart. Cyber defenders need to be right via prevention almost every time. They need to be ready to detect quickly when the deterrent or preventative measures fail. From the perspective of business - via continuity, operations, liability and reputation, there are a few steps that will be immeasurably important to acting rationally when an event or incident occurs that throws the organization into chaos.
The idea for this comes from my time in the military. Beside every phone was a bomb threat checklist. This was a list of actions to take and questions to ask if someone called in a bomb threat. Through some internet searching, I was able to find one from the Department of Homeland Security online and another in the Marine Corps directive for dealing with such threats. These steps are meant as a starting point to implement within an organization to help provide the most timely and accurate information to the incident response team or cybersecurity directorate to enable them to act with as much precision as possible.
Define Who To Contact
Often times, people are not directed to contact anyone in specific. This leaves a lot to the existing knowledge and imagination of the victim. It is important to give non-technical employees a phone number, email address (not ideal if a malware infection is suspected or if the victim of a phishing attack), chat, Slack or other means of communication to report suspicious behavior. While designating an employee to contact may be prudent in small organizations, this will likely not scale well and may cause negative outcomes in larger organizations, outside their working hours or if they are out of the office. Designating a team, shared email list or hotline number is likely the most prudent method to address this.
Define How To Contact Them
As alluded to earlier, the organization should define how to contact this point of contact. If there is a suspected piece of malware, suspicious activity or a potential phish to report, doing so via email may compound the issue at hand, especially if the attacker can (and is) reading emails. Having the forethought to define how to report such issues is critical. Set up a phone line, an out of band chat like Slack, or if the organization is small enough, instruct employees to walk over and report the incident.
Define What Steps To Take With The Computer
Almost as important as reporting, are the actions to take. Depending on what the organization's incident response plan and other associated policies and procedures direct, there is a multitude of actions that users could take when they suspect something malicious happening. Depending on the digital forensics (also known as cyber forensics) posture and capabilities of the organization as well as any requirements enacted via regulatory compliance, law or membership in any groups or ISAC (Information Sharing and Analysis Centers), the organization may seek to collect forensic information about the incident before restoring normal operations. If this is the case, powering a system off or restarting the system may lose some forensic data. Below are some of the options and potential outcomes:
- Do nothing: This is the best action if containment is not a concern and if the organization plans on conducting forensic analysis. The lack of containment will potentially allow the actor to move to other systems in what is called pivoting. If the user has to leave the computer and does nothing, someone could potentially do something (for good or bad) on the computer and have it attributed to that user.
- Take a picture or video with a phone: If a window pops up or any other suspicious activity (like remote control of the mouse), the user could take a picture or video with their phone and send to the point of contact (via Scott on Twitter) if allowed by company policy.
- Log off: This will do little to stop the attacker but can prevent other people onsite from performing actions on the computer as the user. This option offers no containment, but maybe a better option than doing nothing, unless the attacker changes the user's password and locks them out.
- Lock screen: This is almost the same as logging off, except it may prevent or complicate any cybersecurity or incident response staff from logging into the system remotely. It is worth noting that if the organization plans on forensic analysis, most analysis will be done at the computer, vice remotely (in the absence of agents like that in Google Rapid Response for example).
- Sleep: This option will put the computer in a low power state but should preserve the memory. The downside to this is that it does nothing for containment and the attacker can possibly take action to "wake the system up."
- Hibernation: Is an option similar to sleeping, but will write the contents of memory to a hard drive and put it in a hiberfil.sys file (on Windows), which can be forensically analyzed nearly identically to memory.
- Reboot/restart: This option may solve the problem if a rapid restoration is the desired outcome. If the organization plans on doing forensic analysis, this will dump the contents of memory and possibly kick the actor off the system. If the attacker has installed a backdoor or implanted another form of persistence, this will only complicate the efforts of the cybersecurity team without providing any containment.
- Disconnect the system from the network: This can be tricky if users are on a wireless network. If on a wired network, I recommend using a uniform color of network cabling so that all employees know to pull (or even cut with scissors; via Ryker on Twiter). If using a wireless network, it is imperative that users are trained on how to disconnect from wireless networks.
- Powering down or unplugging from power: If the organization plans on doing forensic analysis, this is the worst-case scenario. If the organization plans on restoring from backup or known, good media then putting back into service, this is the best course of action. This will eliminate any access the actor has (unless they have implanted something malicious for persistence) unless they have moved to more systems. This can also be tricky if the users are on laptops. They should be trained on how to ensure the system is shut down, otherwise, the system will remain on until the battery dies.
- Do not touch the computer: This is a good course of action if the system has been potentially altered by a physical intruder. This will preserve any potential fingerprints and allow the collection of any that may exist (via Allen on Twitter). This is a worst-case scenario for containing an attacker if they have malware running on the system.
Define What Information To Make Note Of
Just as important as the actions taken, the environment where the event occurred can help the organization and the responders. Providing situational data about what was happening when the incident or event occurred can lead the cybersecurity team to a swift and precise response. These pieces of information will help responders narrow in on what to look for (at least initially) and provide an idea as to what may have caused the incident.
- Ideally, the exact time of the event. If this is not possible, try to get a 5-15 minute window.
- What is the operating system of the computer? What is the hostname (if known)?
- If possible, provide the IP Address of the system.
- What application(s) were being used or open when the event occurred?
- What website(s) were being viewed or open when the event occurred?
- Was this after opening an email? If so, who is the sender?
- Was anything recently installed?
- Did anyone come by and need access to the computer?
- Did anyone call asking for access to the computer or your password?
Define What Non-Technical Processes Are Triggered
Despite this being a technical issue, there are non-technical processes to trigger. What will need to occur internally? Just as importantly, what will need to occur externally? From an internal perspective, who else is notified and how. If this is the product of a phishing attack, how does the organization get the word out without sending the phishing email to everyone, risking someone else clicking the email? Is it practical for the organization to block all links in an email before sending it out to everyone? Not entirely. There could be malware or malicious scripts embedded in the email that could compound the issue at hand.
From the external perspective, does this need to be reported to an ISAC or government regulator? Does this require a press release? What is known? As an organization, is outside help warranted? Depending on the scope and severity of the incident, the answers to these questions may vary and there is never a one-size-fits-all answer to them. This will largely depend on the type of incident or event and what data types were affected. This is a question best answered by legal counsel.
Also, will any employee sanctions occur? I am not a fan of punitive actions against an employee that acted in good faith that reported and acted in line with company policies and procedures. While the user may warrant addition cybersecurity measures and training, as professionals, we want people to report things to us and they won't do that if they fear punitive actions (up to and including losing their job). While there are times that sanctions or terminations are appropriate, consider the precedent that terminating a non-technical employee for falling victim to a single phishing email that was mostly benign. Would the same actions be taken if it were an executive falling victim to business email compromise?
Conclusion
In conclusion, there is no specific one-size-fits-all approach to this. As a business decision-maker, you need to determine what requirements you have to meet with regulators, ISACs and other bodies while maintaining the operations of your systems and productivity of your employees. While collecting forensic data and analyzing it to prevent future attacks with a similar root cause is valuable, so is maintaining the operations of your business. There are compelling arguments on both sides of the scales to weigh before making any decisions. The bottom line is to make the decisions far enough in advance that the cybersecurity team can have the infrastructure and procedures ready and that the users can be trained on what to do to assist the company and the cybersecurity staff in responding to such incidents.
