For the SiteWorks project to give maximum benefit to the user community, Website Administrators are reminded that they have to adhere to several guidelines.

All website administrators, editors and authors are responsible for working to the conditions discussed in the Website Terms of Use and Standard Operating Procedures.

If an u3a committee agrees to activate the Contact Form Log, the Website Administrator must change the u3a privacy policy to reflect the activation.

Overview of SiteWorks Security. #

The SiteWorks project team and the SiteWorks hosting company Sarah Hayes have taken several steps to protect SiteWorks sites.

All the sites hosted on the Sarah Hayes server are protected by:

• ConfigServer Security and Firewall
• Corero DDoS Protection  (for denial of service protection)
• Imunify360 (for anti-virus protection)

Following discussions with Sarah Hayes, the SiteWorks distribution includes the Loginizer plugin to prevent brute-force username/password attacks. The SiteWorks plugins have been independently assessed for potential security risks and were considered secure.

Additionally, the SiteWorks configuration plugin enforces strong user passwords, in addition, it is advised that an individual user name has a degree of randomness.

The Sysadmin team ensures that all sites are running the latest version of WordPress and the plugins in the SiteWorks distribution. The SiteWorks team also monitors the installation of 3rd party plugins across all sites.

It is important to note that this does not take away the responsibility of Web Managers to make their security assessment of additional plugins that they add to the provided distribution.
For more information see Operational Procedures

System Updates #

All updates to WordPress are automatically applied.

The updates to supported and unsupported plugins are applied as follows:

• The System Administrators automatically update all supported plugins included in the SiteWorks distribution.
• System Administrators can see when an unsupported plugin needs updating:
  • If the update is security-related, the System Administrators will update the plugin, to maintain the security of SiteWorks. Website Administrators should be aware that this could cause issues, hence the functionality of any website that incorporates unsupported plugins needs to be monitored regularly.
  • If the update is solely feature-related, the update will be left to the Website Administrator’s discretion.

Before any update to WebPress or the supported plugin that enhances features, details will be communicated to Website Administrators via the user guide and a widely distributed update bulletin.

Backups #

Every SiteWorks website and account hosted via TATL will be fully and automatically backed up daily. At least two weeks’ worth of backups will be retained. There will be two copies of each backup, one on your SiteWorks server storage and one off-site in the UK.

A Website Administrator can request a full restore of their site through the Help Desk.

The backup processes perform incremental backups that only capture site changes from the previous day and are far less demanding of disk space than full backups. The restore capability is fast, tested and proven.

There should be no need for sites to make additional backups, but if this is done the plugins must be configured to make off-site backups, i.e. Google Drive, Microsoft OneDrive, DropBox or similar. Full backups take up as much storage as the site itself and storing other backups on the SiteWorks hosting service contravenes the SiteWorks Operational Procedures, and gives no additional security.

Copying your website for testing or training purposes #

If the Administrator considers it necessary to copy the website for development and training purposes, a plugin, for example, WP Migrate Lite can export a complete copy of your website as a zip file. This file can then be imported directly into LocalWP. However, before undertaking, the section on Plugins must be reviewed.

It is strongly recommended that only a LocalWP system is used for development purposes, as this will catch any outgoing emails, particularly those to the system administrators, to protect the integrity of the system If a Website Administrator wishes to use a development environment such as WAMP, MAMP, XAMP or a personal hosting account for testing or development, the SiteWorks Administration Email Address within the WordPress settings MUST be changed, when you activate your copied site. From the Dashboard ⇒ General Settings ⇒ Settings ⇒ Administration Email Address, to set the new address.

Security Issues Relating to Adding and Maintaining Unsupported Plugins #

The SiteWorks software distributions include all the required plugins to create, maintain and publish a u3a site. In some cases experienced Website Administrators may wish to “experiment” with one of the many thousands of available open source plugins.

If the Web Manager wishes to review the operation of an unsupported plugin, this MUST be undertaken on a LocalWP site AND NOT on a production or live site. Deleting “test” plugins may not “clean up” properly and can leave settings or data on the production site that can affect site operation and may be difficult to resolve should a problem arise.

Before considering the use of an unsupported plugin the Website Administrator must consider the following:

• The rationale of why the plugin is required over the SiteWorks distribution:
  • If the Website Administration considers additional security is required over that discussed above, together with the features incorporated in the SiteWorks plugins considerable caution should be exercised. Due to possible unintended implications, the Website Administrator should contact the SiteWorks team to ascertain if (a) the security from the unsupported plugin is necessary and (b) if this is already or planned to be incorporated in future SiteWorks releases.
  • If additional backup capability is required, its use, storage and configuration must be considered. The current backup requirements are considered more than adequate for an individual u3a. If a copy is required for training on LocalWP, the Website Administrator must appreciate that training by this route is unsupported.
  • If the plugin adds additional features, care should be taken to ensure the overall theme is not extensively modified. Again, the Website Administrator should review forthcoming enhancements, or suggest that the requirement is included in SiteWorks at a future date.
  • The WebMangar when considering an unsupported plugin MUST review its long-term support, user base and GDPR implications.
• The Website Administrator must consider the additional effort when an unsupported plugin is added, including its ongoing updating and ensuring the individual u3a’s Standard Operating Procedures and training documents are updated as required. It MUST be noted that unsupported plugins are not discussed in SiteWorks training or user guides.
• If an unsupported plugin is added, it is the responsibility of the u3a, to ensure that the cookie policy and other conditions within the Website Terms of Use and Standard Operating Procedures (in particular section 1.4) are maintained at all times.

Maintaining Email Reputation #

A large proportion of emails sent during the testing and commissioning of a u3a site can easily fall into the category of “not looking like a genuine personal email” and damage the “reputation” of the server.  If this occurs the email system has a higher probability of rejecting genuine emails as spam.

In addition, the emails generated by WordPress regarding password changes or resets can look like phishing emails, further damaging the reputation of the sending server.

To prevent this:

• Website Administrators, Editors and Authors MUST avoid using the standard contact form to send messages with words such as “test” or “urgent” in the title and very brief messages.  If you want to test out the contact form, the sender should simulate a genuine enquiry using genuine names, email addresses and messages that contain several lines of text.
• When creating a new user, as discussed here,  remove the tick from the box to send the new user an email about their account, This may be classed as a phishing email.  Instead, send the new user their username and password using their regular email account (via Beacon if available).