S 2.80 Drawing up a requirements catalogue for standard software

Initiation responsibility: Head of Specialised Department

Implementation responsibility: Head of IT, Specialised Department

The market commonly offers numerous standard software products with similar functionality to accomplish a task performed with the help of IT. Although their basic functionality is comparable, they differ in terms of certain criteria such as purchasing and operating costs, additional functionality, compatibility, administration, ergonomics, and information security.

Requirements catalogue

For this reason, it is necessary to draw up a requirements catalogue for the selection of a suitable product first. The requirements catalogue should contain statements relating to the following aspects, amongst other things:

• Functional requirements the product must meet in order to help the specialised department perform its tasks. Emphasis should be placed on the individual functions relevant to the specialised task.
  
  Brief examples:
  • Text processing with the additional functions: incorporation of graphs, macro programming, spell checker and syllabification. It must be possible to switch off macro programming. Spell checker must be available in English, French, and German. It must be possible to import and export the specified text formats.
  • Text processing with the additional functions: incorporation of graphs, macro programming, spell checker and syllabification. It must be possible to switch off macro programming. Spell checker must be available in English, French, and German. It must be possible to import and export the specified text formats.
  • Database (front-end and backend) for multi-user mode supporting the default query language SQL and graphical user interface
  • Schedule for coordinating and controlling dates of the members of the department, including integrated coordination of dates, automatic sending of invitations and task and priority lists, interface to the internal mail program
• IT application environment described by the general conditions arising from existing or planned IT application environments on the one hand, and on the other hand by the performance requirements specified regarding the application environment by the product.
  
  Brief example:
  • Required IT application environment and performance requirements: operating system, CPU, main memory, hard disk capacity, interfaces for external data media and for networking
• Compatibility requirements regarding other programs or IT systems, i.e. support for migration and upward and downward compatibility.
  
  Brief examples:
  • It must be possible to accept databases from the present database XYZ.
  • The functions A, B, C must be maintained after version changes.
  • It must be possible to exchange data with the Unix system XYZ.
• Performance requirements describe the performance needed in terms of the throughput and runtime response. The specifications of the maximum allowable processing times for the required functions should be as precise as possible.
  
  Brief examples:
  • The maximum response time when executing function X must not exceed a value of 2 seconds.
  • Other simultaneously processed processes must only be slowed down by the product by 30% at the most.
• Interoperability requirements, which means it must be possible to use the product across different platforms in conjunction with other products.
  
  Brief examples:
  • Versions of the text processing program are to be available for Windows, Unix, and MacOS platforms (in the versions to be specified). It should be possible to create documents on one operating system and process them on a different operating system.
  • The text processing program must be able to collaborate with the email program currently used.
• Reliability requirements refer to the stability of the product, which means the detection of errors, tolerance to errors, and operational reliability of the product.
  
  Brief examples:
  • Erroneous entries of the user must be detected and must not result in any program cancellation or system crash.
  • The data must have mechanisms allowing for reconstructing all transactions in the event of a system cancellation, including database destruction (roll-forward).
• Conformity with standards, which can mean international standards, de-facto standards, or even organisational standards.
  
  Brief example:
  • The product must comply with the EU display directive 90/270/EEC.
• Adherence to internal provisions and legal regulations (e.g. concerning adequate data privacy when processing personal data)
  
  Brief examples:
  • The product must meet the basic principles of proper DP-supported accounting systems.
  • Since personal data is processed, the provisions of the Federal Data Protection Act must be complied with by means of the implemented functions.
• Requirements regarding user-friendliness, which are characterised by how easy it is to use, understand, and learn to use the product. In particular, this means the quality of the user interface, as well as the quality of the user documentation and the help functions.
  
  Brief examples:
  
  • An online help function must be implemented.
  • The user interface must be designed in such a way that untrained employees can be instructed regarding its use within two hours.
  • The user documentation and the user interface should be present in the local language.
• Requirements regarding the serviceability for the user mainly arise in terms of troubleshooting the product.
  
  Brief examples:
  • The administrative effort must not be too high.
  • The provider must establish a hotline for questions.
  • Product installation and configuration must be easy.
  • Product de-installation must be easy.
• The upper limit of the costs incurred through the purchase of this product must be specified. The maximum cost specified must not only include the direct purchase price of the product itself, but also the subsequent costs such as the cost of upgrading the hardware, personnel costs, and the cost of the necessary training.
  
  Brief examples:
  • The product must cost at most 15,000.00 euro.
  • The training costs must not exceed an amount of 2,000.00 euro.
