HostedDB - Dedicated UNIX Servers

-->
IT Baseline Protection Manual - Chapter 2.2 Assessment of Protection Requirements

2.2 Assessment of Protection Requirements

Assessment of the protection requirement of the IT structure captured entails four separate steps. First of all the protection requirement categories are defined. Typical damage scenarios are then used to determine the protection requirements of the various IT applications. The protection requirements of the individual IT systems are then derived from the results. These in turn are then used to arrive at the protection requirements for the transmission routes and the premises in which the IT assets are located.

Assessment of protection requirements for IT applications

The aim of the assessment of protection requirements is to decide for every IT application, including the data held or used on it, what degree of protection is required in terms of confidentiality, integrity and availability. This protection requirement is geared towards the potential loss or damage which could occur in the event of degradation of the IT application concerned.

As the protection requirement is generally not quantifiable, the IT Baseline Protection Manual will confine itself below to a qualitative statement when assigning protection requirements to three categories.

Protection Requirement Categories
Basic to moderate The impact of any loss or damage is limited.
High The impact of any loss or damage may be considerable.
Very high The impact of any damage can attain catastrophic proportions which could threaten the very survival of the agency/company.

The steps outlined below explain how to determine the right protection requirement category for IT applications.

Step 1: define protection requirement categories

The loss or damage which could occur as a result of loss of confidentiality, integrity or availability of an IT application including its data can typically be assigned to the following damage scenarios:

Often a single instance of loss or damage may involve several damage categories. Thus, for example, failure of an IT application could prevent essential work from being performed, resulting in direct financial loss and at the same time in a loss of image.

In order to be able to draw clear boundaries between the protection requirement categories "Basic to moderate", "High" and "Very high", upper and lower limits should be defined for the individual damage scenarios. To obtain a rough idea of what protection requirement is appropriate for a given level of potential damage and its impact, the following tables should be consulted.

Protection requirement category "Basic to moderate"
1. Violation of laws, regulations or contracts
  • Violations of regulations and laws with minor consequences

  • Minor breaches of contract which attract little in the way of contractual penalties
2. Impairment of the right to informational self-determination
  • Impairment of the right to informational self- determination would be assessed as tolerable by the individual.

  • Possible misuse of person related data has minimal effects on the social or financial standing of those concerned.
3. Physical injury
  • Does not appear possible.
4. Impaired performance of duties
  • Impairment would be assessed as tolerable by those concerned.

  • The maximum acceptable down time is greater than 24 hours.
5. Negative effects on external relationships
  • Minimal impairment of reputation / confidence, confined to within the agency/enterprise.
6. Financial consequences
  • The financial loss is acceptable to the agency/company.

Protection requirement category "High"
1. Violation of laws, regulations or contracts
  • Violations of regulations and laws with major consequences

  • Major breaches of contract with high contractual penalties
2. Impairment of the right to informational self-determination
  • Significant impairment of the individual's right to informational self-determination could be possible.

  • Possible misuse of person-related data would have considerable effects on the social or financial standing of those concerned.
3. Physical injury
  • Physical injury to an individual cannot be absolutely ruled out.
4. Impaired performance of duties
  • Impairment of the performance of duties would be assessed as intolerable by some of the individuals concerned.

  • The maximum acceptable down time is between one and 24 hours.
5. Negative effects on external relationships
  • Considerable impairment of reputation / confidence can be expected.
6. Financial consequences
  • The financial loss is considerable, but the agency/company can survive it.

Protection requirement category "Very high"
1. Violation of laws, regulations or contracts
  • Fundamental violation of regulations and laws

  • Breaches of contract with ruinous damage liabilities
2. Impairment of the right to informational self-determination
  • A particularly significant impairment of an individual's right to informational self-determination could be possible.

  • Possible misuse of person-related data would mean social or financial ruin for those concerned.
3. Physical injury
  • Serious injury to an individual is possible.

  • Danger to life and limb.
