Here's a loosely-worded example that may act as a template for a small team working on a WordPress site. It's littered with ideas for discussion. Rip it apart to end up with a document that everyone is happy to work with. The core principles should never change, but you should fine-tune the details on an ongoing basis.
To protect somesite.com and its users by securing those assets that may impact upon the website, its data, and user-base.
This wishlist is the most active element of the document. As you detail and update assets, you'll uncover possible improvements. Key decision-makers should agree on these goals.
This may be just you, bridled with full responsibility. For small outfits, if there are team members with privileged access, their roles and security responsibilities should be specified. Try not to mention individuals because while people move, roles don't.
The buck stops with the SM who oversees the policy. This role involves delegating those of the Site and Server Administrators and structuring a reasonable, enforceable policy.
Reporting to the Security Manager, the System Administrator oversees the security of the network and its assets, applies patches, and undertakes file and data backup.
Again reporting to the Security Manager, the Site Administrator oversees the security of the web files and data, not least by ensuring the updating of WordPress and its plugins.
Reporting to the Site Administrator, Site Editors oversee the security of content and this may include auditing its external use. Authors and Contributors each report to an Editor.
Every team member has a responsibility to utilize assets securely. Users with some level of privileged access, at least, should be issued with abbreviated documents outlining, for example, password and secure login procedures. Even junior stakeholders need to know:
What is their overall responsibility?
What precisely does that entail?
... and, to win their support, they need a darned good reason why
And don't forget to regulate, as far as is practical, user's local devices, their media, and the online risks that we covered in Chapters 1, 3 and 4, else to set out how to isolate the site's immediate network from this third party threatscape which, all too often, is ignored.
Now for assets challenging security. List your hardware and, for each item, branch its software, maintenance schedules, and procedures. This info is gold dust for hackers so keep it minimal, in separate documents, and give it to users on a need-to-know basis.
Only PCs, LiveCDs, and other media approved by the System Administrator should gain network access. Pin this down by listing the lot and, for each, specifying what wares should be running with what update procedures, with what extensions and in what modes.
For example, you could stipulate that Firefox is used with NoScript, that Comodo's Defence+ sandbox is enabled, or that Windows' User Access Control is set to paranoid.
And remember, cell phones and other gizmos can be PCs too.
In our case, the website is probably the gist of the policy. Here are some considerations.
Specify a backup procedure, its structure, where it lives and, pre-empting an emergency, test the reimplementation policy (do that, also, when the guy responsible is off sick!)
While adding, say, an untested plugin to a live site is run of the mill for most of us, this direct approach is anathema to the Site Administrator of a monster site. Lay out a beta-to-alpha strategy to test new or revised code on a development server before sending it live.
The database may be the single most important asset. (Your site visitors at least, having given sensitive information, may reckon so.) More rules may involve:
The creation of least privilege administrators
Data collection and retention
The privacy of your user's data
Don't forget to renew the registration and, as outlined in Chapter 2, lock the domain and consider a private registration.
This template's overweight for small sites and barely scratches the surface for others. As I've suggested, it may form the backbone for a series of documents but, in other cases, may itself be an offshoot of a wider policy. You be the judge.
In all cases, though, there are other areas to think about with your overall policy:
Content collection
Content copyright and enforcement
Data encryption
Disaster recovery (Appendix B helps here)
Information security (from passwords to this document)
Internet use
Network penetration testing
Roles enforcement and violation
Chock-a-block doc, huh? Trust me, this ultra-dull policy set is a boon to security. Try it.