In a previous post titled Malware Shmalware, I shared that a friend had turned to me for help when his website had been "hacked". The Hollywood portrayal of a malevolent hacker madly clickety-clacking the keyboard with ingenious commands to break into websites is far from the truth. The pedestrian explanation is that the site in question was not actively maintained and had fallen far behind its CMS's recommended version. An automated script churning through the internet eventually discovered a vulnerability and exploited it.
This attack falls under "Using Components With Known Vulnerabilities", which is risk #9 in the OWASP Top 10 web application security risks list, a well-known compilation of threats found on the web.
The Open Web Application Security Project (OWASP) Foundation is a non-profit focused on improving software security. Their Top 10 list is "...a standard awareness document for developers and web application security. It represents a broad consensus about the most critical security risks to web applications."
We won’t go through every point here, but while reading the Top 10 list, it becomes fairly clear that securing your website is not about ingenuity, as much as it is about following web security best practices, paying attention to release cycles, and keeping your software up-to-date. At Chromatic, we strongly encourage our clients to commit resources to regular website maintenance so that security is a matter of course rather than a scramble to fix things once disaster strikes.
Best Practices Come Standard
Our standard practices include:
-
Following appropriate security announcement channels E.g. We follow Drupal security team announcements.
-
Automating the process to track new software releases. E.g. We use GitHub's Dependabot to automatically open pull requests when new versions of project dependencies are released.
-
Standardizing our build and deployment processes using Ansible. This allows us to keep the steps we follow consistent and update our processes globally when needed.
-
Maintaining a dedicated DevOps team.
-
Using a Content Delivery Network (CDN) such as CloudFlare or Fastly in front of sites to boost security and performance.
-
Using New Relic to monitor system performance.
All of the above is crucial, but it also sounds fairly dull because, with proper security, there is no drama! For fun, let's imagine a theoretical breach and what needs to be done to restore normal service.
Unanticipated Disaster Strikes
In this scenario, a mischievous 12-year-old named Mia gets access to her veterinarian mother's laptop and finds pre-populated login fields for the veterinary association's website! (OWASP risk #5 "Broken Access Control")
She's unhappy her parents didn't get her a horse for her birthday and wants to teach them a lesson. Using the admin UI's content filter and bulk actions, she deletes all equine-related content with a few clicks.
Though Mia used a correct username and password combination, we'll call this broken access control. If two-factor authentication had been enabled, a feature we always recommend, Mia would not have been able to log in with the saved username and password alone.
Not long after Mia's mischief-making, users of the website complain that all of their favorite horse-related content has disappeared. Initial investigation fails to find any of the lost content – it truly is gone! The CEO wants to know what happened, but no one is sure. When did this happen? How did it happen? Who did it? These are questions that can be answered by a system with sufficient logging mechanisms in place. (OWASP risk #10)
Keep a Digital Paper Trail
Our content management system (CMS) will have a record of which user deleted content and when. In fact, we can go a step further and implement an action to inform site administrators when content is deleted, which can alert the team to the mischief in real-time.
Now we know what happened and which user did it, but how do we get that content back?
Fortunately, we have a back-up and restore plan in place. We keep nightly database back-ups and can restore all the lost content by rolling back to a version of the database from before the content was deleted. Any content created after the deletion might need to be re-entered, but that is a much smaller job than restoring all the lost content.
There is an adage in IT that says back-ups don’t exist unless you are able to restore them. Fortunately, our day-to-day development includes Tugboat, a system that builds testing environments for every pull request. Every night, Tugboat builds test copies of our client sites, using the latest database back-up. In essence, we automatically test our ability to restore sites nightly!
Our hypothetical scenario shows that even a serious breach can be contained if you have a back-up plan and process to restore compromised websites. In order to keep these scenarios as hypotheticals, your team has to keep up the mundane tasks of keeping site software up-to-date. In web security as in health, an ounce of prevention is worth a pound of cure.
