Guidelines for External Service Providers, Consultants and Contractors

There is a growing trend towards the provision of financial and security systems that rely on Information Technology (IT) and networking. This applies to modern till systems, door locking mechanisms and "turnkey" systems for running financial databases. Examples are cash registers which need to be connected to a data network, electronic door locks with embedded computer chips, and College financial systems outsourced to external consultants. This list is not exhaustive.

Salesmen may present such systems as a technical advance without dwelling on, or even suggesting, the IT or networking implications, often because they themselves are unaware of them.

Intended Audience

In all cases where systems involve IT or networking the information in the following document should be read and its implications fully understood. University or College Officers who may be responsible for acquisition of such systems, but who are not fully conversant with the IT issues raised in this document, are encouraged to consult their own departmental or College Computer Officers for elucidation.

Initial Planning

Any company or individual chosen to provide services within cam.ac.uk which are to be accessible via a College or departmental network must ensure that the local Computer Officer(s), and if necessary the Computing Service (at the CO's request), are notified of the project, its requirements and implications. The significance of this advice is that the local Computer Officer (and the Computing Service) should be able to address any potential security issues in advance of the system's installation, not after it has been hacked.

This is particularily true if the equipment/services concerned involve products or data which are known to be potentially attractive to hackers and/or involve financially, commercially or personally sensitive data (in which case, under the Data Protection Acts, a privacy policy for the service must be appropriately published, amongst other things). Such systems include such obvious targets as webservers, especially with associated databases; third-party databases which utilise commonly-used software; email servers and any personnel, financial, security-related or research records.

The Cambridge University Data Network (CUDN)

It is important to realise that data networking in the University is managed on a distributed basis by the individual institutions - each College and department runs its own network. These networks are connected to a core network, the CUDN, which is maintained by the Network Division of the Computing Service; the Division is responsible for all aspects of running the core including conditions of connection for institutions and the link to the outside world.

Network Security

Cambridge is a collegiate University composed of a wide variety of organisations, some of which like the Colleges are legally separate entities. This means that in comparison with most commercial networks, networking in the University is remarkably open. Most machines within it are open to a wide variety of attacks, from both within and without cam.ac.uk. Individual departments or Colleges may implement strict access control policies, but these will not extend over the whole of cam.ac.uk. Not all communities within the University are the same; it is recognised that data and services are used differently by various units within the University. The principles of academic freedom apply to these guidelines, and they are not intended to limit or restrict those principles.

The Computing Service does maintain some controls, particularily port-blocking at the borders of the CUDN (e.g. incoming ftp is blocked), but the current list is necessarily rather limited. A copy of the current list can be obtained from the local Computer Officer. Most machines within cam.ac.uk have global IP addresses, which means that many are visible and can be probed remotely.

Note: Although private (i.e. RFC1918) IP addresses are available upon request (which should be made by the local Computer Officer), only the class 172.x.x.x is generally routed across Cambridge. Institutional requests for entire subnets should be made by the local Computer Officer in the normal way to ip-register@ucs.cam.ac.uk.

Security Breaches

Security breaches are dealt with by CamCERT (the Cambridge Computer Emergency Response Team) in conjunction with the relevant specialist group such as Windows Support and Unix Support. In the event of a security breach, CamCERT will expect to communicate with the local Computer Officer to establish the extent of the compromise and to take remedial action.

Security and Networking Guidelines

Consultants or individual contractors employed by individuals, Departments or Colleges should take notice of Computing Service security and networking guidelines when planning a project and/or connecting machines to College or departmental networks, preferably well in advance of the actual work involved.

Given the nature of networking in the University, security at the individual machine level becomes a prime focus of concern. In general, networked machines should observe the following rules:

• They should have a vendor-supported version of the operating system installed ie a current version.
• They should be current with security patches, whether the mechanism involved is a manual or an automated one.
• They should be provided with an approved, licensed anti-virus product which is frequently updated. Details of the University's current anti-virus software (which is freely available for use on any system within cam.ac.uk) is available.
• They should allow access to the CS friendly probing suite, so that their security can be checked on a regular and timely basis. If this is not possible the local Computer Officer should discuss the situation with CamCERT, prior to the system's installation.
• The local Computer Officer should be provided with an account on the machine(s) in question at an appropriate level so that he or she can access the system in an emergency eg be able to shut it down, investigate a system compromise or patch it.

Access Issues from outside Cambridge

It is recognised that some consultants may have a continuing relationship with a department or College which means that remote access to the server(s) is required. However such an account should be strongly secured, since it imposes an additional risk not only to the institution, but also to all other institutions connected to the CUDN. In particular it is strongly recommended that the password or other network traffic should not be visible "in clear" because of the ever-present risk of internet snooping and password capture by miscreants.

For example, external telnet access is not acceptable, but ssh access is. An ordinary http login would not be acceptable but an https access (over SSL/TLS) would be. In addition since however strongly the network traffic is encrypted, too simple a password (eg 'Administrator' or 'letmein') negates any such security, it is recommended that passwords for such access should be complex (eg a pass phrase of not less than fifteen characters long, not a dictionary word, consisting of mixed alphanumeric characters and punctuation).

Dedicated Systems

If a computer forms part of a buildings control system (for example is installed as part of an EMBS contract) or is connected to laboratory equipment for research purposes (eg a scanner or an electron microscope), it is strongly recommended that it should either not be connected to the CUDN or, if connected, set up with a private IP address (which at least gives some protection from external attack).

Further Security Recommendations

System-based security recommendations for PCs can be found in Windows Support's pages or for Linux/Unix in Unix Support's pages. General questions on security or who to contact for specific information can always be emailed to the UCS Service Desk who will try to ensure that the query is passed onto the appropriate group or person(s).

Information on securing specific products within Cambridge can be found below:

• IIS and Security
• SQL/MSDE Security Page
• Obtaining SSL and TLS Server Certificates for https within Cambridge
• Securing Webservers Using https

Last updated: May 2010
Last reviewed: July 2011