Plugins:PluginDirectory/BadDataPolicy
Bad Data Policies
Bad data shall be scorned. "Bad data. Bad data".
Bugs/Bad Data
Changes to pieces of plugin data can cause "bugs" which are easily corrected. The Plugin Manager should use their editor rights to correct minor data issues, working with vendors as needed.
Plugindir Compromised
This policy should be used very infrequently. This flow documents how we will deal with a compromised plugindir database.
- Suspicious Data is noted that doesn't look like a minor accident and which subjects our users to risk
- Critical IT request is filed - take production plugindir webheads offline for maintenance
- Plugin Manager and Security work to identify bad data
- Issue is during normal work hours? Security does intrusion detection work
- Dataset is certified by plugin manager
- IT Bug is reopened and updated to put webheads back into rotation
- Plugin Check page begins working again
Security will evaluate if intrusion detection work is needed. During the middle of the night or other odd times, this step should not block putting the plugindir back online.
Any security vulnerabilities will be filed as bugs and triaged. A vulnerable plugindir should not be put back into server rotation. Security bugs must be fixed and verified by QA/Security before deployment.
Audit Trail
Security will examine Plugindir SysLogs for changes to the database to track down how the accident/malicious changes were made. They may also work with IT on other aspects of the environment.
Recovering from Bad Data
Bad plugins or releases should be deleted, unless it's obvious how to fix a single piece of data.
The Plugin Manager may also use the Audit Trail logs to recover data specifics.