HACKEN IS FORBIDDEN
The law requires the department to maintain a minimum level of protection for its computer systems. Everthing else that has to be done to keep hacker out, diminishes the level of services for education and research. The costs involved are defensible, up to a point. Beyond this point, we have to rely on (the effectiveness of) rules.
Making student coputers hackerproof, will never be a first priority of the department.
In the past, the department had to make the decision to introduce the Microsoft operating systems in the student environment. Argument pro was that most students were using these facilities at home, and a better integration would benefit students (and indirectly the department). Argument contra was the poor trackrecord of MS systems regarding security and managebility.
Despite the risks, MS was introduced.
Regarding 'rights' we distinguish three groups: third parties, students, staff, csg (systems staff) ; ordered from fewer to more rights.
The primary goal of the department's security policy is to protect groups with more rights, against groups with fewer rights. A secondary goal is to protect members of each group against each other.
The idea is that these groups will be cooperative. Wihtin each group, members have little to gain from gaining the rights of others in the same group. Moreover, the (social) costs of detection of illegally gained rights will be high.
Making systems hacker proofs ; it requires the department to always stay ahead in the hackers/admins race. This involves a lot of work.
Setting and maintaining rules ; users will refrain from breaking and entering computer systems if the possible costs are too high.
In a costs/benefits analysis, setting rules if of course easier and cheaper. It only works if rules are seen to be maintained.
The department relies on 'rules' to protect users within each group (staff, students) against each other. Systems are sufficiently protected (in view of the law) but they are not watertight. Now and then, a dedicated person will break the rules, and illegally gain rights.
The department's systems are loaded with lots of software,
including software that may contain exploitable bugs.
The possibility of such bugs hardly ever influences the
decision to deploy software.
If we can't rely on the effectiveness of 'rules', installing software would be severely limited. This is not what we want in an academic environment.
Raising bigger barriers between groups hinders close cooperation between for instance staff and students; it is not acceptable.
It will be clear that this is a very costly operation, because of the downtime of computer systems involved, and the effort systems administrators have to make.