University Information Security Incident Management Policy

University Information Security Incident Management Policy

Report an Information Security incident

A variety of methods are available for reporting security incidents:

Please note that work is in progress to update this policy and it will be refreshed soon.

Purpose

Threats against IT systems and information are becoming more prevalent and sophisticated in nature. Weaknesses inherent in almost all computer operating systems, many support services and network applications can be exploited in a variety of ways e.g.,

  • Intruders gaining privileged status
  • Viruses
  • Worms
  • Denial of Service attacks  

Computer systems and network compromises can cause significant damage to an organisation's Information Technology resources and harm to its reputation through attacks on other systems and networks via compromised systems. The purpose of this Policy is to ensure that all 'security incidents' that occur or are suspected of having occurred on any part of the University's Information Technology Infrastructure are handled in a structured and consistent manner. The primary concern is to handle security incidents in a way that ensures:

  • Incidents are properly reported
  • Incidents are handled by appropriate authorised personnel with 'skilled' backup as required
  • Incidents are properly recorded and documented
  • All evidence is gathered, recorded and maintained in a form that will withstand internal and external scrutiny
  • The full extent and implications relating to an incident are understood
  • Incidents are dealt with in a timely manner and service(s) restored as soon as practical
  • Weaknesses in procedures or policies are identified and addressed

Scope

This policy applies to all uses of the University's Information Technology Resources and all methods of accessing those resources. This Policy covers all 'incidents' or suspected 'incidents' reported or discovered by:

  • External alerts, advisories, complaints or other communications
  • External scans, probes, hacks, collateral spams, viruses or worms
  • Internal detection of compromised hosts or unusual activity
  • Internal detection of breaches of relevant University Policies

Effective incident handling may well span traditional areas of responsibility, require a variety of skill sets and ultimately, the authority to take decisive actions. For these reasons the University has established an 'Computer Security Incident Response Team' (IRT) who will have the responsibility and authority for managing all reported security incidents.

Definitions

There are many definitions associated with 'security incidents' e.g.,

  • Event: An observable occurrence; an aspect of an investigation that can be verified and analysed
  • Incident: An adverse event or series of events that impact the security requirements of an organisation
  • Incident:  Any irregular or adverse event that occurs on any part of an organisations computing systems and facilities
  • Incident: The act of violating or threatening to violate an explicit or implied security policy
  • Evidence: Data on which to base proof or to establish a truth or falsehood
  • Forensic Analysis: Examination of material e.g., data to determine its features and relationships in an effort to discover evidence that will be admissible in disciplinary or legal proceedings
  • Incident Response Team (IRT): A group of specialised technical managers, technical and security investigators that respond to and investigate security incidents

Policy

This policy defines the general steps that must be taken in order to effectively manage and resolve security incidents in a structured and consistent manner. Platform, operating system and application specific procedures will be produced and advertised by the IRT. Systems managers, IT support staff, Network and systems administrators must familiarise themselves with this Policy and the specific recommendations pertaining to their areas of work.

Roles and responsibilities

The University of Glasgow's Computer incident response team (UGCirt) will have overall responsibility and authority for managing all reported security incidents. Specific responsibilities for handling certain incidents or aspects thereof will lie with other groups i.e.,

  • System managers - for incidents that span systems or areas where they have managerial authority
  • Systems administrators - for incidents that affect their systems, e.g., system compromises, malicious activity
  • Network administrators - for incidents that affect their networks, e.g., scans, DoS attacks
  • Postmasters - for mail related incidents, e.g., e-mail based viruses, spam, open relays, defamatory messages
  • Web masters - for Web related incidents e.g., defacements
  • IT support staff - for incidents involving their users
  • Users - for incidents that affect them or that they initiate, e.g., lost data, compromised workstation, viewing inappropriate material  

These groups must work with or under the direction of the IRT. If disciplinary or legal proceedings are indicated then relevant, sustainable and reliable evidence must be submitted to the appropriate University authorities.

Detection and reporting

'Incidents' will be detected via a variety of methods and may involve personnel external to the University as well as personnel from various disciplines within the University; in particular:

External events

External events may be detected from the following sources, resulting in the initiation of the corresponding 'Incident Handling' procedures.

E-mail or telephone notifications to well known central support addresses (see above for contact details). Notifications received via this route are generally associated with the following:·       

Copyright violations -Apparent legal notices are received indicating the IP address of a system suspected of hosting 'copyrighted' material illegally. This type of incident must be reported to the IRT who will liaise with the relevant support personnel and user to ensure that, if the notification is valid then all relevant material is removed from the system in question. If necessary the offending system will be removed or blocked from accessing the campus network until the incident has been resolved.       