• The requirements for the documentation must specify which documents are necessary and in which quality (i.e. completeness, understandability).
  
  Brief examples:
  • The user documentation must be easy to understand and suitable for self-instruction. The entire functionality of the product must be described.
  • The system administrator documentation must contain instructions for possible errors.
• In terms of the software quality, requirements can be specified ranging from the manufacturer declarations and the quality assurance procedure used, ISO 9000 et seq. certificates, up to independent software tests according to ISO/IEC 25051.
  
  Brief examples:
  • The software production process of the manufacturer must be certified according to ISO 9000.
  • The functionality of the product must have been checked independently according to ISO/IEC 25051.
• If the product will be used to provide security functions, these functions must be formulated in the form of security requirements (see S 4.42 Implementation of security functions in IT applications).This is explained in more detail in the following.

Security requirements

Security functions can be listed in the requirements catalogue depending on whether the product is required to provide security features. Typical security functions that come into question here are explained briefly below. The Common Criteria (for testing and evaluating the security of information technology) contain further information.

• Identification and authentication
  
  Many products will have requirements for specifying and monitoring those users who have access to the operating resources monitored by the product. For this, it is not only necessary to verify the identification data provided by the user, but also to check whether the user is actually the person he/she claims to be. This is accomplished by requiring each user to supply the product with information that is permanently linked to the user.
• Access control
  
  For many products, it will be necessary to ensure that users and the processes active for these users are prevented from obtaining access to information or operating resources they do not have the right to access or to which they do not require access. Likewise, there will be requirements relating to the unauthorised generation or modification (including the deletion) of information.
• Retention of evidence
  
  For many products, it will be necessary to ensure that information on the operations executed by the users and/or by processes in the name of such users is recorded so that the consequences of such operations can be traced back to a specific user later on and the user can be held responsible for his/her actions.
• Log evaluation
  
  For many products, it must be ensured that adequate information both on normal processes and on extraordinary incidents is recorded so that it is possible to check later on whether security violations were actually committed and which information or other operating resources were affected by the violations.
• Incorruptibility
  
  For many products, it will be necessary to ensure that certain relationships between various data remain correct and that data is transmitted between individual processes without making any changes during transmission.
  
  In addition, functions must also be provided that allowing for losses, additions, or changes to data to be detected or prevented during the transmission of the data between individual processes, users, and objects and rendering any modifications to the apparent or actual source and/or destination of the data transmission impossible.
• Reliability
  
  For many products, it will be necessary to ensure that time-critical tasks are executed exactly at the time required, meaning no later and no earlier than specified, and it must also be ensured that it is impossible to convert tasks time is not a criterion for into time-critical tasks. Likewise, it will be necessary for many products to ensure that access is possible at the necessary times and that operating resources are not held back or requested unnecessarily.
• Secure transmission
  
  This term includes all functions needed to protect the data during transmission over communication channels:
  • Authentication
  • Access Control
  • Data confidentiality
  • Data integrity
  • Send and receive conformations
  • Some of these functions are implemented by means of cryptographic processes.

Furthermore, additional security requirements may be specified in detail for standard software.

• Data backup
  
  High requirements exist regarding the availability of the data processed by the product. This item also includes the functions integrated into the product for preventing losses of data such as the automatic storage of intermediate results or the automatic creation of backup copies before making a large number of changes.
• Encryption
  
  Encryption serves to maintain the confidentiality of data. For many products, it will be necessary to ensure that user data is encrypted before transmission or after processing and decrypted upon receipt or before processing the data further. A recognised encryption method must be used to this end. It must be ensured that the parameters (e.g. the keys) needed for decryption are protected in such a manner that unauthorised persons cannot gain access to this data.
• Functions to preserve the integrity of data
  
  For data whose loss of integrity may result in damages, it is possible to use functions allowing errors to be detected or even corrected with the help of redundancy. Usually, procedures for checking the integrity are used that can reliably detect deliberate manipulations to the product and/or to the data generated by it, as well as any unauthorised restorations of data from backups. They are based on cryptographic methods (see S 4.34 Using encryption, checksums, or digital signatures).
• Requirements relating to the data protection laws
  
  If personal data are to be processed using the product, additional special technical requirements must exist regarding the product extending beyond the mentioned security functions to ensure conformance to the data protection regulations.

Strength of the mechanisms / attack resistance

Security functions are implemented using mechanisms. Depending on the purpose, these mechanisms must have a varying strength to defend against attacks. The required strength of the mechanisms must be specified in the requirements catalogue. When applying the Common Criteria (CC), the attack resistance of an IT product operated in a certain application environment is evaluated using the threats for the data objects to be protected defined in the security specifications or possibly in a protection profile and the testing intensity specified for evaluation. The required testing intensity includes the definition of the attack resistance and depends on the protection requirements and the use of the product. The testing intensity is defined on the basis of a catalogue(see CC, part 3), mostly with the help of predefined evaluation stages (EAL 1 to 7).

