Running Drupal Sites That Cannot Fail

Andrew Kenney, VP Cloud EngineeringCash Williams, Technical Architect

What we’ll cover...• Overview of Drupal sites that “cannot fail”• Recommendations for maintaining secure, highly

available Drupal sites• Concepts of the Shared Responsibility Model and

Defense in Depth• Incident response planning and minimizing risk to

Drupal sites

Is it possible?

Can a Drupal site be built so it “cannot fail”?

Reality Check

• No site is perfect …• You must plan for failure in the cloud• No plan is perfect• Security is a continuum

Everything can fail

• Machine loss / service outage

• Network disruption• Storage system,

database, etc. failure

• Traffic spike / DDOS

• Failed code deployment

• Bad code• Human error• Security attack

Security failure points• Application vulnerabilities

• SQL Injection• Broken Authentication• Cross Site Scripting• etc.

• Vulnerable systems• Unpatched services• Privilege escalation

attacks

• Network attacks• DOS & DDOS attacks• Network intrusion

• Social engineering• Phishing & Spoofing

Shared Security Model

Because we’re all in this together...

Shared Security Model• Shared responsibility between

Acquia, our customers, and our infrastructure provider (AWS)

• Customers depend on service providers to continually improve and enforce security

• Customers must themselves ensure application and application SDLC are secure

How Acquia helps customers’ security

Acquia Cloud PaaS provides the space to build, test, tune & deploy web apps in a secure way.

Every layer of the PaaS is optimized for Drupal to maximize security & performance.

Acquia Security Tools & Services• Subscription Security

• IP Whitelisting• Strong Passwords• Two Step Verification

• User Accounts & SSH Keys• Teams & Permissions• Insight - Security Tests and

scoring for all sites

Backups & Disaster Recovery• Use automation• Test backup and

restoration procedures often

• Secure backups

Defense in Depth

A layered approach to security

Defense in Depth• Multiple layers of security

controls• Covering personnel,

procedural, technical and physical

• Goal = buy the organization time tohandle an attack

“a security officer’s best hope is to layer on many different defenses — strong passwords, two-factor authentication, antivirus software, firewall protection, breach detection plans that can sift through vast amounts of employee data in search of anomalies — then pray they never make the headlines”

http://bits.blogs.nytimes.com/2014/08/30/getting-a-clear-picture-of-a-computer-networks-security/?_php=true&_type=blogs&_r=0

Defense in Depth importance

Defense in Depth layers

• Anti-virus software• Authentication and password

security• Biometrics• Demilitarized zones (DMZ)• Firewalls (hardware or software)• Hashing passwords• Intrusion detection systems (IDS)• Logging and auditing

• Packet filters• Vulnerability scanners• Physical security (e.g. deadbolt

locks)• Timed access control• Internet Security Awareness

Training• Virtual private network (VPN)• Sandboxing• Intrusion Protection System

From: http://en.wikipedia.org/wiki/Defense_in_depth_(computing)

Defense in Depth in practice

From: http://en.wikipedia.org/wiki/Defense_in_depth_(computing)

Acquia Compliance

• Acquia is pursuing a FedRAMP Agency ATO with the Department of Transportation

• Acquia is a QSA Audited PCI-DSS Level 1 Service Provider

• Builds on AWS Credentials to provide a consistent platform across IaaS and PaaS for Customers to build PCI Certified Apps

Incident Response

Preventing catastrophic failures and loss of control

Incident Response Plan• Documentation & Artifacts

– Incident Response Plans– Call Trees

• Training– Employee onboarding / LMS courses– Continual training

• Testing– Quarterly or yearly tests (mock or real scenarios)

• Regular review– Retrospectives & post-mortems– Review as part of compliance

Heartbleed bug• Patching Acquia systems was only part of

the response, it also included:• Working with vendors• Documenting how to overcome• Proactively notifying & educating

customers• Post Mortem for incident lead to us adding

an Incident Commander role for future events

Real World Preparation Scenario• Large, multinational sporting event

– Over 100k hits/sec at peak. Nearly 40 billion hits over the course of the event

– Acquia Live Event support– Load tests & mock scenarios ahead of event– Boots on the ground during the event– Multiple layers of defense to protect against cyber threat– Hardened Drupal site & infrastructure

Drupal Security

Keeping the largest open source project in the world secure

Process, not a Product• Like everything else here a secure Drupal

site is a process• Having a secure product on launch day

does not mean you are secure a year later• Audit, and audit often

Audit, Audit, Audit• The site build

• Module selection• Views/Panels access controls• Development vs Production settings• Development modules enabled

Audit, Audit, Audit• All user accounts

• Ensure account should exist• Ensure roles are appropriate

• All permissions• Code change means permission

change

Audit, Audit, Audit• Custom code

• Majority of vulnerabilities I’ve found on client sites is in custom code

• Themes are typically the most vulnerable

Audit, Audit, Audit• Ensure all “public code” is up to date

• Drupal Core• Drupal Contrib modules and themes• Non-Drupal code, such as JS libraries

etc

The Drupal Security Team

How the team works and how to work with them

Drupal Security Team• Team of volunteers• Works to track and resolve reported

security issues• Provides Drupal security documentation• Bridge between Drupal and other open

source projects

Know When Updates are Released• Signup for emails from the Security Team

(drupal.org/user)• RSS Feeds (drupal.org/node/406142)• @drupalsecurity on Twitter• Drupal’s update status module

Drupal security best practices

Additional tips

Where is your data?• Non-production environments

• drush sql-sanitize• Code Repository

• http://rosspenman.com/api-key-exposure/• Use encryption

Editorial Domain• Sites where a small set of trusted users login

from a known location• Most of the traffic is public and cached• edit domain does not need to be public DNS• https://www.acquia.com/blog/protecting-

drupals-fleshy-underbelly-htaccess

Security Modules• Paranoia• SecKit• TFA• Security Review• Acquia Connector

Security Modules• When using local Drupal accounts

• Password Policy• Login History• Email Change Confirmation

Security Modules• If usernames are “sensitive”

• Real Name• Username Enumeration Prevention

Questions?

andrew.kenney@acquia.comcash.williams@acquia.com