The recent Panama Papers data breach seems to have more than a few political leaders trying to explain their offshore investments, or in some cases, forced to resign because of the exposure’s embarrassment. While I am not at all suggesting that you have anything to fear from such exposures, the manner in which the law firm Mossack Fonseca was hacked might have you sit up and take notice.
According to WordPress security vendor Wordfence, the attack was enabled via an outdated plug-in (Revolution Slider) that is very popular with WordPress-run websites. Our own website, plus that of some organisations (and more than a few schools) that we know of use WordPress as the basis of their sites. And why not? A W3Tech report states that 57% of websites that use a content management system (CMS) are using WordPress, and that near 25% of all web sites use WordPress. It’s popular, fairly easy to use (especially for updating portions of your website), and has a huge eco-system of 3rd party plug-ins and themes that add all kinds of flexibility and panache to your site.
Problem is, in that adding all of these goodies to a WordPress site brings in a level of diligence that some might tend to neglect, simply because of the frequency of updates. So far this this year of 2016 there have been 7 WordPress releases and near 24 releases in 2015! Each time there is a new WP release, before you might install the new WordPress version, you should check your plug-ins to see that their current release is supported within the newest release of WordPress. If not, perhaps it is wise to wait for your plug-ins to catch up in compatibility to the current WordPress before installing the latest WordPress version. I get confused just trying to put this into words!
Does it matter? It might, even if you do not have confidential data within the depths of your website. It could be a ransom-based malware, or matter of inconvenience when your website content is replaced or encrypted on a WordPress site that you run. We rescued a site a that was hacked and had its content re-written to show support for a radical political group. In the Mossack Fonseca case, the attack exposed key usernames and passwords that allowed entry into their email system and other areas.
What can be done to secure your WordPress-based site? Here’s a few pointers:
- Use a security plug-in to secure your site. We like Wordfence. There is a free version, but the premium paid version is not expensive. It will also tell you when there are updates ready – for your WordPress installation and for your plug-ins as well. This is worth the price alone.
- De-activate the plug-ins you are not using regularly. That plug-in that imported your users or graphics files was great at setup, but does it need to stay active?
- Frequently check your plug-ins for updates. Check compatibility with the latest version of WordPress before you patch them.
- Do not set your WordPress site to update automatically – this can break your site if your plug-ins are not compatible.
- Have a backup in place for your WordPress site. Many hosting vendors that host WordPress sites provide for backups of WordPress databases at no charge. Popular plug-ins for WordPress backups that we have tested and like are Backup Buddy and Updraft Plus.
- Use your (tested) backups to test plug-in compatibility with new versions. New release of WordPress breaks one plug-in? Roll it back using a recent backup.
- Change the default administrator name for your WordPress logon.
There are a number of other great suggestions out there – do scour the WordPress site itself for its own recommendations for securing your site.
When Google Apps for Education are introduced into a K-8 school, administration, staff – and especially parents – may have some concerns about security and protection for their children. With a little planning, there are ways to substantially partition off successive layers of access to email features within your school’s Google domain….
When Google Apps for Education are introduced into a K-8 school, administration, staff – and especially parents – may have some concerns about security and protection for their children. Some may not even want an ability for children to have an email account, while teachers may desire an email account for their student to facilitate usage of a particular application, or student-student, student-teacher, student-parent communication. What can be done?
I once thought this might be an all or nothing approach, but a recent session at a Google Apps for Education summit convinced me otherwise. While not a matter of a few clicks here and there to set this up, with a little planning, there are ways to substantially partition off successive layers of access to email features within your school’s Google domain. Here’s one way of tackling this:
- Create a suborganization for every graduating year possible for your school. For an initial setup, this would include the current graduating year, plus an additional 8 or more years to cover Kindergarten and JK. In this example, you would create suborganizations for 2013, 2014, 2015, and up. Think carefully about this – your users (students, staff, committee member, administrators) can only belong to one suborganization at a time. If you organize them here for other purposes, you will need to consider your main usage of suborganizations. The settings for creation of sub organizations and user assigment to these can be found under the <Users> section on the administrative app for your Google Apps site.
- Move your (users who are) students into the appropriate group for graduating year. This will rarely change. The idea behind this type of organization is that as the graduating year approaches, you can decide to progressively allow more email features to that graduating year group.
- Here’s where the fun and decisions can now be made for what you allow. These settings can all be found under the <Settings> menu on the top, then by selecting <Gmail> from the sidebar, selecting each suborganization by graduating year, and then modifying the settings found in the <Compliance> section.
Here’s what some of those settings control:
- Append footers – You can set up outgoing email footer text for legal compliance, informational or promotional requirements. This might not be too relative to what is being discussed here.
- Restrict delivery – here you can whitelist (include) or blacklist (omit) whichever email domains that you want allowed for delivery and receipt of emails. You could , for example, only allow delivery and sending of emails that belong to your school’s email domain…..and bypass it for internal-only messages.
- Content compliance – this setting states what action to perform for messages based on predefined sets of words, phrases, text patterns, or numerical patterns. It scans messages for content that matches rules that you configure. Messages can be rejected or delivered with modifications.
- Objectionable content – similar to above, inbound or outbound messages can be modified or rejected, based on content matching word lists that you define.
- Attachment compliance – Attachments can be filtered based on their file type, name, or size.
- Receiving and Sending routing – interesting options here – one capability is that any email sent from outside of the sub organization’s group to any member of the group can be routed to one person . You could, for example, force all emails sent to a group to go (only) to the teacher or principal.
Between all of these, one can see that you can force email communications within any one grade to only members of that grade, and / or include a teacher, parents, or others (another ‘partner’ school, for example). Couple this with the content filtering, and you have a quite impressive, albeit somewhat tedious-to-setup control on email usage for your Google-based organization.