OSsecure: Sicherer IT-Betrieb – Anforderungen an einen ordnungsgemäßen Programmeinsatz

Das folgende Dokument beschreibt alle Fragestellungen zum „Sicheren IT-Betrieb“, den daraus resultierenden „Anforderungen an einen ordnungsgemäßen Programmeinsatz“, sowie der „Ordnungsmäßigkeit und Prüfung der Datenverarbeitung“ (OPDV) Nr. 1 / 2006. Alle Fragestellungen resultieren auch aus den Anforderungen der MaRisk i.Bes. AT 7.2 – Technisch-organisatorische Ausstattung, sowie den Anforderungen an den IT-Grundschutz, welchen das Bundesamt für Sicherheit in der Informationstechnik (BSI) als Vorgehensweise zum Identifizieren und Umsetzen von Sicherheitsmaßnahmen der unternehmenseigenen Informationstechnik bezeichnet. Ziel des IT-Grundschutzes ist das Erreichen eines angemessenen und ausreichenden Schutzniveaus für IT-Systeme. Weiterhin finden Sie Informationen und Zertifikate zu ECB•S und VdS, den bekanntesten Zertifizierungsstellen für Sicherheitsprodukte im Bankenumfeld. Bitte beachten Sie unsere Copyright-Informationen bei der Verwendung und Weitergabe dieser Informationen.

Zusätzliche Informationen zum Datenschutz, zur Datensicherheit und zur Risikobewertung, sowie Mustervorlagen zur Einwilligung der Datennutzung und für Vorlagen für die Vereinbarungen mit Personalräten beim Einsatz biometrischer Systeme finden Sie hier:

Die folgenden Erläuterungen beschreiben zunächst die gängigen Standards und Zertifizierungen, welche bei Prüfungen häufig angefragt werden. Im zweiten Abschnitt erfolgt dann eine zusammenfassende „Software-“ Beschreibung, sowie eine Gliederung der unterschiedlichen Konfigurationsmöglichkeiten des OSsecure-Systems. Abschließend finden Sie die häufigsten Fragen zu dieser Thematik kurz und verständlich beantwortet. Weiterführende Antworten auf Ihre Fragen entnehmen Sie bitte der FAQ-Kategorie in diesem Support-Portal.

Überblick Standards und Zertifizierungen

Um die Umsetzung von (Informations-) Sicherheits-Systemen zu unterstützen, wurden in der Vergangenheit unterschiedliche Standards, Normen und Zertifizierungen entwickelt (z. B. ISO/IEC 2700x, IT-Grundschutz, VdS-Prüfnormen). Durch die Anwendung dieser Sicherheitsstandards wird sichergestellt, dass allgemein anerkannte, einheitliche Methoden und Best Practices in die Realisierung von Sicherheits-Systemen einfließen. Die standardkonforme Umsetzung ist in der Regel prüf- und auditierbar und je nach Standard auch zertifizierbar. Eine Zertifizierung kann als Nachweis für IT- und Sicherheits-Verantwortliche, Sachversicherer oder die Berufsgenossenschaft dienen.

Aufgrund ihrer unterschiedlichen Themengebiete kommt es oft vor, dass verschiedene Standards und Anforderungen für Verantwortliche relevant sind. Durch Überschneidungen und auch durch die Gleichsetzung oder Vermischung von Themen entsteht ein entsprechender Koordinierungs- und Infomationsbedarf, welcher hier aufgezeigt wird.

OPDV – Anforderungen an einen ordnungsgemäßen Programmeinsatz

Der Einsatz von Software hat in Banken auf der Grundlage eines geregelten Programm-Einsatzverfahrens (PEV) zu erfolgen. Der Umfang und die Gestaltung des PEV kann nach individueller Risikoeinschätzung der Bank abgestuft gestaltet werden. Alternativ kann auch auf ein „zertifiziertes“ Prüfungsverfahren zurückgegriffen werden, welches die Freigabe der Software z.B. gemäß „OPDV“ bescheinigt. Das OSsecure-System fällt nicht unter die prüfungsrelevanten Kriterien, da die für die relevanten Risiko-Faktoren auf die Geräte und Prozesse des Systems nicht zutreffen oder durch das System beeinflusst werden. OSsecure bietet keine Abhängigkeiten hinsichtlich „risikobehafteter“ Kriterien und in Bezug auf prüfungsrelevante Vorgaben. OSsecure greift in keine Prozesse der Rechnungslegung ein und es bestehen zwischen den Kernbanksystemen (OSPlus, bank21, agree BAP) und OSsecure keine „schreibenden“ Schnittstellen. Das OSsecure-System ist nicht auf Bank-Systemen installiert, sondern OSsecure als „Produkt“ bezeichnet eine „Firmware“ (Software), welche auf der Hardware der Kassensicherungs-Systeme integriert ist. Historisch war die OPDV Prüfung immer dann erforderlich, wenn eine „fremde“ Software-Anwendung auf einem Bank-System installiert wurde oder mit anderen Bank-Systemen „interagierte“. In der erweiterten Stellungnahme „OPDV – 1/2006“ wurden weitere Kriterien ergänzt, welche die Ordnungsmäßigkeit und Prüfung der Datenverarbeitung sicherstellen sollten.

MaRisk – Technisch-organisatorische Ausstattung AT 7.2 und BTR 4 Operationelle Risiken

Neben den Anforderungen an einen ordnungsgemäßen Programmeinsatz, sind die Abhängigkeiten – basierend auf der MaRisk, AT 7.2 – hinsichtlich der technisch-organisatorische Ausstattung zu bewerten. Konkret geht es um spezielle Teil- oder Geschäftsprozesse, welche sich mit Hilfe des OSsecure-Systems steuern lassen. Die System-Bewertung hinsichtlich MaRisk hängt hierbei von dem jeweiligen Einsatzzweck oder genutzten Geräten und Modulen des OSsecure-Systems ab. Weiterhin fordert die MaRisk BTR 4 die Identifikation, Bewertung, Meldung und Maßnahmenableitung der operationellen Risiken. Nahezu alle Geräte und Prozesse des Systems haben keinerlei Einfluss auf die nach MaRisk zu bewertenden Geschäftsprozesse der Bank. Der Prozess der Bargeldver- und entsorgung und die damit verbundenen Schließ- und Öffnungsprozesse der Wertgelasse (Geldautomaten, Tresore, AKT, Recycler, etc.) sind jedoch zwingend zu bewerten. Die MaRisk fordert, dass die Abhängigkeiten mit deren Hilfe jene Prozesse Umsetzung finden, mit in die Planung der Geschäftsaktivitäten einbezogen werden.

Die Risikoeinschätzung sollte sich an folgenden Kriterien orientieren:

1. Einfluss auf die Kundenbeziehung.
2. Wirtschaftliche Auswirkungen bzw. Auswirkungen auf geschäftspolitische Entscheidungen.
3. Einfluss auf die Einhaltung von gesetzlichen oder bankaufsichtlichen Vorschriften.
4. Überstellung von Daten an Anwendungen, die unter diesen Kriterien als „risikorelevant“ einzustufen sind.

Wird bei der Risikoeinschätzung festgestellt, dass beim Einsatz der Software nur geringe oder keine Risiken eingegangen werden, so kann ein vereinfachtes PEV durchgeführt oder gänzlich auf das Verfahren verzichtet werden.

