Open-Source CMS Security In The Enterprise
Regardless of the size of your organization, the security challenges with open-source Content Management Systems (CMS) security are the same. In the enterprise the issue stems not from the technology or existing processes, but the fact that security is slipping through our fingers. We’ve made it too difficult for our counter parts in marketing and sales, and where there is a problem new solutions step in to solve them. We see this being enabled by the explosion of cloud platforms like Platform as a Service (PaaS), Software as a Service (SaaS) and technologies that easily work in those environments like open-source CMS applications.
As a community we have to do something about this. These activities stem from the perception that IT / Security is always going to say “no” or “make my life too hard” and I can’t help but think there is a better way to handle this. To do this, we have to be prepared to embrace technologies like open-source CMS application and be willing to silence our personal biases towards them (i.e., WordPress is insecure, which is grossly untrue). A good first steps is better understanding how these technologies might fit into existing governance and their associated security policies and tools.
Accounting for Website Security in The Enterprise
Open-source CMS web applications are no different than any other applications enterprise security teams are responsible for. The principles like Defense in Depth still apply, and integrating things like Prevention, Detection and Response solutions are just as critical. The difference being that in the enterprise, these aren’t new concepts, yet when it comes to open-source CMS applications they’re dismissed.
Compromises within the open-source CMS domain are achieved through two key areas: access control and exploitation of software vulnerabilities. Here are a few tips to help enterprises think through the security challenges they face:
1. Asset Accountability
There is one common theme with every organization I’ve worked with, no one seems to know how many website assets they have. They are owned and managed by different groups, they bypass all existing IT / security controls, and they’re distributed across internal and external infrastructure.
Before an organization can deploy any security controls, they must understand what they’re working with.
2. Security Monitoring (SM)
The concept of security monitoring should not be a foreign concept. It’s the collection and analysis of data to help you detect and respond to intrusions. Technologies like Host-Based Intrusion Detection Systems (HIDS), OSSEC, exist to help you with this process and work seamlessly on the web server. It tracks and records all application level activity, including but not limited to file integrity issues within the applications core files and the application access logs. Take that information and pipe it into your Security Information and Event Management (SIEM) system.
3. Indicators of Compromised Behavior (IoCd-B)
Evolve the way we think about our monitoring, expand our thoughts on identifying malicious behavior and turn our attention inward to what we would otherwise categorize as benign behavior. My partner, Daniel Cid, talks to IoCd Behavior; it’s the idea that we have just as much to learn from the habits of our website users than we do from the actions bad actors take.
If we expand on the idea of IoCd-B we can ask:
- What times should people be able to access your website?
- What times should people be allowed to log into your website?
- Should people be able allowed to initiate Post requests? or will Get requests suffice?
- Who is logging into your environment? Where should they be logging in?
- What is changing on your website? Should that article, post, page have changed?
4. End-point Hardening
When we’re talking open-source CMS applications, the end-point becomes the web server. There are a number of things that every enterprise should work to employ regardless of platform:
- Functional Isolation to reduce the odds of cross-site contamination;
- Disable PHP execution in most directories, especially image, cache and upload directories;
- Remove web server writability of application files;
- Include the web enviornments into your existing update and maintenance regiments;
- Reduce server level access in production, and introduce staging environments;
It’s unfair to expect any security team to stay ahead of every threat, it’s why these steps are platform agnostic and designed to assist in the process. Most organization employ some form of a vulnerability management programs, leverage tools where possible to assist you in better understanding potential software vulnerabilities within the specific platforms.
- Droopescan for Drupal
- WPScan for WordPress
- Joomscan for Joomla
These tools are designed to help you identify potential issues in the core of the application and it’s various extensible components. They include detection of the top 10, and more, vulnerabilities as defined by the Open Web Application Security Project (OWASP).
5. Extend Perimeter Defenses
We employ technologies across entire network for both prevention and detection, now it’s time to extend those technologies to help with websites specifically.
There are Intrusion Detection Systems (IDS) designed to specifically monitor websites and report on any potential Indicators of Compromise (IoC). Indicators like malware distribution, SEO Spam, Phishing Lures, and a number of other nefarious acts. As well as indicators that include changes in uptime, anomaly behavior in the website responses, DNS changes, and file integrity issues.
Additionally, extend local and network firewalls to account for website / application specific traffic and attacks, and we do this through the employment of technologies like Website Application Firewalls and Intrusion Prevention Systems (IPS) designed specifically for websites. These technologies are designed to specifically help with the access control and software vulnerabilities that all open-source CMS applications face.
Security in the Enterprise is Achievable
We have to start putting more emphasis on our entire stack, and that stack includes all external properties – including websites. Most organizations already have the teams and governance in place to address the challenges, but they fail to correlate the relationship between these technologies and their existing environment.
One trend I do see some enterprises taking is out-sourcing their website needs to fully-managed environments. Environments like InMotions Drupal managed hosting and WP Engine and Pagely for WordPress. They are also complementing their services with security focused services, like Sucuri – a platform agnostic security provider built for open-source CMS applications.
Security is achievable in the enterprise. We just have to evolve the way we think about it.
Open-source CMS applications are no stranger to the battle they face with security. The size of the organizations adopting the platform also has little to do with it – from bloggers to mom and pop shops to Fortune 500 companies; the concern is the same. Can open-source CMS applications be deployed securely within their respective stacks?There are those that look at open-source and have a general distrust for it. The idea that people can see the code and submit patches makes them uneasy. There are also those who can’t get their head around the general ambiguity of open-source, in which the code belongs to no-one and everyone. What they don’t realize is that most open-source projects have a stringent commit process.