[documentation] security pages in handbook

[Laura Scott]

Greg, I think this is a great idea. I have a concern that this  
hierarchy might miss some important user experiences when the  
audience/users you identify go to the security area of the  
documentation.

> ++Proposed hierarchy:
> 1) Security team, including our processes - http://drupal.org/node/ 
> 32750
> 2) Coding - http://drupal.org/writing-secure-code
>   2.a.) breakdown of specific topics by "what you want to  
> do" (current system)
>   2.b.) cross-reference of 2.a. broken down by attack vectors (e.g.
> XSS) and how to prevent them
> 3) Drupal Configuration Weaknesses (e.g. filters, permissions, etc)
> 4) Web Server Configuration Weaknesses (e.g. allowing the apache user
> to write to all files)
> 5) Useful security related contrib modules (remember me, paranoia,
> login_security, openid)

What if we focus on what the user might be asking in going to these  
pages? We could focus on the fundamentals from the perspective of the  
question asker. In that sense, perhaps a structure might be:

0. Drupal Security Update releases. (This should be the first and  
last thing on the main page, imho. Maybe a direct link to the email  
subscription page, too.)

1. Why pay attention to security?
(I suggest this because many admins and evaluators are unaware that  
security updates are important to pay attention to and deploy. They  
come looking for free software and maybe heard great things about  
Drupal. Even many coders out there also seem to be rather ignorant of  
security issues. Witness how many [insecurely] hacked versions of  
core are being brought to consultants for repairs etc. It may seem  
obvious to us that security is essential, but the ignorance out there  
re even the importance of the subject is appalling.)

2. Secure site administration: Making your Drupal site secure.  
(Starting at the site admin level, most basic: Secure Drupal  
configuration settings, basics on filters, permissions, etc.)

3. Secure systems administration: Configure your server with security  
in mind. (e.g., apache permissions, etc.)

4. Secure Drupal development: Writing secure code. (An entire section  
for developers. Include all appropriate sub-topics.)

[Then moving on to resources, but keeping the items top-level so they  
are visible and easy to find and get to....]

5. Helpful modules. (paranoia, openid, update status, etc.)

6. Drupal Security Update releases. (A reminder that this is where  
the latest security updates can be found. Maybe a direct link to the  
email subscription page, too.)

7. The Drupal Security Team (who, what, how, etc.)
I don't mean to diminish the importance of the fabulous people  
working on this by putting this last, but from an end user standpoint  
the "who" is the last question when it comes to security. It's the  
reassurance at the end, that excellent, capable people are "on the  
job" regarding security (and maybe an invitation for security-savvy  
community members who might want to offer their expertise?).

??? Do we also want a section like "What to do if your site has been  
hacked"? This could be some hints and resources on diagnosing what  
has happened, because if you already have a problem, you can't solve  
it until you've figured out what happened, right? This could be a way  
of generating case studies that illustrate why all these best  
practices are so important.

Is this helpful?

Laura