CURRENT YEAR ISSUES

1.1. Application Security Observation

Sx3 iWorld

There is no system enforced minimum password length – users can therefore enter blank passwords. Additionally, there are no lockouts for incorrect unauthorised attempts to login.

We understand that the parameters had not been set due to the upgrade to Sx3 iWorld and that administrators were waiting for users to get used to the system before parameters were set. There was also concern regarding lockouts and that the helpdesk would not be able to handle a large volume of calls of this nature.

Anite

User passwords have not been set to expire after a pre-determined period.

Recommendation Rationale We recommend that management review the configuration of

systems security for all environments and applications, but particularly those mentioned above and give consideration to enhancing system security per the following recommendations:

• Minimum password length should be set to 6 characters.

• Password changes should be enforced every 30 to 90 days.

• Users should be allowed up to three invalid login attempts before being referred to security administration.

Where adequate password controls are not in place there is a risk that the level of security within the company is insufficient to protect the organisation against the risks of the unauthorised access to information system resources.

Additionally, there is a risk of sensitive information being accidentally or deliberately disclosed, unauthorised modification or destruction of programs or data.

There is also a risk of attempted or successful unauthorised access to systems and data being undetected.

Management Response

Fully complied with and implemented recommendations.

We have now implemented a minimum password length on Sx3 I-World, this being 5 characters, and now additionally lock accounts after 3 incorrect login attempts.

Anite passwords have been set to expire after 60 days.

`

1.2. Computer Room Security Observation

We commend the timely and effective installation of a new computer room. Although an alarm system has been installed, it is currently not in operation; it has been proposed that security staff rather than IT staff set and de-activate the alarm each evening and morning.

All security procedures currently relate to the old computer room. There is a new Operations Manual which has been compiled however this needs to be edited for IT staff use.

Recommendation Rationale

We recommend that management ensure procedures are in place with regards to security for the new computer room. Procedures should be specifically designed for the new alarm security system, and appropriate personnel are assigned responsibility of setting it.

There is a risk that unauthorised access to the computer room is undetected and therefore sensitive data could be compromised.

Management Response

An alarm system is currently in operation for the rear door of the computer room and is permanently switched on. However the alarm in not activated on the main door which has limited access through a swipe card system. Security do get an alert through the access control system if the main door has been left open.

The Computer Room procedures still need to be completed and sent around all the relevant IT/Security staff. Target date is now 31^st December.

1.3. Process For Timely Removal of Leaver Accounts Observation

A process to de-activate the access rights of leavers has not been fully established. There is a risk that leavers’ accounts are still valid on respective systems as leavers list are not being made available in order to perform reviews. It was further noted that as leavers depart, emails are not necessarily sent out to all relevant departments including IT to ensure timely removal of network access. We are informed that Oracle HR functionalities with respect to producing starters and leavers list are cumbersome and are therefore not being used.

With respect to network access, from our sample of ten leavers, one was found to have an enabled account. This account had not been used after the employee’s leave date. Also, with respect to the Anite application, from a sample of five leavers taken during the year, two accounts were not locked out. Further investigation demonstrated that the accounts had not been used since the respective leaving dates. Finally it was also noted that leavers are now assigned to the ‘OENQ’ group which has view only access rights to the whole system.

Recommendation Rationale

We recommend that the leavers process be reviewed and a single clear procedure be implemented. The HITS helpdesk should be the primary point to which managers communicate users leaving the council.

Additionally a leavers’ list should be out weekly by HR – we understand that this process was in place previously but due to functional difficulties within Oracle HR this has not been done. We therefore recommend that training be provided to relevant members of staff to enable this.

In the absence of member of IT responsible for administration of user access rights for leavers, there are no contingencies in place to ensure that another member of staff could perform this task to ensure that leavers’ access rights are revoked on a timely basis.

There may be a risk of unauthorised access to the processing functions especially in situations where staff are dismissed from the council.

Management Response

Processes for the production and circulation of leaver information have now been agreed, with the HITS helpdesk being one of the services that Personnel send the leaver information to. The removal of user accounts within the helpdesk is currently undertaken by just one member of staff, but with vacancies recently filled it is anticipated that additional staff will also be covering this function by the end of December.

The process will be reviewed as part of the Health Check of all Help Desk procedures currently being performed by NCC.

1.4. Change Control Procedures Observation

We commend management efforts to introduce a formally documented change control process and a process to document all change requests relating to applications on a change control spreadsheet. However, we noted during testing that eFinancials changes are not updated on the spreadsheet (an independent process is in place); that some changes have no evidence of authorisation on the spreadsheet and that there is uncertainty about what levels of changes require authorisation.

We acknowledge the efforts being made to utilise the new Helpdesk software, TouchPaper, to log all change requests and encourage any efforts made to formalise the process to ensure documentation and audit trails are securely maintained.

Additionally we noted that some of issues following the eFinancials implementation relating to BACS payments could have been identified through the use of a documented and detailed test plan. Similarly for Sx3 iWorld patches there is no test documentation created and retained, even for significant changes.

Recommendation Rationale

We commend the initiative to formalise the change control process and recommend that the change control process be reiterated to all applications developers to ensure that a single method is being followed.

We also recommend that for all future implementations test plans are used and signed off. Where appropriate significant changes should be confirmed with and signed off by users.

The use of different methodologies and processes could present a risk in that developers and users are unaware of appropriate steps and may make changes that can not be traced or that present a risk to the stability of financial data. Also, the lack of adequate test plans and documentation could result in errors not being identified.

Management Response

It should be noted that there is much planning for the changes to Sx3 and then documentation retention, this being held by the QSD team which is now part of Harrow IT Services. Although it is envisaged that we will utilise Touchpaper for documenting change control in the future (target date 31 march 2005), the current logging of application changes within a spreadsheet does mean that records are being kept of upgrades and changes. In addition a review of all procedures across the department is currently being planned and will be implemented over the next 6 to 12 months. This is intended to make all processes ITIL compliant.

1.5. Remote Access Requests Observation

RAS access requests must be approved by heads of a particular service. Due to the small number of RAS users and the involvement of management familiar with the staff involved there is no formal documentation to provide an audit trail for RAS access requests. We understand that an access request procedure is under development to enable the controlled roll-out of SecureID (to replace RAS) in the future.

Recommendation Rationale

We commend management initiative in this area and recommend that the access request procedure be developed as soon as possible.

The use of different methodologies and processes could present a risk in that developers and users are unaware of appropriate steps and may make changes that can not be traced or that present a risk to the stability of financial data.

Management Response

Procedure and operational processes for the authorisation, tracking and set-up of new remote access accounts is currently being worked on, with initial logging and subsequent tracking of requests through Touchpaper.

There needs to be consideration to 3^rd party remote access, staff/councillor remote access, and remote working access. The “code of connection” agreements, other documentation, and finalisation of the processes cannot be completed until the conclusion of the current

“Flexible Working” project. However it is envisaged that all procedures and processes will be in place by 31^st March 2005.