4. Impaired performance of duties
  • Impairment of the performance of duties would be assessed as unacceptable by all individuals concerned.

  • The maximum acceptable down time is less than one hour.
5. Negative effects on external relationships
  • A nation- or state-wide loss of reputation / confidence is conceivable, possibly even endangering the existence of the agencies/company.
6. Financial consequences
  • The agency/company may not be able to survive the financial loss.

Customisation of the assignment table

It is possible that in an individual case there may be other damage scenarios which are not included in the six scenarios listed above, in which case the table should be extended accordingly. The borderline between "Basic to moderate", "High" and "Very high" must be decided for all instances of loss or damage which are not covered in the above table.

Moreover, the individual circumstances which apply to the agency/company should be taken into account. A loss of euro 200,000 could be relatively trivial as a proportion of turnover and IT budget in a large company, whereas for a small organisation even a loss of euro 10,000 could be difficult to survive. It may therefore be appropriate to express the boundaries as percentages of the total turnover, total profit or IT budget.

Similar considerations apply as regards the availability requirements. Thus, for example, in some organisations a down time of 24 hours could still be regarded as acceptable. However, if such incidents occur relatively frequently, e.g. more than once a week, the overall effect could be unacceptable.

When setting the boundary between "Moderate" and "High" it should be borne in mind that the standard security safeguards described in this manual should be sufficient for a moderate protection requirement. The values decided on should be documented in the security concept in an appropriate manner.

Step 2: consider of damage scenarios

Starting from the assumption that a loss of confidentiality, integrity or availability of an IT application or the related information occurs, the maximum damage and consequential damage are considered. On the basis of the question

"What if ... ?"

realistic damage scenarios are developed from the user's point of view and the expected material or non-material damage is described. The extent of this possible damage ultimately determines the protection requirements of the IT application. The persons responsible for the IT applications under consideration and their users must be asked for their personal opinions. They will normally have a good idea of what damage could occur and should be able to provide a useful input into the data collected.

To simplify calculation of the possible damage, a set of questions is presented below for each of the damage scenarios mentioned, as a tool for drawing out the possible effects. These suggestions do not claim to be complete; they are merely intended as a guide. In every case it is necessary to consider the specific work and the situation of the agency/company, and the questions provided in this manual must be supplemented accordingly.

Working through the damage scenarios listed below, including the related questions, is recommended for each of the IT applications recorded. Once this has been done, the tables above should be used to determine the protection requirement with regard to confidentiality, integrity and availability by assigning each IT application to a protection requirement category.

Damage scenario "Violation of laws, regulations or contracts"

Such violations can result from the loss of confidentiality, integrity or availability. The severity of the ensuing damage will often depend on the specific legal implications for this agency/company.

Examples of relevant German legislation are:

Examples of relevant regulations are:

Examples of contracts:

Questions:

Loss of confidentiality

Is confidentiality of the data required by law?
Is disclosure of information likely to result in criminal prosecution or a claim for compensation?
Is the agency/company bound to observe any contracts which stipulate that certain information is to be treated as confidential?

Loss of integrity

Is data integrity required by law?
How severe would any violation of regulations/laws due to loss of integrity be?

Loss of availability

Would failure of the IT application result in infringement of any regulations or even of any laws? If so, to what extent?
Is certain information required to be available at all times by law?
Have any deadlines been set which it is imperative to observe when using the IT application?
Are there any contractual conditions for certain deadlines which have to be observed?

Damage scenario "Impairment of the right to informational self-determination"

When implementing and operating IT systems and IT applications, the danger exists of impairing the right to informational self-determination which can lead to abuse of person-related data.

Examples of impairment of the right to informational self-determination include:

The following questions can be used to assess the consequences and the extent of any damage:

Questions:

Loss of confidentiality

What harm could come to an individual if his person-related data were not kept confidential?
Is any person-related data processed for unauthorised purposes?
When carrying out authorised processing of person-related data, is it possible, for example, to determine the health or financial status of a person from this data?
What loss or damage could be caused by misuse of stored person-related data?

Loss of integrity