Scans or Probes detected on external systems - Complaints received from external network/systems administrators or users indicating that they have evidence of scans or probes against their systems from an IP address or addresses registered to the University. This type of incident must be reported to the IRT who will liaise with network support and the relevant support staff and users of the systems involved. If the complaint is valid then the course of action will be dependant on whether the incident was caused by in-appropriate user action or a compromised system.

  • CERT notifications - These will either be indications of 'incidents' that are suspected of having arisen from systems belonging to the University or advisories about potential or active threats. These incidents will be dealt with as appropriate by the IRT.
  • E-mail specific notifications - Postmasters frequently have to deal with complaints indicating in-appropriate use of e-mail, spam or open relays etc. Postmasters must report all such complaints to the IRT.
  • General notifications - Complaints and or information about a variety of topics may be received e.g., web defacements, web content, failure to access on-campus resources, actions by individuals, reports from other sites etc. All such incidents must be reported to the IRT who will take the appropriate actions.
  • Law enforcement agencies - Under exceptional circumstances reports or requests from law enforcement agencies may be received. Incidents reported in this way are likely to be of an extremely sensitive nature and must be handled accordingly
  • Intrusion Detection Systems (IDS) - The IRT operate an IDS system. This is  configured to detect common attack signatures to provide an early warning system for potential attacks and to identify hosts which may be compromised.
  • Network equipment and System logs - Core network equipment together with central and key departmental systems must be configured to detect and log unusual events. Routine inspection of these logs will provide an early warning system for potential incidents. Incidents detected in this way must be reported to the IRT who will take the appropriate action.

Internal events

Internal events may be detected from the following sources, resulting in the initiation of the corresponding 'Incident Handling' procedures.
Network/systems administrators - Network and system administrators may detect incidents or potential incidents during the course of their work from a variety of sources, e.g.,

  • Reviewing log files
  • Monitoring system parameters
  • Monitoring data communications facilities
  • Reports received from users or other sources  

In all cases Incidents must be reported to UGCirt. If a network or systems administrator regards an incident as trivial or easy to deal with they must still report the Incident to UGCirt and provide documentation on how the Incident was handled. Other reported Incidents will be handled in co-operation with or under the direction of UGCirt. Detailed system specific 'Incident handling' procedures will be provided by UGCirt for all University supported platforms, operating systems and applications.

IT support staff - IT support staff may discover or be made aware of incidents during the course of their work from the following sources:

  • Users complaining about a particular topic
  • Notice inappropriate material on a system monitor
  • Receive defamatory or suspicious e-mail
  • Notice unusual file store activity
  • Notice unusual login times and dates
  • Experience problems accessing IT resources  

IT support staff must report such incidents to the IRT and provide assistance in the resolution of the incident. If local IT support staff consider an incident to be trivial and easy to deal with, e.g., updating virus software or cab files, they must still report the Incident to the IRT and include documentation on how the Incident was handled.

Users - Users may discover information, which could indicate a problem requiring further investigation e.g.,

  • Notice in-appropriate material on a system monitor
  • Receive defamatory or suspicious e-mail
  • Notice unusual file store activity on their account
  • Notice unusual login times and dates on their account
  • Experience problems accessing their normal IT resources  

Users are asked to report all such incidents to their supervisors, local IT support staff or line managers as appropriate giving as much detail as possible

  • IRT - In addition to receiving reports as indicated above, the IRT might receive information from a variety of other sources e.g.,
  • Advisories from other CERT sources
  • Contacts with other IRTs
  • Subscriptions to dedicated security e-mail lists Security and incident specific Web sites
  • Vendor specific security Web sites and e-mail lists  

The IRT will record and act as appropriate on all such information. The IRT will be responsible for contacting and liaising with outside bodies as required, e.g., external organisations, ISPs, IRTs, CERT and law enforcement agencies.

Security Incidents detected through internal events must be reported to the IRT as soon as possible. Under no circumstances should an incident be ignored or covered up. A variety of methods are available for reporting security incidents - see above for details.

 

Security Incident Handling

Once an Incident has been detected and reported it must be handled as follows:

Impact assessment

An impact assessment will be performed at regular intervals; this will generally be done by the IRT in collaboration with whoever reported the incident and any other stakeholders. The object of the impact assessment is to categorise the incident, determine its likely impact and allocate the most appropriate resources to handle it. National CERT provide generic incident classifications for computer systems as follows:

  • Compromise of integrity - Virus or serious system vulnerability
  • Denial of Service - Service has been disabled or network bandwidth saturated
  • Misuse - Unauthorised use of account or other breaches of acceptable use
  • Damage - Data destroyed or reputation impacted
  • Intrusions - Breaches of systems security

In addition security 'Risk assessments' will be available for core systems and services, which will aid the IRT and other stakeholders in providing an accurate Impact assessment. Once the Impact has been assessed an 'Impact level' will be assigned indicating the seriousness of the incident as follows:

  • High impact level: The incident will seriously affect elements of the University's Information Technology resources or reputation and will require immediate action. NB. Any incident involving Law enforcement agencies will have an automatic High Impact level.
  • Medium Impact Level: The incident affects elements of the University's Information Technology resources and should be dealt with as soon as possible.
  • Low impact level: The Incident won't immediately affect any elements of the University's Information Technology resources but may indicate some action and should be monitored in case the impact level changes.

Document Events

