The following list was lifted directly from an excellent presentation by Alan Dixon Black Fly Solutions
The Basics of Security Hygiene
1. Keep it as simple as you can. E.g. if you have a bunch of copies of a site
sitting around and suddenly you have a vulnerability, they all need attention.
2. Keep up to date. You don’t have to always be on the latest version, but you
need to be on a version that is being maintained and that you can manage if a
security issue arises.
3. Grant permissions as needed – consider the minimum permissions for each
person to do their job, don’t give everyone full administrator permissions.
4. Don’t rush or do more custom development than you need to.
5. All user input is tainted.
My take on each point:
1 – I don’t keep a dev site updated all the time — I keep my backups of major points, and database backups as required by the project/client, separate from the site and not on a working web server (for disaster recovery). When I need a copy to try something out, I clone the site to a dev copy to work on.
2 – Except in the case of an immediate security issue (e.g. Drupalgeddons 1 and 2) I wait to see that an update isn’t breaking other people’s sites (unless I’m working with the developer of a module/extension to test for a problem I’m trying to solve).
3 – It’s always easier to just make everyone able to do everything and assume they’re never going to make a mistake. Until they make a mistake and it takes a lot of time and effort to recover. Let them be admins on a test copy of the site, and take the time figure out what each person’s role really requires.
4 – Somebody has already figured out most problems or features. If there isn’t a tested module/extension maybe there’s another way to your goal.