What harm could come to an individual if his person-related data were to be corrupted by accident or wilfully tampered with?
When would the loss of integrity of person-related data first be noticed?

Loss of availability

Is it possible in the event of an IT application crashing or of a fault occurring during the transmission of person-related data for any data to get lost or become corrupted so that the person concerned's social standing is harmed or he faces the risk of personal or financial detriment?

Damage scenario "Physical injury"

The malfunctioning of an IT system or an IT application can result directly in injury, disability or even death. The extent of the damage must be assessed on the basis of the direct personal damage.

Examples of such IT applications and systems are:

Questions:

Loss of confidentiality

Could a person be physically or psychologically injured through the disclosure of person-related data?

Loss of integrity

Could tampering with program sequences or data endanger people's health?

Loss of availability

Could the failure of an IT application or of the IT system result in physical injury?

Damage scenario "Impaired performance of duties"

Loss of availability of an IT application or loss of data integrity, in particular, can significantly impede or disrupt the performance of tasks within a company or agency. Here, the severity of any ensuing damage depends on the duration of the impairment and the extent to which the services offered are constrained.

Examples are:

Questions:

Loss of confidentiality

Is there any data whose confidentiality is critical to task performance (e.g. criminal prosecution information, investigation findings)?

Loss of integrity

Could data alterations restrict the performance of tasks in such a way that the company/agency will be unable to act?
Would significant damage be caused if tasks were performed using corrupt data? When would unauthorised data alterations be detected at the earliest?
Could corrupted data in the IT application under consideration lead to errors in other IT applications?
If data were incorrectly attributed to a person who did not actually generate it, what would be the consequences?

Loss of availability

Could failure of an IT application impair performance of the tasks of the given agency/company to such an extent that the resulting wasted time was no longer acceptable to those concerned?
Would any other IT applications be affected by the failure of this IT application?
Is it important to the agency/company that access to IT applications, including programs and data, must be ensured at all times?

Damage scenario "Negative effects on external relationships"

Loss of one of the fundamental parameters of confidentiality, integrity or availability in an IT application can result in a number of negative effects on external relationships, for example,

The extent of damage is defined on the basis of the severity of the loss of confidence, or on how far such external impact has actually spread.

Such damage can have a variety of causes:

Questions:

Loss of confidentiality

What implications would the unauthorised publication of sensitive data stored in the IT application have for the agency/company?
Could the loss of confidentiality of the data stored in the IT application result in any impairment of the enterprise's competitive position?
Would the disclosure of confidential data held in the IT application raise doubts about the observation of official secrecy?
Could the publication of data lead to political or social insecurity?

Loss of integrity

What damage could result from the processing, dissemination or transmission of incorrect or incomplete data?
Would the data corruption become publicly known?
Could the publication of corrupted data lead to a loss of prestige?
Could the publication of corrupted data lead to political or social insecurity?
Could corrupted data lead to reduced product quality and thus to loss of prestige?

Loss of availability

Would the failure of the IT application restrict information services provided to external parties?
Would (temporary) failure of the IT application be noticed by outsiders?

Damage scenario "Financial consequences"

Direct or indirect financial damage can result from the loss of confidentiality of sensitive data, from alteration of data, or from the failure of an IT application. Examples include:

The extent of the total damage caused is determined by the direct and indirect costs, e.g. damage to property, compensation, additional expenses (e.g. data recovery).

Questions:

Loss of confidentiality

Could the publication of confidential information result in claims for compensation?
Does the IT application contain any data which, if known to a third party (e.g. a competitor), could give it any financial advantage?
Is any research data of significant value stored using the IT application? What would happen if such data were copied and passed on without permission?
Could any damage be caused by premature publication of sensitive data?

Loss of integrity

Could any data relevant to accounting be altered by data manipulation in such a way as to cause financial loss?
Could the publication of incorrect information result in any claims to compensation?
Could any financial loss result from corrupted ordering data (e.g. just-in-time production)?
Could corrupted data lead to wrong business decisions?

