Breadcrumbs

Network Service, Systems and Data Communications Monitoring Policy

Purpose

This Policy defines the environment and circumstances under which Network Service, Systems and Data Communications Monitoring activities will be performed, i.e.,

Informs users of the extent that network activities; interactions, services, systems and communications methods may be monitored
Identifies what personnel may be authorised to perform monitoring functions
Highlights the ethics, procedures and safeguards authorised personnel must employ prior to, during and after performing monitoring functions
Identifies what information the monitoring processes may gather
Identifies how long recorded information may be retained
Outlines the purposes 'monitored information' may be used for, including any actions that may follow e.g., anti virus measures, anti spam measures, system blocks, protocol blocks etc

Monitoring is an essential tool for gathering information, which may be used for a variety of purposes, e.g.,

Capacity planning for Network expansion and Service upgrades
Fault investigations Incident handling
Conformance testing against other University policies
Law enforcement requests

Scope

The Secretary of Court of the University of Glasgow has granted the Director of the Computing Service, and other Directors and Heads of Departments involved in IT infrastructure support, the following authority:

To authorise members of their staff to perform Network, Systems, Applications and Data Communications monitoring procedures that conform to this Policy and all relevant UK laws and regulations.

From a legal perspective the Regulation of Investigatory Powers Act (RIPA) and the companion Telecommunications regulations 2000, covering lawful business practice and interception of communications, requires that all users of the University's Information Technology resources be made aware of the following

Users are hereby informed that their use of the University's data communications infrastructure, services, systems and applications may be monitored by authorised personnel as permitted by UK legislation. UK legislation allows the monitoring of systems and network traffic without consent for legitimate purposes such as:

Recording evidence of transactions
Policing regulatory compliance
Detecting crime or unauthorised use
Safeguarding the integrity of the University's Information Technology Infrastructure

Policy

Authorised personnel may monitor and analyse network services, systems, data (including file systems), applications and data communications facilities pertaining to the University's teaching, research and administration functions. This policy will also apply to Sponsored or Proxy licensees directly connected to the University's networks. Sponsored or proxy licensees will be monitored for compliance with the terms of their license and compliance with the JANET acceptable use policy.

Authorised Personnel

In accordance with current UK legislation, Service Directors and Heads of Departments require delegated authority from the Secretary of the University Court before they may authorise personnel to engage in monitoring activities.

It is important to note that the Director of the Computing Service has the 'delegated' authority' to authorise appropriate personnel to monitor the University's campus wide data communications infrastructure and all centrally supported systems, services and applications. Other Directors and Heads of Departments may obtain 'delegated' authority to authorise appropriate personnel to monitor only those service elements for which the Department or Service has complete responsibility.

It will be considered a disciplinary offence for anyone to engage in monitoring activities without proper authorisation or monitor areas out with their areas of responsibility. Furthermore it is likely that any individual who violates this policy will be breaking the law.

Ethics

Authorised personnel including network and system administrators must execute their duties in accordance with the University's 'System and Network administrators Guidelines', in particular authorised personnel must:

Respect the privacy of others
Not use or disclose information realised in the monitoring process for purposes other than those for which the process was approved.
Safeguard information collected in the monitoring process
Destroy information collected in the monitoring process when it is no longer required

Network services and Applications

General

All networked systems providing network services or applications are monitored where relevant for:

CPU utilisation Active processes
File store - utilisation, anomalies, file types and file sizes
Licensed software violations
Network statistics e.g., peak and average bandwidth utilisation and errors
System and security log anomalies
Successful access attempts - user account, date/time stamp, session duration
Unsuccessful access attempts
Unusual network traffic

This information is used to help determine whether or not University systems are operating as intended. System logs and other metrics are retained for as short a period as possible.

The University reserves the right to examine any file residing on any server or workstation owned by the University, connected to the University's networks or located on University premises. This Policy includes University owned machines used at home and personal systems that are connected to the University's flexible access networks.

Physical monitoring

The University has installed video surveillance equipment in open access cluster locations. Video recordings of these areas are kept for two weeks, however if an incident is under investigation then recordings will be kept for as long as necessary to help resolve the incident.

E-Mail

All Incoming E-mail processed via the central mail systems is subject to the following:

Virus prevention measures, which include blocks resulting from:
- Tests for executable file extensions including bat, exe, vbs etc
- Tests for the initial byte sequence conserved across Microsoft Windows executables
- Signature based anti-virus scanning
Blocking occurs at the SMTP transaction level giving a 'permanent failure' response to the SMTP DATA command. This approach results in:
- Genuine senders get a meaningfull error report from their message transport agent (MTA)
- Our servers do not compose and deliver 'bogus virus alert' messages to innocent users who have had their e-mail sender details counterfeited
Spam delivery prevention measures. Spam is defined as unsolicited bulk e-mail, which can range from the relatively innocuous but annoying receipt of unwanted communications to a denial of service attack through a concerted attempt to flood a network or overload and crash a server. Sites are blocked according to the RBL (Real-time Black hole List), which is a blacklist of networks known to be originators of Spam. RBL is served via JANET and the RBL service funded by the JISC on behalf of the Academic community. Additional measures to help prevent the delivery of spam e-mail have been implemented and these are documented on the Computing services web site
Unauthorised mail relaying is not permitted. This prevents external attempts to use University of Glasgow mail systems to relay Spam or other messages. Mail from specific sources may be blocked on receipt of valid complaints
Mail logs are used to follow up problems reported to Postmaster. These logs are kept for 1 month then deleted. The length of time that the logs are kept reflects the fact that problems can take some time to come to light if the recipient is absent.

