Skip to content

Commit

Permalink
Add Security Updates guide, #17
Browse files Browse the repository at this point in the history
  • Loading branch information
theodorosploumis committed Nov 14, 2022
1 parent 7a83c26 commit edabf9f
Show file tree
Hide file tree
Showing 5 changed files with 79 additions and 4 deletions.
1 change: 1 addition & 0 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -32,6 +32,7 @@ My Personal notes and bookmarks regarding Work, Drupal, Project management and m
- [Migration from 8.x to latest version](drupal/migration-8-plus.md)
- [README template](drupal/readme-template.md)
- [Script: Get Prod config](drupal/script-get-prod-config.md)
- [Security Updates for Drupal](drupal/security-updates.md)
- [Selling Drupal](drupal/selling-drupal)
- [Start with Drupal](drupal/start-drupal.md)
- [Teamocil (tool)](drupal/teamocil.md)
Expand Down
1 change: 1 addition & 0 deletions drupal/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -19,6 +19,7 @@
- [README template](readme-template.md)
- [Script: Get Prod config](script-get-prod-config.md)
- [Selling Drupal](selling-drupal.md)
- [Security Updates for Drupal](security-updates.md)
- [Start with Drupal](start-drupal.md)
- [Teamocil (tool)](teamocil.md)
- [Terminology](terminology.md)
Expand Down
2 changes: 1 addition & 1 deletion drupal/mastering-authoring.md
Original file line number Diff line number Diff line change
Expand Up @@ -23,7 +23,7 @@
## Other

- UI option to take backups before any change
- DEV/STAGE/PROD environemnts
- DEV/STAGE/PROD environments
- Override backend theme
- Custom Admin content views
- All blocks on code (under vcs)
Expand Down
72 changes: 72 additions & 0 deletions drupal/security-updates.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,72 @@
# Drupal security updates

> Drupal security updates guide and best practices.
## Important things to know

- Drupal core and contrib modules security updates are maintained by the [Drupal security team](https://www.drupal.org/drupal-security-team).
- **Security release "windows" are every Wednesday for Drupal contributed projects, and one Wednesday a month (usually the third Wednesday) for Drupal core.** See more at [D.O.: Security release numbers and release timing](https://www.drupal.org/drupal-security-team/security-release-numbers-and-release-timing)
- For Drupal core the **bug fix/feature** rele1ase window is on the **first Wednesday of the month**.
- Security releases happen between 16:00 UTC and 22:00 UTC.
- D.O. Security updates list: <https://www.drupal.org/security>
- D.O. Security updates Twitter alerts: <https://twitter.com/drupalsecurity>

## When to do the updates

- Always use a maintenance window and a **shared calendar** (with the customer) to plan the updates. For example. you should not do the updates (even if there is a sec. issue) when the site is having a high traffic campaign.
- Prefer the same dates as Drupal core security releases. For example, **the third Wednesday of each month** is a good option to plan for updates.
- ASAP when the security issue is of high priority.
- Do not do the updates late on the day (at least 4 hours before leaving the office) or on the last day of the week (eg Friday).
- Try to do the updates when all the related parts are active (developers, sysadmin, hosting provider, customer etc)
- Do not plan for updates then other systems (eg the Hosting Provider) is also having a maintenance window.

## Best practices

- Security updates should be done as a "**first level task**" and not as a minor boring task.
- During the update the developer(s) should always follow all the steps even if you are sure they are not needed.
- During the update the developer(s) should not be tired, doing multitasking, talking on the phone etc.
- During the update the developer(s) should not be on a hurry when doing the sec. updates.
- After the update the developer(s) should monitor the site for some time and be ready to revert/act if anything happens.
- Demand a **content freeze** during the updates (you can use the module [readonlymode](https://www.drupal.org/project/readonlymode) or the core **maintenance_mode** variable for that).
- Maintenance windows (date or range of dates).
- Maintenance calendar (a shared calendar where the site owner should mention which dates should not be an option for security updates).
- Maintenance emails (inform the customer about the **upcoming** update, inform the customer about the update **happened**).
- Create a technical report about each update (git tag/commit, Drupal core, Drupal contrib versions, PHP packages versions). You can use tools like [generate_drupal_report](https://github.com/theodorosploumis/generate_drupal_report).
- Add **datetime to bash history** so each cli command has a datetime entry.
- Use a special **cli color when ssh on a Production server** (eg make it with red background).
- Allow for emergency **system rollback** from the UI (code, database, public files). This is needed in cases where an error occur after a sec. update and there is lack of communication between the sec. team and the site owner.
- First complete the sec. updates on a **full copy of the Prod site (code, db, public files, same server config)** before doing the same on Prod.
- Establish a **manual (UAT) testing** guide to allow the customer check the updates.
- Establish a **clean plan about the responsibilities**. Who is going to have each responsibility, which are the communication options (email, phone etc), which are the tasks need to be done when a problem arise etc.
- If there are **many companies or vendors evolving** be careful about any misunderstands and delays that may happen due to the number of the people evolved.

---

## Monitor site health

- Uptime monitoring (external SASS, eg [uptimerobot](https://uptimerobot.com), [New Relic](https://newrelic.com))
- Get SMS and email alerts for PHP fatal errors on Drupal

---

## UAT examples for Drupal

- View a node (for each bundle)
- Edit a node (for each bundle)
- View a list (views)
- User login works
- Webform submissions work
- Search works
- Cron task works
- SMTP and mail system works
- There are no JS errors on console

---

## Related guides

- [Drupal report](https://github.com/theodorosploumis/drupal-report)
- [Generate drupal report script](https://github.com/theodorosploumis/generate_drupal_report)
- [Notes: Drupal Contract](contract.md)
- [Notes: Deployment workflow for Drupal](deployment-workflow.md)
- [Notes: Testing Drupal](testing/README.md)
7 changes: 4 additions & 3 deletions drupal/testing/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -37,10 +37,11 @@

## Examples

What to test with a Drupal project:
What to test for a Drupal project:

- dev\* and \*\_ui modules are disabled on Production
- A user for Role X can submit a node form
- A user of Role X can submit a node form of a bundle
- A user of Role X can view a node of a bundle
- New site can be installed from configuration and/or demo content
- REST API (CRUD operations)
- REST API (get Nodes single, list, filtering, pager)
Expand All @@ -52,7 +53,7 @@ What to test with a Drupal project:
- REST API (security test)
- REST API (Permissions)
- Functionality (eg module API, test functions)
- Permissions (eg a Druapl user can access a page)
- Permissions (eg a Drupal user can access a page)
- Integration (eg PHP versions, dependencies versions, Drupal core versions)
- UI (Expected behavior on a Drupal page)
- Code validation according to standards
Expand Down

0 comments on commit edabf9f

Please sign in to comment.