Skip to main content
SpringerLink
Log in

Vorstellung und Bewertung rechnergestützter Beratungssysteme zur Entwicklung von Sicherheitsstrategien

  • Chapter
Sicherheitsstrategien in der Informationsverarbeitung

  • 32 Accesses

Zusammenfassung

Für verschiedene Teilbereiche der Sicherung der Informationsverarbeitung sind rechnergestützte. Informationssysteme entwickelt worden. Sie lassen sich nach einem ersten Klassifizierungsansatz in operative und strategische1 Systeme unterteilen. Operative Systeme unterstützen die Verantwortüchen bei der Realisierung von Sicherungsmaßnahmen. Zu diesen Systemen zählen z. B.2 rechnergestützte Katastrophenpläne3, Systeme zur formalen Verifikation von Software, zur Unterstützung der Suche nach typischen Schwachstellen in Betriebssystemen4, zur Überwachung von Rechnersystemen5 und Netzwerken6 oder zur Analyse von Schwachstellen in ‘Key-Management-Systemen’7. Die verbreitetsten operativen Systeme ermöglichen Identifikation und Autorisierung der Benutzer in Großrechnersystemen8. Die operativen Systeme sollen im Rahmen dieser Arbeit nicht weiter berücksichtigt werden.

This is a preview of subscription content, log in via an institution to check access.

Access this chapter

Log in via an institution
Chapter
USD 29.95
Price excludes VAT (USA)
  • Available as PDF
  • Read on any device
  • Instant download
  • Own it forever
eBook
USD 49.99
Price excludes VAT (USA)
  • Available as PDF
  • Read on any device
  • Instant download
  • Own it forever
Softcover Book
USD 59.99
Price excludes VAT (USA)
  • Compact, lightweight edition
  • Dispatched in 3 to 5 business days
  • Free shipping worldwide - see info

Tax calculation will be finalised at checkout

Purchases are for personal use only

Institutional subscriptions

Preview

Unable to display preview. Download preview PDF.

Unable to display preview. Download preview PDF.

