1 / 16

CMS Security

Justin Klein Keane CMS Working Group March 3, 2010. CMS Security. 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.

jacqueline-nieves
Download Presentation

CMS Security

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

  3. 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

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

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

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

  7. 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

  8. 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?

  9. 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

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

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

  12. 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?

  13. 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'?

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

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

  16. Questions?

More Related