I want to paint a picture here for a moment. It’s Monday morning and one of your employees comes to you and says they can’t open a report. The file format isn’t recognized, it won’t work, it’s just a bunch of gobbledeegook of a word document now. You tell them to call IT and if you’re like me you’re wishing you had gotten the extra large coffee before you came in. 30 minutes later another person complains, then another.
Sounds familiar right?
Signs of Ransomware
For those of you who have never seen ransomware these are the typical signs of a bigger problem. What’s dangerous about ransomware is it starts as a single issue for a single user. By the time someone properly identifies it as a larger threat, it’s already spread out and it’s almost too late.
Obvious signs of ransomware are wallpapers or locked screens, these show messages claiming all data is gone or compromised, with instructions on how to pay. More subtle signs of a spread are documents no longer working, programs not opening. It’s as if the entire computer is slowly falling apart as more and more things get infected.
It’s at this point that incident response and user awareness come into play. If you and your IT team can’t identify an incident as it happens, it will only get worse.
What is an incident?
The primary goal of information security is confidentiality, integrity, and availability of data and systems. These sound like simple concepts, but the idea of an ‘incident’ is very nebulous. When we talk about information security what we are really talking about is keeping your systems and date safe and keeping it confidential. Not everyone needs to know everything. Password, financial information, health records, etc. Also, key is keeping the data available – the data, the systems, all of it needs to work when it’s needed by you or your customer.
An incident is the opposite: disclosure, destruction and denial of your data or systems.
This is when data or systems are:
Disclosed – information is leaked, trade secrets are made public, personal information is no longer just personal.
Destroyed – data is missing, data is deleted, systems are no longer functiong This could be from a virus like Stucknet, or simply from a environmental hazard such as electrical outage, an earthquake, an angry employee.
Denied – Or when you or your customers are denied the data and systems. Ransomware falls under this. The data isn’t destroyed, it’s not disclosed, but it’s not available. Another example is DDoSing, where someone intentionally causes an outage at a key moment.
Once you reach this stage of an incident, your plan should be coming into action. Or at the very least the incident should be identified and the beginning of a response should be happening. Often in IT we triage based on the amount of affected users. A single user is generally not a concern, but when multiple users are unable to do something, we escalate the priority level.
Ransomware is dangerous because once it has spread, it’s almost impossible to contain. To draw real life parallels, it’s like trying to contain a pandemic after it’s already crossed the border. Your IT department will start getting more and more calls. It’s important that someone there takes a step back, looks at it from a birds eye view and asks “Is all of this caused by a bigger issue”.
That’s when the response is usually triggered. Unfortunately, most companies don’t have that employee who is trained to look for that, nor trained on how to respond.
Responding to an Incident
Can you identify an incident? Who responds? How do they respond? What’s at risk? Can you afford it? What do you do first?
So what do you do first?
That’s the heart of an incident response plan. It prevents choice paralysis where there are so many decisions to make that its easier to make no decisions at all. This is often compounded by a lack of identifying roles in an organization. Whose job is it to handle the communication, who is in charge? With no one identified you get conflicting responses, which makes the situation worse.
Often the end user will sit there and assume it’s IT related and simply wait. Executives will call IT demanding to know when it’s fixed, and somewhere in a cubicle in a corner buried under Monster cans, one person is finally realizing what’s going on.
You get the point.
The longer the incident the more things unravel. A larger company will most likely survive this incident. But medium and small businesses, this could be the end for them. 70% of all businesses don’t survive ransomware. Being prepared is the only way to mitigate the damage that an information technology incident causes.
Remember the layers of cybersecurity we discussed?
A firewall will block 99% of attacks, antivirus will block 99% of the 1% that gets through the firewall, and backups will fix it if everything is still compromised. Assuming your backups are not also hit.
IT and Security providers must get security right 100% of the time, but a threat actor only need to get it right once. A compromise only takes a single user to click. This is why IR Planning is so important. And there is no silver bullet to offer 100% protection. Security is really all about mitigating risk.
So, what’s your security plan?
An organization will only make security a priority if the top echelon makes it one. If the owner or the executive suite don’t push security as a priority, it will never become one. Even if they do, and a plan is in place. It needs to be shared with the key people involved. The plan needs to be reviewed regularly and accessible.
Finally, it needs to be signed off by insurance. Money makes the world go round, and knowing that if you follow your plan you’ll at least be covered by cyber liability insurance will help take some of that stress off your shoulders.
An Incident Response Plan should include:
Preparation – policies, checklist, forms, tools, software
Detection – Identify an incident, report it
Response – Respond to it, “send out a team”
Mitigation – Contain the damage
Reporting – Report to higher, report to media
Recovery – Restore to normal state
Remediation – Identify how it happened and prevent it
Lessons Learned – Review the IRP, did it work?
More Key Incident Response Plan Specifics
Finally, there are other considerations to keep in mind:
Can your employees identify an ‘incident’? Do they know who to call? What to do? Can they operate without technology? For how long?
What systems have to be recovered first? In what order? What if payroll was affected? What if data was also exfiltrated?
Do you have cybersecurity insurance?
What will you tell the media?
Have you budgeted for ransoms? Or for remediation?
We can help you not lose sleep at night. Learn more about cybersecurity services from Diamond IT