Loss of availability

Would failure of the IT application impair production, inventory management or distribution?
Would failure of the IT application result in financial loss due to delayed payments or loss of interest?
How much would it cost to repair or restore the IT system if it were to fail, develop a fault, be destroyed or stolen?
Could failure of the IT application result in deficient solvency or in contractual penalties?
How many important customers would be affected by a failure of the IT application?

Step 3: documentation of the results

It is recommended that the protection requirements ascertained above for the various IT applications are documented in a table. Such a central document offers the advantage that it can be referenced during the subsequent assessment of the protection requirements of the IT systems.

Care should be taken here to ensure that not only the assessed protection requirements are documented, but also the underlying rationale for these conclusions. This rationale will ensure that the conclusions can be traced and reused subsequently.

Bundesamt für Organisation und Verwaltung (Federal Agency for Organisation and Administration, BOV) - Part 4

The table below shows the main IT applications, their protection requirements and the reasoning behind the assignment of protection requirements categories.

IT application Assessment of protection requirements
No. Name Personal data Basic parameter Protection Requirement Rationale
A1 Processing of HR data X Confidentiality High HR data constitutes particularly sensitive personal details, disclosure of which could significantly harm the person concerned.
      Integrity Moderate The protection requirement is only "moderate" since errors can be detected quickly and data subsequently corrected.
      Availability Moderate Down times of up to a week can be handled by following manual procedures.
A2 Benefits processing X Confidentiality High Benefits data includes person-related data which has a particularly high protection requirement. Some of it may also refer to illnesses and the results of medical tests. Disclosure of this data could be very harmful to the persons concerned.
      Integrity Moderate The protection requirements is only "moderate" since errors can be detected quickly and data subsequently corrected.
      Availability Moderate Down times of up to a week can be handled by following manual procedures.

At this point it may be appropriate to look beyond this information and consider the protection requirements also from an overall view of the business processes or specialist tasks. To this end it is recommended describing the purpose of an IT application within a business process or in a specialist task and inferring its importance from this. This importance can be classified as follows:

The importance of the IT application to the business process or specialist task is

The particular advantage of implementing such a standard assignment to predefined categories is that when it comes to the assessment of protection requirements, Management, which has the last say in determining the protection requirement of individual IT applications, can now act. For example, it might be that a person responsible for an IT application views its protection requirements as "basic", whereas a manager might assess it more highly, given his view of the application within the wider business process or specialist task.

This optional data should likewise be documented in a table.

Assessment of protection requirements for IT systems

In order to determine the protection requirement of an IT system, it is first of all necessary to consider the IT applications which have a direct association with the IT system. A summary of which IT applications are relevant was prepared under the previous step "Capturing information about the IT applications and related information".

In order to determine the protection requirement of the IT system, the potential damage to the relevant IT applications must be considered in its entirety. The protection requirement of an IT system is determined by the damage or the sum of the most serious instances of damage (maximum principle).

When studying the possible damage and its implications, it must also be born in mind that IT applications of an IT system may use the results of other IT applications as input. A seemingly less important IT application A can assume significantly greater importance if another, important IT application B depends on its results. In this case the protection requirement ascertained for IT application B must also be transferred to IT application A. If the IT applications in question are from different IT systems, the protection requirements of the first IT system must be transferred to the other (dependency relationship).

If several IT applications or sets of information are processed on one IT system, it should be considered whether the cumulative effect of several cases of (e.g. minor) damage is greater. In this case, the protection requirement of the IT system increases accordingly (cumulative effect).

Example: All the IT applications used by the typing department are held on one network server. The damage in the event of failure of this IT application was estimated as low, however, as there are sufficient alternatives. Should the server fail, however, (and thus also all the IT applications), the resulting damage is considerably higher. It may no longer be possible to perform the work required within the necessary time-frame. The protection requirement of these "central" components should thus also be considered higher.

