[gap height=”15″]
“I have been investigating a large number of failed logins on your server. Due to the volume of failed attempts, it does appear that the attempts are coming from an outside source. My company recommends that you reach out to a security firm to have your network investigated for a possible breach.”
[gap height=”15″]
He couldn’t believe what he was reading. A local cybersecurity professional was forwarded the email above from his new client’s outsourced computer management company. The owner of the business was concerned, and for good reason. They had only brought him onboard as their part-time cybersecurity advisor the month before, and the vendor that manages their network had kicked this ball squarely into his court. He had to figure out what to do – fast.
[gap height=”15″][gap height=”15″]
The priorities were simple:
- Alert his client’s executive team about the situation.
- Determine if this is or is not a real hacking attempt.
- If it is a real hacking attempt, determine how it is occurring.
- Assess whether the hack was successful in any way. Was any damage done? Was any data accessed?
- If the hack was unsuccessful, terminate the hacker’s access immediately.
- If the hack was successful, start making calls to his client’s CEO, their cybersecurity insurance carrier, a third-party company that specializes in breach remediation, and my client’s attorney.
- Follow-up with root-cause analysis and recommend preventive measures.
[gap height=”15″]
It took over ten hours to determine the extent of the issue. Cybercriminals had breached a single server, and a malicious program was running on that server. It was trying various dictionary words as passwords against common “administrator” level accounts. He breathed a tiny sigh of relief to see that it had only started several hours earlier and appeared to be moving ahead at full steam, which meant that the bad guys had, most likely, not yet been successful at cracking an administrator-level password.
[gap height=”15″]
The cybercriminals gained access into that server via a combination of a phishing email and a bad firewall configuration. Thankfully, forensics found no evidence of further intrusion.
[gap height=”15″]
His blood pressure began to return to a more reasonable level.
[gap height=”15″]
The example above is real, and while it represents the best possible outcome of a cybersecurity incident, it was used here to make a number of points. This client didn’t have a “playbook” on what to do when a cybersecurity incident is suspected, so he had to make it up as he went. Doing so took extra time and might have led him to miss obvious steps.
[gap height=”15″]
The company did not have documents outlining how to bring operations back online if the hack had been successful, nor did they have procedures to follow if it was determined that any sensitive data had been stolen.
[gap height=”15″]
Their IT services vendor wasn’t well trained in how to get to the bottom of the technical issues quickly, which lengthened the incident by hours.
[gap height=”15″]
The client didn’t have a list of whom to call if a cybersecurity incident was suspected, which made the phone number to their cybersecurity advisor the only number they thought to use. What if he was unavailable when this took place?
[gap height=”15″]
In a nutshell, they didn’t have their act together, and it showed.
[gap height=”15″][gap height=”15″]
After an incident occurs, your company will be judged on the following criteria:
- Before the incident, did your company take all actions to prevent the incident that one would expect of a prudent organization?
- Did your company respond to the incident using procedures that one would expect of a prudent organization?
- Are there any ways that the media could portray your actions around steps 1 and 2 to make your company appear culpable or incompetent? If true, expect that they will. It attracts more readers to their publication.
[gap height=”15″]
A robust playbook that includes the CEO, Chief Legal Counsel, and all other senior leaders will do immeasurable good in your ability to respond to an incident.
[gap height=”15″][gap height=”15″]
An Incident-Response Playbook needs several key elements to be effective. It must:
- Identify who in your organization has the authority to declare a cybersecurity incident. Who can initiate the playbook?
- Spell out how much money that person can authorize to be spent to have an incident investigated or remediated.
- Have a list of the types of scenarios that it is designed to cover. Examples include the loss of sensitive data, a ransomware attack, the loss of a critical system, natural disasters, law enforcement contacting your organization about a warrant or subpoena, and the loss of the use of one or more of your sites due to a natural disaster or because of other issues (such as a crime taking place in the building and the police barring your employees from entering the premises).
- Have a call tree that includes which people or groups to call when an incident takes place.
- Define the people or groups responsible for making the decision on when to bring in law enforcement.
- List the people authorized to speak to the media about a cybersecurity incident, and what those who are not authorized to speak to the media should say if they are approached by a reporter.
- List all of your critical systems, the location of the data in those critical systems, and the location of the backups of the data for those systems.
- Outline your general incident-response process. While every scenario is different, this process normally follows these steps: preparation, detection/analysis, containment, eradication, recovery, incident closure/root-cause analysis, and preventative measures.
- Be reviewed on a frequent basis. These plans get stale quickly, and need to be reviewed whenever a significant change in your organization takes place.
[gap height=”15″]
If the above points are reviewed as a group, an interesting trend emerges. Most of them are non-technical – the majority are operational and financial in nature. That is a critical misstep in many incident-response plans. If your technology team manages your incident-response plan, they are making business and financial decisions that should be made by CEOs, COOs, CFOs and legal counsel.
[gap height=”15″]
Above all, your incident-response plan needs to be tested. Unless you have rehearsed an incident-response procedure, you’re only able to guess if it will work. This is too important to be left to guesses.
[gap height=”15″]
The takeaway messages from this article are easy to list:
- Your company needs an Incident-Response Playbook.
- The Incident-Response Playbook should be owned by a non-technical member of your executive team.
- Your company needs to periodically test your incident-response capabilities.
- Your company needs to update the playbook from lessons learned as a result of tests, whenever significant changes occur to the operational or technical aspects of the company, or when merger/acquisition activity occurs.
[gap height=”15″][gap height=”15″]
Questions to explore this topic further with your company’s leaders:
- How do we test our incident response playbook?
- How often do we test it?
- What did we learn from our last test?
[gap height=”15″]
Unless you have rehearsed an incident-response procedure, you’re only able to guess if it will work. This is too important to be left to guesses.
