S 2.80 Drawing up a requirements catalogue for standard software

Initiation responsibility: Head of the Specialist Department

Implementation responsibility: Specialist Department, Head of IT Section

In order to solve a task processed with IT, there are a number of similar standard software products available on the market. These are similar in their basic functions but differ in certain criteria, such as purchase and operating costs, additional functions, compatibility, administration, ergonomics and IT security.

Requirements Catalogue

When selecting a suitable product, a Requirements Catalogue must first be compiled. The Requirements Catalogue should contain information on the following points:

• Functional requirements which the product must meet concerning the fulfilment of the task of the relevant department. The individual functions relevant for the specific task should be highlighted.

Brief examples:

• Word processing with the additional functions: the inclusion of graphics, macro programming, spell check and syllabification. It must be possible to switch off the macro programming, the spell check must be available in English, French and German. It must be possible to import and export the specified text formats.

• Data base (front end and back end) for multi-user operation with support of the standard language SQL and graphic user interface.

• Appointment calendar to co-ordinate and monitor appointments of the members of the department with integrated appointment coordination, automatic despatch of invitations and tasks and priority lists, connection to the internal mail program.

• IT environment. On the one hand, this is determined by the requirements of the existing or planned IT environment and on the other hand by the requirements placed on the environment by the product.

Brief examples:

• Predetermined IT environment: With Novell 3.11 networked PC, 80486 processor, 8 MB main memory, 500 MB hard disk capacity, disk drive, CD ROM drive, MS DOS 6.0. The product may occupy a maximum of 50 MB on the hard disk, it must run under Windows 3.11 and be compatible for networking.

• System requirements: The word-processing program X requires 16 MB, it runs on a PC with at least a 80386 processor, 8 MB main memory, Windows 3.11.

• Compatibility requirements with other programs or IT systems, i.e. migration support and upward and downward compatibility.

Brief examples:

• Data in the existing data base XYZ must be taken over.

• The functions A, B, C must remain in the event of version exchange.

• The exchange of data with the Unix system XYZ must be possible.

• Performance requirements describe the required performance as regards throughput and running time. Information concerning the maximum permissible processing time should be as precise as possible for the required functions.

Brief examples:

• The maximum response time when carrying out function X must not exceed 2 seconds.

• The encryption rate should be at least 60 KB/sec on a 486 DX 33.

• Other simultaneously conducted process must not be slowed down by more than 30 % as a result of the product.

• Interoperability requirements, i.e. it must be possible to work together with other products despite platform limitations.

Brief examples:

• Versions of the word processing program should be available for Windows, Unix and Macintosh platforms. It should be possible to compile documents on one operating system and processes them on another.

• The text processing program must be able to work together with the mail program used.

• Reliability requirements affect the stability of the products, i.e. the detection of errors and tolerance, failure and operational security.

Brief examples:

• Incorrect input by the user must be detected and must not cause the program or system to crash.

• The data base must have mechanisms which allow all transactions to be reconstructed (roll forward) in the event of a crash with destruction of the data base.

• Conformity with standards. These may be international standards, de-facto standards or internal standards.

Brief examples:

• The product must comply with the EU monitor guideline 90/270/EEC.

• The implementation of a token ring LAN must be in conformance with ENV 41110.

• The product must be in accordance with the X/Open Standard.

• Adhering to internal regulations and legal stipulations (e.g. sufficient data protection when processing person-related data)

Brief examples:

• The product must comply with the principles of proper EDP-controlled auditing systems.

• As person-related data are processed, it must be possible to meet the requirements stipulated in the Federal Data Privacy Act.

• Requirements regarding user-friendliness, characterised by how easy the system is to operate, understand and learn, i.e. particularly by the quality of the user interface and documentation, and the help functions.

Brief examples:

• An on-line help function must be available.

• The user interface must be designed in such a way that unskilled persons can become familiar with the basic functions within two hours.

• The documentation should be available in the local language.

• Requirements concerning serviceability for the user are mainly based on the handling of errors.

Brief examples:

• The amount of administration involved must not be too high.