Bei den operationellen Risiken handelt sich es aus Sicht der Bafin um Risiken, welche z.B. durch Betrug, Diebstahl, Limitüberschreitung, Insiderhandel, falsch bewertete Positionen oder Systemausfälle (z.B. von Kernbank-Systeme) entstehen können. Auch hier geht von den durch OSsecure gesteuerten Geschäftsprozessen kein oder nur ein sehr geringes Risiko aus, da die Schutzziele der durch OSsecure gesteuerten Geschäftsprozesse auf die Prävention und den Schutz vor Überfällen abzielen. Der Einsatz von biometrischen Systemen innerhalb der Kassensicherung erfolgt auf der gesetzlichen Grundlage der „DGUV Vorschrift 25“, bzw. der früheren Unfallverhütungsvorschrift BGV C9 / GUV-V C9 (UVV „Kassen“). Mit dem Einsatz des OSsecure Systems (bzw. dem Einsatz von Zeitverschluss-Behältnissen/Tagestresoren, Personenschleusen, Biometrie) soll der Anreiz eines Überfalls für externe Täter reduziert werden, um Mitarbeiter präventiv vor Gefahren (z.B. Überfällen) zu schützen. Der Schutz der Sachwerte (z.B. Bargeldbestände in den Wertgelassen) ist hierbei nicht primäres Ziel. Der Sachwerten-Schutz wird durch die Vorgaben und Zertifizierungen des VdS und der Sachversicherer, sowie der internen Revision erfüllt. Der VdS prüft beispielsweise Hochsicherheitsschlösser von Wertgelassen (z.B. TwinLock) auf ein mögliches Risiko durch Manipulation. Hierbei ist es unerheblich, ob es sich beim potentielle Täter um interne oder externe Personen handelt. Das Tresorschloss muss die Anforderungen des VdS erfüllen und möglichen Manipulationen Stand halten. Hinsichtlich der operationellen Risiken der Bargeldver- und entsorgung und die damit verbundenen Schließ- und Öffnungsprozesse der Wertgelasse zu bewerten. Insbesondere vor dem Hintergrund der externen Geld- Ver- und Entsorgung werden hier häufig Risiken unterschätzt (siehe unten: Besonderheiten für Verschluss-Konzepte von Wertschutzschränken).

IDW PS 330 – Abschlussprüfung bei Einsatz von Informationstechnologie

Der IDW Prüfungsstandard „Abschlussprüfung bei Einsatz von Informationstechnologie“ (IDW PS 330) ist ein Prüfungsstandard, der von Wirtschaftsprüfern bei Abschlussprüfungen eingesetzt wird, wenn die Rechnungslegung der Bank unter dem Einsatz von Informationstechnologie erfolgt. Da dies heutzutage bei allen Banken (und Unternehmen) der Fall ist, ist der PS 330 ein viel beachteter Standard. Der Prüfungsumfang ist dabei auf IT-Systeme konzentriert, die „rechnungslegungsrelevante“ Daten verarbeiten, also beispielsweise für Buchführung, Jahresabschlüsse, Lageberichte oder ähnliches. Ähnlich der MaRisk, kann die Prüfung „IDW PS 330“ sich auch mit allen IT-Systemen beschäftigen, bei denen durch dort auftretende Sicherheitsrisiken dem Unternehmen ein wesentlicher wirtschaftlicher Schaden entstehen könnte. Grundsätzlich verarbeiten OSsecure-Systeme keine rechnungslegungsrelevanten Informationen und oder Daten. Es werden auch keine rechnungslegungsrelevanten Prozesse mit OSsecure gesteuert oder in rechnungslegungsrelevante Prozesse eingegriffen. Die Ordnungsmäßigkeit der Buchführung und damit die Einhaltung der Grundsätze ordnungsmäßiger Buchführung (GoB) müssen und werden von OSsecure Systemen daher auch nicht eingehalten.

Die Bewertung hinsichtlich „IDW PS 330“ hängt hinsichtlich einer möglichen Risikobewertung, bei dem ein wirtschaftlicher Schaden entstehen kann, aber auch von dem jeweiligen Einsatzzweck oder den genutzten Geräten und Modulen des Systems ab. Allgemein haben nahezu alle Geräte und Prozesse des Systems keinen Einfluss auf Prozesse aus denen ein wirtschaftlicher Schaden entstehen kann. Der Prozess der Bargeldver- und entsorgung und die damit verbundenen Schließ- und Öffnungsprozesse der Wertgelasse (Geldautomaten, Tresore, AKT, Recycler, etc.) sind jedoch analog zur MaRisk zu bewerten. Bei den Prüfungen nach „PS 330“ stehen die Angemessenheit, also ob die IT-Systeme den Anforderungen des Unternehmens genügt, sowie die Wirksamkeit, also ob die dokumentierten bzw. geplanten Maßnahmen wirksam umgesetzt sind und gelebt werden, im Vordergrund.

IDW PS 880 – Die Prüfung von Softwareprodukten (IDW RS FAIT 1/2/3)

An Rechnungslegungssoftware werden durch Handelsgesetzbuch und Abgabenordnung zwingende Anforderungen gestellt, um die Ordnungsmäßigkeit der Buchführung und damit die Einhaltung der Grundsätze ordnungsmäßiger Buchführung (GoB) zu gewährleisten. Grundsätzlich sind die allgemeinen Anforderungen an die Ordnungsmäßigkeit in den §§ 238, 239 und 257 HGB und gleichlautend in den §§ 145 und 146 AO gesetzlich geregelt. Demnach muss ein im Rechnungswesen eingesetztes IT-Verfahren den GoB entsprechen. Weiter spezifizierte und relevante Anforderungen sind u.a. „IDW RS FAIT 1, 2 und 3„, Die Prüfung der Ordnungsmäßigkeit von Softwareprodukten richtet sich gem. „IDW PS 880“ auf die notwendigen Verarbeitungsfunktionen (Beleg-, Journal- und Kontenfunktion), die programmierten Verarbeitungsregeln, die Softwaresicherheit, sowie die Dokumentation.

OSsecure ist keine Rechnungslegungssoftware und fällt daher auch nicht unter die Anforderungen an die Ordnungsmäßigkeit.

UVV-Kassen Zertifizierung – BGI/GUV-I 819 1,2 und 3

Die VBG (Verwaltungs-Berufsgenossenschaft) und die DGUV (Deutsche Gesetzliche Unfallversicherung) müssen für alle Systeme, welche in Banken, Sparkassen und anderen Kreditinstituten zum Einsatz kommen, eine Eignungsbescheinigung ausstellen. Mit jener Prüfung wird das jeweilige System für eine bestimmte Dauer nach den Vorgaben der UVV-Kassen zertifiziert. Auf der Grundlage der Forderungen in den §§ 13, 16 und 18 der UVV-Kassen werden Behältnisse für die zeitlich gestaffelte Betragsfreigabe und beschäftigtenbediente Bankenautomaten, Schleusen und andere Systeme stellvertretend vom Sachgebiet für alle UV-Träger, geprüft. Darüber hinaus werden Eignungsnachweise für biometrische Kassensicherungssysteme, Zeitverschlussbehältnisse und weitere Produkte im Bereich von Banken erstellt. Im Rahmen von DGUV-Test werden die Systeme nach UVV “Kassen” und der BGI/GUV-I 819-2 geprüft.

Die jeweils aktuelle Zertifizierung des OSsecure-Systems nach UVV-Kassen finden Sie hier.

VdS Zertifizierung – nach EN 1300 (VdS 2396)

Die VdS Schadenverhütung ist ein Unternehmen des Gesamtverbandes der Deutschen Versicherungswirtschaft e. V. (GDV). Die deutsche Versicherungswirtschaft prüft und zertifiziert Produkte im „Hochsicherheitsbereich“ für eine aktive Schadenverhütung und, um Risiken beherrschbar und versicherbar zu machen. Der VdS ist von der Deutschen Akkreditierungsstelle Technik e. V. (DATech) und der Trägergemeinschaft für Akkreditierung (TGA) für verschiedene Prüfungen und Zeritifzierungen nach DIN, ISO und EN-Normen akkreditiert. Komponenten von Einrichtungen zur Schadensverhütung oder ganze Systeme werden vom VdS prüft und zertifiziert. Eine Anlage (ein System) darf sich nur VdS zertifiziert nennen, wenn alle sicherheitsrelevanten Produkte und Komponenten miteinander zertifiziert sind.

Alle TwinLock Verschluss-Systeme (Hochsicherheitsschlösser) für Wertgelasse haben eine VdS-Zertifizierung (Klasse 2 und Klasse 3) nach EN 1300. Hier finden Sie die G-Nummern (Zertifikats- und Anerkennungnummern).

