|
|
Initiation responsibility: Head of IT Section, IT Security Management
Implementation responsibility: Administrator, IT users
Before a file is dispatched via e-mail or placed on a WWW-server, or before a data medium is transferred to another party, a check must be made as to whether the file/data medium holds residual information not intended for public attention. Such residual information can have a variety of origins entailing a corresponding variety of measures which need to be taken. The most common sources of such residual information are described in the following.
In general, files generated with standard software such as word processing and spread-sheet programs should be checked for residual information. Some of this information is stored with, and some without the user being aware of this.
Before files are forwarded, they should at least be spot-checked for the presence of undesired additional information. For this purpose, a different editor should be used than the one with which the file was originally created.
In this process, it must be noted that not all residual information can be deleted directly without disrupting the file format. If, for example, certain bytes are deleted from a file generated with a particular word processor, the software might no longer recognise the file format. To eliminate residual information:
To prevent the forwarding of information which was originally added on purpose by the creator of the document - such as text in "hidden" format - but whose presence was later forgotten, it might prove useful to print out the file. For this purpose, all printer options for outputting hidden formats should be activated.
Residual information / slack bytes
Every operating system has a smallest possible physical memory unit of a specified size. Under DOS, this unit is termed sector and has a size of 512 bytes. Under Unix, this unit is termed block, and its size depends on the type of Unix system in use. Under DOS, the individual sectors of a partition are grouped logically into clusters. The number of sectors in a cluster depends on the size of the partition. When a file is opened, one or more clusters are allocated to it. The last cluster is not occupied fully, unless the size of the stored file happens to be an exact multiple of the cluster size.
This takes up memory. The average storage space required increases with the cluster size. As the cluster size, in turn, increases with the partition size, the latter should not be allowed to exceed a certain limit. Example: Given a partition size of 1024 to 2047 MB, each cluster is 32 KB large. This results in a memory loss of 16 KB for each file.
Another problem (in the case of DOS-based systems) is that the remaining bytes of the last cluster or block are filled with old data still present in the main memory. Termed slack bytes, they can consist of unintelligible entries, information concerning file structure, and even passwords. Depending on the size of the clusters involved, a file can also be filled with slack bytes when being copied from one data medium to another.
Before files are forwarded, care must be taken to ensure they do not contain any slack bytes. This can be checked with a suitable editor (i.e. hex editor). or with the PRUNE public-domain program. Available from the BIS mailbox, this program can be used specifically to overwrite slack bytes.
In addition, many Windows applications are problematic in that they do not continuously overwrite the available memory with program data while a file is being processed. This can create gaps containing old data of the IT system.
Hidden text / comments
A file can contain text passages with a "hidden" format. Some programs also offer the possibility of adding comments which often do not show up on printouts or monitors. Such text passages might contain remarks not intended for the attention of the recipient. Consequently, this type of additional information should be deleted from files before they are transferred to external parties.
Marking of changes
In some cases, it is necessary to mark changes made to files when processing them. As such markings can be masked out on printouts and monitors, files should also be checked for these markings before being forwarded.
Version management
Microsoft Word 97 allows several different versions of a document to be stored in one file. This makes it possible to invoke earlier versions of a document should the need arise. However, this can also easily lead to very large files, for example, in the case of documents containing graphic objects. On no account should the option titled "Save version automatically on closing" be activated, as this would also store the entire, previous version of a file each time it is closed.
File attributes
File attributes are stored in the file information module which is meant to facilitate subsequent searches for the file. Depending on the application involved, this file information can include the title, directory path, version, creator (and editor, if applicable), comments, editing time, date of last printout, document name and document description. Some of this data is generated by the program itself, and cannot be influenced by the person editing the file. Other data needs to be entered manually. Before being transferred to external parties, files should be checked for additional information of this type.
Fast storage
Most word processing programs provide a fast-storage function which, instead of saving an entire document, only saves changes made to it since it was last saved in its entirety. This procedure thus takes less time than a full storage. However, a full storage requires less hard-disk space than a fast storage. The main disadvantage of performing a fast storage is that the file might contain text fragments which should have been eliminated during the process of reworking. For this reason, the fast-storage option should, in principle, remain deactivated.
If a user nevertheless decides to make use of the fast-storage option, he/she should always perform a full storage in the following situations:
Additional controls:
| © Copyright
by Bundesamt für Sicherheit in der Informationstechnik |
July 1999 |