Thoughts on 403

Emphasis on self-managed servers

Project 403 asks for training materials to teach users about security.

In this project we want to focus on users who manage a self-managed machine, and especially on those who have a self-managed server. Self-managed servers do need looking after. Sitting in a corner of a room for years, not being anyone's main everyday machine, these machines can be particularly vulnerable to being quietly hacked and infected with malware.

Someone needs to be in charge of them. That person has responsibilities. This project is about:

  1. identifying which of these responsibilities concern security.
  2. identifying the most basic and important of these.
  3. finding a way to teach them effectively to everyone responsible for such a machine.

If there is time, a Learn course will be produced, and it's envisaged that passing such a course would be compulsory for the managers of self-managed servers. If there isn't time, we'll knock up some explanatory web pages, hoping to grow them into a Learn course later on.

This project does not plan to track whether or how the responsible person actually carries out these security duties. It does not seek to do more than teach the duties, preferably in a verifiable way.

What do we want to say?

These, more or less, are the responsibilities laid on the machine manager by the self-managed policy:

  • Everyone using the machine is bound by the computing regulations.
  • If the machine is disruptive or compromised it'll be disconnected from the network without warning (though computing support will contact you as soon as they can to explain the issue).
  • Users must abide by the School's policies.
  • You must obey the law. (Notable laws: GDPR, freedom of information, RIPA.)
    • (We should mention that every computing service handling personal data must have a DPIA done for it.)
  • External networks come with Acceptable Use Policies.
  • You must keep its software and OS and its hardware fully updated with security fixes.
    • We should refer somehow to how to enable / configure automated security updates in popular operating systems.
    • Intel only issues firmware fixes for certain models of its processors. (It periodically publishes a list of these models.) Other Intel processors do not receive firmware fixes, and can therefore not be used.
  • You must configure the OS and software to be secure enough, too.
  • You must not create a wireless network without explicit permission.
  • You must agree to the University's periodical electrical safety tests.
  • If a vulnerability is identified, you must fix it in a timely manner.
We can add some more:
  • Keep it somewhere that's secure enough that it won't be either stolen or physically interfered with.
  • A member of staff of the School of Informatics must be responsible for the machine, including for its security, user accounts, configuration, etc.
    • That person can then nominate technical contacts, who can be Informatics staff or Informatics PGRs. (Refer to the Self-managed server rooms space policy at
    • For the convenience of the machine's users, they should document their management of the machine, such that someone else could take over the job if needed.
    • If/when the machine's responsible person leaves, someone else MUST take over the role.
      • When this happens, they must tell Computing Support!
      • Orphaned machines are liable to be turned off and removed, to save space and power.
  • All users should have at least a visitor account (as proof of their relationship with the University).
  • Accounts must not be shared. Each person needing to use the machine(s) must have and use their own account on them. (For instance, the Janet acceptable use policy requires that all network activity be traceable to an identifiable individual person, effectively outlawing shared accounts.)
  • Are you aware of how frequently disks can fail?
  • Given this, are you happy with the data backup arrangements?
  • Are you keeping offsite backups? Are they secure enough? Are they really offsite? Many personal "offsite backups" were lost when our South Bridge offices burnt down, because they were in desk drawers in the same building.
  • If you care at all about the data on the machine(s) you should consider using a multi-disk redundancy system such as a suitable RAID level.
  • If you're managing several machines, consider automating the configuration. This doesn't have to be complicated - some configuration systems are relatively simple and easy to adopt.
  • Does your machine need to be accessible by people outside Informatics, or outside the University? Are you aware of the relentless attack attempts on our externally visible machines?
  • Who has access to the machine? Is everyone's login password adequately secure? Is everyone with access still meant to have it? Do you lose access to the machine when you leave the research project?
  • Was the machine externally funded? Did that funding come with security requirements, whether explicit or implied?
  • Given all this, are you sure that you don't want the computing staff to manage the machine for you?
    • Not that that lets you out of responsibility for certain things, for example personal data, where you'd need to do a DPIA.

Threats and obligations

What are we trying to keep secure here? What are the threats?

  • The physical hardware
    • It could be stolen.
    • Portable and removable components could be stolen - e.g. GPUs, memory, SSDs.
    • Hardware could be subverted in some way.
    • Someone might want to destroy or damage it.
  • The software
    • could be maliciously altered or replaced.
    • ... or simply vandalised.
  • The data
    • Someone might want to destroy it.
    • Someone might want to copy it.
  • The service
    • Someone might want to take down the service. (Either that service in particular, or just University targets in general, for instance to embarrass or discredit the University.)

For each possible disaster, the people running the machine should know:

  • How disastrous would it be if this happened - what would the consequences be?
  • What are my obligations with respect to this?


Not all of these points are about security, particularly. Some are simply things which the managers of such machines are required to do (e.g. comply with the law) or which would be a good idea (e.g. regular backups).

The dictionary defines security as freedom from danger or threat - but it's conventional to think of computer security as being concerned specifically with vulnerability to malicious attack.

If we use this latter sense, these would seem to be the most directly security-related points:

  • Keeping the OS and software updated with all security fixes.
  • Keeping the machine's configuration secure enough.
  • Fixing security problems quickly.
  • Keeping the machine in a secure enough place.
  • Accessibility from outside, and awareness of the extra threat that brings.
  • Keeping track of who has access; keeping their passwords secure; removing accounts when people no longer need access. (There should be a mechanism which people can use to have their account removed when they no longer need access.)

However, several other points are also about security, albeit indirectly, because they make it far more likely that effective measures will actually be taken.

  • There should always be someone with responsibility for the machine's management. If the manager leaves Informatics, someone else in Informatics should take over. (This is already policy, see above. Each self-managed server has to have a current Informatics member of staff responsible for it - although they can be assisted by other Informatics staff members or PGRs).
  • The manager should document what they do, or at least adequately train their replacement.
  • Knowing that compromised machines will lose their network connection.
  • Especially if there are more than one or two machines, consider automating your machine management, for instance with a configuration management tool.
  • Remember that if the computing staff manage your machine for you, you won't need to worry about most of this. (You will need to pay attention to certain laws (expand this) though, for example on data protection matters.)

To Do

Write learning outcomes for the course. These will (broadly) define the content of the course, and they'll also form the summary of course content which will begin the course.

Flesh out all the details, for instance of the laws and the School policies which machine managers have to obey. Keep references for all of these!

Topic revision: r18 - 23 Apr 2020 - 10:24:11 - ChrisCooke
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback
This Wiki uses Cookies