The opposite effect can also occur. Thus it is possible for an IT application to have a high protection requirement, but for its protection requirement not to be passed on to an IT system under consideration because only insignificant parts of the IT application run on that IT system. In this case the protection requirement must be put in perspective (distribution effect).

Examples: The distribution effect is mainly relevant to the basic parameter of availability. Thus, for example, where IT systems have been designed in a redundant fashion, the protection requirement of the individual components may be lower than that for the entire application. Distribution effects are also possible in the area of confidentiality. For example, if there is no possibility of a client being able to retrieve critical data from a highly confidential database application, then the client, unlike the database server, may have only a low protection requirement.

Presentation of Results

The results of the assessment of the protection requirements of the IT systems should once again be recorded in a table. This should show the protection requirements of each IT system with regard to confidentiality, integrity and availability. Particular importance is to be attached to providing a rationale for the assessments made so that these can also be understood by third parties. Here reference may be made to the assessment of protection requirements for the IT application.

Bundesamt für Organisation und Verwaltung (Federal Agency for Organisation and Administration, BOV) - Part 5

Such a table might be structured as follows:

IT system Assessment of protection requirements
No. Description Basic Parameter Protec-tion Reqt. Reasoning
S1 Server for Human Resources Confidentiality High Maximum principle
    Integrity Moderate Maximum principle
    Availability Moderate Maximum principle
S2 Primary domain controller Confidentiality Moderate Maximum principle
    Integrity High Maximum principle
    Availability Moderate The protection requirement for application A4 has been assessed as high; therefore a high protection requirements for this parameter should be assumed. However, it should be borne in mind that this application is distributed over two computer systems. It is also possible for staff working in the Bonn office to be authenticated via the backup domain controller in Berlin. Unserviceability of the primary domain controller is acceptable for a period of up to 72 hours. Given this distribution effect, the protection requirement is therefore only "moderate".

Notes: If the majority of IT applications on an IT system require only moderate protection, and one or only a few require high protection, it may be appropriate to consider the option of transferring these few applications to a stand-alone IT system as a way of achieving possible savings. The case for such an alternative can be prepared for submission to Management for a decision.

Additional aids:

Some record sheets have been developed as an aid to the task of assessing protection requirements. These will be found on the CD-ROM which comes with the manual (see Annex: Auxiliary Aids).

Assessment of protection requirements for communications links

Once the protection requirements for the IT systems under consideration have been established in the previous step, the protection requirement regarding the networking structure must now be determined. The main source used here is the network plan prepared in Section 2.1 for the IT assets under investigation.

To prepare the way for decisions as to which communications routes require the use of cryptographic security safeguards, which parts of the network should have built-in redundancy and over which connections attacks by insiders and external adversaries are to be expected, as well as the IT systems themselves, the various communications links must now be considered. In this analysis, the following communications links should be regarded as critical:

One approach to gathering information about critical communications links is as follows. Initially all "external connections" are identified and recorded as critical connections. All the connections which lead from an IT system with a high or very high protection requirement are then investigated. In this way the connections over which information having a high protection requirement is transmitted are identified. The connections over which this sensitive data is transmitted downstream are then investigated. Finally the communication links over which such information is not supposed to be transmitted must be identified. The information collected should include:

The data collected during this exercise can either be documented in tabular form or else highlighted graphically on the network plan.

Bundesamt für Organisation und Verwaltung (Federal Agency for Organisation and Administration, BOV) - Part 6

In our fictitious example of the BOC, there are the following critical connections:

In the diagram, the critical connections are indicated by "bold" lines. The numbers next to the lines indicate the reason (or reasons) why a particular connection is critical and are explained in the column headings of the next table.

  Reason for criticality
connectionen 1
External connection
2
High confidentiality
3
High integrity
4
High availability
5
Transmission not permitted
N1 - Internet X        
N5 - N6 X        
S1 - N4   X      
S3 - N3       X  
S4 - N3       X  
S5 - N3       X  
C1 - N4   X      
N1 - N2       X X
N2 - N3       X  
N4 - N3         X