Mail logs record the following information:

Time stamp; sender e-mail address & mail system ip address; recipient e-mail address & mail system ip address; message id; message size

Certain SMTP protocol information associated with the initial and final SMTP dialogues

Note that no content information, not even the mail subject field, is held.

Web access

All Web access, with very few specific exceptions, is forced through the University's Web cache service. At present no site blocks or content filtering is performed. It is however possible to apply filters or block access to sites on request, or for security or defensive reasons. For example as part of the measures taken to protect the Campus against the NIMDA and CodeRed viruses, content filters were applied on the Caches.

Cache logs are used primarily to produce statistics on the service. They are also used to investigate any cases of suspected unauthorised use, or illegal activity that are reported. To support trend analysis, daily logs are aggregated into monthly logs, which in turn are aggregated into annual logs.

The daily raw log file records the following information

Ip address of requestor; time stamp; time to download page; status code; size, URL

The daily raw data is compressed into three separate daily files for ease in producing statistics. In addition the raw data is aggregated into the current monthly log file in an anonymised fashion. Daily files are retained for 240 days; this figure maximises the number of days that log files are stored within the confines of available disc space.

Monthly log files:

These files are anonymised and retained for 1 year.

Yearly log:
Aggregated from monthly log files; anonymised;
No yearly data has been disposed of to date.

System Inspection

As a condition of connection to the University's campus network; System owners must agree that GUCS, UGCirt or other authorised personnel may inspect their systems on request and at any reasonable times.Data communications infrastructure

Infrastructure records and Associations

The data communications infrastructure consists of many components i.e.,

Fibre optic cabling systems
Building premises distribution schemes
Backbone and edge routers
Ethernet hubs and switches
Remote access devices

Detailed records and inventories are maintained for all infrastructure components and these are used to support the following:

Fault investigations
Maintenance contracts
Capacity planning
Risk analysis

A key feature of all centrally supported active components, (Routers, hubs, switches etc) is manageability via native TCP/IP stacks supporting IP applications including SNMP agents. This manageability is used extensively for the following purposes:

To monitor active components for failure or error conditions
To associate a particular active port with a specific system MAC address, IP address, DNS name and network connection point.
To track changes in any associations
To assist in fault investigations and incident handling
To check compliance with other University Policies

Network monitoring

SuperJANET and Internet Traffic

Incoming traffic from JANET is subject to the following restrictions; implemented at the boundary router connecting the University network to SuperJANET:

Specific IP ports, which are associated with services that present serious vulnerabilities, are blocked. The actual 'port block' list is derived from local knowledge, experience and national CERT advice.
Filters are in place to block sites from which the University has previously been attacked.
On occasion filters are used to block specific sites in response to a specific request

The campus boundary Router maintains extensive network flow information, which is transferred periodically to flow collectors. The collectors store flow information in log files, which are then processed and used for the following purposes:

Fault investigations
Incident Handling
Traffic profiling
Alerts on unusual activity e.g., DoS attacks, potentially malicious traffic

Flow logs do not record application data content; they merely record certain IP fields and volume data i.e.,

Source ip address, destination ip address, port numbers, volume, and time stamp

Due to disc space considerations the flow log files are kept for a maximum of 6 days

Traffic Monitoring

Authorised personnel may monitor the campus backbone or specific segments for the following:

Protocols and applications in use
Sources and Destinations - traffic patterns
Performance metrics
Bytes sent and received per Router and switch interface
Errors per Router and switch interface
Failure conditions

Statistical records are retained for as long as they are deemed useful.

Under exceptional circumstances i.e., to help investigate incidents or fault conditions, specific interactions between endpoints maybe monitored and recorded for analysis. Records are retained for as long as the incident or fault is active after which time all records are destroyed.

Intrusion Detection Systems

The campus backbone network incorporates several Intrusion Detection Systems (IDS) that are used to identify malicious activity, including local compromised hosts, and derive additional campus backbone router security filters. These systems continually look for recognisable signatures of common attack profiles e.g., CodeRed, Nimda etc. When a signature is recognised an event is logged providing details of the signature, e.g.,

Source IP address, destination IP address, source port, destination port and suspect payload.

Intrusion Detection Systems produce extensive logs, which require detailed scrutiny to reliably identify malicious activity. IDS logs are retained for short periods.

Active scanning

Authorised personnel may perform active scanning of network segments to identify vulnerabilities and or compromised hosts. Authorised personnel must exercise due diligence when performing any scanning activity: in particular authorised personnel must:

Inform the network and systems administrators responsible for the systems on a segment of the planned scan activity and provide the following:
- Schedules including Time and duration of scans
- Systems performing the scan, (IP addresses)
- Object of the scan i.e., vulnerabilities to be tested
Take reasonable steps to ensure the continued operation or functionality of any system being scanned
Identify systems with vulnerabilities to the relevant system administrators

Records from active scans will be kept to help identify areas where actions associated with other University Policies may be required. Users of the flexible access facilities should note that active scanning would apply to any personal system connected to those facilities. Any user who considers this condition unacceptable should not connect their system to the flexible access facilities.