It is agreed we need to move from site based to group based security.
This means disabling the current server based security and enabling the PMWiki page and group security. See Passwords for more information on how this works.
Project owners will be responsible for setting up their own group security.
Default security will be:
- no passwords implemented at site level
- no password required to read pages
- group administrators (ie project owners) can change passwords within group
- each group set up with standard, default password for editing pages (same across all groups)
- group administrators can either tighten or open security (ie change passwords, restrict or enable access to pages within groups) as required
- group administrators need to ensure that where there are cross group linkages, that these continue to function for each group (note some of these will be across projects - eg TIS to ESAF, or TESDoc to other tertiary projects)
Group owners need to note the sequence in which passwords take effect in planning their group security - which reinforce the principle of starting open and restricting as required:
In PmWiki, page passwords override group passwords, group passwords override the default passwords, and the admin password overrides all passwords. This gives a great deal of flexibility in controlling access to wiki pages in PmWiki. At present there isn’t any way to have a non-password protected page within a password-protected group, or a non-password protected group with a site-wide default password set.
General principles for security:
- open access across groups is supported and encouraged, unless good reason for not doing so
- security is tightened on an as-needed basis related to business requirements of the projects
- the purposes for tighter security should be to protect content of areas that contain more official or stable text and to protect any information that is considered confidential to the project
Response plan for attacks on content will be:
- Group administrators are responsible for regularly checking changes to content - this is something they should be doing routinely as part of project management
- Where changes appear to be in the nature of an attack (ie irrelevant, inappropriate etc), in the first instance, group administrators restore pages to pre-attack state using page history as soon as possible
- Where there is a series of attacks on one group, the group administrator will need to take appropriate action - such as changing the group edit password and implementing an edit password on open pages for a specified period of time
- Where there is a series of attacks across the site, cross site security measures may need to be taken for a specified period - such as implementing site level passwords.
- Aim should be to deter through low level response initially, escalate responses only if required and return to normal security levels as soon as reasonable.
← URL Options | Where to Next | Improved Help →