It is very important during this survey to make sure that the summary produced is complete. It only takes one critical connection to be omitted for the overall security to be compromised. Thus, for example, all the modems used must be recorded as potentially critical connections to the outside world could run from them. Often, however, these modem external connections are viewed as objects conferring prestige on their "owners" and their existence is denied in order to obtain personal advantage, or modems are purchased and classified as consumables without those responsible for IT being informed of the purpose for which they are to be used. However, if IT security is to be maximised, such critical devices and connections must not be overlooked.

Assessment of protection requirements for IT rooms

When it comes to IT baseline protection modelling and planning of the target versus actual comparison, it will be helpful if a summary has been drawn up of the rooms in which IT systems are installed or which are used for IT operations. These include both rooms which are used solely for IT operations (e.g. server rooms, data media archives) and rooms in which IT systems happen to be operated (e.g. offices). Where an IT system is housed in a protective cabinet instead of in a special technology room, the protective cabinet should be classified as a room.

Note: the installation locations should have already been recorded when information was being gathered about the IT systems.

The protection requirements for each room should then be derived from the results of the assessment of the protection requirements of the IT systems. This protection requirement is derived from the protection requirements of the IT systems or the data media stored in the room according to the maximum principle. During this assessment the possibility of a cumulative effect should be considered where a relatively large number of IT systems are located in a single room, such as is frequently the case in server rooms. In addition, the reasoning behind the assessed protection requirement should be documented.

Once again, it is helpful to draw up a table containing the necessary information.

Bundesamt für Organisation und Verwaltung (Federal Agency for Organisation and Administration, BOV) - Part 7

The table below shows an extract of the results obtained for the BOV:

Room IT assets Protection requirement
Desig-nation Type Location IT systems / data media Confiden-tiality Integrity Availability
R U.02 Data media archive Bonn building Backup data media (weekly backups of servers S1 to S5) High High Moderate
R B.02 Technology room Bonn building Private Branch Exchange Moderate Moderate High
R 1.01 Server room Bonn building S1, N4 High High Moderate
R 1.02 - R 1.06 Offices Bonn building C1 High Moderate Moderate
R 3.11 Protective cabinet in room R 3.11 Bonn building Backup data media (daily backups of servers S1 to S5) High High Moderate
R E.03 Server room Bonn building S6, N6, N7 Moderate High High
R 2.01 - R 2.40 Offices Bonn building C4, some with fax machines Moderate Moderate Moderate

Interpreting the results of the protection requirement assessment

The results obtained from the protection requirements assessment serve as the starting point from which to proceed towards drawing up the IT security concept. The assumptions regarding protection requirements categories which are used to deduce the level of protection afforded by the standard security safeguards recommended in this manual are as follows:

Protective effect of standard security safeguards aimed at achieving IT baseline protection
Protection requirement category "Basic to moderate" Standard security safeguards aimed at IT baseline protection are generally adequate and reasonable.
Protection requirement category "High" Standard security safeguards aimed at IT baseline protection afford a basic level of protection but may not be sufficient on their own. Additional safeguards can be ascertained by performing a supplementary security analysis.
Protection requirement category "Very high" Standard security safeguards aimed at IT baseline protection afford a basic level of protection but generally are not sufficient on their own. The necessary additional security safeguards must be ascertained on a case-by-case basis on the basis of a supplementary security analysis.

If the protection requirement for an IT system is defined as "moderate", then it is sufficient to implement the standard safeguards aimed at IT baseline protection across the board. For IT systems, network connections and rooms where IT assets are used which have a "high", and especially if they have a "very high", protection requirement, a supplementary security analysis should be planned in. Again, the high protection requirement of these components should be borne in mind during the target versus actual comparison when working through safeguards identified in the manual as being "optional". Thus, for example, safeguard S 1.10  Use of Safety Doors may not be necessary in a server room which has a moderate protection requirement, yet where a high level of confidentiality is required it could be absolutely essential.


© Copyright by
Bundesamt für Sicherheit in der Informationstechnik
last update:
October 2000
home