Welcome back to the Patchstack Weekly security update! This update is for week 22 of 2022.
This week there is only one high-risk security bug patched to report on in the vulnerability news.
During this week’s knowledge share I will talk about the incident response plan and the importance of having it ready for worst-case scenarios. Because having a plan will help you turn bad situations into learning experiences.
Users of the KiviCare plugin, a plugin for medical clinic patient management, need to make sure they have updated the plugin to patch a security bug.
An unauthenticated SQL injection bug was patched by the developer in late April, the developer noted “Security issues fixed” in the changelogs.
This week, I will talk about the importance of having an incident response plan, and show you how you should put an incident response plan together.
Isn’t just planning for the worst, It is planning to save you a lot of time and frustration. Because, being prepared to face a bad experience turns those experiences into a way to improve yourself, your process, or your organization.
An incident, is an unwanted event, such as a website compromise. Your response, to that incident, can be planned out beforehand, and you likely need to plan to do more than just clean up the malware.
Malware cleanup, is, of course, an important step, but you need to know more than just that your site is clean and safe to visit.
You need to look into the evidence available to determine the attack vector. Then, with that evidence, you need to take action, clean up any changes the attacker made, and, perhaps, change a lacking process that may have led to the incident in the first place.
The goal is, you plan to prevent the same incident from happening the same way ever again. Or, in short, you turn a negative experience into a learning experience.
This is the essence of a good incident response plan, and if you can execute the following actions then you’ll have a solid security incident response plan for your organization:
Of course, needs to be a detection phase that triggers the incident response plan to begin.
This could be malware detection, unauthorized access, or other, but in short, once you have an IoC (Indicator of Compromise) confirmed then you know it is time to follow through with your Incident Response plan.
This can be done by reviewing web server access logs, being able to narrow down the requests you’re looking at to a specific timestamp (or short time window) will help save you a lot of time here.
The creation timestamp of a malware backdoor file created or uploaded by the attackers is a great piece of evidence to work off of here.
Another great option here, which requires a plugin or extension on your website is to monitor user activity in the web application. WordPress does not do this by default, but there are a few plugins that provide this level of monitoring and can be very useful.
You can easily monitor user activity with Patchstack. Try Patchstack’s 7-day free trial!
The outcome from this step should be that you know what the attack vector was, and what actions the attackers took after they gained access so you can undo what they did in the next step.
For most people, this is the malware cleanup phase. And I should emphasize, an important concern: if you clean up the malware before you identify the actions taken by the attackers, you’re destroying the evidence you needed to know what they did.
If you need to get the site cleaned and back online ASAP, be sure you make a backup of the compromised site’s files, database, and logs so you can investigate and identify the attack vector using the backups at least.
This step could involve using tools to manually clean up files, setting up the site from scratch again, or restoring from a backup. As well as additional steps like rotating secret keys and passwords.
The outcome here is to get the website running again. But your work is not done.
If you know how the attack happened, and you were able to recover the compromised website and get the business running again. Now, you need to make sure the attackers can’t just hack the site again.
You can use the information gathered in the first two steps to help you now.
This step will look different based on different attack vectors, but here are some examples of outcomes:
This is the final step of a successful incident response plan. You will use the prior steps to build a report which outlines the attacker vector, the actions attackers took, the steps you took to clean things up, and the steps you are taking to prevent further attacks.
You may need to share this report with your customers (if they were affected), or law enforcement (depending on your local laws.)
Reporting that your website or service experienced a compromise is a step that some organizations fear having to do. I hope you see though, that if you have a solid incident response plan, then this should be no worry.
In this final step, you will use the findings and evidence from the first three steps, identification, remediation, and action to prevent further compromise to show your customers that can trust you, and that you had a plan in place to respond to even the worst possible incident of a site compromise.
You will also show them you are like everyone else, you make mistakes, but you’re mature and have a well-thought-out plan to turn a catastrophe into an accomplishment.
This week’s thanks go out to the developers of the KiviCare plugin. Thank you for patching that security bug a few weeks ago, I see this is an actively developed plugin that you are improving every week, great job.
A special thank you is extended out to everyone, who has learned that mistakes are opportunities to learn. Be it development, website management, business, or your personal life.
Learning from mistakes, not making the same mistake twice, and improving yourself is a signs of maturity. So, thank you for improving.
I will be back next week with more security tips, tricks, opinions, and news on the Patchstack Weekly security update.