DrupalCon Baltimore 2017 — Backend Security notes

Duke University IT Security Office’s PDF is found here here

1. Physical aspects:
   • Access-controlled server rooms
   • Authorized physical access only
   • Log all access as required by data
2. Network aspects:
   • Appropriate Host-based access controls, i.e., firewall, port control, access lists)
   • Require secure remote access, using VPN or SSH
   • Encrypt all authentication traffic
   • Log all network-based server access
   • Third-party Vendor requirements
   • Avoid authentication trust relationships
3. Operating system
   • Login prompts to remind users regarding prohibition of unauthorized access, lack of privacy for its users, last access time stamp
   • Disconnect inactive logins
   • Strip banner and error messages regarding system information
   • Mitigate announced vulnerabilities within a reasonable time-frame (same for applications)
   • Install anti-virus for periodical full storage scan
   • Approved OS’s only
   • Disable host web browsers that do not receive automatic browser updates
   • Routine scheduled downtime to mitigate vulnerabilities
   • Device reporting on the above configuration for department review
4. Data
   • Protected data heightens access requirements
5. Application
   • Ensure development tools, code samples, and the like, are removed in production
   • Vendors must incorporate security in the initial design phase
   • Develop on non-production servers only
   • Use de-identified data for development and testing
   • The principal of least privilege: apps only access what they must.
   • Username password credentials must not be stored in the program source code
   • Hash passwords, 3DES minimum
   • Publicly-accessible apps must not execute OS shell commands or pass non-admin user input to the shell
   • Remove commented code from production apps
   • Disable path traversal and directory browsing
   • Leverage Drupal’s input validation mechanism for all input data. Sanitizing input alone is insufficient.
   • Authenticate all credential data
   • Robots.txt can unwittingly provide path data, do not rely on it
   • Periodically review Drupal and OWASP requirements
6. User and accounts
   • Use Shib for Drupal user management.
   • Do not share user accounts. One person per account.
   • Regularly review user membership per site
   • Revoke user access within one business day for exited employees
   • Remove accounts inactive for 3 months
   • Admin users must change passwords every 180 days
   • Use the principal of least-privilege regarding account access. Do not require an admin account for site backup
   • Encourage MFA
   • Vendors must have guest NetID accounts, managed by their departments
7. Tools we use:
   • Fail2Ban
   • Splunk
   • Ansible
   • Tivoli
   • Autofs
   • Shibboleth
   • Composer (D8)