• The provider must offer a hotline for questions.

• The product must be easy to install and configure.

• The product must be easy to deinstall.

• The maximum costs resulting from the purchase of this product are predetermined. Not only the immediate purchase costs should be taken into consideration, but also costs arising at a later date, e.g. for updating hardware, personnel costs or training.

Brief examples:

• The product may cost a maximum of DM 15,000.

• The training costs must not exceed DM 2,000.

• The requirements concerning documentation must highlight which documents are required and in which quality (completeness, comprehensibility).

Brief examples:

• The user documentation must be easy to understand and suitable for reading without instruction. All functions of the product should be described.

• The system manager documentation must include troubleshooting information.

• Demands on software can range from the manufacturer's declaration concerning the quality assurance systems used, ISO 9000 etc. certificates to independent software tests according to ISO 12119.

Brief examples:

• The software production process of the manufacturer must be certified according to ISO 9000.

• The functionality of the product must be checked by an independent body according to ISO 12119.

• It the product is to fulfil IT security functions, these are to be set down in security requirements (c.f. S 4.42 Implementation of Security Functions in the IT Application). This is described in detail below.

Security Requirements

Dependent on whether the product must have security features, security functions can be stipulated in the Requirements Catalogue. Typical security functions which are relevant here are briefly explained. Further details are to be found in the ITSEC.

• Identification and authentication

Many products require that those users who have access to resources controlled by the product should be determined and monitored. Not only the claimed identity of the user should be determined, but it should be checked whether the user really is the person he claims to be. This takes place by the user providing the product with information connected to the user in question.

• Access control

For many products it will be necessary to ensure that users and processes working for these users are prevented from gaining access to information or resources when they are not entitled to access or when access is not necessary. Further, there will be requirements concerning the unauthorised creation or modification (including deletion) of information.

• Logging

For many products it will be necessary to ensure that actions taken by users or processes on behalf of such users are recorded. This allows the consequences of such actions to be assigned to the user in question so that the user can be held responsible for his actions.

• Protocol evaluation

For many products it will be necessary to ensure that sufficient information is recorded concerning both usual and unusual incidents. Checks at a later date can thus determine whether security breaches have taken place and which information or other resources were affected.

• Incorruptibility

For many products it will be necessary to ensure that certain relations between various data remain correct and that data can be transferred between various processes without alteration.

Furthermore, functions must be available which allow losses, additions or alterations to be detected when transferring data between various processes, users and objects, and which make it impossible to alter the supposed or actual origin or destination of the data transmission.

• Reliability

For many products it will be necessary to ensure that time-critical tasks are carried out at precisely the required point in time, i.e. not earlier and not later. It is also necessary that tasks which are not time-critical are not transferred into time-critical tasks. Furthermore, it is necessary for many products to ensure that access is possible at the relevant moment and that resources are not unnecessarily called up or withheld.

• Transmission security

This term comprises all functions designed for the protection of data during transmission via communication channels:

• Authentication

• Access control

• Data confidentiality

• Data integrity

• non-repudiation

Some of these functions are implemented by means of cryptographic processes.

Further security requirements in addition to ITSEC can be placed on standard software.

• Data backup

Great demands are placed on the availability of data processed with the product. This includes functions integrated in the product which serve to prevent data loss, such as the automatic saving feature or the automatic creation of backups before making major alterations.

• Encryption

Encryption serves as a preserver of data confidentiality. For many products it will be necessary to encrypt data before transmission or after processing and to decrypt information after receipt or before rerouting. An accepted encryption algorithm should be used for this purpose. It should be ensured that the parameters required for decrypting (e.g. key) are protected in such a way that unauthorised access to this data is not possible.

• Functions for the preservation of data integrity

In case of data whose loss of integrity could lead to damage, functions can be used which are able to detect or even correct errors by means of redundancy. In most cases, integrity tests are used which can reliably detect intentional manipulation of the product or data and any unauthorised replay of data. These tests are based on cryptographic mechanisms (see S 5.36 Encryption under Unix and Windows NT and S 4.34 Using Encryption, Checksums or Digital Signatures)