Anmerkungen zu Kapitel 4

  1. Vgl. zur Definition und Abgrenzung der Begriffe ‘operativ’ und ‘strategisch’ Kap. 3.1

    Google Scholar 

  2. Die hier aufgeführten Systeme sind in der Fachliteratur häufig genannte Beispiele für rechnergestützte Instrumente zur Verbesserung der Sicherheit der Informationsverarbeitung.

    Google Scholar 

  3. Solche Katastrophenpläne werden in rechnergestützter Form in der Bundesrepublik Deutschland z. B. von der Heine & Partner GmbH und von der SNI AG vertrieben. Vgl. Heine & Partner /Kv-Plan/ 1 ff.; Siemens /Führungssystem/ o. S. und SNI /FÜSYS/ o. S.

    Google Scholar 

  4. Vgl. Schultz /Overview/ 75

    Google Scholar 

  5. Diese Systeme dienen im wesentlichen der Aufdeckung von Anomalien bzw. von Eindringversuchen. Vgl. Liebl, Biersack, Beyer/Sicherheitsaspekte/ 198 ff. Das bekannteste System dieser Kategorie ist das Intrusion Detection Expert System (IDES). Vgl. Denning /Model/ 118 ff. und Denning, Neumann /Requirements/ 1 ff. Über weitere Systeme dieser Kategorie berichten Kerr /AI/ 57; Liebl, Biersack, Beyer /Sicherheitsaspekte/ 198 f.; Schultz /Overview/ 75 und Tener /Discovery/ 261 ff.

    Google Scholar 

  6. Möglichkeiten zur Überwachung und Steuerung des Netzwerkbetriebs mit Hilfe von Expertensystemen werden bei Terplan aufgezeigt. Vgl. Terplan/Kommunikationsnetze/ 149. Vgl. zu realisierten wissensbasierten Systemen für diesen Bereich Hitson /Monitoring/ 210 ff.; Khakhar/Expert Systems/ 39 und Liebl, Biersack, Beyer/Sicherheitsaspekte/ 199

    Google Scholar 

  7. Vgl. Longley, Rigby /Expert Systems/ 213 ff.

    Google Scholar 

  8. Solche Systeme sind z. B. RACF, ACF 2 und TOP SECRET. Vgl. zur Struktur und Funktionalität dieser Systeme z. B. Hutt /Role/ 20 ff. und Walsh /Security/ 211 ff.

    Google Scholar 

  9. Die verschiedenen im Rahmen der Strategieentwicklung anfallenden Aufgaben sind in Kap. 3.2 und 3.3 behandelt worden.

    Google Scholar 

  10. Vgl. Schmitz, Bons, van Megen /Software-Qualitätssicherung/ 17 ff.

    Google Scholar 

  11. Vgl. Schmitz, Bons, van Megen /Software-Qualitätssicherung/ 20 ff. Die Strukturierung der Anforderungen lehnt sich an folgenden Quellen an: vgl. DIN /DIN 66285/ 6 f.; Schmitz, Bons, van Megen /Software-Qualitätssicherung/ 21 ff.; Seibt /Qualitätskriterien/ 27 ff. und TÜV /Rahmenprüfplan/ 10. Anforderungen an rechnergestützte Werkzeuge zur Entwicklung von Sicherheitsstrategien sind auch von Browne und Gilbert vorgestellt worden. Vgl. Browne /Information/ 27 ff.; Gilbert /Guide/ 10 ff. und Gilbert /Risk Analysis/ 220

    Google Scholar 

  12. Vgl. Schmitz /Software-Qualitätssicherung/ 311 und Schmitz, Bons, van Megen /Software-Qualitätssicherung/ 23

    Google Scholar 

  13. Vgl. zur Erläuterung der Begriffe Kap. 3.3.1

    Google Scholar 

  14. Die Schulung der Mitarbeiter wird in den meisten Unternehmen derzeit noch vernachlässigt. Vgl. Farhoomand, Murphy /Managing/ 68 und Kap. 3.2.2

    Google Scholar 

  15. Vgl. Browne /Framework/14

    Google Scholar 

  16. Vgl. zu den Phasen der Strategiebildung Kap. 3.3.2

    Google Scholar 

  17. Vgl. DIN /DIN 66285/ 6; Schmitz /Software-Qualitätssicherung/ 312 f.; Schmitz, Bons, van Megen /Software-Qualitätssicherung/ 25 ff. und TÜV /Rahmenprüfplan/ 10

    Google Scholar 

  18. Vgl. DIN /DIN 66285/ 3 ff. und TÜV /Rahmenprüfplan/ 2 ff.

    Google Scholar 

  19. Alternativ dazu sind auch andere Einteilungen denkbar, z. B. in Hardware, Software, Organisation, Personal und Gebäude oder ähnliches. Vgl. hierzu Kap. 3.3.2.3

    Google Scholar 

  20. Beispielsweise ist die Gefahr ‘Duplikation’ lediglich für Programme und Informationen, nicht aber für Hardware relevant Bei der Risikoanalyse eines Hardware-Elements soll die Gefahr ‘Duplikation’ also nicht aufgeführt werden.

    Google Scholar 

  21. Vgl. zu einer näheren Erörterung der Begriffe Kap. 4.2.1

    Google Scholar 

  22. Vgl. hierzu Kap. 3.3.2.3 ff.

    Google Scholar 

  23. Vgl. hierzu Kap. 3.3.2.8

    Google Scholar 

  24. Vgl. hierzu Kap. 2.2.3

    Google Scholar 

  25. Vgl. hierzu im Detail Kap. 6

    Google Scholar 

  26. Vgl. DIN /DIN 66234/ 236 ff.; DIN /DIN 66285/ 6 f.; Schmitz /Software-Qualitätssicherung/ 312 und Schmitz, Bons, van Megen /Software-Qualitätssicherung/ 25

    Google Scholar 

  27. Vgl. DIN /DIN 66285/ 6; Schmitz /Software-Qualitätssicherung/ 312 und Schmitz, Bons, van Megen /Software-Qualitätssicherung/ 25

    Google Scholar 

  28. Vgl. DIN/DIN 66285/6

    Google Scholar 

  29. Vgl. DIN/DIN 66285/6 f.

    Google Scholar 

  30. Vgl. hierzu Kap. 3.3.1

    Google Scholar 

  31. Vgl. DIN /DIN 66285/ 6; Schmitz /Software-Qualitätssicherung/ 312 und Schmitz, Bons, van Megen /Software-Qualitätssicherung/ 26 f.

    Google Scholar 

  32. Vgl. TÜV /Rahmenprüfplan/ 11

    Google Scholar 

  33. Vgl. DIN /DIN 66285/ 6; Schmitz /Software-Qualitätssicherung/ 312 und Schmitz, Bons, van Megen /Software-Qualitätssicherung/ 26 und TÜV /Rahmenprüfplan/ 10

    Google Scholar 

  34. Sicherheitsbegriffe dieser Art liegen z. B. Systemen zugrunde, die im wesentlichen auf Checklisten für Gefahren oder Maßnahmen basieren, ohne einen Hinweis auf die prinzipielle Unvollständigkeit dieser Checklisten zu geben.

    Google Scholar 

  35. Vgl. hierzu Kap. 2.1.2

    Google Scholar 

  36. Vgl. Stelzer /BSI-Grundfunktionen/ 25

    Google Scholar 

  37. Vgl. zu einer detaillierteren Erörterung von Sicherheitsmodellen Kap. 7

    Google Scholar 

  38. Vgl. Schmitz /Software-Qualitätssicherung/ 312; Schmitz, Bons, van Megen /Software-Qualitätssicherung/ 22 und TÜV /Rahmenprüfplan/ 13

    Google Scholar 

  39. Vgl. Schmitz /Software-Qualitätssicherung/ 312; Schmitz, Bons, van Megen /Software-Qualitätssicherung/ 27 f. und TÜV /Rahmenprüfplan/ 5

    Google Scholar 

  40. Vgl. Kap. 4.1.3

    Google Scholar 

  41. Vgl. hierzu auch die Ausführungen zum Qualitätsmaß ‘Verständlichkeit’ in Kap. 4.1.3

    Google Scholar 

  42. Vgl. Schmitz /Software-Qualitätssicherung/ 312; Schmitz, Bons, van Megen /Software-Qualitätssicherung/ 25 f. und TÜV /Rahmenprüfplan/ 13

    Google Scholar 

  43. Vgl. DIN /DIN 66285/ 4; Schmitz /Software-Qualitätssicherung/ 311; Schmitz, Bons, van Megen /Software-Qualitätssicherung/ 24 und TÜV /Rahmenprüfplan/ 13

    Google Scholar 

  44. Vgl. hierzu Kap. 9

    Google Scholar 

  45. Vgl. Kap. 2.1 und Schmitz, Bons, van Megen /Software-Qualitätssicherung/ 27. Die Verbindlichkeit spielt bei den Beratungssystemen nur eine untergeordnete Rolle und soll deshalb hier nicht näher erörtert werden.

    Google Scholar 

  46. Als weitere Beispiele für Sicherungsfunktionen nennt Gilbert die automatische Speicherung der Namen von Bearbeitern bei neuen Eingaben und Modifikationen sowie des Bearbeitungsdatums. Vgl. Gilbert/Guide/ 16

    Google Scholar 

  47. Vgl. zu einer ausführlichen Diskussion des Begriffs Wirtschaftlichkeit Stüdemann /Betriebswirtschaftslehre/ 19 ff. Seibt stellt den Zusammenhang zwischen Leistungsprofil und Kosten in bezug auf Software dar. Vgl. Seibt /Qualitätskriterien/ 30 f.

    Google Scholar 

  48. Vgl. Seibt /Qualitätskriterien/ 30 f.

    Google Scholar 

  49. Im Rahmen der Bewertung gegebener Beratungssysteme interessieren lediglich die Kosten und Leistungen im Zusammenhang mit Betrieb und Wartung des Softwaresystems. Bei einer Neuentwicklung muß auch die Wirtschaftlichkeit der Entwicklung berücksichtigt werden.

    Google Scholar 

  50. Vgl. hierzu Kap. 4.1.2

    Google Scholar 

  51. Vgl. hierzu insbesondere die Kap. 4.1.3 bis 4.1.6

    Google Scholar 

  52. In diesen Zahlen sind keine Systeme enhalten, die lediglich für den Eigenbedarf einzelner Organisationen entwickelt wurden und die Dritten nicht zugänglich sind.

    Google Scholar 

  53. Einige der Systeme sind nicht explizit zur Unterstützung der Strategieentwicklung konzipiert worden. Trotzdem leisten sie alle zu einem oder zu mehreren Teilaspekten der Strategiebildung einen Beitrag. In die Betrachtung sind nur solche Beratungssysteme aufgenommen worden, zu denen dem Verfasser dieser Arbeit eine ausreichende Informationsbasis vorlag. Zunächst wurden Literaturquellen zu den entsprechenden Systemen ausgewertet. Im Frühjahr 1991 wurden die Hersteller bzw. Vertreiber der Beratungssysteme angeschrieben und um Mithilfe gebeten. Bei der Abfassung dieser Arbeit lagen dem Verfasser z. T. die kompletten Systeme, z. T. Demonstrationsdisketten und z. T. umfangreiche Dokumentationen vor. Über die im Rahmen dieser Arbeit behandelten Werkzeuge hinaus berichtet vor allem Gilbert über weitere, in den USA vertriebene Beratungssysteme. Vgl. Gilbert /Tools/ o. S.

    Google Scholar 

  54. Vgl. hierzu z. B. Computer Associates /CA-EXAMINE/1 ff.

    Google Scholar 

  55. Hierzu zählen z. B. die Systeme @RISK und PRISM, die zwar von Gilbert in die Betrachtung einbezogen werden, die aber nicht sicherheitsspezifisch sind. Vgl. Gilbert /Tools/ o. S.; Palisade Corporation /@RISK/ o. S. und Palisade Corporation /PRISM/ o. S.

    Google Scholar 

  56. Vgl. Browne /Information/ 28 und Gilbert /Guide/ 3 ff. Gilbert grenzt quantitative Systeme folgendermaßen von qualitativen Systemen ab: Quantitative Systeme basieren auf mathematischen Modellen und unterstützen den Benutzer bei der Durchführung von Rechnungen. Der Problemlösungsbeitrag von quantitativen Systemen beruht hauptsächlich auf verbalen Problemlösungsbeschreibungen. Vgl. Gilbert/Guide/ 15. Browne unterscheidet außerdem ‘große’ und ‘kleine’ Systeme. Diese Unterscheidung soll hier jedoch nicht verwendet werden.

    Google Scholar 

  57. Sofern nichts anderes erwähnt wird, sind alle Beratungssysteme auf Mikrocomputern unter dem Betriebssystem MS-DOS ablauffähig.

    Google Scholar 

  58. Vgl. zu den folgenden Ausführungen Bound, Ruth /Tool/ 147 ff. und Meitner /Objectives/ 4–8 f.

    Google Scholar 

  59. Vgl. zu den folgenden Ausführungen Gardner /Evaluation/ 480 f.; Gilbert /Tools/ o. S. und Jacobson /Tools/ 73 ff.

    Google Scholar 

  60. Dieser Erwartungswert wird mit dem Begriff ‘Annual Loss Expectancy (ALE)’ bezeichnet und in Kap. 6 näher erörtert.

    Google Scholar 

  61. Vgl. zu den folgenden Aussagen Gilbert /Tools/ o. S. und Jacobson /Tools/ 73 ff.

    Google Scholar 

  62. Vgl. zu den folgenden Ausführungen Gardner /Evaluation/ 481 f.; Gilbert /Tools/ o. S.; Hoffman /Prototype/ 135 ff. und Pfleeger /Security/ 465 ff.

    Google Scholar 

  63. Vgl. hierzu Hoffman /Prototype/ 135 ff.

    Google Scholar 

  64. Vgl. zu den folgenden Aussagen Gilbert /Tools/ o. S. und Ozier, Perry & Associates /BDSS/ o. S. Kap. 4.3.1 dieser Arbeit beinhaltet eine ausführliche Bewertung von BDSS.

    Google Scholar 

  65. Vgl. hierzu Kap. 4.3.1.3

    Google Scholar 

  66. Vgl. zu den folgenden Ausführungen Mitroff /Programming/ 75 ff.

    Google Scholar 

  67. Vgl. zu den folgenden Ausführungen Carroll /COSSAC/ 2 ff. und Gardner /Evaluation/ 484 f.

    Google Scholar 

  68. COSSAC wurde mit Hilfe der Expertensystemsheil ‘Versatile Expert System’ entwickelt.

    Google Scholar 

  69. Die Wissensbasis von COSSAC ist in verschiedene Module unterteilt, die in Regeln formuliertes Wissen zu folgenden Bereichen enthalten: zentrale Komponenten der Informationsverarbeitung; sensitive, aber nicht klassifizierte Informationen; klassifizierte Informationen; Komponenten von IVS, die finanzielle Transaktionen unterstützen, und Computer-Viren.

    Google Scholar 

  70. Vgl. hierzu DoD /Criteria ’85/ 1 ff.

    Google Scholar 

  71. Vgl. zu den folgenden Aussagen Gilbert /Tools/ o. S. und Fitzgerald /CONTROL-IT/ o. S.

    Google Scholar 

  72. Dieses Modul wird auch als eigenes Produkt unter dem Namen ‘RANK-IT’ vertrieben.

    Google Scholar 

  73. Vgl. zu den folgenden Ausführungen Gilbert /Tools/ o. S. und Countermeasures Inc. /Information/ o. S.

    Google Scholar 

  74. Der Sicherheitsverantwortliche kann beispielsweise ‘What-If-Analysen’ durchführen, um auf diese Weise besonders gefährdete Bereiche zu ermitteln.

    Google Scholar 

  75. Der orthographische Fehler ist Teil des Produktnamens. Vgl. zu DDIS Abel /DDIS/ 301 ff.; Abel, Schmölz /DDIS/ 6 ff.; Breuer /DDIS/ 105 ff.; Breuer /Risikoanalysen/ 470 ff.; Lang /DDIS/ o. S. und Wettmann /Software/ 348

    Google Scholar 

  76. Diese Problembereiche werden in der Bewertung von DDIS in Kap. 4.3 noch einmal angesprochen.

    Google Scholar 

  77. Vgl. zu den folgenden Ausführungen Baratte /MARION AP/ 323 ff.; Gilbert /Tools/ o. S. und Lamère /MARION-XP/ 85 ff.

    Google Scholar 

  78. Hierzu zählen neben dem Produkt MARION-XP die Methode MARION (Méthodologie d’Analyse des Risques Informatiques et d’Optimation par Niveau) sowie weitere, darauf aufbauende Softwareprodukte, z. B. zur Durchführung von Sicherheitsanalysen in vernetzten Systemen und in kleinen und mittleren Unternehmen. Vgl. Baratte /MARION AP/ 323 ff. und Lamère /MARION-XP/ 85 ff.

    Google Scholar 

  79. Die angemessene Höhe des Sicherheitsbudgets wird durch Vergleich mit dem branchenüblichen Durchschnitt ermittelt. Vgl. Gilbert /Tools/ o. S. Dieses Beratungsergebnis kann daher nur einen ersten Anhaltspunkt darstellen und bedarf in jedem Fall einer weiteren Prüfung.

    Google Scholar 

  80. Vgl. zu den folgenden Ausführungen Clark /CRAMM/ 1 ff.; Farquhar /Approach/ 21 ff.; Gilbert /Tools/ o. S.; Moses, Glover /CRAMM/ 1 ff. und Moses, Glover /Risk Analysis/ 243 ff.

    Google Scholar 

  81. Die fehlende Modifikationsmöglichkeit ist problematisch, da viele — vor allem organisatorische — Sicherungsmaßnahmen in Begriffen formuliert sind, die zwar für britische Regierungsinstitutionen typisch sind, in privaten Unternehmen aber nicht unbedingt verstanden werden. Vgl. Farquhar /Approach/ 22

    Google Scholar 

  82. Vgl. zu den folgenden Aussagen Gilbert /Tools/ o. S.; Smith /Analysis/ 483 ff.; Smith /Expert System/ 179 ff. und Smith /LAVA/ 1 ff.

    Google Scholar 

  83. Vgl. Smith /Analysis/ 483 ff.; Smith /Expert System/179 ff. und Smith /LAVA/ 1 ff.

    Google Scholar 

  84. Vgl. zu den folgenden Ausführungen Breuer /Risikoanalysen/ 473 ff.; Browne /Framework/ 1 ff.; Browne, Laverty /Decision Analysis/ 117 ff.; CPA /RISKPAC/ o. S. und Gardner /Evaluation/ 482

    Google Scholar 

  85. Dieses Modell wird in Browne /Framework/ 1 ff. und Browne, Laverty /Decision Analysis/ 117 ff. beschrieben.

    Google Scholar 

  86. Vgl. hierzu auch Kap. 4.4.1

    Google Scholar 

  87. Die in BDSS vorgesehenen Kategorien sind: ‘computer equipment, facility/support equipment, media & supplies, documentation, personnel, application/systems software and data, goodwill’.

    Google Scholar 

  88. Das Bayes-Theorem ist eine Vorschrift für das Rechnen mit bedingten Wahrscheinlichkeiten. Es dient dazu, Aussagen über die Wahrscheinlichkeit von Ereignissen unter der Voraussetzung des Eintreffens anderer Ereignisse zu machen. Vgl. hierzu z. B. Bohley /Statistik/ 326 ff.; Karras, Kredel, Pape /Entwicklungsumgebungen/ 51 f. und Sieben, Schildbach /Entscheidungstheorie/ 59 f.

    Google Scholar 

  89. Im Rahmen der Bewertung der Qualitätsmerkmale ‘Funktionsabdeckung’ und ‘Vollständigkeit’ werden diese Aspekte aus-führlicher behandelt. Vgl. Kap. 4.3.2.2

    Google Scholar 

  90. Allerdings ist diese Strukturierung nicht sehr sinnvoll. Vgl. hierzu Kap. 4.3.2.3

    Google Scholar 

  91. Vgl. hierzu Kap. 2.1.2.1

    Google Scholar 

  92. Vgl. Kap. 4.3.2.3

    Google Scholar 

  93. Vgl. Gilbert /Tools/ 6. Die von Gilbert gemachten Aussagen beziehen sich auf die Risikoanalysefunktionen der auch im Rahmen dieser Arbeit betrachteten Systeme BDSS, The Buddy System, CONTROL-IT, CRAMM, CRITI-CALC, IST/RAMP, LAVA, MARION, RiskCALC und RISKPAC.

    Google Scholar 

  94. Vgl. zum Konzept des Ebenenmodells Kap. 2.2.2

    Google Scholar 

  95. Vgl. hierzu Kap. 3.2.2.1 und 3.2.3.1

    Google Scholar 

  96. Breuer /Risikoanalysen/ 474

    Google Scholar 

  97. Breuer/Risikoanalysen/473

    Google Scholar 

  98. Vgl. zur Erörterung der genannten Aspekte der Strategiebildung Kap. 3.3.2.4

    Google Scholar 

  99. So überschreibt z. B. Breuer eine Untersuchung der Produkte DDIS und RISKPAC mit dem Untertitel “Die ... «Expertensysteme» ... im Vergleich”. Breuer /Risikoanalysen/ 470. Für das Produkt RISKPAC wird mit Hilfe des Attributs ‘Expertensystem’ geworben: “RISKPAC. Expert System Risk Assessment Software”. CPA /RISKPAC/ o. S.

    Google Scholar 

  100. So basiert z. B. DDIS auf der konventionellen Software Framework III. Vgl. hierzu Kap. 4.3.2.5 dieser Arbeit. Der Hersteller von RISKPAC begründet das Attribut ‘Expertensystem’ damit, daß bei der Erstellung von RISKPAC Expertenwissen verwendet wurde. Vgl. CPA /RISKPAC/ o. S. Durch Aussagen von Browne und Laverty wird allerdings deutlich, daß es sich bei RISKPAC nicht um ein Expertensystem im Sinne der in dieser Arbeit verwendeten Definition handelt: “RISKPAC ... does not (yet) embody artificial intelligence.... RISKPAC does not use a commercial AI ‘shell’, nor is it programmed in Prolog or Lisp. It uses QuickBasic, a highly structured language, and a considerable amount of Assembly Language code”. Browne, Laverty /Decision Analysis/ 129

    Google Scholar 

Download references

Authors
  1. Dirk Stelzer
    View author publications

    You can also search for this author in PubMed Google Scholar

Rights and permissions

Reprints and permissions

Copyright information

© 1993 Springer Fachmedien Wiesbaden

About this chapter

Cite this chapter

Stelzer, D. (1993). Vorstellung und Bewertung rechnergestützter Beratungssysteme zur Entwicklung von Sicherheitsstrategien. In: Sicherheitsstrategien in der Informationsverarbeitung. Deutscher Universitätsverlag, Wiesbaden. https://doi.org/10.1007/978-3-663-14556-1_4

Download citation

  • DOI: https://doi.org/10.1007/978-3-663-14556-1_4

  • Publisher Name: Deutscher Universitätsverlag, Wiesbaden

  • Print ISBN: 978-3-8244-2038-4

  • Online ISBN: 978-3-663-14556-1

  • eBook Packages: Springer Book Archive

Publish with us

Policies and ethics

Search

Navigation