In der Informationsgesellschaft des 21. Jahrhunderts stellt Wissen die entscheidende Ressource für Unternehmen und Organisationen dar. Davon wird mittlerweile der größte Teil digital aufbewahrt, damit der Zweck des Unternehmens bzw. der Organisation auch unabhängig von den aktuell handelnden Personen zukünftig erfüllt werden kann, sein/ihr Wert für die Gesellschaft erhalten bleibt und der Zugriff sich einfach gestaltet – leider auch einfach für Unbefugte.

Inhalte können dabei beliebige Formen und Formate annehmen und unterschiedlich groß und schützenswert sein.

C.O.S begegnet der stetig wachsenden Bedrohungslage im digitalen Zeitalter mit einer proaktiven Sicherheitsarchitektur, die gepaart mit angemessenen Kontrollprozessen in der IT-Organisation (wie etwa nach ITIL, cobit, …) Angriffe aufdecken und abwehren hilft bzw. ihr Auftreten unwahrscheinlich macht.

C.O.S hat die seitens des BSI (Bundesamt für Sicherheit in der Informationstechnologie) empfohlen Maßnahmen zum IT-Grundschutz und zur Softwareentwicklung, soweit auf ihre Produkte anwendbar, umgesetzt. Regelmäßige Entwicklerkonferenzen behandeln aktuelle Herausforderungen.

Vorgaben und Empfehlungen von Standards wie GMP werden somit von der Anforderungsdefinition im Entwicklungsprozess bis zum Betrieb mit Support und Transporten von Patches, Updates oder Releases.

Im Rahmen von IT-Hardening Projekten internationaler börsennotierter Konzerne haben wir alle Sicherheitsmechanismen implementiert und praktische Erfahrung gesammelt.

Ein Missbrauch auf Benutzerkonten durch unautorisierte Dritte wird nicht nur durch die verschlüsselte Speicherung der Kennworte mit einstellbarer Passwortpolitik begegnet. Für beliebige Benutzer/Rollen kann eine Multi-Factor Authentisierung gefordert werden.

Der logische Zugriffschutz ist in der Ebene der Datenzugriffsschicht verankert und damit von der Anwendung und dem Webserver selber entfernt worden. Potenzielle Angreifer müssten sich demzufolge Zugang zur Datenbank selber verschaffen, um unautorisiert an Inhalte gelangen zu können.

Die personenbezogenen Daten in der Anwendung werden so gering wie möglich gehalten. Die Verarbeitung in unseren Anwendungen dürfte regelmäßig der Genehmigung durch Artikel 6 Absatz 1 Buchstabe f) der EU-Datenschutzgrundverordnung unterfallen.

Besondere Kategorien personenbezogener Daten werden standardmäßig in unseren Anwendungsmodulen nicht erhoben (Gesundheit, Biometrie, Genetik, …). Welche flankierenden Maßnahmen beim Einsatz von (unserer) Software zu ergreifen sind, klären Sie mit Ihrem Datenschutzbeauftragten. Gerne erteilen wir hierzu weitergehende Auskünfte.

Da die anwendenden Unternehmen regelmäßig ein berechtigtes Interesse an der Weiternutzung der Daten nach Ausscheiden von Benutzern oder Löschungsauftrag von Geschäftspartnern haben, stellt C.O.S eine Anonymisierungsroutine zur Verfügung, um historische Vorgänge nicht zu verfälschen und dem dazu in Konflikt stehenden Zielen der Revisionssicherheit bzw. Gerichtsfestigkeit der Daten ebenfalls gerecht zu werden.

Die Kommunikation zwischen Anwender-Frontend (Browser-Client) und Webserver sowie zwischen Webserver und Datenbank sind jeweils verschlüsselt. Nur durch extrem aufwendige Brute-Force Angriffe ließe sich der Schlüssel „knacken“. Ressourcen dafür haben nur sehr wenige Einrichtungen auf dem Planeten.

Es gibt nur eine zentrale Datenbank und jeden Inhalt demzufolge nur einmal (mit Ausnahme von Sicherungskopien). Damit ist die Angriffsfläche minimiert.

Die Benutzerkonten der Datenbank sind für den täglichen Betrieb und Verwaltungsaufgaben aufgeteilt. Während das Kennwort für den täglichen Betrieb naturgemäß von der Anwendung benötigt wird und in einem geschützten normalen Anwendern unzugänglichen Verzeichnis verschlüsselt aufbewahrt wird, ist das Kennwort für weiterreichende Verwaltungsaufgaben überhaupt nirgendwo abgelegt. Demnach kann es nur durch „social Engineering“ oder „böswillige“ Mitarbeiter entwendet und missbraucht werden.

Je nach Kritikalität und Vertraulichkeit lassen sich die Inhalte nach Schutzbedürftigkeit in verschiedene Klassen untergliedern und ihnen das angemessene Schutzniveau zuordnen. Damit wird die Zugänglichkeit für unkritische Inhalte nichtüber Gebühr erschwert und die wirklich kritischen