• Requirements concerning data privacy

If person-related data are to be processed with the product, additional special technical requirements should be placed beside the stated security functions in order to be able to comply with data privacy stipulations.

Strength of the Mechanisms

Security functions are implemented by mechanisms. Depending on the field of usage, these mechanisms must be of various strengths which provide defence against attacks. The necessary strength of the mechanisms is set forth in the Requirements Catalogue. According to ITSEC, differentiations are made between three mechanism strengths:

• low: offers protection against unintentional attacks, e.g. operational errors

• medium: offers protection against attackers with limited opportunities or resources.-

• high: can only be overcome by attackers with an extensive knowledge, opportunities and resources. A successful attack is generally not considered possible.

Examples of Requirements on Security Features

Below are examples of some important security functions which highlight typical requirements placed on security features.

In the event that the product is to have an identification and authentication mechanism, the following requirements could be made, for example:

• Access should only be possible via a defined interface. A log-on mechanism can be used, for instance, which requires unique user identification and a password. In the event that the identity of the user is known when the IT system is accessed, an anonymous password is sufficient. Other possibilities are processes based on certain "tokens", such as a chip card.

• The access procedure itself must correctly handle the critical parameters, such as password, user identification etc. Current passwords should thus never be stored unencrypted on the relevant IT systems.

• The access procedure must react to incorrect entries in a predefined manner. For instance, if an incorrect authentication takes places three times consecutively, the access to the product should be rejected. Alternatively, the time intervals in which further access attempts can be made should be gradually increased.

• The access procedure must allow certain minimum requirements for security-critical parameters to be set. The minimum length of a password, for example, should be 6 characters, the minimum length of a PIN should be 3 digits. The syntax for passwords can also be stated, as necessary.

If the product is to have access control, the following requirements can be placed, for instance:

• The product must be able to differentiate between various users.

• The product must be able to assign resources to individual authorised users and to completely deny access to unauthorised parties.

• It should be possible to control access by means of a differentiated rights structure (read, write, execute, change etc.). The data relevant for the management of rights should be managed in such a way that they are protected against manipulation.

In the event that the product is to keep log records, the following requirements are recommended:

• The minimum the product must be able to record should be parameterisable. It should be possible to record the following actions, for example:

• For authentication: User ID, date and time, success, ...

• For access control: user ID, data and time, success, type of access, what was changed, read, written, ...

• Implementation of administrative activities

• Occurrence of operational errors.

• Unauthorised persons must neither be able to deactivate the logging function, nor should they be able to read or edit the actual logs.

• Logs must be clear, complete and correct.

In the event that the product is to have a protocol evaluation feature, the following requirements are recommended:

• An evaluation function must be able to distinguish between the various data types contained in a log (e.g. "filtration of all unauthorised attempts at accessing any resource over a specified time period").

The evaluation function must be capable of generating transparent, readable reports so that no critical security-related activities can be overlooked.

In the event that the product is to have functions concerning incorruptibility, the following requirements can be placed, for example:

• A data base management system must be able to describe rules of certain relationships between the stored data (e.g. referential integrity). Furthermore, suitable mechanisms must be in place which prevent these rules being violated by changing data.

In the event that the product is to have functions regarding data backup, the following requirements can be placed, for example:

• Specifications can be made as to which data should be backed up when.

• An option for loading any required data backup is available.

• It is possible to backup several generations.

• It is possible to backup instantaneous data at specified intervals while an application is being run.

In the event that the product is to have encryption components, the following requirements are recommended:

• Encrypted algorithms used by government agencies should be approved by the BSI. Individual consultation by the BSI is recommended in this case. If not in agencies, the DES is suitable for moderate protection requirements.

• The key management must be in line with the functionality of the product. In particular, fundamental differences between algorithms must be considered here:

• symmetric algorithms use a key for encrypting and decrypting which is to be kept secret,

• asymmetric algorithms use a public key for encrypting and a private key (to be kept secret) for decrypting.

• The product must correctly manage security-critical parameters, such as the key. Keys should thus never be stored unprotected (even expired keys), i.e. readable.

