This is the last article in the series WordPress application hacked (and how to recover!) on how to recover from a WordPress hacking attempt. In the previous articles you could read how to prioritize immediate actions and how to recover your WordPress platform. That’s all good and well, but the most important thing is to avoid such headaches in the future.

Introduction

Assuming you are at the point where the service is fully recovered and want to up your security game. There are a lot of different options to consider. Below you can find several good suggestions going from lower level aspects like account management, via platform security to business process improvements that you can implement.

Account management

The thing you should look at when it comes to account management is implementing a policy, as they call it. Below are some WordPress specific items, but they are applicable to all SaaS platforms living in the cloud.

• WordPress specifically has a user attribute called ‘user_registered’ and with certain plugins you can also monitor ‘last_login’. These can help maintaining (and removing) old accounts. The latter is a good one to use, for instance disable and remove accounts after 6 months of inactivity.
• Depending on the nature of your platform and the sensitivity of the data therein, you could consider multi-factor authentication (ref: https://en.wikipedia.org/wiki/Multi-factor_authentication). This has become common good in recent years and is fairly easy to implement. The higher your data value, the more reasonable it is to do this.
• If it regards very sensitive data, VPN protection can be considered. This has impact on the user’s ‘ease of use’ but can be useful and required in specific cases. I would recommend against it for regular simple wordpress websites though. However, we maintain datalake systems where customers (and their customers) can look at business performance data. This is of such importance that we only allow access after connecting to the relevant VPN server.

Platform health

Although user management is part of platform security, in this section the focus is on the security of the actual platform itself is.

• Run your wordpress and plugin (and code) updates … Always and frequently!
• Version your code (with git) if you didn’t already. Also, preferably separate custom code (and wp and plugins) from content uploads or data. Use an designated folder for items that can be changed by the users
• Keep your code base components up to date. Any web framework is built with underlying libraries on which it depends. All these underlying components have a version and can suffer from security exploits. These should be monitored and updated when needed.
• Run the latest stable version of php. There are usually multiple PHP versions maintained. See version life cycles for this at: https://www.php.net/supported-versions.php. You don’t need to have the latest version immediately after it is released. However, you should never run a version that has seen it’s EOL (end of life) because found vulnerabilities are not patched anymore beyond that date.
• Secure your WordPress installation and code as much as possible. These configuration ‘lock downs’ are best done on an isolated VPS if requirements are very specific. You can for instance disable the use of .htaccess which results in full control. Mind you this might mean a bit of extra management but is definitely more secure. Mind this though: when WordPress is running in a shared hosting environment, you most likely are limited in your options.

Platform perimeter

This section is also about platform security. However, it focusses on border security and makes sure the traffic that hits your platform is healthy and not malicious.

• Properly setup your network firewall. Obviously you open up port 80 and 443 because you need visitors to be able to access your services. Any other type of access (like SFTP or SSH) should preferably be IP whitelisted or VPN-ed
• You can implement server side security measures, for instance brute force login attacks. There are a lot of tools available and easy installed on a Cloud server. However, don’t reinvent the wheel if it already exists. A lot of these are provided by the different WAF’s (Web Application Firewall) out there.
• Monitor what happens with your platform. Besides checking for availability and load time, which is conventional monitoring, WAF’s can look out for
  • Incoming malicious traffic
  • Weird login behavior
  • Detecting (and blocking) abusive traffic
  • Anomalies like DOS attacks
• Implementation of a WAF.
  • Depending on the size of your platform and the traffic volume, you can place an actual WAF in front of your platform. A familiar global service for this is for instance Cloudflare.
  • Another option is to run an integrated WAF to up your WordPress security. A familiar one to look at is Wordfence. Although from an operational perspective a WAF should not be ‘in’ your platform but placed in front. However Wordfence is viable option for upping your security.

Side note: WAF’s, either integrated or actually in front of your platform provide a lot of combined functionality. Services like Cloudflare for instance also provide Content Delivery Networks (CDN). While on the other hand, integrated WAF’s like WordFence provide account usage monitoring, local security scanning, etcetera. Your mileage may vary but there are always tool combinations possible that fit your needs.

Business processes

As far as the business aspects of an event like this go, your business should be resilient enough to handle some form of disaster recovery. But there are also process aspects that you can improve.

• Have a ‘what if’ plan in place. Should something like this happen, have a one-pager available with steps, so you know the bare minimum of actions to take. If you’re interested in the full series, check out: WordPress application hacked (and how to recover!).
• Do a risk assessment when (platform) changes are implemented. You can think of software upgrades and functional or technical changes. But also in regards to changes in company processes or contractual agreements with customers or vendors.
• Make it part of the management agenda. Allthough relevant for bigger scale, risk assessment is usually part of your Governance. Especially when your company is ISO (or other) certified, this must be an integral part. Schedule and execute a recovery procedure yearly.
• Have a scheduled penetration test done by somebody. Either cyclic (yearly) or after major changes. CAP5 does external penetration testing on its customer platforms. CAP5 performs daily automatic pen testing with an external monitoring platform. So network, firewall and content changes can be detected as they occur.
• Implement automated forms of software testing during deployment. This checks a lot of possible issues before a newer version goes live.
• Standardize deployment and upgrade processes. Some simple examples are: Create an extra backup before deployments or upgrades, store file checksums (or some other way to audit the state of play) right afterwards.

That’s it. If you made it this far I thank you for that. This article series described a specific use case and there’s definitely no ‘one size fits all’. However, from a high over perspective everything in here should have a place on your stage when coping with break-ins.

I’ve handled these kind of disasters before. However in this case, the customer and I have a good form of communication in place. Priorities were set and therewith the necessary work on both ends could be handled quickly. For me the biggest lesson learned (again) while helping the customer recover was this:

A website or software platform is like a car. If you don’t perform recurring maintenance and make sure everything stays in working order, eventually you get a big bill.

Are you hacked or are you questioning the health and security of your website or platform? Get in touch if you need help or advice.

This article is part of the series WordPress application hacked (and how to recover!).