XClose

Information Security

Menu

Information Risk Management - Server and Application Security

Endorsed by the Security Working Group - 14th October 2014. Approved by the Information Risk Governance Group - April 2017. These principles are to be applied on a "comply or explain" basis.

Back to: Information Security Principles

This page describes the minimum security measures or "controls" to be applied to IT systems controlled by UCL and providing services while in development and when operational. It applies equally in ISD and in departments and divisions.

Controls are to be applied on a comply or explain basis. If any control is not to be applied as described below, then the risk owner for the system should record why their chosen alternative is suitable and appropriate. 

Alternative controls may be chosen because, for example:

  • the alternative provides a higher level of security than the control originally specified.
  • the control specified is not applicable.
  • the risk which a specified control is intended to address may be adequately controlled by other measures.

Considerations for Virtual Platforms

  • Where systems of different levels are hosted on the same virtual platform, the platform inherits the security requirements of the most secure system.

Development systems

  • Self signed SSL certificates allowed.
  • No information above Normal classification.
  • Isolated from production environment/information and isolated from non-development systems - see guiding principle 7.

All non-development systems

  • All remote access to be via securely encrypted channels.
  • Changes to be reviewed to ensure they do not adversely affect the security of the system.
  • AV to be installed, up to date and actively scanning (on systems commonly affected by malware).
  • Admin passwords to be sufficiently strong (see password policy).
  • Passwords to have a lifespan related to their strength.
  • Lockout, timeout and tarpits to be considered and implemented as appropriate.
  • Passwords to be stored and transmitted in encrypted form at all times (see password policy and authentication policy).
  • Each individual to be uniquely identifiable. Avoid use of shared accounts (e.g. sudo can be used with only one person with the root password, with suitable escrow arrangements). See password policy.
  • Passwords to be kept separately from the systems/applications they relate to.
  • Default passwords to be changed.
  • Unnecessary functionality/accounts to be disabled. No development/test accounts to remain.
  • The principle of least privilege to be applied with regard to system configuration, application design and configuration, and user access/privileges.
  • Encrypted channels to be used for transmitting data with higher classifications than Normal.
  • No self-signed SSL certificates. This only applies where the use of a self signed certificate may cause users to be presented with a warning message.
  • Logical segregation to be used to isolate systems which have radically different security requirements, e.g. servers supporting critical components/services to be separated from non-critical ones.
  • AV logs to be passed periodically1 to an independent log server.

Systems supporting services which are rated 2 (important), in addition to the above

  • All remote access to be via securely encrypted channels.
  • Web applications to be tested (using automated testing product) upon implementation, and yearly, for vulnerabilities. Issues rated High or Critical to be remediated within 30 days, followed by re-testing to confirm.
  • Operating systems and applications to be currently supported (including security patches).
  • Security patches to be risk assessed and applied within an appropriate time frame.
  • Penetration testing to be carried out when systems are introduced, and after any major changes.
  • No single person to be able to make changes to a system and then modify the related audit log files.
  • Logs of security-related events to be passed periodically1 to an independent log server.

Systems supporting services which are rated 3 (critical), in addition to the above

  • Segregated from other systems1.
  • Full formal change control to apply.
  • Systems to be configured securely according to industry-accepted standards.
  • Developers to be trained in secure coding techniques.
  • Written secure coding and development lifecycle standards to be agreed and followed.
  • Code to be reviewed by a third party in order to pick up security flaws. Automated test suites could also be used to discover flaws.
  • Yearly penetration testing, and penetration testing after major changes. Critical findings to be resolved.
  • Logs of security-related events to be passed to an independent log server within 12 hours.
  • Inactive user accounts to be identified and disabled on a regular basis.
  • Where practicable two-factor authentication to be implemented for privileged access.
  • Physical access to the hosting hardware to be separately secured from other system levels.
  • Systems hosting Highly restricted or Secret information to have a support agreement that allows disks to be retained.

1To be defined based on risk.