Security

As we've just seen recently with References project SA followed by the module being marked as unsupported, though this is just an example of many, this may be a major issue for thousands of sites using a module. May be you cannot disable it right away, there may be available replacements or not, but in any case this way of doing things (Unspecified SA, then Unsupported) is putting thousands of sites at risk.

I believe there should be better ways to handle these cases and though I don't know how exactly, it will need some discussion, here are just some ideas about it:

We have clear(-ish) instructions on how to report a security issue but we don't clearly define what we consider not to be a security problem. It would be useful if we had a clearly defined list of things that are not considered security issues to reduce the amount of issues being opened unnecessarily, thus reduce the amount of time needed to triage the security issue queue; also, this list should either be present on the "how to report" page or at least linked off it right at the top of the page.

We need some clarification and standardizing around how to handle an issue logged on the public drupal.org site for a project which is covered by the security team. There currently isn't a standard process, though the following appear to be the defacto process:

• The node is unpublished.
• An sdo issue is created if needed.
• The person is added to the sdo issue.

This leaves a few open questions:

<

ul>

Disclaimer

As I don't find a issue queue for the security team (probably a good thing), I am posting this here.
Thanks @DamienMcKenna for pointing me to this direction.

Problem/Motivation

Currently the security updates window is every wednesday between 12 noon and 5pm Eastern time.
Depending on where you are in the world, this might be outside office hours.
Belgium is such a case, where the release window is currently between 5pm and 11pm.
Such a wide release window makes it very hard and expensive for individuals to be on call for possible releases.

Problem/Motivation.
Drupal stores data for each entity in few tables: base table, field tables, revision table, field revision tables. It becomes difficult to support script for cleaning database when we have a lot of entities in a project and structure of entities are changed periodically.

Existing method of cleaning database from personal and critical data drush sql-sanitize command has few restrictions: need to implement hook_drush_sql_sync_sanitize in your modules and write all sql commands manually, need to keep in mind entities structure and it doesn't have UI.

Hi,

I'm excited to announce a new feature in the paranoia module: database sanitizing based on a whitelist.

The main way to sanitize databases now is drush sql-sanitize which works on a blocklist approach. If you add a module or table to your site that stores data in the database that you want to clean up then you must actively add a hook_drush_sql_sync_sanitize that will declare the right command, but it doesn't say if it has cleaned up all the columns in the table.

Hi there,
Apart from SSL, malware protection provided by web hosting company I need to be sure about Drupal providing the following features:

1) Disable right click on my website.
2) Image copy protection.
3) Mirror Image of site should not be allowed by end user on his/her local PC.
4) My videos have copy rights and I only want live streaming and end- user should not be allowed to download the videos directly or by downloading my entire site.

Old and unused accounts with admin access are a common entry point for attacks. They often have weaker passwords than a current account and the passwords are not being rotated making the accounts easier to brute-force over a long period.

There are two policies that create a solution to this problem:

1. If a vendor will be doing work for a known amount of time, set their account to expire (be made inactive) on the date their work is likely to be done. This is required by PCI DSS 3.1 section 8.1.4.

The Drupal core is well protected by default, but you can ensure your website security by following some additional security rules that can protect your site from attacks and other threats.

These rules are about using http, deleting/blocking a user, preventing the execution of unreliable php code, hiding information from users and more. If you are interested, you can find all the details in the blog post by our developer.

http://internetdevels.com/blog/your-drupal-website-security-how-you-can-ensure-it