2.5 Supplementary Security Analysis
As explained in Section 2.2 "Assessment of Protection Requirements", the standard security measures aimed at securing baseline protection will normally provide a reasonable and sufficient level of protection. However, if in the course of assessing protection requirements it has transpired that an IT application together with its data has a high or very high protection requirement, it may be appropriate to check whether the standard security safeguards need to be supplemented or replaced by more stringent IT security safeguards, which will generally also be more expensive. The additional measures which are appropriate can be determined after the basic IT baseline protection security check has been performed using a supplementary security analysis.
To limit the amount of effort devoted to a supplementary security analysis to what is strictly necessary, it may be appropriate to concentrate on the sensitive areas rather than analysing all the IT assets. For this purpose the areas which possess a high or very high protection requirements or are classified as sensitive should be extracted from the results of the protection requirements assessment. These might be as follows:
A supplementary security analysis is then performed on this subset of the IT assets, comprising only the sensitive items. Various methods can be used here. These include
It should be mentioned in advance that the success of the supplementary security analysis depends critically on the expertise of the project team. It is essential that the team members have in-depth specialist knowledge in the areas of information technology and IT security, ideally supplemented by broad background experience. Otherwise there is a danger that significant weaknesses or safeguards could be overlooked and that the results could convey an unwarranted impression of security. It may therefore be appropriate to have the supplementary security analysis performed by specialist external consultants.
In a risk analysis, an attempt is made to identify the threats to which an IT system is exposed due to existing security weaknesses. The probability of each of these threats occurring is then estimated and combined with the protection requirements to rate the existing risks. For any risks which are unacceptable a set of IT security measures is then selected so as to reduce the probability of occurrence and/or the extent of the potential damage.
Estimation of probabilities is particularly difficult and prone to error. Usually no statistical information is available. It is especially difficult to make these estimates for threats which entail wilful action by perpetrators. The estimates only needs to be a little on the low side to produce a risk which appears to be acceptable so that no additional measures are taken even though these are in fact necessary.
A description of how to perform a risk analysis is provided in the IT Security Manual (see References).
Penetration testing is used to estimate in advance the prospects of a deliberate attack on a set of IT assets succeeding and to deduce from this what additional measures are necessary. It entails simulating the aggressive behaviour of a wilful insider or external aggressor and ascertaining what existing security weaknesses could be used and what potential damage could be caused. The following are some of the approaches commonly used:
A distinction should be made here between two different forms of penetration testing:
A further distinction is whether penetration testing is only co-ordinated with Management or whether the staff concerned are given advance warning. Penetration testing requires in-depth knowledge and experience to perform effectively, as otherwise the possibility that the "attacks" implemented during testing may cause unintended damage cannot be excluded.
Differential security analysis
One approach to identifying the more stringent IT security measures that are necessary for those IT assets which are particularly sensitive is to perform a differential security analysis. The first step here is to investigate which IT security safeguards go beyond baseline protection or which IT baseline protection safeguards that have been implemented are classified as optional. A comparison is then performed as to whether the more stringent safeguards taken correspond to the standard solutions which have been established in practice for highly sensitive IT areas. It should be noted here that the relevant basic parameters (confidentiality, integrity and availability) are critical in determining whether the more stringent safeguards are appropriate. Thus, for example, cryptographic measures will assist in raising confidentiality and integrity aspects of security but generally they will have little effect on availability or they may even have a negative impact on achieving this objective of protection. It is also important to ensure that any products needed are suitable and that the more stringent safeguards are correctly implemented so that they can achieve their full effect.
Typical more stringent measures in the area of IT systems include the use of certified operating systems or special security versions of operating systems, the use of authentication tokens or even isolation of IT systems. Examples of more stringent measures which might be used in the area of communications links are: capping of external connections, line encryption or end-to-end encryption, armoured cable runs or pressure-monitored cables, redundant communications lines or redundant cable routing and the use of multi-level firewalls combined with intrusion detection tools. In the area of infrastructural security, the possibilities include isolating filters, fire extinguishing technology, video monitoring, access control systems and intruder detection devices through to backup computer centres.
The BSI publishes "protection class models" in which sets of more stringent safeguards suitable for IT assets with high and very high protection requirements are collected together for particular subject areas (e.g. private branch exchanges).
© Copyright by Bundesamt für Sicherheit in der Informationstechnik 2000
Last Update: October 2000