CMS Security Justin Klein Keane CMS Working Group March 3, 2010

Overview Background in CMS development  ASP, Java, Cold Fusion, Perl, Python and PHP CMS security generalities  Specifics drawn from SAS deployment of Drupal

Insecurity is a Given Software engineering studies show bugs per KLOC  Predicatable average # of bugs in code  Some portion are security related Some vulnerabilities are not functional flaws Information security is an evolving space

Considering a CMS Given any system chosen will be insecure: How do you choose a CMS?

Ubiquity How widely used is the CMS? Recognize this could mean higher risk Wide use may also mean more eyeballs  But not necessarily

Modularity Is the system monolithic?  Important in understanding impact  Also affects upgrades How does modularity affect scope?

Patch Management/Upgrade How easy is upgrade?  Monitor for advisories  Evaluate  Acquire  Prioritize and schedule  Test and approve  Create and test deploy  Deploy  Confirm  Clean up  Document

Compartmentalization Complexity is the enemy of security What is level of dependence in the system?  OS, web server, db server, programming language, etc. Component security concerns How sill component security affect the CMS?

Measuring Vulnerability Tempting to measure reported vulnerabilities  Potential false metric (more eyes = more bugs) Mean time to patch is a good metric Severity of vulnerability Better metric is project activity  People involved, update release, community “noise” Healthy dev community = faster patching

Maturity Not necessarily longevity How closely does the CMS model a “real” enterprise system? Established security team Security reporting and response procedure

User Management CMS offers power to users in varying scale How is privilege separated Can you disable/protect dangerous permissions?

Configuration Consider: Many security flaws are configuration issues How can configuration be changed to increase the security posture of your CMS? Are there security configuration guides/guidelines available?

Security Testing Automated web app testing in infancy  If used be sure to test behind authentication Manual testing is still the best way Complexity of systems obviates advantage of source code in many cases System should be tested as a whole before deployment Components should be tested prior to install Patches/upgrades should be tested Commit to a continuous security testing cycle If you don't have resources is it possible to leverage others'?

Commitment to Security Must be ongoing Security space evolves Systems are digital bonsai trees Look beyond the CMS to supporting  Technology  Process  configuration

SAS Practice Published security guidelines  Setup and Configuration guidelines Approved modules  Module approval procedure Dedicated security team doing active research

Questions?