LogIn

Sonance System Services Security Policy

We run a lot of machines and services, and this costs a lot of sysadm time. We cannot let these machines run "open" because:

  • Abuse causes Sonance and our hosting providers to be blacklisted, which costs downtime and long-term interoperability / reputation loss.
  • Time taken to repair damage is dead time, cannot be used for positive things.
  • Repairing machines that should have been secure is demoralising.
  • Downtime is disruptive to the users.
  • Cracked machines and services are used to defraud users.

Given all that, we have decided we can only afford to run a tight security policy.

  1. All machines should be run tightly, or not at all. That includes experimental services.
  2. All VMs must have a designated and responsible systems administrator who can manage the issues.
  3. All PHP.ini settings to be closed, off.
  4. Only full security-supported release packages should be installed for production use (e.g., for long term).
  5. Bleeding-edge stuff should be carefully managed and maintained, and advised and approved by the tech team.
  6. Any failing of these rules will result in loss of access and shutdown of services.

Sorry it is so tough, but we have collectively lost too many weekends because systems were hacked.