Information Security Assurance – Primary Care Trusts
Guidance
Requirement 305Does the PCT ensure that operating and application information systems under its control, support appropriate access control functionality?
Objective: To effectively control access to information.
Access to information, information processing facilities, and business processes should be controlled on the basis of business need and security policy requirements.
Access control rules should take account of both local and national policies, where these exist, for information dissemination and authorisation.
This requirement addresses ISO/IEC17799 (revised 2005) controls ref 11.1, 11.5, 11.6
NPfIT systems
NHS Information systems are being developed and rolled out by the National Programme for Information Technology (NPfIT). These systems are not under the direct control of the PCT but are subject to robust access controls. Therefore, they should be considered outside the scope of this requirement.
Whilst the guidance provided below reflects best practice as it is generally understood, work is being carried out within the National Programme for IT to provide detailed access control specifications that it is expected will be available for local integration. PCTs should carefully consider the need for new or changed access control functionality for existing systems in advance of the publication of NPfIT standards.
In the interim, current functionality for systems under the control of the PCT should be measured against the following criteria:
Computer-based information systems access controls
This requirement is concerned with access controls for computer-based information systems. Paper-based information systems are covered under records management requirements and the PCT should ensure that relevant access controls exist for these. The Information Security Manager/Officer should liaise with those responsible for Records Management requirements to ensure controls meet the requirements of information security standards.
This requirement is scoped to include all Operating systems (e.g. Linux or Windows 2000), Application and information systems (e.g. Patient Administration System, Microsoft Excel).
Access Controls & Related Functionality
Access Control Policy
Each system should have a security policy that includes rules regarding its access control. The security policy should be approved by the Information Governance Board or its equivalent, be available to all users who are granted access to the system and should be reviewed on a regular basis. A typical system security policy should take account of the following:
· The system security requirements. A risk assessment for the system will help determine the security requirements. For example, the level and type of access controls, location of hardware associated with the system, type of data held, etc.
· Identification of all information related to the system, and possible risks to the information. For example, a system holds patient data. A risk analysis will point to risks of unauthorised access, input of inaccurate data, corruption of data, loss of processing facilities, etc.
· Rules for information dissemination and authorisation e.g. dissemination based on need to know basis and authorisation to data based on granular user profiles.
· Consistency between the access control and any information classification policies of different systems and networks. This applies where an information classification scheme has been implemented within the PCT.
· Relevant legislation and any contractual obligations regarding protection of access to data or services. Reference should be made to legislation such as the Data Protections Act 1998, Freedom of Information Act 2000, etc. Any national NHS or other relevant guidelines should also be acknowledged.
· Standard user access profiles for common job roles in the PCT. This relates to granularity of access. In practice, system user profiles should be kept to a minimum, based on business needs. For small departmental systems, this can mean administrator; user with ability to read, create, amend, delete, copy and print files; user with ability to read only, etc. However, systems with a wide variety of users will require significant thought in devising and reviewing access profiles.
· Management of access rights in a distributed and networked environment which recognises all types of connections available. The policy should take account of the ways in which users can get access to the system e.g. local workstation only, any networked workstation, remote access, wireless, etc; and ensure secure access procedures for those applicable are put in place.
· Segregation of access control roles. The system owner should ensure that written procedures are produced that cover access requests, authorisation and administration. The procedures should ensure that no single member of staff is able to authorise all access (see Local User Access Management policy for a typical procedure that segregates roles).
· Requirements for formal authorisation of access requests. A written procedure detailing how to apply for access and how to process applications should be made available (see Local User Access Management policy and requirement 306).
· Requirements for periodic review of access controls. The review should ensure that user accounts remain appropriate. For example, is the account still used, has the user changed role, do changes to the system call for a new assessment of role-based access, etc?
· Removal of access rights. Documented procedures should exist that include the criteria for removal of access rights, who authorises removal and when removals are permitted, and for audits of removals.
It should be remembered that the policy document does not need to include all the details of these criteria. Rather, the policy document should be brief and along the lines of “…procedures will be implemented for the following criteria”.
Secure logon procedures
All computer systems should have a logon procedure that includes at least a unique user ID and password (some systems may potentially require additional verification, such as user smartcard. A risk assessment should help determine what level of authentication is required). The following features should be considered:
· System/application identifiers should not be displayed until the logon procedure has been successfully completed.
· A ‘pop-up’ window or prime-screen acceptable use warning that the workstation should only be accessed by authorised users. This will not stop determined crackers. However, it does show that the PCT has demonstrated that the system is not freely available and that unauthorised use may contravene The Computer Misuse Act.
· Do not indicate which part of logon information is incorrect e.g. if a user makes an error. This prevents unauthorised users identifying patterns when attempting to gain access to systems.
· Limit the number of unsuccessful consecutive logon attempts. Many systems allow three unsuccessful attempts before locking users out. A pop-up window then advises the user to contact a helpdesk to have the password reset. The system can also be set to record unsuccessful logons (useful to identify frequency of errors and to alert a user of a hacking attempt).
· Limit the maximum time allowed for logon.
· The system should record the date and time of successful logons. Logs may be used during investigations. The log is therefore a valuable source of evidence and should be linked to a workstation identity (the Media Access Control (MAC) address will be needed to do this.
· The password being entered should not be displayed in clear text. Most systems show a number of asterisk characters and some systems nothing at all in the password field.
· Passwords should not be transmitted in clear text over the network. Passwords should be encrypted through, for example, a RSA or hashing algorithm, for transmission over networks.
Identifying users
In order to facilitate access control and audit functions it should be possible to uniquely identify all system users. This function may be achieved by unique username and password combination or, in systems containing sensitive information, smart token technology and biometrics.
Group IDs prevent successful audits being carried out that trace actions to an individual and should therefore only be used if absolutely necessary and in locally approved circumstances.
Password management system
Password management systems are used to establish rules concerning the use of passwords in the system. The system owner should establish the rules, which will then be implemented by the system administrator. The following criteria should be considered:
· Is it necessary to use group passwords on the system? Preferably, all users will be identified as individuals (including system administrators) when they log on.
· Do users have to change their initial password (issued by the system administrator) following their first logon? Users should be encouraged to set their own password, as it will usually be based on something they can remember.
· Does the system log user passwords and prevent re-use? Repetitive re-use of passwords poses a security threat and should be avoided.
· Can users change their own passwords when they wish? This function increases security as users can change passwords, if they feel their current one has been compromised.
· Are complex passwords required? Simple passwords (less than 6 characters, number or letter only, repeated use) pose a threat to the system. Alphanumeric passwords of 6 characters or more should be considered for any system. See User Guide to Passwords for more details.
· Are periodic password changes enforced? A maximum period of three months between enforced changes is the norm for most systems.
· Are passwords displayed on the screen when being entered? Displayed passwords can obviously be seen by others and pose a security threat. Most systems now display only asterisks when characters are entered and some systems do not display anything. One of these latter rules should be implemented.
· Are passwords stored separately from application system data? Crackers normally search application sub-folders to locate password files. Therefore, every care should be taken to store passwords in protected network folders. CERT offers advice on protecting password files and has many other pages illustrating vulnerabilities in named application password file storage.
· Are passwords stored and transmitted in encrypted or hashed form? All passwords should be stored or transmitted using encryption or hashed.
Use of system utilities
Some systems may include utilities that can override normal controls (such as all those listed above). The system owner should ensure that all system utilities are identified, disabled where not necessary, and access to and use of any functional system utilities strictly controlled.
Session time-out
Some systems incorporate time-outs that clear a session screen if activity has not taken place for a pre-determined time. On some sensitive systems the connection with the application/network is also terminated. The system owner should ensure that a time-out assessment has taken place and suitable rules put in place.
Limitation of connection time
Some systems restrict user sessions to time slots e.g. the system can only be used between 0900hrs and 1300hrs. Others utilise maximum session periods e.g. remote access sessions last for four hours and are then terminated. The former control is rarely used in NHS systems. However, the latter is used quite commonly.
Information access restrictions
The integrity and availability of information is obviously important and should be considered by the system owner. The ‘need to know’ basis of access should be supplemented with additional controls for altering or deleting information. File storage systems should be constructed with these criteria in mind as, in many cases, access to a folder allows the user to view, alter, copy or delete files in the folder (and sub-folders) unless they are protected.
Sensitive system isolation
When looking at computer systems in NHS organisations it is difficult to define what system should not be considered sensitive. The nature of the data, the relationship of the system to other systems and the network, and the location of the system all contribute to a variety of risks and threats that can have an impact on more than a single system or its data.
Patient, personnel and financial data are all considered sensitive due to legislation e.g. Data Protection Act 1998 or commercial considerations. System weaknesses in a system that does not contain sensitive data can lead to malicious code being transmitted to systems that do include sensitive data. Therefore, these criteria should be considered during the risk assessment for the system.
Systems that are considered sensitive should be physically and logically protected from unauthorised access.
Improvement plans
· Level 1
The PCT should define and document in an action plan its requirements for access control including the operational, managerial and technical controls to be applied.
· Level 2
The PCT should implement its action plan to introduce appropriate access control functionality for systems under the control of the PCT.
The PCT should ensure that access is only granted to individuals who have been duly authorised and introduce appropriate technical functionality and management controls to support and maintain this.
· Level 3
The PCT should ensure appropriate access control functionality is built into all systems under its control.
The PCT should put a programme in place to audit its access control and management processes (e.g. reviewing password configuration settings, password cracking, penetration testing etc) and undertake any remedial/improvement activities that may be necessary.
Requirement checklist
IS_PCT_305_V5_Checklist 07-04-26.doc
Key Guidance Document(s):
DH: Information Security NHS Code of Practice
The code is a guide to the methods and required standards of practice in the management of information security for those who work within or under contract to, or in business partnership with NHS organisations in England. It is based on current legal requirements, relevant standards and professional best practice and replaces HSG 1996/15 – NHS Information Management and Technology Security Manual.
BS ISO/IEC 17799:2005 & BS ISO/IEC 27001: 2005 BS7799-2:2005
Note that only NHS Information Governance Toolkit (IGT) administrators may download a copy of the standards for their organisation. The administrator must be logged on to download the standards.
NHS Connecting for Health Good Practice Guidelines: NHS Network users only
· Wireless LAN Technologies
· Email, Calendar and Messaging services
· Site to Site Virtual Private Networks