In order to evaluate the attack resistance, the attacks relevant for the application scenario are analysed according to the state of the art up to a certain intensity, taking into consideration the required attack duration, technical expertise of the attacker, knowledge regarding the product, attack opportunity, and required resources. In this, the attack resistance is confirmed within the certification framework in the classes basic, enhanced basic, moderate, and high.

Basic means protection against publicly known attacks and against attackers with very limited skills and resources. High means that a successful attack requires very good technical knowledge, product know-how, opportunities, and resources and therefore is deemed extremely complex.

Examples of requirements for security features

Below, examples for some important security functions are mentioned used as a basis for typical requirements for security features.

If the product is to provide identification and authentication mechanisms, the following requirements may exist regarding the product, for example:

• Access may only be obtained over a defined interface. In this case, a login mechanism may be used, for example, requiring the user to enter a unique user ID and password. If the identity of the user is already ensured by the IT system before access is requested, then the entry of an anonymous password is adequate. Other possibilities include procedures based on the ownership of certain "tokens", for example based on a chip card.
• The access procedure itself must manage the parameters critical to security such as passwords, user IDs, etc., securely. For example, current passwords must never be stored in unencrypted form on the corresponding IT systems.
• The access procedure must react in a defined manner to incorrect data input. For example, if authentication fails three times in a row, access to the product must be denied or, as an alternative, the delay specified before another attempt to access the IT system is allowed can be gradually increased.
• The access procedure must allow certain minimum values to be specified for the parameters critical to security. For example, the minimum password length should be at least eight characters, and the minimum length of a PIN should be four digits. The complexity of the passwords should be specified as well.

If the product is to provide access control, the following requirements could exist regarding this access control, for example:

• The product must be able to differentiate between users.
• The product must be able to grant authorised users access to individual resources according to the specifications and to completely deny all access by unauthorised persons.
• It must be possible to control access using a detailed rights structure (read, write, execute, change, ...). The data relating to the administration of these rights must be managed by the product in such a way that this data cannot be manipulated.

If the product is to be equipped with a logging function, then it might make sense to specify the following requirements:

• It must be possible to parameterise the minimum scope of information that the product must log. For example, it should be possible to log the following actions:
  • for authentication: the user ID, time and date, success, etc.
  • for access control: the user ID, time and date, success, type of access, what data was read, stored, or changed and how it was changed, etc.
  • the execution of administration tasks
  • occurrences of functional errors
• It must be impossible for unauthorised persons to disable the logging function. It must also be impossible for unauthorised persons to read or modify the log files themselves.
• The logs generated must be clear, complete, and correct.

If the product is to be equipped with a log evaluation function, it might make sense to specify the following requirements:

• An evaluation function must be provided with the ability to differentiate between the different types of data required to be logged (e.g. "filter all unauthorised accesses to all resources in a specified time period").
  
  The evaluation function must generate readable reports so that no activities critical to security will be overlooked.

If the product is to be equipped with functions for incorruptibility, the following requirements could be specified, for example:

• A database management system must provide the ability to draw up rules for certain relationships between the stored data (for example for referential integrity). In addition, suitable mechanisms must be available making any violation of these rules impossible by changing the data.

If the product is to provide functions for data backups, the following requirements can be specified, for example:

• It must be possible to configure which data will be backed up at which times.
• There must be an option available for restoring any of the data backups available.
• The function must permit the backing up of several generations.
• It must be possible to make data backups of the intermediate results of running applications.

If the product is to be equipped with an encryption component, it may make sense to specify the following requirements:

• The implemented encryption algorithm should match the protection requirements and should have sufficient mechanism strength (see also S 2.164 Selection of a suitable cryptographic procedure).
• The key management must harmonise with the functionality offered by the product. In particular, basic differences between the algorithms used must be taken into consideration:
  • Symmetric methods use a key to encrypt and decrypt information, and this key must be kept secret
  • Asymmetric methods use a public key for encryption and a private key (to be kept secret) for decryption
• The product must manage the parameters critical to security, for example the keys. For example, keys (even keys not used any more) should never be stored unprotected, meaning in a readable form, on the corresponding IT systems.

If the product is to provide mechanisms for performing integrity checks, it may make sense to specify the following requirements:

• The product must execute an integrity check every time the program is called.
• When transmitting data, mechanisms must be used that can detect deliberate manipulations to the address fields and the user data. In addition, sheer knowledge of the algorithms used alone should not be enough to make undetectable manipulations to the data without any additional special knowledge.