Der jeweilige Schutzklasse hat die Optionen:

• Per Default Lesezugriff für keinen Benutzer,
• Verschlüsselte Ablage,
• Kennzeichnung der Vertraulichkeit bei Darstellung des Inhalts (Wasserzeichen, Warnhinweis, …)
• Formular-Authentifizierung bei Zugriff,
• 2 Factor Verfahren / TAN-Verfahren bei Zugriff.

Die Schlüssel können in einem geschützten Bereich typischerweise einem Zertifikatsserver abgelegt werden. Sie verlassen nie den Anwendungsserver. D.h., Angriffe auf des Browser-Frontend zur Erlangung des Schlüssels sind immer zum Scheitern verurteilt.

Fundament eines IT-gestützten, internen Kontrollsystems ist die proaktive Funktionstrennung. Rollenkonflikte werden durch Definition sich ausschließender Aufgaben (Autor und Redakteur, Auditor und Geprüfter, …) vermieden. Durch den logischen Zugriffsschutz in der Anwendung kann ein Benutzer nicht mehr sich widersprechende Rollen bekleiden und einen Genehmigungsworkflows umgehen. Das Vier-(Sechs-)Augenprinzip wird erzwungen.

Aufdeckende Kontrollen sind aufgrund der Protokollierungsmöglichkeit für alle Bereiche ebenfalls immer vorhanden.

Versäumnisse oder Verzögerungen in Vorgängen werden eskaliert, indem vordefinierte Personen (normalerweise Vorgesetzte) nach Verstreichen eines festgelegten Toleranzpuffers benachrichtigt werden.

Darüber hinaus sind die Module für:

• Managementsystem und Corporate Governance – co_documents
• Projektmanagement – co_issues
• Auditmanagement – co_audits
• Reporting – co_reporting

jeweils selbst wichtige Elemente eines internen Kontrollsystems der Gesamtorganisation.

Die Softwarekomponenten werden in einem geschützten Application Pool aufbewahrt. Die Transporte von der C.O.S erfolgen – auf Wunsch Passwort-geschützt, so dass Manipulationen an der eingesetzten Software im Zuge der Lieferung vermieden werden.

Im Zuge der Softwareentwicklung finden regelmäßige Security Assessments statt. Identifizierte Schwachstellen werden dann einem Rechercheverfahren unterzogen, um die beste Lösung in der einschlägigen Fachliteratur zu finden.

Heutzutage besteht eine Anwendung aus einer Vielzahl von „Zukaufteilen“. Drittanbieterkomponenten können Schwachstellen mit sich bringen und werden von uns deswegen regelmäßig daraufhin gescannt. Flankierend überwachen wir die in der Usercommunity kursierenden Diskussionen, um schnellstmöglich darauf reagieren zu können.

Der Anwender kann auswählen, welche Daten bzw. Änderungen daran er protokolliert haben möchte. C.O.S gibt zum Mindeststandard für Revisionssicherheit Empfehlungen. Dadurch kann Revisionssicherheit gewährleistet werden. Unautorisierte Zugriffe können aber vertuscht werden, wenn ein Angreifer sich die Mühe macht auch die Protokolleinträge dazu zu fälschen.

Deshalb haben wir ein spezielles Verfahren entwickelt, dass die Verfälschungen beliebiger Protokolleinträge jederzeit aufdecken. Erkannte und nachweisbare Manipulationen durch elektronisches Radieren sind dann ein untrüglicher Indikator für Verfehlungen, dolose Handlungen oder Computerkriminalität.

Die verarbeiteten Inhalte können mit den auf dem Markt gängigen Methoden (Public-Private Key-Infrastruktur) signiert, qualifiziert signiert oder gar gesiegelt werden. Die weitere Verwendung in der Datenbank und die Verteilung der öffentlichen Schlüssel an die weiteren Adressaten der Inhalte übernimmt die Anwendung. Der private Schlüssel verbleibt beim jeweiligen Autoren.

Hierdurch wird die eindeutige Herkunft und Unverfälschbarkeit der Inhalte abgesichert, ohne dass die Zugänglichkeit in der Organisation darunter leidet.

Wenn als Quelle nicht der Autor, sondern die gesamte Organisation dienen und die Authentizität sichergestellt werden soll, so können unsere Anwendungsmodule zentral digital signieren. Mit einem eigenen Zertifikat werden auf dem Server alle Dokumente der Organisation verschlüsselt abgelegt und verteilt. Die Verteilung der öffentlichen Schlüssel an die Nutzer der Inhalte wird dann vom System übernommen. Der private Schlüssel wird unzugänglich auf dem Zertifikatsspeicher des Servers selber oder auf einem externen Zertifikatsserver aufbewahrt.