Drupal Security: There is a Mini-DrupalGeddon every week & how to survive it

Michael Schmid & Manuel Pistner

Michael Schmid

CTO at Amazee Group (amazee.io, Amazee Labs, Amazee Metrics)

Welcome

The security process

Manuel Pistner, CEO at Drop Guard

How a security patch is released

● User submits patch on special issue queue

● Security team reviews it

● Security team contacts maintainer

● Patch released by security team & maintainer

Security patch release

● patch is publicly available

● conspicuous vulnerability → hackers know how & where to hack

the several versions now

● site update needed in time!

The security levels

● Not Critical: scores between 0 and 4 ● Less Critical: 5 to 9 ● Moderately Critical: 10 to 14 ● Critical: 15 to 19● Highly Critical: 20 to 25

0 day release idea

Why do we need to update?

Update even not enabled modules!

DrupalGeddon: first attacks just 7h after security update release

Drupal 8 & Front-End Build systems: external libraries

Every library as an item of any upcoming software needs individual protection

How to stay informed

● Drupal.org

● Newsletter/ Mailinglists

● RSS Feed

● Social media (Twitter, LinkedIn..)

Manual process

● “drush updb”, check patched core/ modules

● Manual QA

● Ticketing system

● Stakeholder communication

● Deployments

● and so on!

How it feels like:

And now:

Do this in 7 hours. At 4 am.

With 100 sites.

The solution:

Automate every piece of itthe hackers are doing it as well

Needs for automation

● Monitoring

○ Current Module Version

○ Available Module Version, plus security level

● Patching

○ Regular Patching, Patch detection, Composer,

Git Submodules

○ Failure Handling -> Ticketing system

● Git support

○ Push into different Git branches based on

security level

Needs for automation

● Testing

○ Integration into Continuous Integration System

● Fully Automated Deployments

○ Running Deployment tasks

● Reporting

○ Ticketing system

our solution

Drop Guard Monitoring

● Installed Drop Guard Module on each production site● Monitors each Module for version● Compares to available Modules from drupal.org

Drop Guard Patching

● If new Module version available○ Check against security levels○ Automated applying of security patch to

Core or Contrib Module○ Commits into Git production branch

● Supports plain code, git submodules, composer

● Reports into Jira (errors or success)

amazee.io deployments

● Full automatic deployment on new push into branches

● Possible deployment tasks○ drush updb, etc

Drop Guard

● different processes based on security levels

● non-highly critical patches applied to another branch

amazee.io

● syncs database and files from production to testing site

process

● after testing done, manual merge into production branch

automated testing● visual regression testing● Unit Testing inside Docker containers

Demo

Highly Criticaldirectly to production (master)

Criticalto dropguard branch (with sync)

FIND USthere will be demos!

Drop Guard - Booth #105amazee.io - Booth #700

JOIN US FORCONTRIBUTION SPRINTS

First Time Sprinter Workshop - 9:00-12:00 - Room Wicklow 2AMentored Core Sprint - 9:00-18:00 - Wicklow Hall 2BGeneral Sprints - 9:00 - 18:00 - Wicklow Hall 2A

Evaluate This Session

THANK YOU!

events.drupal.org/dublin2016/schedule

WHAT DID YOU THINK?