Automate validation of security review so that manual intervention isn't required.

One of the biggest problems is that while a host could create one secure install and get the badge, how do we know ordinary joe signing up gets that?

We should fix this problem by coming at it from a different angle. The hosting page was originally created to do two things (1) Generate funds for the project and (2) highlight the growing number of hosts that supported Drupal. When the page was created several years ago not a lot of hosts knew what Drupal was. This page showed the world that a growing number of hosts supported Drupal.

"Look at us.. We're growing.. Look at these hosts.. see.. see. we're going places" .

At first there was 1, then 2, then 10, then 40, then 100... now there are 1,000s. The Drupal project has come of age and almost every host supports Drupal. As a community we accomplished goal #2. Drupal Rocks!

Now we need to focus on #1 and change #2

Our core mission is to develop Drupal, advance the project by making bad-ass software, and support a rocking community of contributors. We no longer need to highlight the 1,000s of hosts around the world that support the Drupal project.

The hosting page should be used for two things. (1) Generate funds for the project and (2) Highlight amazing hosts that are doing extraordinary things for the Drupal project. Hosts are a very important part of the Drupal lifecycle and several hosts are really helping to advance our goals and we should highlight their work.

I propose that we first drop a large number of the hosts listed and add back only two types of hosts (1) Those contributing to the project and (2) Those financially supporting the project. Of course *all* hosts must maintain a great reputation, make us look good, and be secure. We will *never* arbitrarily add hosts without vetting them (no matter how much cash they give us). I propose that we list a total of only 10 hosts.

With this shift the process of approval will change:

Currently the process is the following:
1) Host performs a security self-test
2) They submit the security self-test results as part of their application
3) The Security team performs a test on their system to verify the results
4) DA Staff (Megan and I) review the company
4A) We check BBB ratings, Google Reviews, and check the state of the company
4B) Do they contribute? are they a reputable company? Will they make the project look awesome?
4C) What are they doing for the project? Are they contributing code? documentation? cash?
5) Judgement call. On the page or not.

I want to flip this completely to the following:
1) Apply
The application will include information on what the company has done for the project and what they are willing to do. Have they contributed code? documentation? ran amazing camps? etc. In short tell us why you are awesome and should be listed

Most hosts will simply offer a cash payment and that's great because we'll use those funds to buy servers, diversify our revenue away from DrupalCon, and help create a more robust project. (free DrupalCon anyone?)

2) DA Staff reviews the company
Are they awesome? What are their reviews like?
What have they contributed? What will they contribute?
... A human review to ensure that as a project we're aligning ourselves with great companies. It is very important to us that we are always aligned with great companies. We recently moved away from GoDaddy because they were against our values, the same applies to *all* hosts listed on this page. Be awesome.

3) Ensure they are secure
Once the DA Staff has verified that this is a great company and a great addition to our project then we will perform a security review.
If and only if they pass the security test we'll post them to the page.

The difference may be a small flip to the process but it is not subtle. The problem we are running into now is two fold.
(1) We communicate that we'll list everyone that passes the security test (mistake)
(2) Hosts run a self-test and pass (no surprise here)
Later they get bogged down in the process and get frustrated and angry. Honestly I think it is rightfully so, the process is flawed.

I am very clearly stating that the hosting page is not central to our project and putting time and effort into an automated testing platform is a distraction. The page should not be open to every host in the world. It should be open to only those that are going to help make our project be amazing. Standard business drivers will keep these hosts on their toes after they are listed, we don't need automate testing.

Be awesome to be listed. I see no value to our project to maintain our current process.

Let's shift our time and energy to creating a better process for Drupal based businesses to be listed on the Service page and in the marketplace. We are currently frustrating a growing group of Drupal contributors and Drupal-based businesses by not defining an on-ramp process for these companies. Let's fix it. The hosting page is a distraction.

I'd love to see time and energy put into resolving: http://drupal.org/node/1103306

My $0.02. Actually more like $2.00 based on how long this is.

The Security Review module is quite helpful for individual sites to determine their Drupal-specific security posture. It can help a site owner tweak settings, permissions, and the like to improve their security. That being said, I don't think it is a very good barometer of whether or not a hosting company should be depended on for having a solid security program in place.

At a high level, I look at security as an ongoing process and I'm sure you all do as well based on reading your posts on the other thread. This includes everything from policies and procedures to software development practices to system administration standards to supplemental maintenance practices such as patching. While passing a single run of the Security Review module may be a good thing, it's all for not if the host is running php 5.3.9 and didn't immediately update to close the remotely exploitable vulnerability. The same is true for the local Linux kernel privilege escalation bug a few weeks ago. A one-time pass of the Security Review module isn't a bad thing, but to an uneducated end user it could lead them to believe they have a secure hosting platform when in reality they don't. The issue is that end users can't effectively determine the security posture of the host because they lack enough information (both on questions to ask and answers to those questions.) My feeling is that any badge that is awarded should be granted with a big disclaimer that this does not mean the hosting provider is secure.

This brings up a larger question of security certifications and vendor management. It's a difficult and unsolved problem at all levels. How many of the big breaches in the past year or two have been at companies that are PCI certified? Multiple, and it's not surprising. And achieving PCI certification is far from easy or cheap if you are doing anything beyond a self-assessment questionnaire.The Cloud Security Alliance also has a nice series of reference controls but no real method of ensuring compliance via third-parties. As for vendor management, lots of work in that area but still a big lack of standardization. The Shared Assessments group is gaining ground in financial services but it's not free and is VERY lengthy to answer all of the questions.

