home	education	contact	library	calendar	search
	about us	research	people	archive	services	jobs

Hacking

in a few words ...

HACKEN IS FORBIDDEN

... and somewhat longer

1. HACKEN IS FORBIDDEN

2. when in doubt about the applicability of this rule regarding actions you intend to take, please consult helpdesk in advance.
3. user who don't understand this rule of conduct, should use department computers only for tasks assigned to them (students) or tasks they were hired to do (staff)
4. there is no gray area
5. there are no exceptions

6. in case of a violation, the board of the faculty will be notified
7. each violation will have, individually determined, far reaching and nasty consequensces for the perpetrator
8. the reasons or intentions of a perpetrator will not matter a great deal when consequences for the perpetrator are determined
9. the police may be notified of violations
10. the department may reclaim direct and indirect, material and/or immaterial damages from the perpetrator

background

the law

The Netherlands has special laws regarding hacking. The rules are strict ; people have been convicted. The surfnet brochure (in dutch) Ik en de Wet Computercriminaliteit tells you more.

goal, priorities

The computer science department has a clear goal: research and education. To reach that goal with a given set of means, the department has to set priorities when allocating those means (for instance computer systems support staff).

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.

security

Regarding security you can define systems secure if users can only perform tasks with the permissions associated with accounts/passwords handed out to them by the department.

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.

'hacker proofing' versus 'rules'

To make systems secure we rely on two methods:

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.

computer science department

The computer science department uses 'hacker proofing' to protect one group against the other.

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.

System management

If a break in is detected, the whole system will have to brought back to the last known secure state before the incident, where a worst case scenario has to be assumed.

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.