Documenting events will be critical to effective investigation and successful 'Incident handling'. Poor documentation is the most common cause of bad or inappropriate 'Incident handling'. It is essential to document all events, names, dates, and times in detail and as they occur; this may be done electronically or by hand. Screenshots and photographic images can provide valuable and unambiguous evidence in certain cases. Detailed documentation must be done throughout the incident handling process as this will provide the audit trail and evidence for detailed analysis and proposed courses of action.

Incident containment

Containing an incident will be critical to ensure that it does not propagate, change or disappear before it can be dealt with. The steps that need to be performed will obviously be dependant on the nature and impact of the incident and will include some or all of the following:

  • Remain calm - Work methodically, do not rush
  • Preserve as much evidence as possible
  • Isolate the system or systems - Disconnect from campus network
  • Disable user accounts - To prevent further unauthorised access
  • Disable network services - To prevent further network access
  • Change router/firewall filter rules - To block access
  • Restrict information- Information should be disseminated on a need to know basis  

It should be noted that certain containment actions might, in themselves, change the view that further investigations will reveal e.g., loss of temporary files, terminated processes, logged in users, loss of network connection and network services etc.  

Evidence gathering

Evidence gathering relates to the identification, capture and recording of data relevant to the incident investigation. It is important to note that the UGCirt and other authorised personnel have the authority to inspect any system that is deemed to be part of an incident investigation. Evidence must be gathered in a manner that ensures the integrity of the data and establishes an evidence chain of custody. Since the process of gathering evidence may lead to the disclosure of sensitive, restricted or personal information only authorised trained personnel working in collaboration with, or under the direction of the UGCirt may undertake this task. Evidence gathering may also involve systems not directly implicated in the incident e.g., Router, IDS, BootP/DHCP, and e-mail logs, building access (sign in) books, surveillance videos etc; in such circumstances the IRT will liaise with the relevant providers to obtain evidence. It is essential that internal system clocks be synchronised via the Network Time Protocol, NTP, to ensure accurate correlation between evidence gathered from system logs. Certain incidents may require a more rigorous forensic analysis approach to be undertaken. Forensic analysis techniques would be used to discover and record evidence that established the following:

  • What happened
  • Where it happened
  • When it happened
  • Who was responsible
  • How it was done  

Forensic evidence gathering requires that everything be documented in a form that is capable of recreating the exact steps that were followed to gather the evidence. The evidence itself must not be altered or contaminated and a chain of custody must be maintained; RFC-3227 provides a best practice guide.

A chain of custody consists of the logs containing dates, times and signatories of the personnel who had custody of the evidence.

Eradication and recovery

It will be necessary to get rid of all artefacts associated with the incident and recover any systems and services affected; this might involve:

  • A forensic analysis if incident and assessment warrants
  • Removing 'illegal' copyright material, offensive or defamatory material, Trojans, root kits, scanners or sniffers
  • Re loading systems or network equipment to last known good working state
  • Re installing operating systems
  • Re instating file systems and user data
  • Applying all operating system, applications and manufactures recommended security patches  

Once all artefacts have been removed and all affected systems or services recovered then under the direction of the IRT any containment measures may be removed. NB that Prior to removing any containment measures the IRT may perform independent tests to ensure that vulnerabilities have in fact been removed or addressed.

Follow up analysis

The follow up analysis is intended to provide a detailed incident report, archive evidence, review the incident handling process, gauge its effectiveness and learn from the experience; in particular;

  • Collate and secure all documentation and evidence
  • Produce reports to include
    • Actual impact assessment
    • Actions taken
    • Follow up actions to eliminate or mitigate weaknesses
  • Identify lessons learned and any changes required to University Policies or procedures  

It is the responsibility of the IRT to ensure that a proper 'follow up analysis' is conducted and that all evidence is securely stored. In most cases it will be necessary to archive all incident reports and original and backup copies of evidence collected. Under exceptional circumstances it may be necessary to destroy some of the material collected and this must be done using secure disposal methods. 

Media contacts

Any contact from the Media should be referred to the University's publicity services and GUCirt. If publicity services authorise individuals to interact with the media then the following guidelines will apply:

  • Only facts should be discussed
  • Speculation should be avoided
  • No opinions should be offered
  • Answers should be kept short
  • Individuals should be polite at all times
  • Media contact details should be recorded
  • A record of all discussions and key points should be kept for future reference  

Training

Personnel involved in 'Incident handling' might require skills over and above those pertaining to their normal duties. Evidence gathering and analysis may require tools, computer forensic skills and working practices that ensures data integrity and sound analytical processes leading to relevant conclusions and courses of action. In exceptional circumstances, involving disciplinary or legal proceedings, evidence, analysis and courses of action may be subjected to legal scrutiny.  The University should allocate resources to provide members of the IRT and central support teams with the tools and training required to conduct and advise on all aspects of the Incident handling process. The University should also consider funding training courses in 'computer forensics' for other network and system administrators.

References

This Policy is based on information gathered from a variety of sources including:

  • Local experience
  • Consultation with relevant groups
  • Other Organisations and Institutions Policies