Welcome back to the Patchstack Weekly security update! This update is for week 21 of 2022.
In this week’s knowledge share, I will talk more about communicating security. But, not too much, because this week I will talk about over-communicating security, also known as alert fatigue.
Of course, I will start with a few notable security bug fixes added to the Patchstack Database in this week’s vulnerability news.
Users of the RSVPMaker plugin by David Carr should update to the most recent release, the developer addressed an unauthenticated SQL Injection security bug this week. So, please update and keep your sites secure.
According to reports by Jetpack’s security team, the School Management Pro premium plugin developed by WebLizar was identified as having code in it that allowed remote code execution in the plugin.
The vendor removed the problematic code once they were informed and pushed a release to secure their user’s websites.
So, if you are a user of the premium plugin school management pro by WebLizar, please make sure you update as soon as possible.
The Member Hero plugin was also affected by an unauthenticated remote code execution vulnerability, which unfortunately received no patch.
It appears, that another plugin with a critical vulnerability was abandoned and has no one to steward this code, even for matters of security.
Users should disable this plugin if they are using it, and find an alternative before it is too late.
Last week, I talked about the importance of communicating security. This week, I would like to talk about over-communicating security, or to borrow a term from healthcare: alert fatigue.
Alert fatigue is caused by, you guessed it, an excessive number of alerts or warnings leading to important alerts being ignored or not acted upon.
I can clarify this with an example: If your inbox or security logs are full of messages about hundreds of thousands of failed logins, and thousands more failed attack attempts against software your site doesn’t even run, you might miss that one alert regarding the need to patch an insecure component on your website.
Which makes me think, what is so important or useful about a record of a bunch of failed attack attempts? That seems to just bolster a false sense of security to me because if it isn’t actionable it’s over-communicating security.
It is far better to limit alerts to items that need intervention by a user. Sending security communications only when there is an issue that needs the site’s owner’s attention, clears up the site owner’s inbox and makes sure they don’t just filter all of the security notifications to a sub-folder they rarely check.
Avoiding alert fatigue is easy too. If the alert does not include something that is actionable, then it is better off stored in a log or dashboard to be reviewed periodically.
Limiting alerts to only actionable notifications, the ones that require intervention by the site owner, means all security alerts need to be reviewed and triaged to be handled in order of their priority.
Prioritization is key too, this is where another concept borrowed from the medical field comes in: triage.
Alerts should be triaged, some issues may need immediate attention (for instance, a critical severity security bug in components running on dozens of websites you’re responsible for) while other issues can be scheduled in the next few days, or used to create a task to do later or email your co-workers or a vendor about.
However, if an alert requires no action, let’s say an alert about how an attack targeting software you don’t even run was detected and blocked. Well, frankly, that is useless information.
No one should care if a bot attempted an attack against software that a website doesn’t even run. The same goes for alerts about failed logins, bots attempting to brute-force passwords are the background radiation of the internet.
Recording data about the insane number of failed logins these bots attempt is only good for making charts and graphics to show people the importance of choosing a unique, secure password in the first place. It is not an alert-worthy event.
If a website’s users are practicing good password hygiene, or better yet, have 2-factor authentication set up. Then security alerts about bots that would never have a chance at success, are just a waste of electrons and risk drowning out more important alerts, that actually need intervention.
Security alerts go beyond just notifications, if we consider all security communication a form of a security alert then we can review how useful a few common security notifications really are.
For developers, a security bug report is an alert that helps your project. But, an incomplete or invalid report or a report made public before you can patch – we can agree those are not helpful.
This is something the Patchstack Alliance can help with. We review security reports filed against open-source projects and only pass along the valid reports, with sufficient details to replicate.
For WordPress website owners, a notification about insecurity your site is actually running is useful, it will help you to take the action to update or patch.
The Patchstack plugin and Patchstack App can help you out here.
We also know the world is full of sensationalist headlines about software with vulnerabilities affecting thousands or millions of users, but these headlines are communicating the security issue to a lot of people that don’t use the plugin and are not affected. A bit of overkill if the goal was to notify affected users.
And of course, there are these weekly security updates, where I try to keep them brief, so that’s my queue to end this section and move on to some thanks and appreciation.
This week’s thanks go out to developers who patched security bugs, thank you David Carr for patching the security bug in RSVPMaker, and thank you to the WebLizar developers who cleaned up the School Management Pro premium plugin’s codebase.
I will be back next week with more security tips, tricks, opinions, and news on the Patchstack Weekly security update!