My very wordy point is this: Security Review is an excellent module and I'd recommend it to anyone. But I don't think it should be a hurdle to listing a host on Drupal page nor do I think passing it should confer a badge or other distinction (at least not without a disclaimer). Perhaps instead what we should ask is that each host that is listed establish a page on their site describing their security posture, and not in marketing terms. Amazon is a great example of what this could and should look like. This could provide their certifications, white papers, descriptions of controls or audits, FAQs, and contact details on how to report security issues.

I'm always happy to help pitch in with this as well, either with third-parties or with the process.

While security is an ongoing process most hosts easily deal with that by using the OS' own security bugfixes. As for the bugs you linked, the hashtable bug is not a remotely exploitable vulnerability, it's one DDoS possibility, if you are running Drupal (or for that matter, any complex enough PHP script) you already a ton of DDoS options :(

Local kernel escaltion bugs are, again, less of concern cos you cant run your own binaries, most places/

What we do care about is a sane base level of security, something an ordinary Drupaler can rely on. That's it. We can't verify the whole stack, we can't verify whether their shared phpmyadmin is insecure as hell etc. We do what we can.

Now re #2, only 10? How much money can that generate? I would be shocked if ten sites would pay a million bucks a year (which is my rough estimate on the DrupalCon ticket revenue.)

@rjbrown - "I don't think it is a very good barometer of whether or not a hosting company should be depended on" - your solution is much more work than what we currently have. I think that makes it a non-starter.

@chx $1M/year is within reason.

@webchick The problem with an automated solution is that we would need the hosts to automate not just one site but also the continuous re-installation of a default Drupal site. I think most hosts would not be willing to do that and we'd still have to trust they aren't lying to us or do a periodic audit, so it creates more work up front (building the tool to verify their install) and doesn't reduce long term use.

@jredding - flipping the order makes a ton of sense to me.

@chx the best way of increasing the funds for our project from that page is to increase traffic. We can take some cues from Wordpress's 1,2,3 step program. Step (1) Choose a host. Step (2) Download.. see: http://wordpress.org

They push a ton of traffic to the hosting page that lists only four exclusive hosts. Those hosts pay a pretty penny for the privilege of being on that page.

Like the Marketplace we should use this leverage to encourage every company to contribute to the Drupal project.

[edit] link added

Ideally, my solution would be to drop the security component of it completely and do one of two things: 1) Educate the user on how to ask good questions to make informed security choices about their provider, or 2) Ask the vendor to place public statements and pages about their security posture to try to help educate their potential customers.

Either way, it gets the broader Drupal community out of the mix of trying to do service provider security assessments that are point-in-time snapshots of only one aspect of a provider's security posture. I'm only focused specifically on the security aspect (and not the community involvement/funding). I don't think either of these would take more time than what is being done today.

I'm open to rjbrown99's proposal, but:

I don't think either of these would take more time than what is being done today.

You must work in an environment where technical copy is easy to get written, published and approved ;)

I guess it's all relative - I work in information security so I write stuff like this constantly. We are a service provider in a highly regulated industry so our team is on the receiving end of the vendor management stick from our customers. I'm happy to try to take a shot at this, or at least start a wiki page somewhere to collaborate on a basic set of due diligence questions to ask vendors. Perhaps a wiki page on the security group of groups.drupal.org as a starting point?

I have no real considerations on the broader issue of who is listed on the hosting provider page, community support, what it takes to get there, etc - my interest is in the security part and trying to help educate folks on what to do and why.

Perhaps a wiki page on the security group of groups.drupal.org as a starting point?

An offer to write more documentation on how to have a secure Drupal hosting company? The answer is absolutely yes!

There's also a hodge-podge of information at http://drupal.org/security/secure-configuration that you may want to reference, improve, or incorporate your content into (or all three). If you can't edit any of those pages feel free to contact me and I can fix that.

Sounds good, I'll have a look and give it a whirl. I do appear to have edit access to that page already. Perhaps adding a new child page "selecting a service provider" would be a place for some of the information.

@rjbrown99 - did you make any progress on writing that page?

@all - this issue is in the security_review.module queue but I'm not sure of much left "to do" here that's related to the module. Should we move it somewhere else? Close it? postponed (nmi) status for that question.

@greggles - Yes and no :) I'm running into a bit of trouble as I wouldn't personally trust shared hosting but I know lots of other people would. I also fear that the questions I am asking are so granular that I'm doubtful most providers would answer in detail, and if they did I'm not confident users would have enough background to understand what the answers mean to the choice.

Here's what I started with.

1) Does the provider have a web location where they regularly communicate and update security, compliance, and due diligence information? This includes a list of any security certifications or accreditations such as SSAE16, PCI DSS, etc.

2) How does the provider handle patch management for the environment, including security fixes to the PHP interpreter itself?

3) Does the hosting company provide an SLA as to how quickly critical security fixes are implemented? For example, how quickly after the release of PHP 5.4.3 will it be required in production?

4) How does the provider handle security of the PHP interpreter? More specifically, what mechanisms are in place to isolate PHP process ownership to each of your hosting provider accounts, such that customer A can not access customer B's source code or data?

5) How is PHP session data stored, and how do you ensure that customer A can not access customer B's session details?

6) Are database access credentials separated on a per-user/account basis?

7) Are filesystem-level permissions to PHP scripts separated on a per-user/account basis? IE, each customer has a different userID at the operating system level and restrictions are in place disabling the ability for customer A's account to access customer B's data.

8) What individuals at the hosting provider have access to the customer PHP source code, and in what circumstances will those files be accessed?

Closing as outdated after 6 years as we transition to Drupal 10.

I'm keeping an eye on the 7.x branch of this module, reviews and majors, but active work is going toward 42x (supporting D10)

If valid for 2.x please reopen