ECB•S Zertifizierung – European Certification Board – Security Systems

Es gibt in Deutschland und Europa mehrere Prüfinstitute/Zertifzierungsstellen die z.B. nach EN 1143-1 zertifzieren. ECB•S (und VdS) sind die bekanntesten Zertifizierungsstellen für Sicherheitsprodukte im Bankenumfeld und anerkannt unter allen deutschen Versicherungen. ECB•S steht für European Certification Board und ist ein Zertifizierungsorgan, sowie Forschungs- und Prüfgemeinschaft für Geldschränke, Tresoranlagen und Hochsicherheitsschlösser.

Alle TwinLock Verschluss-Systeme (Hochsicherheitsschlösser) für Wertgelasse haben eine ECB•S-Zertifizierung (Klasse B und Klasse C) nach EN 1300. Hier finden Sie die Zertifikate. SC-Sicherheitstüren zu sensiblen Bereichen oder als Personaleingang sind nach EN 1627 in der „Resistance class RC3/RC4“ geprüft und zertifiziert.

Einleitung – System-Beschreibung

OSsecure-Systeme kommen im Rahmen der Kassensicherung zum Einsatz. Ein OSsecure System kann ein Tagestresor, eine Personenschleuse, ein Hochsicherheitsschloss auf einem Tresor, Geldautomat, Recycler, o.ä., ein Zutrittssystem oder ein Türschloss für Personaleingänge, Büros, Geldbearbeitungsräume oder andere sensible Bereiche sein. OSsecure bringt die Sicherheits-Einrichtungen in den Filialen auf einen einheitlichen technischen und gesetzlichen Standard und bietet den Benutzern und Verantwortlichen komfortable Möglichkeiten in der Umsetzung interner organisatorischer Prozesse und im Rahmen der sicherheitstechnischen Anforderungen.

Die Prozessgestaltung, sowie die Vorgaben zum Einsatz verschiedener Sicherheitssysteme resultieren aus den gesetzlichen Anforderungen der Unfallkasse (GUV) oder den Vorgaben der Sachversicherer (VdS Schadensverhütung). Das folgende Schaubild zeigt eine schematische Darstellung des Systems und deren Abhängigkeiten.

Die Grafik zeigt die verschiedenen Module des OSsecure Systems und die Einflüsse und Abhängigkeiten der gesetzlichen Vorschriften (UVV-Kassen), sowie die Sicherheitseinrichtungen und Geräte, welche sich durch die modulare Hardware-Steuerung des OSsecure-Systems zentral steuern lassen. Während bei Tagestresoren und Personenschleusen ausschließlich die Vorgaben der UVV-Kassen auf das System einwirken, gilt es bei den Hochsicherheitsschlössern zusätzlich die Anforderungen der Sachversicherer zu berücksichtigen. Jedes Tresorschloss benötigt ein eigenständiges VdS-Zertifikat gemäß VdS 2396 und in Abhängigkeit des Einbruch-Widerstandsgrades des Tresor-Systems nach VdS 2450, ECB-S C 01 und DIN EN 1143-1. Schloss- und Tresor Systeme werden je nach Versicherungssumme in den Klassen B und C (Schlösser: z.B. TwinLock ProtectMaster), bzw. CEN III bis XIII (Tresore: z.B. Geldautomat, Recycler, Panzergeldschrank) unterschieden. Die Versicherungssummen der Wertgelasse können durch den zusätzlichen Einsatz von Einbruchmeldetechnik (EMA) erhöht werden. Neben der notwendigen Produkt Zertifizierung des Schloss-Systems (VdS G-Nummer) wirken auf den Öffnungsprozess des Tresors verschiedene organisatorische und gesetzliche Vorgaben ein, welche es nach MaRisk oder z.B. IDW PS 330 individuell zu bewerten gilt und welche sich mit Hilfe des OSsecure-Systems steuern lassen.

Das OSsecure System bietet Schnittstellen zu anderen Systemen, welche in speziellen System-Konfigurationen zum Einsatz kommen. Bitte prüfen Sie, welche zusätzlichen Abhängigkeiten sich in Bezug auf Ihr individuelles OSsecure-System-Setup für Ihr Institut ergeben. Berücksichtigen Sie, dass durch jene Abhängigkeiten mit Drittsystemen, ein ordnungsgemäßer Programmeinsatz und eine Prüfung der Datenverarbeitung in Teilen erforderlich werden können.

System Konfiguration (System Setup)

Folgende Konfigurationsmöglichkeiten des OSsecure-Systems sind möglich:

1. SoC (System on Chip) – autarkes OSsecure-System
   Dieses System-Setup kommt in den überwiegenden Fällen im Umfeld der Sparkassen und Raiffeisen-und Volksbanken zum Einsatz. In dieser Konfiguration werden die OSsecure Komponenten vollkommen autark und losgelöst von Drittsystemen konfiguriert. Das System kommt vollkommen ohne Software Installationen aus und bringt alle technischen Voraussetzungen, Systemlogik, gesetzliche Anforderungen und Komfort-Möglichkeiten in einer Chip-Lösung mit. Das System ist vollständig in das jeweilige Gerät (Produkt) integriert. Ein Tagestresor, eine Schleuse, etc. bringt alle erforderlichen Komponenten mit und es findet kein Datenaustausch zwischen Bank-Systemen und den Sicherheitseinrichtungen statt. Die Bedienung, Administration, Steuerung und Verwaltung des Systems erfolgt über die in den Geräten integrierten Menüs, welche über die Displays und Tastaturen oder auch über den Webbrowser gesteuert werden können. Bei der zentralen Browser-Steuerung über einen Bank-Arbeitsplatz werden keine zusätzlichen Plugins, Browser-Komponenten oder spezielle Port-Freigaben benötigt. Die Einrichtung von OSsecure muss bei dieser Art der System-Nutzung nach den Vorgaben der UVV-Kassen erfolgen. Eine Zertifizierung des OSsecure-Systems durch die Unfall-Kasse ist zwingend erforderlich. Die jeweils aktuelle Bescheinigung finden Sie hier zum Download.

---

2. FI integrierte Lösung – OSsecure FI-Signalbox
   Dieses System-Setup kommt bei speziellen Anwendungs-Fällen in Sparkassen zum Einsatz. Der wesentliche Unterschied bei diesem System-Setup besteht darin, dass die biometrische Freigabe aus dem Banksystem heraus erfolgt (z.B. FI-Leistung: Biometrie Basiskomponente). Je nach Leistung, werden an Biometriesysteme, welche zur Autorisierung gegenüber IT-Systemen zum Einsatz kommen (z.B. FI-Leistung: Starke Authentisierung) nach ISO 19092:2008 (Biometrics for the authentication of persons seeking financial services) definierte Qualitäts- und Leistungs-Anforderungen gestellt. Jene Anforderungen werden durch die eingesetzten DigitalPersona Biometric-Services beim Einsatz von Passwort und Biometrie oder Passwort und Smartcard erfüllt. Eine hohe Leistungsfähigkeit begründet sich durch die Kombination von Benutzer-Credentials. Man spricht von einem 1:1 Abgleich (Verifikation) – oder einer zwei-Faktor Authentisierung. In dieser Konfiguration erhält die OSsecure-FI-Box – als Schnittstelle zwischen Physikalischer Sicherheit und IT-Sicherheit – die biometrische Freigabe aus dem IT-System. Die OSsecure Komponenten werden durch OSPlus Kasse (in Österreich auch durch die SI-Systeme) gesteuert. Das System wird seriell an einen Kassen-Arbeitsplatz angeschlossen (in Österreich Ladensystem) und agiert als Schnittstelle zu den Hardware-Komponenten. OSsecure reagiert auf Freigabe-Signale des Host-Systems (OSPlus Kasse) und ein Datenaustausch zwischen Bank-Systeme und OSsecure findet „einseitig“ statt. Steuersignale werden aus den Bank-Systemen an OSsecure übermittelt. Eine Steuerung der Bank-Systeme durch OSsecure ist hingegen nicht möglich. Die Bedienung, Administration, Steuerung und Verwaltung des Systems erfolgt über OSPlus. Biometrische Daten werden ausschließlich innerhalb der IT-Systeme verwaltet und gespeichert (Active Directory). Die in den Tagestresoren integrierten Menüs, welche über die Displays und Tastaturen gesteuert werden können, bieten Komfort-Funktionen oder auch Notfall-Prozesse, welche bei einem Ausfall von OSPlus oder anderer für den Betrieb relevanter Komponenten greifen. Die Umsetzung und Einhaltung der gesetzlichen Anforderungen obliegt bei dieser Konfigurations-Art dem Bank-System OSPlus und nicht dem OSsecure-System. Bei Fragen zur UVV-Kassen Zertifizierung und zur Biometrie, wenden Sie sich bitte an die Finanz Informatik. Eine Validierung des OSsecure-Systems durch die Finanzinformatik ist für den integrierten Betrieb mit OSPlus Kasse zwingend erforderlich. Die Leistungs-Bestätigung über die Validierung finden Sie hier zum Download.