If personal data is processed using the product, the following data protection requirements could be specified, for example:

• The product must not allow general queries to be submitted to evaluate data. It must be possible to restrict the evaluation of the data records to certain criteria.
• It must be possible to configure that changes to, deletions of, or the output of personal data are only possible for certain files when the two-person rule is applied.
• It must be possible to configure the log function so that it is possible to record who made what changes to which personal data.
• It must be possible to monitor and check for transmissions of personal data using suitable spot check procedures (BDSG, § 10). It must be possible to individually specify the type of spot check.
• The product must allow the deletion of personal data. As an alternative, it must be possible to block personal data to prevent or restrict the further processing or use of such data.

Assessment scale

In order to be able to compare different products in the context of a benefits analysis, there must be criteria available for evaluating the degree of fulfilment of each of the requirements. For this, it is necessary to quantitatively or qualitatively assess the importance of each individual requirement for the ability to perform the desired IT-based tasks in advance.

This assessment can be done in three stages, for example. In the first stage, you specify which of the features specified in the requirements catalogue are required and which are desired. If a required feature is not provided, then the product must be rejected (referred to as a K.O. criterion). The lack of a desired feature is assessed negatively, but the lack of a desired feature does not necessarily lead to the rejection of the product.

In the second stage, the importance of the desired features to the ability to perform the corresponding tasks is specified. The importance can be evaluated quantitatively using values between 1 for low and 5 for high, for example. Required features do not need to be evaluated quantitatively. However, if a quantitative assessment is necessary to perform other calculations, their quantitative assessments must always be higher than the assessments of each of the desired features (to indicate the importance of a required feature, you could assign it a value of 10, for example).

In the third stage, a confidence factor could be used to specify the ability of the required features to fulfil their tasks correctly (for example with values between 1 for low and 5 for high). Based on the confidence factor, it is then decided how extensively the feature needs to be tested later on. The confidence factors for the security mechanisms must be specified according to the strength of their mechanisms, for example:

• Low-strength mechanism with confidence factor 1
• Moderate-strength mechanism with confidence factor 3
• High-strength mechanism with confidence factor 5

This basic scheme must be specified individually on a case-by-case basis.

Examples:

Excerpts of security requirements for typical standard software products should be provided:

Text processing program:

Required security features:

• Automatic data backup of intermediate results during live operation
  
  Desired security features:
• Password protection for individual files
• Encryption for individual files
• It must be possible to disable the macro programming functionality

File compression program:

Required security features:

• For data backups, the files to be deleted after compression should only be physically deleted by the compression program after the compression has completed successfully without errors.
• The integrity of the files must be checked before decompression so that bit errors can be detected in the compressed files, for example.

Desired security features:

• Password protection for compressed files

Appointment calendar:

Required security features:

• Secure identification and authentication of each user must be enforced, for example using passwords.
• Access control is necessary for the appointment calendars of each individual employee.
• It must be possible to grant different access rights to individuals, groups, and supervisors.
• It must be possible to grant read and write privileges separately.

Desired security features:

• Automated backup of the data in encrypted form.

Travel expense accounting system:

Required security features:

• Secure identification and authentication of each user must be enforced, for example using passwords.
• Access control must be available and also applicable to individual databases.
• It must be possible to grant different access rights to users, administrators, auditors, and data protection officers. It must be possible to separate the administrator and auditor roles.
• It must be possible to execute data backups so that they can be stored in encrypted form and can only be restored by authorised persons.
• Detailed logging functions must be provided.

Desired security features:

• The product should offer an optional integrity check for transaction-related data.

Example of an assessment scale:

A specialised department wants to purchase a compression program for data backup purposes. After creating the requirements catalogue, the features specified in the catalogue could be assessed as follows, for example:

Property	Required	Desired	Importance	Confidence factor
Correct compression and decompression	X		10	5
Detection of bit errors in a compressed file	X		10	2
Deletion of files only after successful compression	X		10	3
DOS PC, 80486, 8MB	X		10	5
Windows-compatible		X	2	1
Throughput of over 1MB/s at 50MHz		X	4	3
Compression rate over 40% for text files of the program XYZ		X	4	4
Online Help system function		X	3	1
Maximum cost of 50.00 Euro per licence	X		10	5
assword protection for compressed files (high-strength mechanisms)		X	2	5

Review questions:

• Is a requirements catalogue comprising security requirements drawn up for the selection of software products to be used?
• Was an assessment scale for the individual requirements for software products drawn up in order to be able to compare the products?