In the event that the product is to have an integrity test feature, the following requirements are recommended:

• The product carries out an integrity check every time a program is called up.

• Mechanisms should be used which can detect intentional manipulation of address fields and payload data during data transmission. Knowledge of the algorithms alone, without other special knowledge, should not be sufficient to manipulate the above data without detection.

In the event that person-related data are to be processed with the product, the following requirements concerning data privacy are placed, for example:

• The product may not permit general requests for data analyses. These analyses of data must be limited to certain criteria.

• It must be possible to parameterise the system in such a way that changes, deletions or print-outs for certain files are only possible according to the two-person principle.

• It must be possible to parameterise the logging feature in such a way that records can be kept of who made which changes to person-related data.

• The transfer of person-related data must be determined and checked with suitable random tests (BDSG, § 10). The type of random test must be individually programmable.

• The product must enable person-related data to be deleted. Alternatively, it must be possible to block person-related data in order to limit or prevent these being processed or used.

Assessment Scale

In order to be able to carry out a comparison of various products, criteria must be available as to what extent the various requirements are fulfilled. To do this, it is necessary to assess the quantitative and qualitative importance of the various requirements for the IT-supported task.

This assessment can take place in three steps, for example. In the first step, it is determined which features stipulated in the Requirements Catalogue are necessary and which are desirable. If a necessary feature is not fulfilled, the product is rejected (so-called K.O. criterion). In the event that a desirable feature is not fulfilled, this is considered as a negative aspect, but the product is not necessarily rejected as a result.

As a second step, the importance of the desirable features is determined. This can be quantitative, for example, with values between 1 for low and 5 for high. Necessary features must not be assessed quantitatively. In the event that this is necessary, however, these features must be of a higher value than the desirable features (in order to highlight the importance of a necessary feature, it can represent a value of 10, for example).

In the third step, a confidence factor is determined for the feature with regard to fulfilment of its intended task (e.g. with values between 1 for low and 5 for high). On the basis of this confidence factor, a decision is taken as regards the extent to which feature is to be tested. The confidence factor of the security mechanisms must be determined in accordance with their strengths.

• low mechanism strength with confidence factor 1

• medium mechanism strength with confidence factor 3

• high mechanism strength with confidence factor 5

These guidelines should be checked according to the individual cases.

Examples:

In extracts, security requirements for some typical standard software products are described below:

Word processing programs:

Necessary security features:

• Automatic saving of intermediate data while the program is running

Desirable security features:

• Password protection of individual files

• Encryption of individual files

• It must be possible to switch off the macro programming

File compression program:

Necessary security features:

• With regard to data preservation, files to be deleted after compression must only be deleted by the compression program if compression has been performed successfully.

• Before a file is decompressed, its integrity must be checked so that bit errors in the compressed file can be detected, for example.

Desirable security features:

• Password protection of compressed files

Appointment calendar:

Necessary security features:

• Reliable identification and authentication of the users must take place, e.g. using passwords.

• Access control for the appointment calendars of the various employees is required.

• It must be possible to assign separate access rights for individuals, groups and superiors.

• It must be possible to differentiate between read and write access.

Desirable security features:

• Automatic backup of data in an encrypted form should be possible.

Travel expenses calculation system:

Necessary security features:

• Reliable identification and authentication of the users must take place, e.g. using passwords.

• Access control must be in place and available for individual data records.

• It must be possible to assign separate access rights for the user, administrator, auditor, and data privacy officer. It must be possible to separate the functions of administrator and auditor.

• Data backups must be performed in such a way that they are stored in an encrypted form and can only be accessed by authorised persons.

• Detailed logging functions must be in place.

Desirable security features:

• An optional integrity check for payment-related data should be available.

Example of an assessment scale:

A specialist department intends to purchase a compression program for data backup purposes. After a Requirements Catalogue has been drawn up, the features specified in the catalogue could be assessed as follows:

Additional controls:

• Who is involved in the drawing up of the Requirements Catalogue?

• Who decides whether a product must contain security functions?

• Are there standardised requirements concerning how an analysis should be structured?