---

3. Autarkes OSsecure-System in Kombination mit Server Installation (FIDUCIA / GAD)
   Dieses System-Setup ist ein sehr spezieller Anwendungsfall im FIDUCIA/GAD Umfeld. Analog zur ersten „SoC“ Lösung, kommt hier jedoch zusätzlich zum autarken Betrieb des Systems eine Server Installation zum Einsatz. Auch bei der ersten „SoC“ Lösung ist es möglich, beliebig viele „virtuelle“ Geräte (Nodes) mit in das System zu integrieren, welche spezielle Teilfunktionen übernehmen (Schloss-Steuerung, Tür-Steuerung oder zentrales Anlern- Einscann-System. Im Unterschied zur „SoC“ Konfiguration werden diese OSsecure-Systeme aber nicht auf einer System on Chip Lösung integriert, sondern auf dem Bank-Server installiert. Das System arbeitet weiterhin autark ohne jeglichen Datenaustausch zu den Bank-Systemen, aber es wird auf der Hardware (Server) der Bank installiert. Eine Zertifizierung des OSsecure-Systems durch die Unfall-Kasse ist zwingend erforderlich (siehe oben) und zusätzlich eine Prüfung durch das Rechenzentrum. Die FIDUCIA-Prüfung finden Sie hier zum Download. Im Zuge der wave Umstellung im GAD Umfeld entfällt jenes System-Setup. OSsecure ist in der wave Portfolio Datenbank der GAD gelistet.

Das folgende Schaubild zeigt Ihnen die unterschiedlichen Abhängigkeiten der „FI integrierten“ und der „autarken“ Lösungen:

Systembeschreibung der autarken SoC (System on Chip) Lösung

Bei der autarken OSsecure (System on Chip) Lösung handelt es sich um ein Embedded-System. Es ist am ehesten vergleichbar mit einem Router, Switch, o.ä., welcher definierte Aufgaben übernimmt und eine Weboberfläche für die Bedienung bietet. Bei dieser SoC-Lösung sind alle Funktionen des Systems (Benutzerverwaltung, Biometrie/Identifikation, Hardware-Steuerung) auf einem Chip (Die), also einem integrierten Schaltkreis integriert. Es handelt sich um die Kombination unterschiedlicher Elemente, die zusammen bestimmte Funktionalitäten bereitstellen (beispielsweise Türzugangssensor, Tagestresor, etc.). Vorteile jenes Systemaufbaus sind in erster Linie der Verzicht auf „unnötige“ Systemkomponenten, der geringerer Energieverbrauch (Verlustleistung) und eine umfassende Miniaturisierung. Das System ist hoch spezialisiert und für den jeweiligen Anwendungs-Zweck (Tagestresor-Steuerung, Schleusen-Steuerung, Tür-Steuerung, etc.) optimiert. Die Steuereinheit verfügt nur über die erforderlichen und notwendigen Schnittstellen (auf CD-ROM-Laufwerk, grafische Oberfläche, wie z.B. Windows-Betriebssystem, etc. wurde verzichtet). Aus dem hohen Optimierungsgrad resultiert ein „schlanker“ System-Aufbau. Alle nicht benötigten Komponenten müssen nicht unnötig „mitgeschleppt“ werden und erfordern somit auch keine notwendigen Updates, Patches, etc. – wie es beispielsweise bei einem Windows-System. Da das OSsecure-System in sich geschlossen ist, bietet es darüber hinaus wenig „Angriffsfläche“ für Viren, Malware, etc.

Beispiel: Bei dem OSsecure-Türmodul (OSEntry) sind auf dem SoC, die Biometrie-Einheit, die Code-Tastatur, die RFID-Transponder-Lösung und alle für die Benutzer-Autorisierung erforderlichen Komponenten integriert. Zusätzlich sind die Relais für die Steuerung des Motorschlosses und die Schnittstellen für die Netzwerk-Synchronisierung im Modul enthalten. Alle Komponenten finden in dem Gehäuse von 16cm x 5cm Platz, so dass das Wandmodul neben jeder Tür platziert werden kann.

Fragen und Antworten:

Bietet das System eine grafische Oberfläche?
Nein, es wird ausschließlich eine Weboberfläche für die zentrale Bedienung, Steuerung, Verwaltung und Administration des System angeboten. Das System verfügt über keine grafische Oberfläche, wie z.B. Windows Systeme. Einzelne Funktionen sind neben der Web-Oberfläche auch über die in die Geräte integrierten Displays und Tastaturen zugänglich.

Wer hat Zugriff auf das System?
Der Zugriff auf das System erfolgt über den Webbrowser eines beliebigen Arbeitsplatzes. Es wird ein User und ein Passwort oder alternativ ein biometrischer Fingerabdruck benötigt, um auf bestimmte Programmfunktionen zugreifen zu können. Berechtigungen innerhalb des Systems können „frei“ definiert werden. Der Zugriff auf bestimmte Geräte (z.B. Fach eines Tagestresores, Tür, Schleuse, Tresorschloss, etc.) oder der Zugriff auf bestimmte Programmfunktionen (z.B. Stammmdatenverwaltung, Einsicht von Log-Daten, Rechteverwaltung, etc.) kann Gruppenbezogen gesteuert werden. Weitere Infos finden Sie hier.

Lässt sich die OSsecure-Anwendung durch ein 4-Augen-Prinzip absichern?
Ja, die OSsecure Anwendung lässt sich über ein 4-Augen-Prinzip absichern. Häufig resultiert eine Vorgabe oder ein Wunsch nach einem 4-Augen-Prinzip aus den abgeleiteten Anforderungen der MaRisk. Diese sehen eine „geschützte“ IT-Berechtigungsvergabe vor, um Risiken durch mögliche Manipulation von Benutzerrechten oder betrügerische Falscheingaben zu verhindern. Da von einer möglichen Manipulation der Benutzer-Identitäten, deren Rechte oder biometrischen Authentisierungs-Daten innerhalb des OSsecure Systems jedoch keinerlei und im Bezug auf die durch die MARisk bewerteten Risiken ausgehen, kann von einem 4-Augen-Prinzip grundsätzlich Abstand genommen werden. Bestimmte administrative und organisatorisch Mehraufwände, welche aus einem 4-Augen-Prinzip für die Administration resultieren, können vermieden werden. Im Rahmen des IT-Sicherheits- und Risikomanagements entsteht kein Risiko durch die Nutzung der Biometrie. Sofern Sie nichtsdestotrotz oder zusätzlich ein 4-Augen-Prinzip als technisches Kontrollsystem nutzen möchten, finden Sie hier entsprechende Hinweise für deren Konfiguration innerhalb des OSsecure Systems. Gleichzeitig empfehlen wir Ihnen in diesem Zusammenhang auch ein umfassendes Beratungsgespräch (Beratertag) zur Identifikation realer Risiken innerhalb der Prozesse der Kassensicherung.

Wie erfolgt die Vergabe und Kontrolle von Berechtigungen?
Das Berechtigungs- und Zugriffskonzept der SoC-Lösung ist an die Windows-Gruppen-Richtlinien angelehnt. Benutzer, können, zeitlich, örtlich und pro Gerät berechtigt werden. Alle drei Dimensionen lassen sich in Berechtigungsgruppen zusammenfassen. Man spricht auch von einem rollen- oder gruppenbasierten Berechtigungskonzept. Eine zusätzliche Berechtigungsvergabe einzelner Programmfunktionen ermöglicht zudem ein individuell anpassbares Berechtigungskonzept für die Administration und Verwaltung des Systems (Prinzips der minimalen Rechtevergabe). Einzelne Programmfunktionen lassen sich zusätzlich über ein 4-Augen-Prinzip absichern. Das Berechtigungskonzept ist in Anlehnung an Standards wie etwa IT-Grundschutz oder ISO 2700 zur Ausgestaltung des IT-Berechtigungsmanagements, konzipiert.

Ist das Protokoll „Revisionssicher“?
In der Praxis bedeutet Revisionssicherheit eine verfälschungssichere langzeitige Archivierung elektronischer Informationen. An die Revisoren von IT-Systemen sind speziell und in Bezug auf die Kernbanksysteme, bzw. immer dann, wenn Kredit- und Handelsgeschäfte auf IT-Systemen basieren, hohe Anforderungen gestellt. Diese Anforderungen werden nicht an UVV-Kassen-Systeme gestellt. Hier gilt es zu unterscheiden, dass es sich bei Personenschleusen, Tagestresoren, Tresorschlössern oder Türzugängen nicht um IT-Systeme im „klassischen“ Sinn handelt, sondern um Systeme der physikalischen Sicherheit. Die Systeme werden entweder zum Schutz der Mitarbeiter und zur Vermeidung und Reduzierung von Gefährdungen, sowie zum Schutz der Sachwerte eingesetzt. Die Sachwerte gilt es vor extern (z.B. Aufbruch) und intern (Manipulation) zu schützen. Beim Sachwerteschutz werden häufig auch hohe Anforderungen an die Protokollierung gestellt. Jene Anforderungen resultieren aber nicht aus den Anforderungen der IT-Systeme, sondern resultieren aus den Anforderungen der Sachversicherer und deren Zertifizierungskriterien (VdS Richtlinien), sowie den Anforderungen der internen Revision.

In Bezug auf die Benutzerberechtigungen ist die Protokollierung des SoC-Systems nicht (vollständig) revisionssicher, da eine Dokumentation und Bearbeitung von Änderungen an Berechtigungsprofilen nicht vollständig erfolgt. In der SoC Lösung findet eine langfristige und manipulationsgeschützte Protokollierung von Öffnungsprozessen, Alarmmeldungen, etc. statt. Die Dauer der Protokolleinträge lässt sich in den Systemeinstellungen aus datenschutzrechtlichen Gründen definieren. Es lässt sich zusätzlich ein 4-Augen-Prinzip für die administrativen Tätigkeiten oder/und ein detailliertes Berechtigungskonzept definieren. Bei der FI-intergierten Lösung erfolgt die Steuerung der Berechtigungen aus OSPlus heraus und die an das Kernbanksystem gestellten Anforderungen müssen den Anforderungen an IT-Systeme gerecht werden. Alle VdS Systeme bieten eine Protokollierung der Öffnungen und jeder Änderung an den Benutzerrechten. Protokolleinträge werden bei TwinLock-Systemen unterschiedlich lange gespeichert (z.B. TwinLock WTU 768 Einträge, TwinLock ProtectMaster / Business 3000 Einträge). VdS-Systeme bieten einen vollständigen Schutz vor Veränderung und Verfälschung. Dies gilt nicht für die Online-Protokolle, sondern ausschließlich für die in den Schloss-Riegeln enthaltenen Protokolleinträge.

Warum wird in UVV-Kassen Systemen nicht (vollständig) revisionssicher Protokolliert?
Der Aufwand für ein revisionssicheres Protokoll ist hoch und mit zusätzlichen Kosten verbunden. Eine Notwendigkeit für eine solche Protokollierung ist in den UVV-Kassen Vorschriften nicht gegeben. Bei UVV-Kassensystemen handelt es sich nicht um IT-Systeme und die Aufwände für das Herstellen von Integrität und Autorisierung im Hinblick auf die revisionssichere Protokollierung wären sehr hoch, bzw. wären die Systeme im Vergleich zu anderen Produkten am Markt wirtschaftliche benachteiligt. Bei der SoC-Lösung ist zudem eine Trennung von IT-Systemen und physikalischer Sicherheit beabsichtigt und daher wäre ein Signieren der Datenbestände (Kein Protokolleintrag darf nachträglich verändert werden können) oder eine Zertifikate / Public-Key-Infrastructure, um die Autorisierung der einzelnen UVV-Kassen-Systeme sicherzustellen, sehr (Kosten) aufwändig.

Die in der Praxis häufig eingeforderten Revisionsanforderungen werden nichtsdestotrotz auch von den UVV-Kassen-Systemen erfüllt. Lediglich die Dokumentation und Bearbeitung von Änderungen an Berechtigungsprofilen wird zwar als solche erfasst, nicht jedoch mit den vorgenommenen Änderungen vollständig protokolliert. Diese sollten daher (wenn gewünscht) im Rahmen eines Change-Prozesses schriftlich dokumentiert werden. Der bei UVV-Kassen-Systemen nicht erforderliche Abgleich der in den Zugriffskontrollsystemen tatsächlich eingerichteten Berechtigungen mit dem Berechtigungskonzept nach MaRisk AT 4.3 könnte mit der OSsecure Server-Komponente und dem Export-Modul für die Benutzerrechte erfolgen. Weitere Informationen zum Export und Abgleich der Benutzerrechte in OSsecure finden Sie hier.

Das Risikopotenzial durch privilegierte Benutzerkonten kann durch die Möglichkeit der Einschränkung von Programmfunktionen reduziert werden. Es kann auch die Zuverlässigkeit des Zeitstempels erhöht werden. Es lässt sich ein unabhängiger, nicht durch den Benutzer manipulierbarer Zeitstempeldienstes (NTP, Time-Server) hinterlegen. Anschließend sollte dem Benutzer der Zugriff auf jene Programmfunktion entzogen werden.

Überprüfung / Rezertifizierung von Berechtigungen
MaRisk AT 7.2 verlangt eine „angemessene IT-Berechtigungsvergabe“ und MaRisk AT 4.3.1 die „regelmäßige und anlassbezogene Überprüfung von IT-Berechtigungen, Zeichnungsberechtigungen und sonstigen eingeräumten Kompetenzen“. Müssen Berechtigungen im OSsecure-System auch regelmäßig geprüft werden? Nein, die zeitverzögerte Freigabe von Werten innerhalb der Kassen-Sicherung durch ein Zeitverschlussbehältnis erfolgt auf Grundlage der Unfallverhütungsvorschrift, BGV C9 – DGUV zum Schutz der Mitarbeiter und zur Reduzierung vor Überfällen. Das biometrische System überprüft hierbei die Anwesenheit von zwei Mitarbeitern zum Zeitpunkt der Auszahlung. Um welche Mitarbeiter es sich hierbei genau handelt wäre für den Schutz-Prozess theoretisch irrelevant – entscheidend ist die Anwesenheit von zwei Mitarbeitern und die Zeitverzögerung. Nichtsdestotrotz lassen sich Berechtigungen zur Überprüfung / Rezertifizierung aus dem OSsecure-System exportieren. Lesen Sie hier, wie ein Export der Daten erfolgt. Sofern die Rezertifizierung über PROMPT Betriebs-ORGA erfolgt, nutzen Sie bitte diese Excel Vorlage, um die Berechtigungsstruktur in das korrekte Format zu transferieren.

Gibt es die Möglichkeit mit einem Terminal-Programm/Console auf das System zuzugreifen?
Bei Tagestresoren und Schleusen besteht „theoretisch“ die Möglichkeit eines Zugriffs via Console. Bei Tür-Zugängen und Schloss-Systemen gibt eines keinen Terminal-Zugang. Es erfolgt keinerlei Offenlegung – der Zugriff auf Daten ist mit User und Passwort geschützt. Der erforderlich Terminal-Login wird nur nach besonderen Vereinbarungen ausgegeben, da diese Rechte eine zusätzliche administrative Verantwortung hinsichtlich des Datenschutzes darstellen (siehe hier).

Welche Ports sind beim System geöffnet und warum?
Im Rahmen von sog. IT-Sicherheits Audits werden von den (externen) IT-Prüfern häufig „einfache“ Port-Scans mit nmap im Netzwerk des Geldinstituts durchgeführt. Der Port-Scan versucht durch extensives Probieren herauszubekommen, welche Dienste ein Netzwerkgeräte im Bankennetz anbieten. Ein Portscan fragt höflich und formgerecht alle möglichen Dienste (das sind 65535 statusbehaftete und nochmal soviele statuslose Quellen auf Basis von IP) ab. Der Test (Port-Scan) ist praktisch und ungefährlich, weil das Geldinstitut keine Dienste anbieten möchte, die die Bank nicht kennt. 6688 für den Secure-Update Client.

Offene Ports: Bei Schleusen und Tagestresoren: 80 (Webinterface), 443 (https), 21 (ftp, für Firmware-Updates), 22 (telnet, s.o.), 2222 (api, Steuerplatine). Bei IP-Tresorschlössern: 80 (Webinterface), 443 (https), 8080 (Bios, Servicemenü)

Erfolgt die Geräte-Kommunikation verschlüsselt? Kann die SSL-Verschlüsselung eingestellt werden?
Bei der „Verschlüsselung“ des Systems wird zwischen unterschiedlichen Informationen unterschieden. Entsprechend der gesetzlichen Anforderung (z.B. BDSG oder UVV-Kassen) und/oder der für Zertifizierungen relevanten Anforderungen (z.B. VdS) wird entsprechend eine Verschlüsselung und Codierung eingesetzt. Es wird unterschieden zwischen…

• Sensiblen Informationen (§ 3 Abs. 9 BDSG)
• Öffnungsinformationen bzw. für die Sicherheit der Sachwerte relevante Informationen
• Informationen, welche zum Schutz der Organisations-Prozesse, bzw. zur Prävention und zum Schutz der Mitarbeiter eingesetzt werden.

Überall dort, wo beispielsweise Öffnungs-Prozesse von Sachwerten (z.B. Tresor-Öffnung Hintergrundbestand) betroffen sind, kommunizieren die einzelnen Netzwerk-Komponenten untereinander AES verschlüsselt. Gleicher Verschlüsselungs-Standard kommt auch bei den verwendeten DB-Systemen zum Einsatz. Häufig wird von externen IT-Sachverständigen „pauschal“ eine Verschlüsselung gefordert oder empfohlen. Häufig ist hiermit relativ „profan“ die SSL-Verschlüsselung (https) zwischen Webbrowser und Endgerät gemeint. Die hier geforderte „Verschlüsselung“ trägt trotz weitläufiger Meinung und wider Erwarten nicht ernsthaft zur Sicherheit der Prozesse und Sachwerte, sowie zum Schutz der Menschen bei. Man wiegt sich in falscher Sicherheit und vernachlässigt dabei häufig „ernsthafte“ Kriterien, welche zur Sicherheit beitragen würden. Eine entsprechende Beratung und Auditierung hinsichtlich der physikalischen Sicherheits-Komponenten in Verbindung mit organisatorischer und IT-Sicherheit ist hier empfehlenswert. Für die „technischen und organisatorische Maßnahmen“ welche wir unternehmen, gilt ein sog. Verhältnismäßigkeitsprinzip. In der Praxis hat sich häufig gezeigt, dass die Maßnahmen, welche wir zum Schutz vornehmen, häufig höher sind, als beispielsweise die mechanische Sicherheit. Siehe auch hierzu die folgende Fragestellung zum Thema ARP-Spoofing.

Eine SSL-Verschlüsselung für das OSsecure Webinterface können Sie im Menü ► Systemverwaltung ► System einstellen – für jedes OSsecure Gerät (Tagestresor, Personenschleusen und Zutrittssysteme) aktivieren. Für Hochsicherheits-Systeme, welche SB-Automaten und Hintergrundbestände absichern, wie z.B. das Netzwerk-Tresor-Schloss TwinLock Business und ProtectMaster haben wir Ihnen hier zusätzliche Hinweise zur Optimierung der Sicherheit, wie z.B. SSL-Verschlüsselung mit CA-Server, 2-Faktor Authentifizierung (mit Smartphone), sowie 4-Augen-Login zusammengefasst. Bitte beschränken Sie sich hierbei nicht auf das Thema IT-Sicherheit. Dies wäre fahrlässig und falsch. Immer wieder stellen wir bei der Beratung und Konzeptionierung fest, dass Fehler in Organisation und Implementierung der Prozesse viel „kritischer“ zu bewerten sind. Die Identifikation realer Risiken innerhalb der Prozesse der Kassensicherung bleiben häufig unbeachtet, da der Fokus auf standardisierten IT-Sicherheits-Audits liegt.

Abschaltung TLS 1.0 / SHA-1 Zertifikate
Was passiert nach der Abschaltung von Transport Layer Security (TLS)? Lesen Sie hierzu auch: http://www.heise.de/security/artikel/Das-BSI-und-der-Elfenbeinturm-2589893.html

TLS 1.0
Das Bundesamt für Sicherheit in der Informationstechnik (BSI) hat das Verschlüsselungsprotokoll für Datenübertragungen im Internet TLS 1.0 als unsicher eingestuft. Das Protokoll wird daher in den durch die Rechenzentren bereitgestellten Internet Browsern deaktiviert (Finanzinformatik z.B. 2017).

SHA-1 Zertifikate
Verschlüsselungen mit dem Secure Hash Algorithm SHA-1 gelten nicht mehr als sicher. Die Browser-Hersteller Microsoft und Mozilla werden ab 2017 Zertifikate, die mit SHA-1 Algorithmus verschlüsselt wurden, als nicht vertrauenswürdig einstufen und entsprechende Web-Services sind nicht mehr aufrufbar.

Grundsätzlich bietet OSsecure eine Vielzahl von Möglichkeiten zur sicheren Übertragung per SSL an und ist bereits seit Jahren für die Abschaltung von TLS 1.0 vorbereitet. Für welche sich Transport Layer Security sich der Browser letztendlich entscheidet, liegt nicht bei OSsecure, sondern am verwendeten Browser. Als unsicher eingestufte Algorithmen schließt OSsecure ausSicherheitsgründen nach Möglichkeit aus – es müssen aber auch weiterhin beispielsweise TLS 1.0 und SSLv3 abwärtskompatibel angeboten werden, da ältere Betriebssysteme und Browser keine höheren Standards unterstützen.

Zum Thema TLS 1.0:
Alle OSsecure-Systeme mit der Hardware-Generation 2007 bis 2012 unterstützen aktuell maximal TLS 1.0. Für diese System bietet SAFECOR im Rahmen von Wartungsverträgen ein Update, wodurch auch TLS 1.2 unterstützt wird. Alle neueren Systeme ab 2013 nutzen bereits TLS 1.2.

Zum Thema SHA-1:
Ab der OSsecure Version 1.16.83 werden unsere Zertifikate mit SHA-256 (SHA-2) signiert.

Der Schlüsselaustausch ist in diesem Zusammenhang sehr wichtig. OSsecure unterstützt auf allen Systemen das Schlüsselaustausch-Verfahren nach der Schlüsselaustausch nach Perfect Forward Secrecy und TLS_ECDHE-RSA-AES256-SHA, welches vom BSI als sicher bis 2022+ eingestuft wird. Siehe: https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102-2.pdf?__blob=publicationFile

Wo und wie kann die SSL Verschlüsselung (https) eingestellt werden?
Im Menü ► Systemverwaltung ► SSL einstellen (Secure Sockes Layer) ► haben Sie alle Möglichkeiten für die Konfiguration Ihrer SSL-Einstellungen.

Self-Signed Certificate
Als Mindestanfordung zur Nutzung einer sicheren Verbindung über https und SSL müssen Sie ein selbstsigniertes Zertifikat erstellen. Gleichzeitig wird eine Zertifikatsanforderung erstellt. Diese können Sie herunterladen und von einer externen Stelle signieren lassen.

Certificate Signing Request (CSR) anlegen
Wenn Sie Ihr Zertifikat von einer externen Stelle signieren lassen wollen, dann können Sie eine Zertifikatsanforderung herunterladen. Wenn das Zertifikat von der „fremden“ CA signiert wurde, können Sie dieses unter im nächsten Punkt als öffentliches Zertifikat hochladen und das eigensignierte Zertifikat ersetzen.

Schlüssel hochladen / importieren
Laden Sie ein bestehendes bzw. extern signiertes Zertifikat hoch und nutzen dieses. Bitte übertragen Sie Ihren privaten RSA-Schlüssel nur über eine vertrauenswürdige Verbindung! Aus diesem Grund sollten Sie am besten Ihren Rechner zur Übertragung direkt über ein Netzwerkkabel mit dem Gerät verbinden. Wollen sie nur Ihr öffentliches Zertifikat übertragen ist eine sichere, direkte Verbindung nicht notwendig.

Sind ARP-Spoofing oder Man-in-the-Middle Angriffe, wegen fehlender https Verschlüsselung möglich?
Häufig wird diese Frage von IT-Sicherheitsverantwortlichen gestellt, welche im Rahmen eines Audits über die fehlende Verschlüsselung der Systeme von externen Prüfern in Kenntnis gesetzt wurden. Die IT-Sicherheits-Verantwortlichen müssen im Rahmen des Berichtes zu den „Schwachstellen“ Stellung nehmen.

Kurze und knappe Antwort: Ja, ein solches Angriffs-Szenario ist denkbar, aber…

1. Die Klassifizierung des Risikos wird in der Regel wegen fehlender Prozess- und Sachkenntnis vollkommen falsch eingestuft. Das Risiko für die „unverschlüsselte“ Kommunikation innerhalb der Kassensicherung ist als „gering“ einzustufen.
2. Für die „technischen und organisatorische Maßnahmen“ welche im Rahmen der IT-Sicherheit in den Systemen und Geräten implementiert sind, gilt ein sog. Verhältnismäßigkeitsprinzip. Die Geräte und Systeme sind im Standard (bei Auslieferung) häufig so konfiguriert, wie es für die Risikobewertung des jeweiligen Kassensicherungs-Prozesses erforderlich ist.
3. Kommen interne Risiko-Bewertungen der Revision oder externer Prüfer zu abweichenden Ergebnissen, ist SAFECOR im Rahmen von Dienstleistungen und Beratungen gern unterstützend tätig, um zusätzliche Sicherheitsanforderungen abzustimmen und zu implementieren.
   1. Definition von der Sicherheitsanforderungen im Rahmen der MaRisk im Zusammenspiel mit den Kassensicherungs-Systemen, sowie Ableiten der Schutzziele aus IT-Sicht und im Rahmen der gesetzlichen Anforderungen (MARisk, UVV-Kassen), sowie der Anforderungen der Versicherungs-Wirtschaft.
   2. Klärung der Sicherheitsbedenken und entwickeln möglicher Schutzmechanismen.
   3. Implementierung der definierten Schutzziele und Konfiguration der Systeme. In diesem Schritt wird beispielsweise auf den Tagestresoren (Biometrie-Systemen) die https-Verschlüsselung aktiviert.
   4. Implementierung von Wartung- und Update-Routinen für einen dauerhaften 360°-Schutz der Geräte.

Umfassende Antwort zum Thema „ARP-Spoofing“ und „https-Verschlüsselung“

Was ist eigentlich ARP-Spoofing und wie kann das Netzwerk geschützt werden? Hiermit ist der Angriff innerhalb des Banknetzes gemeint, welcher ein Täter durchführt, in dem dieser sich zwischen den Benutzer (Webbrowser) und das Gerät (Tresorschloss, Tagestresor, etc.) schaltet (so, wie ein Proxy) und mit den abgehörten Informationen einen „Man in the Middle“ Angriff durchführt. Der Angreifer „imitiert“ hierbei die MAC-Adresse der Geräte. Es gibt verschiedene Ansätze, solche Angriffe zu unterbinden.

Am wirksamsten ist es, bereits die Adress-Manipulation zu unterbinden. Eine einfache Möglichkeit ist die Verwendung statischer ARP-Einträge (arp –s). Dies erfordert jedoch einen hohen administrativen Aufwand und ist in Netzen mit DHCP kaum möglich. Eine weitere Möglichkeit des Schutzes bieten die eingesetzten Netzwerk Switche, deren Funktionen (z.B. Enhanced Multilayer Image (EMI) und (Dynamic) ARP Inspection (DAI)) das Netzwerk auf ARP-Angriffe „überwachen“ und ARP-Pakete mit ungültiger IP-MAC Zuordnung protokollieren oder verwerfen, bevor sie beim Endgerät ankommen. Die dazu notwendige Datenbasis kann eine DHCP-Datenbank oder eine manuell erstellte Liste (ARP Access Control List) sein. Auch Funktionen, wie „Switchport Port-Security“ machen ARP Angriffe wenig erfolgsversprechend.

Das Netzwerk selber sollte also bereits Schutzmechanismen aufweisen, um ARP-Spoofing zu unterbinden. Wenn also innerhalb des „gesicherten“ Netzwerkes ein solcher Angriff wenig zielführend ist, dann ist eine zusätzliche verschlüsselte Kommunikation innerhalb der Endgeräte des Netzwerkes eine weitere, zusätzliche Hürde für den Angreifer.

Die effektivste Methode zum Schutz der Kassensicherungs-Geräte ist es, keine sensiblen (oder für den jeweiligen Prozess relevanten) Informationen zu übertragen. Ob verschlüsselt oder unverschlüsselt, für einen potentiellen Täter wären nur solche Informationen mitlesbar, welche für den Prozess von minderer Bedeutung sind. Alle Prozesse innerhalb der Kassensicherung sind im Idealfall also so implementiert, dass keinerlei Sicherheits-Risiko durch kompromittierte Systeme entsteht. Dieser Umstand ist sowohl für die Versicherungs-Branche, als auch für die interne Revision ein großer Sicherheits-Aspekt. Der entscheidende Vorteil dieser Herangehensweise ist es, nicht von fehlerhaft implementierten Sicherheits-Prozessen Dritter abhängig zu sein. Da die Sicherheit immer nur so stark ist, wie das schwächste Glied, wird vorab ausgeschlossen, dass ein nicht im Rahmen der Akkreditierung und Zertifizierung (z.B. durch den VdS – Verband der Sachversicherer) geprüfter externer Prozess zur möglichen Schwachstelle wird.

Beispiel: Das Aktivieren der https Verschlüsselung für die Tresorschlösser TwinLock führt in erster Linie dazu, dass Verantwortungsträger sich in trügerischer Sicherheit wiegen. Gerate externen IT-Sicherheits-Prüfern kommt daher eine besondere Verantwortung zu, bei der Auditierung von Kassensicherungs-Systemen nicht einfach „nur“ die nicht vorhandene Verschlüsselung als Sicherheitsrisiko zu klassifizieren und das Aktivieren der https Verschlüsselung einzufordern. Gerade in der beratenden Funktion durch einen externen Prüfer muss der Prozess der IT-Sicherheit dann auch vollständig begleitet und implementiert werden, da sich die Verantwortlichen (IT-Sicherheitsbeauftragte, Revision, Vorstand) auf das Fachwissen der Prüfer verlassen müssen. Wird also einfach „nur“ die https Verschlüsselung implementiert und durch den „gefühlten“ Zugewinn an IT-Sicherheit womöglich noch nachgelagerte „organisatorische“ Prozesse geringer bewertet oder fokussiert, dann wird exakt das Gegenteil erreicht und die Sicherheit fällt schwächer aus. Eine „richtige“ und vollständige Sicherheitsbewertung ist daher immer ausschlaggebend. Von der Implementierung der Verschlüsselung über CA-Server für die Zertifikatsverwaltung, bis zum Festlegen von Update-Intervallen. Nur so kann ein dauerhafter Schutz ernsthaft sichergestellt werden.

Welches Betriebssystem kommt zum Einsatz?
Grundlage des OSsecure-Systems ist ein embedded Linux (wie z.B. Fortress Linux oder eLux). Fachlich sprechen wir von einem „tiny embedded“ System. Viele Systemkomponenten sind darüber hinaus „read only“ und können nicht verändert werden, was einerseits die „Sicherheit“ erhört, da eine Manipulation des bestehenden Systems ausgeschlossen ist und den Update-Prozess von Funktionserweiterungen „stabiler“ macht, da mögliche Fehler innerhalb des Update-Prozesses, nicht zu einem Total-Ausfall des Systems führen. Es kommt ein „gehärtetes“ Linux zum Einsatz – d.h. es wurden alle „Softwarebestandteile und Funktionen“ entfernt, die zur Erfüllung der vorgesehenen Aufgabe durch das Programm nicht zwingend notwendig sind. Es kommt keine Distribution zum Einsatz, sondern es wird lediglich der Kernel 3.13.6 und als Command Busybox 1.22.1 kompiliert (Versionsstand kann sich jederzeit ändern). Weitere Informationen zu jener „Technik“ finden Sie auch im „BSI Leitfaden IT Sicherheit“ (S.44 / 2.Absatz) vom Bundesamt für Sicherheit in der Informationstechnik beschrieben. Es wurden darüber hinaus zusätzliche Zugriffskontrollen auf die Ressourcen im Sinne von „Mandatory Access Control“ implementiert.

Muss auf Virenschutz geachtet werden?
Nein, ein Viren-Schutz ist grundsätzlich nicht erforderlich, da das System in sich geschlossen ist und keine Möglichkeit besteht, zusätzliche Komponenten in das System zu integrieren. Nichtsdestotrotz sind Updates regelmäßig durchzuführen. Wir unterstützen Sie im Rahmen unserer Beratung- und Serviceverträge bei der Pflege Ihrer Systeme. Hier finden Sie weitere Informationen.

Wie erfolgt ein System Update?
Ein System-Update (Firmware-Update) kann über die Browser-Oberfläche eingespielt werden. Nur mit regelmäßigen Updates sorgen Sie für maximale Sicherheit und profitieren von neuen Funktionen. Da sich Technik und digitale Kommunikation stetig weiterentwickeln, stellt SAFECOR regelmäßig eine aktualisierte Firmware zur Verfügung (siehe TwinLock und OSsecure). Gerade in puncto Sicherheit ist eine stets weiterentwickelte Firmware unerlässlich, um Neuerungen im Rahmen der UVV-Kassen und, um auch neue potenzielle Gefährdungen zuverlässig verhindern zu können. Daher gilt: Um im Bankennetz für maximalen Schutz zu sorgen, sind Updates regelmäßig durchzuführen. Wir unterstützen Sie im Rahmen unserer Beratung- und Serviceverträge bei der Pflege Ihrer Systeme. Hier finden Sie weitere Informationen. Weitere Informationen zum Update-Prozess finden Sie hier.

Risiko-Bewertung der autarken SoC (System on Chip) Lösung

Im Folgenden werden die einzelnen Kriterien hinsichtlich Ihrer Risikoeinschätzung und im Bezug auf das OSsecure-System im Detail beantwortet. Maßgebend ist die autarke System-Konfiguration (System Setup als SoC – System on Chip), da beim „FI integrierten Betrieb“ alle für die Bewertung relevanten Steuerungs-Prozesse in OSPlus und nicht in der OSsecure FI-Box stattfinden.

Besonderheiten für Verschluss-Konzepte von Wertschutzschränken

Die Öffnungs-Prozesse von Wertgelassen (Geldautomaten, Recycler, Tresoren, Panzergeldschränken, Hintergrundbeständen, Tresor-Anlagen, sowie Miet- oder Schließfachanlagen) unterliegen besonderen Schutzzielen. Einerseits sind die Gefährdungen bei der Ver-, Ent- und Nachversorgung, beim allgemeinen Cash-Handling, bzw. dem Befüllen- und Entleeren von Wertschutzschränken sehr hoch, anderseits sind alle Prozesse der Werte-Logistik hohen Risiken des Betrugs und der Manipulation (intern und extern) ausgesetzt. Beide „gleichwertigen“ Schutzziele gilt es bei Verschluss-Konzepten zu erfüllen. Die MaRisk fordert, dass die Abhängigkeiten mit deren Hilfe jene Prozesse Umsetzung finden, mit in die Planung der Geschäftsaktivitäten einbezogen werden.

Die Reihenfolge der gestellten Anforderungen folgt einem prozessorientierten Ansatz. Der gesamte Öffnungs- und Verschluss-Prozess lässt sich in der „Risikoanalyse“ vier Phasen zuordnen, so dass dieser auf die sich stetig ändernden Einflüsse angepasst werden und schrittweise verbessert werden kann.

In der Planungsphase werden die Ziele, Strategien und relevanten Prozesse in Bezug auf die entsprechenden Bedürfnisse der Bank geplant. In der Phase Umsetzung und Durchführung wird entsprechend der Planung, bzw. entsprechend der definierten Öffnungs-Prozesse das Konzept umgesetzt. Diese Phase beinhaltet unter anderem die Erstellung eines Plans zur Risikobehandlung, die Umsetzung von risikomindernden Maßnahmen sowie das Management von Operationen und Ressourcen. Die dritte Phase, Überwachung und Überprüfung, dient der Messung und Prüfung im Hinblick auf die Erreichung der in der Planungsphase festgelegten Ziele und Prozesse. Aus den gewonnenen Informationen werden Berichte für die Sicherheitsbeauftragten erstellt. Mit der Wartung und Verbesserung wird die letzte Phase des Zyklus abgeschlossen. Hier werden korrektive und vorbeugende Maßnahmen vorgenommen, um eine kontinuierliche Verbesserung des Verschluss-Konzeptes von Wertschutzschränken sicherzustellen. Die Maßnahmen werden aus den Ergebnissen der Vorphase definiert.

IT-Sicherheits von Netzwerk-Tresorschlössern erhöhen.

Bei Netzwerk-Tresorschlössern erfolgt die Kommunikation zwischen dem Client (Anwender) und dem Schloss über das interne Banken-Netzwerk. Die Kommunikation kann optional verschlüsselt über das SSL-Protokoll (https) erfolgen. Wichtig für die sicherheitstechnische Bewertung hinsichtlich der möglichen Risiken ist die konzeptionelle Kommunikations-Gestaltung des Netzwerkschlosses. Hiermit ist die Gestaltung des generellen Sicherheits-Prozesses gemeint, welches die grundlegenden Sicherheitsaspekte bereits beim Design der Anwendung und der Prozesse des Informations-Flusses zwischen Anwender und Schloss (Client und Server) berücksichtigt. Bei der Daten-Kommunikation über das Netzwerk des Geldinstitutes oder bei jeglicher Datenspeicherung außerhalb des Schloss-Systems handelt es sich ausschließlich um Informationen, welche nicht risikobehaftet sind, da jene Informationen keine Öffnungsgeheimnisse der Schlösser enthalten. Ein „Abfischen“ oder „Belauschen“ der Anwenderkommunikation kann also systemtechnisch zu keiner Tresor-Schloss Öffnung führen, da keine ausreichenden und für die Öffnung relevanten Informationen ausgetauscht werden. Lesen Sie zusätzlich auch hier die MaRisk Informationen zu den Netzwerk-Schloss-Systemen.