nof-digitise Technical Advisory Service - compliance corner: security standards

NOF-digitise
Technical Advisory Service
2001 - 2004 archive

Latest Additions

Introduction

Archive Introduction

Why an advisory service?

What can it help me with?

Compliance Corner

Compliance corner comprises a series of issues that have arisen in the context of projects meeting technical standards. This page covers:

Security Standards

It is noted in the Technical Standards and Guidelines on security that your project should be managed in accordance with the Information Security Management guidelines laid out in BS7799: Part 1.We recognise that compliance with BS 7799 part 1 is by no means a trivial undertaking and may in many instances be inappropriate to the security needs of your website. However it is nonetheless important that your site complies with certain minimum recommendations. Becta states:
"Although compliance with BS 7799 part 1 is not a "Must" requirement, projects "must" adhere to the following:

The machines used to deliver projects must be operated in as secure a manner as possible
The advice in operating system manuals concerning security must be followed
All known security patches must be applied

If a project is not aiming for BS7799 part 1 compliance, they should return in either their Section A or Section B report details of the security arrangements that they will be implementing. These arrangements will need to provide reassurance that the site is being delivered in as secure manner as possible - for instance the project should:

ensure arrangements are in place for the timely application of any security patches
confirm that the server(s) and any associated computers have been correctly configured to provide the optimum level of security
confirm that a schedule of timely data backups is in place
confirm its network is protected by a firewall with all unnecessary ports closed
describe the physical security of the project's server(s)
provide details of the people in the organisation who have administrator rights to its machines

Part of the process of achieving compliance with regard to security is the careful documentation of both the security measures you have set up and the ongoing process of maintaining those security measures. For example, with regard to security patches, it is important to keep a watch on announcements of new security patch releases and apply them immediately; the latter is important since they sometimes appear in response to a perceived and imminent threat. Thereafter it is vital that you document the version and release date of the patch applied and the date when applied. Such records build into documentary evidence of your project's timely and effective implementation of your security measures.

Should your site be externally hosted then it is important to provide the reassurances noted above by quoting the relevant sections of your service level agreement with the organisation that is hosting your site.

Data Protection Act

Note also the "Must" requirements in Technical Standards section 3.1.4 Security that relate to personal information:
" The management and use of any personal information must conform to the Data Protection Act 1998."
This means that if your project is collecting personal information, such as the personal details of users, emails, etc., you must confirm that management of such information is carried out in accordance with the Data Protection Act 1998.

Protection of Data Subjects' Email Details: A common pitfall

Where projects may, with users' consent, hold data on a body of people, termed data subjects, care must be taken in the use of such data, particularly when contacting data subjects. It should be noted that even a person's email address constitutes personal data and a project has a duty of care with regard to the disclosure of a person's email address, even where the latter is freely transmitted to the project.

A common pitfall for projects and other organisations is the unwitting disclosure of email addresses among the data subjects of a project. In other words, persons who were previously unaware of the email address of other users of the site are able to read and use the address. How does this happen?

Origin of the Problem
In seeking to contact the website's users, projects frequently use a groupname in the to: or c.c. line of their mail client. The use of groupname will include all the addresses of persons entered into the mail address groupname and so avoid the need to send individual emails to possibly hundreds of people. Alternatively on other occasions, the list of email addresses is entered in the c.c. line en masse.

The Problem
Herein lies the pitfall: whether a groupname or a long list is entered in either the to: or c.c. line of the email to be transmitted, when sent, that email will expose the email addresses of all the other persons included in the mail header to all its recipients. This arguably constitutes a breach of the rules about disclosure. The data subjects have not expected their email address to be passed round to many other persons. It will only take one of the persons to misuse the email address by contacting the disclosed person for, say, commercial purposes, for the accidental disclosure to cause annoyance.

The Solution
While the use of b.c.c., blind carbon copy, is not possible with all email clients, some, such as Microsoft systems, permit the addition of an extra mail header called b.c.c. A simple way therefore to mail all recipients without disclosing any address other than your own and the individual recipient's is by placing all addresses to be contacted in the b.c.c. line.

In so doing it should be remembered that the text of the email message needs to be phrased in such a way as to reflect the diverse audience. The message equally should be written in a way that does not accidentally disclose information improperly.

On reception the email recipients will see at most your address, their own address and no other. In this way, no accidental disclosure of personal data occurs.

Compliance Corner

Security Standards

Data Protection Act

Protection of Data Subjects' Email Details: A common pitfall

Further Reading