scip AG

Labs

The scip Labs are our inhouse research labs, which focus on understanding and development in the fields of auditing, exploiting and forensics. Within this blog new research ideas and results are published. Most of them on German.

► 23.05.2013 – Sicherheitsverantwortlichkeiten und Risikosteuerung

Für eine systematische Risikosteuerung innerhalb eines Unternehmens ist es unerlässlich, dass Verantwortlichkeiten und Rollen glasklar definiert und umgesetzt werden. Besonders Sicherheitsverantwortlichkeiten bilden zentrale Rollen für die Sicherheit von Business, Services und IT-Infrasturktur. Diese werden typischerweise in gesamten Ownership-Konzepten und Policies oft vernachlässigt bzw. zu vage abgehandelt.

Nebst den typischen Verantwortlichkeiten, die Ownern zugewiesen werden – ist es aus dem Sicherheitsmanagment heraus – grundlegend eben auch Sicherheitsverantwortlichkeiten zu postulieren, die in der Vernatwortung von bestehenden Ownern liegen oder in der Pflicht von sog. separaten, eigenständigen Security-Ownern stehen.

Der Vorligende Artikel ist ein Versuch aufzuzeigen, wie Sicherheitsverantwortlichkeiten in einem Unternehmen als exemplarische Umsetzungsoption strukturiert werden könnten, um Risiken methodisch exakt und umfassend zu behandeln und bewältigen.

Security Owner haben den Auftrag und die Kompetenz, über Sicherheitsziele und Risiken in ihrem Verantwortungsbereich zu entscheiden. Darauf basierend werden nun im weiteren Verlauf die Aufgaben, Kompetenzen und Verantwortlichkeiten der Security Owner beschrieben. Dabei wird festgelegt:

• Wer trägt die Verantwortung für Sicherheitsrisiken von Business Services, Applikationen und IT-Infrastruktur
• Welche Sicherheitsaufgaben bestehen für Sicherheitsverantwortliche
• Wer ist verantwortlich und – wenn möglich-, zuständig für diese Sicherheitsaufgaben

Die hier vorgeschlagene Austellung geht davon aus, dass das Thema immer Teil eines unternehmensweiten, einheitlichen Sicherheitsmanagements ist. Entsprechend muss es aus der Perspektive des Unternehmens adaptiert und formuliert werden.

Die Umsetzung solcher Ownershipkonzepte, kann ja nach Unternehmensgrösse bedingen, dass einzelnen Geschäftsbereichen eine gewisse Autonomie attestiert wird, da Business-, IT- und Entwicklungsprozessen in diversen Geschäftsbereichen eines Unternehmens durchaus unterschiedlich ausgeprägt sein könnten.

Rahmenbedingungen: Anforderungen auf Ebene der Policy bzw. Sicherheitspolitik

Die benötigten Rollen der Sicherheitsverantwortlichen müssen auf dem Niveau einer Weisung, Policy oder Sicherheitspolitik definiert und institutionalisiert werden.

Vorgängig ist ein Aufteilung der Verantwortlichkeiten in den typische Bereiche nötig:

• Business Services / Applikationen
• IT- Infrastruktur
• Entwicklungen

Die Verantwortung für die Sicherheit von Business Services, Applikationen und IT-Infrastruktur wird durch sogenannte Sicherheitsverantwortliche (Security Owner) wahrgenommen, die durch die Geschäftsleitung nominiert und mit Entscheidungskompetenzen bezüglich Festlegung von Sicherheitszielen und Risikoakzeptanz versehen werden. Sicherheitsverantwortliche sind in der Regel Mitglieder des höheren oder mittleren Managements.

• Sicherheitsverantwortliche für Business Services / Applikationen: Für jeden Business Service und jede geschäftsrelevante Applikation wird ein Sicherheitsverantwortlicher ernannt. Er stuft den Service, bzw. die Applikation und die damit bearbeiteten Daten bezüglich Verfügbarkeits-, Vertraulichkeits- und weiteren Sicherheits- und Compliance-Anforderungen ein und definiert dadurch die Sicherheitsziele für Entwicklung und Betrieb. Der Sicherheitsverantwortliche entscheidet über Sicherheitsmassnahmen und trägt die Verantwortung für die Sicherheitsrisiken während des gesamten Lebenszyklus.

• Sicherheitsverantwortliche IT- Infrastruktur: Für IT-Infrastrukturen, namentlich für Netzwerke, Plattformen, Storage-, Enterprise Systems Management- und Sicherheitsinfrastrukturen, sowie für Service Applications, werden Sicherheitsverantwortliche ernannt. Sie stufen die ihnen zugeordnete Komponente bezüglich Verfügbarkeits-, Vertraulichkeits- und weiteren Sicherheits- und Compliance-Anforderungen ein und definieren dadurch die Sicherheitsziele für Entwicklung und Betrieb der Komponente. Sie entscheiden über Sicherheitsmassnahmen und tragen die Verantwortung für die Sicherheitsrisiken während des gesamten Lebenszyklus der Komponente.

• Sicherheitsverantwortliche für Entwicklungen: Sicherheitsverantwortliche für Entwicklungen von Software oder IT-Infrastrukturlösungen sind verantwortlich für das Erreichen der vorgegebenen Sicherheitsziele, die Definition und Umsetzung der dafür notwendigen Massnahmen, sowie generell für die Einhaltung der Sicherheitsmanagementprozesse, Sicherheitsvorgaben und -standards während Entwicklungsvorhaben.

• Information Owner: Der Information Owner ist verantwortlich für die Behandlung und den Schutz der Informationen und Geschäftsunterlagen, welche der ihm anvertrauten Informationssammlung angehören. Insbesondere ist er zuständig für: die Bestimmung der Klassifizierung und die Festlegung von allfälligen erhöhten Sicherheitsanforderungen bezüglich der Informationssammlung sowie die bedarfsgerechte Erteilung und Löschung der Zugriffs- und Zutrittsberechtigungen zur Informationssammlung.

Abgrenzung

Diser Artikel befasst sich ausschliesslich mit sicherheitsrelevanten Aufgaben und Verantwortungen. So wird dann auch von Sicherheitsverantwortlichen oder Security Owners und nicht generell von IT- oder Business-Owners gesprochen.

Es ist selbstverständlich möglich und u.U naheliegend, die Rolle eines Security Owner Business Service dem Business Owner eines Services zuzuweisen, sofern der betreffende Geschäftsbereich des Unternehmens die Rolle des Business Owners implementiert hat. Entsprechendes gilt für die Rolle des IT-Owners und des Sicherheitsverantwortlichen IT-Infrastruktur.

Begriffsbestimmungen

In diesem Dokument werden die Rollen der Sicherheitsverantwortlichen für Business Services oder Applikationen und der Sicherheitsverantwortlichen für IT-Infrastruktur beschrieben. Diese Rollen beziehen sich auf folgende Definitionen:

• Applikation: ein Anwendungsprogramm (kurz Anwendung) ist ein Computerprogramm, das eine für den Anwender nützliche Funktion ausführt.

• Business Service:Geschlossene Einheit von Applikationen, die zusammen einen IT-Service für das Business liefern.

• IT Infrastruktur: Storage, Plattformen (Hardware + Betriebssystem), Netz, Unternehmes Systems Management, Service Applikationen; sowie u.a. folgende Sicherheitskomponenten: Security Standards (Hardening Guides, Anti-Malware, etc.) Authentisierungs- und Autorisierungsservices, Verschlüsselungs-Services, Disaster Recovery- und Security Event Management-Systeme etc.

Im Zusammenhang mit der Risikoverantwortung von Sicherheitsverantwortlichen gilt:

• Sicherheitsrisiko: Möglichkeit, dass ein Sicherheitsziel oder mehrere Sicherheitsziele nicht erreicht werden.

• Sicherheitsziel, Sicherheitsniveau: Zu erfüllende Sicherheitsanforderung. Durch das Erreichen aller Sicherheitsziele erlangt ein Business Service, eine Applikation oder IT-Infrastruktur das angestrebte Sicherheitsniveau.

• Risikoverantwortung: Verantwortung für das Management von Risiken: für Identifikation, Messung und Beurteilung von Risiken, für die Erarbeitung von Massnahmenplänen und die Risikosteuerung.

• Risikosteuerung: Entscheidung über den Umgang mit Risiken (Umsetzung von Massnahmen, Risikoakzeptanz).

Rollenbeschreibungen

In einer ersten Betrachtung werden nun die Rollen der Sicherheitsverantwortlichen in abstrakter zusammenfassender Form beschrieben. Ein Zuordnung der Verantwortlichkeiten für die anfallenden Sicherheitsaufgaben, sowie eine Erläuterung der spezifischen Risikoverantwortung von Sicherheitsverantwortlichen erfolgt in den nachfolgenden Kapiteln.

Sicherheitsverantwortliche für Business Services / Applikationen

Sicherheitsverantwortliche für Business Services / Applikationen sollten die Gesamtverantwortung für die Sicherheit der Applikation, bzw. des Business Services und der mit damit zu bearbeitenden Daten während des gesamten Lebenszyklus der Applikation, bzw des Business Services tragen.

• Information Owner im Sinne der Group Weisung 1.9 [5]
• tragen Verantwortung für Sicherheitsrisiken und entscheiden – im Rahmen ihres Kompetenzbereichs – über Risikoakzeptanz und Umsetzung von Sicherheitsmassnahmen
• bestimmen Sicherheitsanforderungen die Applikation bzw. Business Service
• bestimmen Sicherheitsanforderungen den Betrieb der Applikation bzw. Business Services
• kontrollieren vor Inbetriebnahme und periodisch die Einhaltung der Sicherheitsanforderungen

Für jeden Business Service und für jede geschäftsrelevante Applikation, die nicht einem Business Service zugeordnet ist, wird ein Sicherheitsverantwortlicher ernannt.

Sicherheitsverantwortliche für IT-Infrastruktur

Sicherheitsverantwortliche für IT-Infrastruktur sollten die Gesamtverantwortung für die Sicherheit der IT-Infrastruktur während des gesamten Lebenszyklus der IT-Infrastruktur tragen. Falls es die IT-Infrastruktur eigene Datenbestände hat, sind die Sicherheitsverantwortlichen für IT-Infrastruktur auch verantwortlich für Sicherheit der zugehörigen Daten.

• Information Owner (vgl. oben)
• tragen Verantwortung für Sicherheitsrisiken, bzw. -schwachstellen und entscheiden – im Rahmen ihres Kompetenzbereichs – über Risikoakzeptanz und Umsetzung von Sicherheitsmassnahmen
• bestimmen Sicherheitsanforderungen an IT-Infrastruktur in Abstimmung mit dem zuständigen Technical Product Manager
• bestimmen Sicherheitsanforderungen an den Betrieb der IT-Infrastruktur
• kontrollieren vor Inbetriebnahme und periodisch die Einhaltung der Sicherheitsanforderungen
• informieren betroffene Sicherheitsverantwortliche für Business Services / Applikationen über sicherheitsrelevante Änderungen der IT-Infrastruktur

Sicherheitsverantwortliche für Entwicklung

Sicherheitsverantwortliche für Entwicklung verantworten die Umsetzung der Sicherheitsanforderungen und die Einhaltung der sicherheitsrelevanten Prozessvorgaben bei der Entwicklung von Software oder beim Engineering von IT-Infrastruktur.
Sie

• verantwortlich für die Spezifikation der Sicherheitsanforderungen aufgrund der Vorgaben des Sicherheitsverantwortlichen für Business Services / Applikation oder IT-Infrastruktur und der anwendbaren verbindlichen internen Vorgaben.
• verantworten die korrekte Umsetzung der Sicherheitsanforderungen
• stellen sicher, dass bei Entwicklung/Engineering die anwendbaren und verbindlichen Vorgaben zur Entwicklung sicherer Software bzw. Infrastruktur eingehalten werden
• verantwortlich für die Erstellung der Sicherheitsdokumentation

Risikosteuerung

Sicherheitsverantwortlicher IT-Infrastruktur

Sicherheitsverantwortliche für IT-Infrastruktur sind zuständig für die Steuerung der Sicherheitsrisiken, die dem Unternehmen aufgrund von Schwachstellen der IT- Infrastruktur in seinem Verantwortungsbereich entstehen. Entscheidungsgrundlagen für die Risikosteuerung sind das angestrebte Sicherheitsniveau der IT-Infrastruktur, sowie die identifizierten und bewerteten Risiken und Schwachstellen.

Die Entscheidung über die Umsetzung von Massnahmen zur Risikominderung und die Akzeptanz von Risiken erfolgt durch den Sicherheitsverantwortlichen.

Sicherheitsverantwortlicher Business Service / Applikation

Der Sicherheitsverantwortliche eines Business Services oder einer Applikation ist zuständig für die Steuerung der Sicherheitsrisiken, die das Unternehmen durch den Business Service, bzw. die Applikation entstehen.

Entscheidungsgrundlagen für die Risikosteuerung sind das angestrebte Sicherheitsniveau des Business Services / der Applikation und die identifizierten und bewerteten Risiken.

Die Entscheidung über die Umsetzung von Massnahmen zur Risikominderung und die Akzeptanz von Risiken erfolgt durch den Sicherheitsverantwortlichen

Der Sicherheitsverantwortliche eines Business Services / einer Applikation kann bei der Risikosteuerung voraussetzen, dass der IT-Infrastrukturbetreiber die für die IT-Infrastrukturkomponenten vereinbarten Sicherheitsniveaus einhält.

Risikoausschuss der Unternehmensführung

Der Risikoausschuss entscheidet über Unternehmensweite Sicherheitsmassnahmen und die Akzeptanz von Geschäftsbereichübergreifende Sicherheitsrisiken. Darüberhinaus ist der Risikoausschuss Eskalationsgremium bei Meinungsverschiedenheiten über Risikoeinschätzungen.

Sicherheitsaufgaben

Der folgende Abschnittg identifiziert die im Zusammenhang mit der Sicherheit von Business Services, Applikationen oder IT-Infrastruktur anfallenden Aufgaben und ordnet Verantwortlichkeiten zu.

Im Fokus sind dabei die generell für Sicherheitsverantwortliche anfallenden Aufgaben. Ausnahmen, in denen auf einige dieser Aufgaben verzichtet werden kann oder Ausnahmefälle, in denen zusätzliche Aufgaben zu erledigen sind, werden nicht betrachtet.

Die Zuordnung von Aufgaben zu Funktionen erfolgt zweistufig. Es wird jeweils angegeben, welche Funktion die Verantwortung für die korrekte und termingerechte Ausführung der Aufgabe trägt und –soweit aus exemplarischer Unternehmenssicht möglich-, welche Funktion die zuständig für die Ausführung der Aufgabe ist. Es werden folgende Abkürzungen verwendet:

• SB: Sicherheitsverantwortlicher Business Service oder Applikation
• SI: Sicherheitsverantwortlicher IT-Infrastruktur
• SE: Sicherheitsverantwortlicher Entwicklung
• D: Delegation: Unterschiedlich, abhängig von den jeweiligen internen Prozessen eines Geschäftsbereichs
• CSO: Chief Security Officer

Risikoverantwortung

Klassifikation von Informationen

Sicherheitsanforderungen festlegen und umsetzen

Sicherheitsadministration

Betriebliche Sicherheitsaufgaben

Audits

Umsetzungsoptionen

Es sollte im Verantwortungs- und Kompetenzbereich der Geschäftsbereiche eralubt sein, die Umsetzung dieses Konzepts entsprechend der Bereichsinternen Prozesse zu gestalten. Im folgenden werden einige Varianten für die Umsetzung in Geschäftsbereichen aufgezeigt.

Falls ein Geschäftsberiech z.B Rollen wie Business Owner oder Business Operation Owner etabliert haben, dann bieten sich folgende Optionen an:

• Vergabe der Rolle Sicherheitsverantwortlicher Business Service / Applikation an den Business Owner des Business Services, bzw. der Applikation.

• Delegation einiger Aufgaben, die unter der Verantwortung des Sicherheitsverantwortlichen für Business Service / Applikation stehen, zur Ausführung an den Business Operation Owner. Dabei ist sicherzustellen, dass die Delegation nachvollziehbar bleibt und die Kontrolle weiterhin dem Hauptverantwortlichen obliegt.

Beispiele: Definition der Sicherheitsanforderungen an den Betrieb, Prüfung/Freigabe von Zugriffsanträgen, Durchführung der fachgerechten Archivierung, Aktualisierung der Kommunikationsmatrix

Weitere Optionen

• Vergabe der Rolle Sicherheitsverantwortlicher IT-Infrastruktur an den IT-Owner der Infrastruktur.

• Vergabe der Rolle Sicherheitsverantwortlicher Entwicklung an den Sicherheitsverantwortlichen Business Service / Applikation, bzw. an den Sicherheitsverantwortlichen IT-Infrastruktur.

• Delegation der Aufgabe Dokumentation der betrieblichen Sicherheitsanforderungen in der verbindlichen Vereinbarung an einen Service Manager

Fazit

Verantwortung ist ein schönes Wort: Das allerdings typischerweise dann an edlem Glanz verliert, wenn es konkret werden soll – Wer trägt wem gegenüber welche Verantwortung? In Unternehmen wird oft der Eindruck erweckt, dass in Bezug auf die Ownership alles klar definiert ist und es keine Verantwortungskonflikte geben kann.

Das mag aus der Vogelperspektive wohl stimmen, aber Verantwortung zerfällt bei genauerem Hinschauen in viele Partikular-Verantwortungen, die nicht unbedingt miteinander harmonieren. Es herrscht ja bei weitem nicht immer Einklang der Interessen und somit natürlich auch nicht der Verantwortungen. Daher ist es von eminenter Bedeutung, sich darüber im Klaren zu werden, welche Aufgaben und Verantwortungen an welcher Stelle durch wen wargenommen werden müssen, um die Risiken in einem Unternehmen umfassend und lückenlos zu steuern.

Flavio Gerbino | G+ (2613 words)

► 16.05.2013 – Computer Forensik – Ein Überblick

Ich beschäftige mich seit einigen Jahren mit Computer Forensik. In diversen Gesprächen ist mir aufgefallen, dass man im Allgemeinen ein völlig falsches Bild von dieser Disziplin hat. In diesem Artikel werde ich mich bemühen, weitere Aspekte der Computer Forensik nahe zu bringen. Dies ist meine und die Meinung anderer Fachpersonen. Wie immer werden Sie auch Fachpersonen finden, welche diesen Ansichten wiedersprechen werden.

Die schiefe Optik

Sobald ich jemandem von Computer Forensik erzählt habe, kam oft und schnell diese Aussage: Ach ja, das sind doch die vom CSI im Fernsehen. Ehrlich gesagt, habe ich CSI noch nie länger als 5 Minuten gesehen. Aber diese 5 Minuten haben genügt, um sagen zu können, Nein, nicht wie die vom CSI. In der Computer Forensik schaut man nicht auf eine Festplatte und weiss danach, was der Mörder zum Mittagessen hatte.

Ein weiteres falsches Bild, das viele Personen haben, ist die Datenrettung. Ja, Datenrettung ist eine Teildisziplin der Computer Forensik und wir haben und kennen verschiedene Tools, um die versehentlich oder absichtlich gelöschten Daten wieder herzustellen. Diese Fähigkeit sollten Sie aber mehr als Mittel-zum-Zweck ansehen, als die Kernkompetenz eines Forensikers. Damit er die Spuren auswerten kann, benötigt er die Daten, und diese können auch nur noch als Daten-Fragmente existieren und müssen daher wiederhergestellt werden. Wenn Sie einen grossen Datenverlust haben, gibt es aber auch Spezialisten, die sich nur um dieses Problem kümmern.

Was ist es dann

Wie immer ist es eine Frage des Blickwinkels. Vielleicht zuerst zur Klärung, wo es Computer Forensiker gibt. Einerseits finden Sie Computer Forensik Abteilungen bei der Polizei. Diese Abteilungen sind in der Regel unterstützend tätig für die Kriminalpolizei. Das bedeutet, ein Polizist der Kripo zieht einen Experten für einen Fall hinzu. Der Experte muss dabei Beweismittel aus elektronischen Geräten und Datenträger (Notebook, Mobiltelefon, PDA, eBook, Speichermedien etc.) suchen. Viele der Fälle werden wohl Drogendelikte sein. Hier gilt es die Kontakte, Nachrichten und Anruflogs eines Drogenhändlers auszuwerten und allenfalls auf weitere Personen zu kommen.

Am bekanntesten sind wohl die Fälle von verbotener Pornografie, am präsentesten die Kinderpornografie. Neben der Polizei gibt es Unternehmen, welche sich auf die Computer Forensik spezialisiert haben (es sind wenige in der Schweiz). Diese arbeiten vor allem unterstützend für die Polizeikorps und Staatsanwaltschaften.

Die nächst grössere und eventuell sogar die grössten Computer Forensik Abteilungen finden Sie in den grossen Wirtschaftsprüfungsunternehmen. Während der Fokus bei der Polizei jedoch sehr technisch ist und in der Systemanalyse liegt, ist er hier eine Ebene höher. Auch diese Forensiker können Datenwiederher- und sicherstellen. Ihr Fokus liegt jedoch in der eDiscovery, dabei geht es darum, innerhalb einer Bestimmten Zeit alle relevanten Dokumente zu sammeln und einem Reviewer zur Verfügung zu stellen.

Neben den vorgestellten Typen, finden Sie auch bei Information Security Spezialisten entsprechende Computer Forensiker. Der Vorteil von uns: Wir haben beide Blickwinkel. Wir kennen die Angreiferseite und wir kennen die Ermittlerseite. Wir können Ihnen helfen Einbrüche zu analysieren, Beweismittel sichern und Vorschläge zur Verbesserung der Sicherheit geben.

Incident

Haben Sie einen Incident, bei dem Sie vermuten, dass jemand unerlaubt auf Ihre System gelangt war? Haben Sie die Vermutung, dass ein Mitarbeiter, welcher die Firma verlassen wird Ihre Geschäftsgeheimnisse mitnimmt? Erhalten Sie E-Mail Nachrichten von unbekannten Absendern mit drohenden Aussagen?

Das sind alles Beispiele von Vorfällen, in welchen Computer Forensik zum Zug kommen könnten und sollten. Die Aufzählung ist keineswegs Abschliessend, es gibt so viele Bereiche in denen eine forensische Analyse sinnvoll sein könnte.

Forensik kurz und knapp

In der Computer Forensik (egal ob eDiscovery oder klassisch) gibt es grob gesagt drei Phasen, die durchlaufen werden.

1. Beweismittelsicherung
2. Investigation und Analyse
3. Dokumentation

Beweismitelsicherung

Bei der Beweismittelsicherung gibt es verschiedene Aspekte, die berücksichtigt werden sollen. Wenn der Auftraggeber bereits zu Beginn keine gerichtliche Auseinandersetzung anstrebt und die Untersuchung der Prävention dienen soll, kann man sich die aufwändige Arbeit der gerichtlichen Verwertbarkeit sparen.
Sollte der Kunde dies zum Startzeitpunkt noch nicht wissen, ist es von Vorteil die gängige Praxis anzuwenden. Somit hat der Kunde auch zum späteren Zeitpunkt noch die Möglichkeit ein Verfahren anzustreben.

Wo finde ich Beweise

Natürlich ist dies von Fall zu Fall unterschiedlich. Grundsätzlich können Sie die Beweismittel in jedem elektronischen Gerät mit Speicher oder auch diversen Speichermedien auffinden. Zum Beispiel:

• Mobiltelefon/Tablet
• MP3-Player
• e-Reader (Kindle, Nook, etc.)
• Spielkonsole (PS3, PSP, XBox etc.)
• Backup-Infrastruktur (Diskstorage, NAS, Magnetband, etc.)
• Server
• PC/Mac
• Netzwerk
• ...

Wichtig ist, dass man die relevanten Beweise auffinden kann. Interessant ist hier das Amerikanische Recht. Rule 401 besagt, dass ein Beweis relevant ist, sofern er die Tendenz hat, ein Fakt mehr oder weniger glaubwürdig zu sein, als ohne des Beweises.

Diese Daten können sein:

• Chat Protokolle
• Dokumente (PDF, Word, Excel, Text, etc.)
• Browser History
• Logdateien
• Digitale Bilder
• E-Mail
• ...

Kurzum: Beweise in der Computer Forensik sind Electronic Stored Information (ESI).

Sicherung

Die Sicherung dieser Beweise wird vorzugsweise durch eine Bitweise Kopie des Original-Speichermediums vorgenommen. Dabei werden zwei Kopien erstellt und der Zugriff auf das Original geschieht über einen Hardware-Schreibschutz. Die erste Kopie gilt als Best Evidence und wird in der Regel archiviert oder allenfalls später zur Kopie für weitere Arbeitsdisks beigezogen. Die zweite Kopie ist eine Arbeitsdisk. Sie wird direkt zur Untersuchung weiterverwendet.

Folgende gilt es zu beachten, damit ein Beweismittel als integer angesehen werden kann:

• Bit-weise Kopie des Originals
• Kopien werden in geschlossenen oder beschränkt zugänglichen Räumlichkeiten aufbewahrt
• Chain of Custody
• Hash Werte zur Kontrolle anlegen

Verschlüsselte oder flüchtige Speicher

Ist ein Speichermedium verschlüsselt, kann selbstverständlich versucht werden die Verschlüsselung zu brechen. In der Regel gelingt dies jedoch nicht. Der Schlüssel kann jedoch im Memory zu finden sein. Auf jeden Fall bedingt ein verschlüsseltes Medium die Akquise der logischen Partition d.h. es muss eine Software von einer DVD oder einem USB-Stick geladen werden. Dieser Schritt gilt es gut zu dokumentieren, da das Original System verändert werden muss.

Das gleiche Problem gibt es bei der Akquise von RAM (flüchgiter Speicher). Sie können zwar den RAM-Inhalt mit enormem Aufwand auch nach dem Ausschalten des Systems im Ursprungszustand behalten, jedoch mit einem enorm hohen Aufwand und nur über sehr kurze Zeit.

Übersicht

Diese verschiedenen Akquise Möglichkeiten gibt es

Investigation und Analyse

Zur Untersuchung und Analyse von Images kann man verschiedene Tools verwenden. Zwei Tools, EnCase und FTK, sind in der Branche sehr populär, es ist aber keinesfalls ein Muss, diese zu verwenden.

Memory Analyse

Im Memory können diverse interessante Informationen enthalten sein:

• Internet History
• Web E-Mail (z.B. GMX)
• Chat Sessions (z.B. Skype, Facebook-Chat)
• Netzwerkverbindungen
• Prozessinformationen

Bei der Memory Analyse muss das Zielsystem noch laufen und man benötigt Zugriff. Es muss dabei ein Tool von einer DVD oder einem USB-Stick geladen werden. Die Daten sollten dabei nicht auf das Zielsystem sondern ins Netzwerk oder auf ein USB-Medium gespeichert werden.

Gelöschte Dateien

Wie im ersten Teil erläutert, verstehen viele Leute unter der Datenwiederherstellung die eigentliche Aufgabe der Computer Forensik. Tatsächlich kann es von grossem Interesse sein gelöschte Dateien wieder herzustellen. Bekommen Leute mit, dass Sie verdächtigt werden oder sind sie einfach nur vorsichtig, so löschen Sie genau die Dateien, welche interessant sein könnten.

Nicht jede gelöschte Datei kann wieder hergestellt werden. Teilweise sind auch nur noch Dateifragmente vorhanden. Wurde der komplette Zielort auf der Disk bereits überschrieben, so ist diese Datei nicht mehr vorhanden.

Untersuchung

Bei der Untersuchung kommt es wiederum auf die eingesetzten Produkte und das Ziel an. Eine Vorgehensweise ist das Eingrenzen des Zeitrahmens und so die Relevanz der Dokumente zu bestimmen. Eine andere ist dies auf eine gewisse Gruppe von Daten einzuschränken (E-Mail, Textdokumente, Bilder, etc.).

Es kann aber auch eine Kombination dieser Punkte sein. Wichtig scheint mir, dass man ein klares Ziel hat. Den Grundsätzlich kann eine forensische Analyse bereits eine Suche im Heuhaufen sein, durch eine offene Fragestellung wird das Spektrum nur erweitert. Wir sind aber in der Lage herauszufinden, welche Dokumente ein Benutzer wann geöffnet hat. In welchen WLAN sich dieses Gerät angemeldet hat. Hiermit lassen sich allenfalls auch Standorte identifizieren. Es ist auch möglich herauszufinden, wann ein USB-Stick angeschlossen wurde. Die Möglichkeiten sind gross und würden den Rahmen dieses Artikels sprengen.

Fazit

Nun haben Sie einen kurzen, zugegeben oberflächlichen Eindruck der Computer Forensik erhalten. Zumindest ist nun geklärt, dass wir mehr können als nur Daten wiederherzustellen. Diese Disziplin kommt in verschiedenen Fällen zum Einsatz. Gesagt werden kann, je mehr Daten ein Forensiker zum Auswerten hat, desto höher ist die Chance auf einen Erfolg.

Oliver Kunz | G+ (1544 words)

► 13.05.2013 – Vortrag zu Security Testing an SGRP Veranstaltung

Am 07. Mai 2013 fand die Frühlingsveranstaltung der Sicherheitsgruppe Schweiz (SGRP) statt. im Rahmen derer wurde in den Credit Suisse Tower nach Zürich-Oerlikon geladen. Ingesamt fanden drei Vorträge, ebenfalls einer von mir zum Thema Security Testing, statt.

Im ersten stellte Stephan Murer der Credit Suisse seine auf langjähriger Erfahrung basierenden Erkenntnisse zu Testdaten vor. Dabei hat er die verschiedenen Fallstricke aufgezeigt und darauf verwiesen, dass mit synthetischen Testdaten ein Mehr an Effizienz, Zuverlässigkeit und Sicherheit erreicht werden kann.

Der zweite Vortrag wurde von Roland Schützig gehalten und besprach das Prinzip der Virtuellen Bank. In dieser werden bestehende Prozesse mit synthetischen Daten kombiniert, um die Voraussetzung für eine intelligente Testumgebung zu schaffen.

Auf der Basis dieser beiden Beiträge habe ich dann in meinem Vortrag das Thema Security Testing aufgegriffen. Dabei habe ich versucht aufzuzeigen, wie aus Sicht eines Analysten die Sicherheit einer solchen Umgebung geprüft werden kann. Das Slidedeck meines Beitrags steht hier zum Download zur Verfügung.

Im Anschluss wurde das Konzept des Smart Workplace bei Credit Suisse gezeigt und guter Wein beim Apéro genossen. Es hat mich gefreut, die vielen bekannten Gesichter – von Kunden bis zu ehemaligen Arbeitskollegen – zu sehen.

Marc Ruef | G+ (229 words)

► 08.05.2013 – Staatstrojaner – Kritik am neuen Bundesgesetz

Mit der Einführung des neuen Bundesgesetzes betreffend der Überwachung des Post- und Fernmeldeverkehrs könnte in der Schweiz etwas einkehren, was bereits in Deutschland für langwierige Diskussionen gesorgt hat: Staatstrojaner, auch GovWare (Government Software) genannt.

Seit geraumer Zeit regt sich grosser Widerstand gegen die Einführung des neuen Gesetzes, wobei die GovWare einen wesentlichen Teil der Kritik darstellt. Auch wenn nicht alle Gegenargumente juristisch stichhaltig scheinen, so zeigen die mittlerweile über 3’900 Unterschriften auf büpf.ch, dass dieses Thema grosse Beachtung findet.

Die juristische Beurteilung des Gesetzes muss durch Fachleute vollzogen werden. Kritik aus diesen Kreisen ist bereits ausgeübt worden. In diesem Artikel möchte ich auf die technischen Schwierigkeiten eingehen, die sich mit dem Einsatz von Staatstrojanern ergeben. Denn wie wir bereits in einem Artikel aufgezeigt haben, bringen Staatstrojaner per se schon einige Probleme mit sich. Unsere drei Hauptpunkte waren:

• Tangierung der Privatsphäre
• Kompromittierung der Integrität
• Erhöhung der Angriffsfläche

Diese Punkte haben sich nicht verändert, sie können eher sogar noch erweitert werden:

Unklare Benutzerverhältnisse

Wie soll sichergestellt werden, dass wirklich die Zielperson das überwachte Gerät zur fraglichen Zeit bediente? Noch haben nicht alle Geräte beispielsweise eine Kamera, mit der dies zweifelsfrei festgestellt werden könnte. Die grosse Mobilität, die durch heutige Notebooks, Handys und Tablets möglich ist, verhindert zudem viele klassische Identifizierungsmöglichkeiten, wie beispielsweise versteckte, stationäre Überwachungskameras.

Der Wert einer solchen Analyse dürfte sich für eine juristische Untersuchung somit in Luft auflösen. Solange die Unschuldsvermutung gilt und die überwachte Zielperson nicht auf andere Art und Weise der zeitgleichen Benutzung überführt werden kann, besteht immer die Möglichkeit, dass jemand anderes als die beschuldigte Person zur fraglichen Zeit das Gerät bediente.

Trennung von Daten

Bei einer Überwachung mittels Staatstrojaner wäre besonders bei Geräten, die regelmässig von mehreren legitimen Benutzern bedient werden, eine Trennung der Benutzerdaten problematisch, wenn nicht gar unmöglich.

So kann beispielsweise nicht von vornherein festgestellt werden, welche Daten für eine strafrechtliche Verfolgung relevant sind und welche nicht. Somit müssten alle Daten durchforstet werden, was mitunter einen massiven Eingriff in die Privatsphäre von unbeteiligten Personen zur Folge hätte.

Zentrale Lagerung

Wie im Statement von Bundesrätin Simonetta Sommaruga nachgelesen werden kann, werden die bei den Überwachungen gesammelten Daten zentral abgelegt. Dies wiederum bringt gänzlich neue Probleme mit sich, die es ebenfalls zu adressieren gilt.

So muss der Zugriff auf die Daten strikt nach dem Datenschutzgesetz geregelt und diese Regelungen konsequent durchgesetzt werden. Denn eine derart grosse Menge an Informationen ist eine Einladung für Kriminelle und korrupte Mitarbeiter – Ein Problem, vor dem man nicht einfach die Augen verschliessen darf.

Anti-Malware

Software, die zur Aufgabe hat, Schadsoftware zu erkennen und zu entfernen, setzt hierzu mitunter heuristische Erkennungsmethoden ein. Dies ermöglicht es der Software, aufgrund des Verhaltens installierter Programme zu entscheiden, ob diese schädlicher Natur sind oder nicht.

Um diese Erkennung zu verhindern, müssten sämtliche Hersteller die Signatur des Staatstrojaners in ihre Datenbanken aufnehmen und als gutartig kennzeichnen. Dies wird aber vermutlich stark erschwert durch die Tatsache, dass viele dieser Hersteller ihre Sitze im Ausland haben und somit ein Interessenskonflikt zwischen der schweizerischen Regierung und der Regierung deren Länder besteht.

Des weiteren besteht dann die Gefahr, dass jemand, der an die Signatur des Staatstrojaners kommt, eine Malware herzustellen in der Lage ist, die von Antivirensoftware nicht mehr erkannt wird. Kriminelle könnten dann ungestört illegalen Machenschaften nachgehen, die von Benutzern grösstenteils nicht mehr aufgedeckt würden.

Diese Situation kann natürlich nur eintreten, wenn der Staatstrojaner grossflächig eingesetzt würde. Da es im letzten Jahr in der Schweiz nur zu 46 Internetüberwachungen kam, dürfte sich das Risiko in dieser Hinsicht relativieren.

Fazit

Der Einsatz von Staatstrojanern bleibt nach wie vor fragwürdig. Nicht nur, dass sie sich rechtsstaatlicher Kritik ausgesetzt sehen, auch aus technischer Sicht bestehen beträchtliche Hürden, die erst noch genommen werden müssen. Schliesslich ist das Missbrauchspotenzial bei solch invasiven Massnahmen massiv. Dies gilt es zu erkennen und einzudämmen. Ob dies allerdings gelingt, ist in Anbetracht der gegebenen Komplexität der Situation mehr als fragwürdig.

Manche Schweizer mögen sich noch gut an die 80er Jahre und an 2010 erinnern, als die sogenannten Fichenaffären ein grosses Thema waren. Das eidgenössisches Justiz- und Polizeidepartement wird sich grösstmögliche Mühe geben müssen, um die Ängste zu diesem Thema glaubwürdig zu zerstreuen. Ein einfacher Vertrauensaufruf wird in diesem Fall kaum ausreichen.

Sean Rütschi | G+ (850 words)

► 02.05.2013 – Overview of Microsoft’s security toolkit EMET

Introduction

Microsoft has developed several tools that help security professionals in the difficult task to keep Windows operating systems safe, like the Microsoft Baseline Security Analyzer (MBSA) or the Security Compliance Manager (SCM). This time we like to give an overview of another interesting piece of windows security software: the Enhanced Mitigation Experience Toolkit (EMET).

EMET is an utility to help protect the Windows operating system platforms against exploitation of vulnerabilities through a series of security mitigation technologies. As any other security tools, EMET does not replace other information security solutions; it is meant to add an additional layer of defence in the existing security framework.

While it may not prevent all possible security exploits, the mitigation technologies implemented by EMET make exploitation significantly more difficult if configured properly.

Features

EMET supports client and server based operating system. The current version (4.0 beta) allows security mitigation technologies to be configured for the system and applications. Mitigations applied to the system will impact the entire system while mitigations applied to the applications will only impact the specified applications. This provides following key benefits:

• Highly configurable even on single executables base
• Application hardening support for all application without recompiling
• GUI allowing ease of configuration
• Enterprise ready (supports group policy deployment, SCCM and command line interface)
• Ongoing improvement and updates

Further, following are the most interesting new features in EMET 4.0:

• Detecting attacks that uses suspicious SSL/TLS certificates
• Allowing customers to test mitigations with an Audit Mode

Below is a table listing the used mitigation technologies:

For more information please refer to the well written EMET 4.0 user manual available via Help menu on the EMET GUI.

Not all mitigation option are supported on all operating systems and application, but Microsoft is continuously improving the software and providing support for all important platforms and application executables.

Here a short overview on supported features on platform and executables:

Another limitation is bound to the web Certificate Trust, it works only with following browsers:

• Internet Explorer 32bit desktop mode
• Internet Explorer mixed 32/64bit desktop mode

Unsupported are by now following versions:

• Win8 APP mode
• Internet Explorer in full 64bit desktop mode (security enhanced mode)

How it works

EMET is not a fire and forget toolkit, it requires you to carefully configure the policy and thoroughly test it before it can be used for production environment; also EMET is not an end-user tool like an anti-virus.

After the installation (that requires .NET Framework 4 and eventually a restart) you can begin using EMET by starting its GUI. It will the show something like this:

In the first window half you’ll see the available system features and its related status: Enabled, Application Opt-In, Application Opt-Out or Disabled; in the second half the are the systems running processes and related active mitigation features. The system mitigation settings are configurable via this panel:

The application mitigation settings are configurable on this other panel:

To add an application specific mitigation settings just push to the add button or right-click in the list of running processes, you’ll then be able to select the mitigation settings checkbox.

All action are written into the Windows application log and reported by the tray icon so if you need to analyze what happens you can filter for EMET log source there; this is important if you are running in audit mode and don’t kill processes that are violating the policy. By default processes are killed here are the configuration settings:

Certificate Trust (configurable certificate pinning)

EMET 4 provides a crypto extension module that will add additional checks during the certificate chain trust validation process. When browsing to an HTTPS website, EMET will validate the end-entity SSL certificate and the Root CA that issued that certificate against the rule configured.

Depending on the rules configured for a specific domain, EMET will detect when a variation of the issuing Root CA for a specific SSL certificate occurs. In this case EMET will only detect the anomaly, but the connection will not be stopped. Exceptions can be also configured on some properties of the Root CA certificate, such as key size, hashing algorithm, and issuer country. For example you can rise a warning if the certificate key length is lower that 2048 bit.

As a short test we can define a pinning policy that has following settings in CONFIGURE/CERTIFICATE TRUST/PINNING RULES/ADD:

• Name: TRUSTED.SSL
• Certificate: click and import GeoTrust
• Minimum Key Size: 2048
• Allowed Country: N/A
• Blocked Hash: MD2,MD4,MD5

Now go to Protected Web Site tab and add a site to test:

• Website: www.google.com
• Select the Pinning rule: TRUSTED.SSL
• be sure to check the Active checkbox

Well, this will ensure that Man in the middle attacks will generate an EMET agent warning message. Now if you like to test it just change a parameter in the pinning rule, like the key length from 2048 to 4096 or just change the Trusted Root CA.

After the changes try to access the site again and a message like this should pup up:

And the following entry inside the application log:

Conclusion

EMET is a powerful toolkit but need to be well configured and tested before going to production. Security on this level is pretty much the last layer of defense. We would recommend to use EMET to finalize your security strategy on very critical components like:

Invest time to create a policy that fits the specific machine usage; don’t try to. Once it’s done, you’ll get a very useful toolkit against Malware… and all for free!!

Andrea Covello | G+ (1623 words)

► 26.04.2013 – Blog Digest April 2013

• 2013 Information Security Survey (liebsoft.com)
• 8 tips for a security incident handling plan (nakedsecurity.sophos.com)
• Apple Finally Reveals How Long Siri Keeps Your Data (wired.com)
• Before you move to the cloud (resources.infosecinstitute.com)
• Debunking Myths: Penetration Testing is a Waste of Time (infosecisland.com)
• Dilbert comic strip for 04/07/2013 (dilbert.com)
• Fuzzers Need Taming (blog.regehr.org)
• Google Uses Reputation To Detect Malicious Downloads (darkreading.com)
• How Attackers Choose Which Vulnerabilities To Exploit (darkreading.com)
• If iOS is Less Secure, Why Does Android Get Attacked? (veracode.com)
• Inside VirusTotal’s pants: VirusTotal += PCAP Analyzer (blog.virustotal.com)
• Is security really dead? Perhaps it’s your lack of depth (nakedsecurity.sophos.com)
• Is Your Scanning Vendor Cheating? (infosecisland.com)
• It’s been an epic few days: What happened? (facebook.com)
• Making Patching Work for SCADA and ICS Security (tofinosecurity.com)
• Memory Safe C/C++: Time to Flip the Switch (blog.regehr.org)
• Metasploit 4.6.0 Released! (community.rapid7.com)
• Nmap Development: Hack Attack (seclists.org)
• Password reset questions (blogs.securiteam.com)
• Secrets of FBI Smartphone Surveillance Tool Revealed in Court Fight (wired.com)
• Security Professionals Embrace Not-So-Secure Mobile Work Habits (pingidentity.com)
• The Boston Marathon Bombing: Keep Calm and Carry On (theatlantic.com)
• The CISO’s Guide to Advanced Attackers (securosis.com)
• The WordPress Brute Force Attack Timeline (blog.sucuri.net)
• When Offense and Defense Become One (pen-testing.sans.org)
• xkcd: All Adobe Updates (xkcd.com)
• xkcd: Authorization (xkcd.com)

Marc Ruef | G+ (402 words)

► 18.04.2013 – Wie statisch sollten Sicherheitsrichtlinien sein?

Nebst den verschiedenen technischen Arbeiten in der Informatik, mag ich den Teil der IT-Philosophie. Das Wie und Warum hat mich schon seit jeher fasziniert und gerade die Informatik, als noch relativ junger Bereich, bietet viel Stoff für Fragen.

Auf der anderen Seite haben sich schon gewisse Meinungen etabliert, die ich zwar gerne hinterfrage, bei denen es aber fast nichts zu rütteln gibt. Ein Beispiel dafür ist, dass eine Firewall das interne Netzwerk vor Eindringlingen aus dem Internet schützt und deshalb unverzichtbar ist.

Solche Meinungen findet man dann meistens auch in den Sicherheitsrichtlinien der verschiedensten Firmen wieder. Was mich, vor allem als Engineer, immer wieder mal gestört hatte, war die Tatsache, dass Sicherheitsrichtlinien meistens nicht verhandelbar waren. Was mich wiederum zum Thema meines Artikels führt:

Wie statisch sollten Sicherheitsrichtlinien sein?

Der folgende Beitrag wiederspiegelt meine Gedanken zu diesem Thema und stellt eine von vielen Möglichkeiten dar, sich mit dem Thema Sicherheitsrichtlinie zu befassen. Es würde mich natürlich freuen wenn es dem einen oder anderen Leser als Gedankenanregung dienen würde.

Ausgangslage

In meinen nunmehr 15 Jahren, in denen ich im Bereich der Informatik tätig bin, habe ich die eine oder andere IT-Sicherheitsrichtlinie durchgelesen. Es ist immer wieder spannend zu sehen wie sich die Richtlinien von Firma zu Firma unterscheiden. Mal passen die Richtlinien auf eine A4-Seite, mal können sie im Umfang mit der Herr der Ringe-Trilogie konkurrieren. Meistens bewegt sich der Umfang aber in einem angemessenen Rahmen.

Über die Jahre wurden immer mehr Bereiche der Informatik in die internen Sicherheitsrichtlinien aufgenommen und durch sie geregelt. Eine der ersten und wohl am meist vorkommende ist, die Passwort Richtlinie. Nun frage ich Sie, wann wurde diese Richtlinie erstellt und wann und wie oft wurde sie geändert? Und was war der Grund für diese Änderung?

Ich denke mal dass die Häufigkeit der Änderungen sich eher im tiefen, einstelligen Bereich befindet. Und der Grund für die Änderungen waren wahrscheinlich neue Erkenntnisse Rund um das Thema Password Cracking. Aber gehören diese Änderungen in eine Sicherheitsrichtlinie?

Meiner Meinung nach definiert eine IT-Sicherheitsrichtlinie den grössten gemeinsamen Nenner der einzelnen Komponenten einer IT-Infrastruktur, womit ich die vorhergehende Frage verneinen würde. Ebenfalls sind Änderungen an der Sicherheitsrichtlinie meist mit langwierigen Prozessen verbunden, was ein schnelles Reagieren auf Änderungen erschwert.

Einflüsse auf die Sicherheitsrichtlinie

Wenn wir die verschiedenen Einflüsse auf die Sicherheitsrichtlinie anschauen, dann sehen wir, dass wir nicht immer nur von dem Bedürfnis den Betrieb sicherzustellen angetrieben werden. Je nach Branche kommen nebst regionalen Auflagen auch noch Bestimmungen durch Regulatoren hinzu.

Nehmen wir hier als Beispiel eine Schweizer Bank. Nebst den lokalen Datenschutzbestimmungen muss eine Schweizer Bank auch die Regulationen der FINMA einhalten. Tut sie dies nicht, kann es bis zum Entzug der Banklizenz kommen. Was die FINMA aber nicht macht, ist die Frage zu klären, wie etwas erreicht werden kann. Wenn die Frage des Wie nicht von der FINMA geklärt wird, warum sollte denn dieser Teil ein Bestandteil unserer Sicherheitsrichtlinie werden?

Das Passwortrichtlinien Beispiel

Kommen wir zurück zum Beispiel mit der Passwortrichtlinie. Haben Sie die obenstehende Frage zur Änderungshäufigkeit der Richtlinie mit mindestens ein Mal beantwortet, dann sind Sie eventuell verwundert, wenn ich Ihnen sage, dass diese Änderung nicht nötig gewesen wäre.

Wenn ich mich nämlich frage, warum ich eine Passwortrichtlinie habe, komme ich zum Schluss, dass es mir um eine sichere Anmeldung an dem jeweiligen System geht. Und dies wiederum resultiert aus dem Bedürfnis, dass nur autorisierte Benutzer auf die entsprechenden Ressourcen zugreifen dürfen. Wenn ich also ein Passwort wählen würde, das einfach zu erraten oder zu knacken wäre, würde ich mich der Gefahr aussetzten, dass unautorisierte Benutzer auf meine Ressourcen zugreifen könnten. Nun steigt die Rechenleistung eines Computers Jahr für Jahr an. Dies kann natürlich direkte Auswirkungen auf das Knacken eines Passworts haben. Was gestern noch als sicheres Passwort galt, kann heute schon als unsicher gelten. Sofort die Sicherheitsrichtlinie anpassen, oder doch nicht?

Eine Anmeldung mittels Passwort ist nur eine von mehreren Möglichkeiten, um einen Benutzer an einem System zu authentifizieren. Muss ich nun jede Möglichkeit einer Authentisierung in der Sicherheitsrichtlinie definieren?

Sowas gehört meiner Meinung nach, in diesem Beispiel, nicht in die Sicherheitsrichtlinie. Wenn die Richtlinie den grössten gemeinsamen Nenner definiert, könnte das in etwa so aussehen:

Der Zugriff auf eine IT-Ressource muss durch den Gebrauch eines sicheren Authentisierungsmechanismus gesichert werden.

Wenn man diese Richtlinie vor 20 Jahren so definiert hätte, sie hätte noch heute ihre Gültigkeit. Aber wo werden aber die Änderungen an der Definition von sicher abgehandelt?

Für diesen Zweck haben uns verschiedene Frameworks eine interessante Möglichkeit gegeben: Das Definieren von Controls. Ein Control ist ein Werkzeug, um das Einhalten der Richtlinien zu messen – vorzugsweise durch IT Auditors und IT Risk Manager. Bei dem Beispiel mit der Passwortrichtlinie, könnte ein einfacher Control in etwa so aussehen:

Wurde der Gebrauch eines sicheren Passwort durchgesetzt?

Nun kann man diesen Control mit der aktuellen Definition eines sicheren Passworts ergänzen. Dieser Control wäre einer von mehreren Controls, um die Richtlinie zu messen.

Eine noch elegantere Lösung wäre das Einführen einer zusätzlichen Ebene mit Unter-Controls. Der Control selbst würde einfach die Sicherheitsrichtlinie in die Frageform bringen:

Wurde die IT Ressource durch einen Authentisierungsmechanismus gesichert?

Und der Control betreffend dem sicheren Passwort würde zu einem Unter-Control.

Vor allem mit dem zweiten Ansatz erhalte ich eine hoch flexible Lösung, welche es mir ermöglicht, auf neue Gegebenheiten (Regulationen, Gesetze, Erkenntnisse im Bereich IT Sicherheit etc.) zu reagieren, indem ich bestehende Unter-Controls anpasse, ergänze oder entferne oder hinzufüge. Dies alles ohne nur einmal meine Sicherheitsrichtlinie zu ändern. Diese hohe Flexibilität ermöglicht es Security Engineers, schneller auf die neusten Entwicklungen zu reagieren und trotzdem gemäss den Sicherheitsrichtlinien zu handeln.

Fazit

Wenn man öfters die Sicherheitsrichtlinie anpassen muss, könnte man die nächste Änderung als Anlass nehmen, um die Richtlinie auf eine höhere Stufe zu bringen und dafür Controls definieren, die das Wie klären. Dies hilft die IT Sicherheitsrichtlinie selbst relativ statisch zu halten, was dazu beiträgt, eine Kontinuität in Bezug auf Sicherheit zu gewährleisten. Auf der anderen Seite hat man mit den Controls, die Flexibilität schnell auf Änderungen in der schnelllebigen Welt der Regulationen und Sicherheitsansprüche zu reagieren, ohne immer gleich das ganze Sicherheitskonzept zu überdenken.

Pascal Schaufelberger | G+ (1108 words)

► 11.04.2013 – Timing für effiziente unentdeckte Portscans

Im Rahmen eines Penetration Tests wurden an uns eher spezielle Anforderungen gestellt:

Die Zugriffe sollten möglichst effizient durchgeführt werden, ohne dadurch auf den Systemen eine Alarmierung auszulösen.

Da die Infrastruktur nicht durch den Kunden selbst, sondern durch einen externen Partner betreut wurde und dieser in das Security Testing nicht involviert werden sollte, wussten wir nicht um das ideale Timing-Verhalten für unsere Zugriffe. Doch ein solches sollte von zentraler Wichtigkeit sein, um automatisierte Zugriffe während einer frühen Phase der Auswertung durchführen zu können. Wir sahen uns also mit diametral entgegengesetzten Bedürfnissen konfrontiert:

Effizienz gegen Unentdeckbarkeit

Recherche

Um unsere Zugriffsmöglichkeiten bestmöglich abstecken zu können, haben wir uns deshalb um das Zusammentragen von Informationen zur Erkennung von vielen Zugriffen (typischerweise in Form eines Portscans oder Floodings) bemüht. Dabei definiert sich der entsprechende Threshold aus zwei Werten:

• Anzahl Zugriffe
• pro Zeiteinheit (in der Regel Sekunden)

Um diese Daten für bekannte Produkte finden zu können, wurden verschiedene Quellen genutzt:

• Dokumentation (Online Help, Handbücher, Screenshots)
• Testing (Download und Installation)
• Quelltext (falls vorhanden, z.B. Snort)
• Diskussionen (Foren, eher unzuverlässig)

Resultate

Die folgende Tabelle zeigt die Zugriffe (Req) pro Sekunde (Sec). Um einen vereinheitlichten Vergleich gewährleisten zu können, werden in der letzten Spalte mit nR/1S die Anzahl Zugriffe (nR) pro Sekunde (1S) ausgewiesen. Der arithmetische Durchschnitt dieses Werts liegt bei 85.928.

Bei dieser Recherche fielen verschiedene Aspekte auf, die die Arbeit nicht gerade einfacher gestaltet haben:

• Viele Produkte bieten eine Port Scan Detection an, erlauben aber lediglich das Aktivieren/Deaktivieren dieser Funktion, ohne Details oder Möglichkeiten granularer Einstellungen (Zugriffe/Sekunden) anzubieten.

• Gewisse Hersteller, die für das Aufkaufen anderer Firmen und Produkte bekannt sind, weisen über die unterschiedlichen Produktpaletten eine sehr inkonsistente Grundeinstellung auf. Hierzu zählt beispielsweise Juniper. Ganz im Gegenteil dazu wartet Checkpoint mit sehr einheitlichen Werten auf (30 Zugriffe / 20 Sekunden).

• Die verschiedenen Hersteller pflegen unterschiedliche Zeiteinheiten für die Prüfung heranzuziehen. Kurze Backlogs gewähren eine hohe Performance und lange Backlogs erreichen eine hohe Erkennungsrate für langwierige Scans. Die gefundenen Zeiteinheiten reichen von 0.3 Sekunden (Sophos) bis 10 Minuten (Inmon Traffic Sentinel). Produkte mit extrem langen Zeiteinheiten (im Stundenbereich) haben wir in der statistischen Auswertung explizit ausgeklammert.

Fazit

Als verlässlichen Richtwert für den Threshold einer Port Scan Detection gilt der Standardwert der Checkpoint Produkte. Dort wird bei 30 Anfragen innert 20 Sekunden aufgeschlagen. Dies ergibt einen maximalen Durschnitt von 1.5 Paketen pro Sekunde, was ebenfalls dem Median der vorliegenden Werte entspricht.

Sieht man sich also mit den gleichen paradoxen Anforderungen konfrontiert, wie im Rahmen unseres Projekts, sollte man ca. 1.3 Pakete pro Sekunde anstreben, um einer Entdeckung und Alarmierung zu entgehen. Die Abweichung von 0.2 wird hier als Puffer gewählt, um der Entdeckung auch ganz sicher entgehen zu können. Bei einem Einsatz von nmap wird entsprechend der Schalter —max-rate 1.3 genutzt, um diesen Anforderungen gerecht werden zu können.

Diese Betrachtung ist natürlich nur in der Lage, die Standardeinstellungen eines Produkts zu berücksichtigen. Die weiterführenden Empfehlungen von Herstellern, Kunden und Experten sowie die effektiv applizierten Einstellungen müssen natürlich in ihrer individuellen Weise berücksichtigt werden.

Marc Ruef | G+ und Oliver Kunz | G+ (622 words)

► 05.04.2013 – Interpreting a Logfile with Grok

We have a BSM audit log, iptable log, Apache, smbd_audit log. How can we normalize the useful information and extract/correlate what we need? A small piece of software can make our life easier: Grok.

The Problem

Interpreting a logfile means to extract the information we need and ignore the rest.

For data transferred via syslog, the field data has no strictly predefined format and can also contain any data type in any order.

The number of existing log formats is around 800, each application logs specific information in proprietary formats; sometimes even the same application uses different formats for different events.

Pure Regular Expressions

With regular expressions it is possible to parse all possible sequences of chars; getting a result is just a question of practice and time (to test), but it can become a nightmare very quickly.

Take for example the parsing of a common IPv4 address: 192.168.1.2

At first look we can write a simple regexp like

\b\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}\b;

Does this regexp grep all IP addresses? Yes, but it also greps a lot of non-IP addresses; in particular all combinations above 255.255.255.255.

We can go further and create a smarter regexp to grep only valid IPs; specifically: the regexp should parse the following valid sequences:

1. 25 followed 0-5
2. 2 followed by 0-4 0-9
3. A possible – but not necessary – 0 or 1 followed by 0-9 and an optional 0-9
4. This must happen 4 times separated by a dot

Just straightforward, but once coded it looks like:

\b(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\b

And that’s just for an IP address!

Debugging and maintaining such monster regular expression can result in
a lot of wasted time.

Using Grok

Grok is a little nice tool that makes regular expressions easier to manage and helps to turn unstructured log and event data into structured data. It is a great tool for parsing log data and program output. You can match any number of complex patterns on any number of inputs (processes and files) and get custom reactions.

You can look at it as a template engine with a lot of predefined and usable (tested) regular expressions, simply accessible through an alias.

Looking at the Grok regexp database we find many predefined regexp with which we can manipulate the most of the log messages format.

Using Grok, if we need to parse an IP address, a valid one, we just specify %{IP}; Grok looks up own regexp library for an IP alias and translates in following monster-regexp:

(?<![0-9])(??:25[0-5]|2[0-4][0-9]|[0-1]?[0-9]{1,2})[.](?:25[0-5]|2[0-4][0-9]|[0-1]?[0-9]{1,2})[.](?:25[0-5]|2[0-4][0-9]|[0-1]?[0-9]{1,2})[.](?:25[0-5]|2[0-4][0-9]|[0-1]?[0-9]{1,2}))(?![0-9])

For example look at the following log line:

Nov  1 21:14:23 scorn kernel: pid 84558 (expect), uid 30206: exited on signal 3

We are interested in timestamp, pid, program-name, uid and exit-signal. We want ignore the message exited on signal and all other human-helps like pid, uid etc.

In Grok, this pattern looks like:

%{SYSLOGBASE} pid %{NUMBERid} \(%{WORDrogram}\), uid %{NUMBER:uid}:exited on signal %{NUMBER:signal}

Straightforward, human-readable, efficient.

Summary

I stumbled on Grok thanks to Logstash and it was love at first run. Writing filters is as simple and straightforward as writing a normal text. Debugging was never so easy. It is possible to use Grok within several languages and/or tools. It is also easy to expand and use as a general parsing instrument.

Rocco Gagliardi | G+ (611 words)

► 03.04.2013 – Spamhaus DDoS mit DNS Amplification

In der letzten Woche wurde viel über den Angriff auf die in Genf und London lokalisierte Organisation Spamhaus geschrieben. Bei gewissen Schlagzeilen hatte man bereits das Gefühl, die Digitale-Welt geht unter.

Was macht Spamhaus

Spamhaus bietet verschiedene Anti-Spam Blacklist und Whitelist Lösungen an. Es handelt sich um eine international ausgerichtete NPO mit dem Ziel, den Spam-Organisationen das Leben schwer zu machen. In diesem Sinne arbeiten sie auch mit Strafverfolgungsbehörden zusammen und lobbyieren in Regierungen für eine effektive Gesetzessprechung. Gemäss eigenen angaben sind Sie verantwortlich für einen Grossteil des zurückgehaltenen Spams und schützen über 1.7 Mia. Mailboxen.

Wer sind die Gegenspieler

Die Gegenspieler von Spamhaus sind die verantwortlichen der unerwünschten Post. Wir können uns diese als verschiedene Organisationen vorstellen, welche als Interesse haben, so viele Spam-Nachrichten wie möglich in den Mailboxen zu deponieren. Mit jeder erfolgreich deponierten E-Mail können Sie ihren Marktwert, den Marktwert des Produktes und dessen Absatz steigern. Es ist davon auszugehen, dass sie zum wesentlichen auch (oder nur) durch den Produktabsatz finanziert werden. Eine Organisation wie Spamhaus schmälert ihren Gewinn.

Aber nicht nur Spam-Organsisationen landen auf der Blacklist von Anti-Spam Anbietern. Es kann durchaus auch vorkommen, dass Domains und Mailserver von Organisationen auf einer Blacklist landen. Beispielsweise kann dies passieren, wenn ein Unternehmen regelmässige Newsletter im grossen Stil versendet und dies auch an E-Mailadressen, welche über keine Mailbox mehr verfügen. Für Mailhoster sind diese E-Mails lästig. Können sie Mails nicht an eine Mailbox weiterleiten, handelt es sich für sie um Spam. Wird dies an einen Blacklist-Verwalter weitergeleitet, landet man auf einer Blacklist.

Ein anderer, nicht unerheblicher Weg auf eine Blacklist ist der Einkauf von Mailadress-Listen. Beinhaltet diese eine Honeypot-Adresse landet man in der Regel direkt in der Blackliste. Unschön dabei ist, jeder der diese Blacklist verwendet, flaggt diese E-Mail als Spam oder im schlimmsten Fall leitet sie gar nicht in die Mailbox weiter.

Die Problematik und Kritik hinter solchen Blacklists ist, dass es sich im eigentlichen Sinn um ein Zensursystem handelt. Gemäss einem Statement von Spamhaus, haben auch sie selbstverständlich die gesetzlichen Rahmenbedingungen einzuhalten und gegenüber ihren Kunden Rechenschaft abzulegen. Diese würden ungewollte Blockaden kaum im grösseren Stil und über eine längere Zeit goutieren.

Attacke auf Spamhaus

Dies war nicht die erste Attacke, welcher Spamhaus ausgesetzt war (bzw. ist). In 2003 wurde bereits ein grösserer DDoS-Angriff lanciert. Betroffen waren auch andere Anti-Spam Anbieter. Spamhaus hatte diesen Angriff gemäss einem Statement auf ihrer Website relativ unbeschadet überstanden.

Für eine Organisation wie Spamhaus gilt, sie sind ständig einem Angriff oder dem hohen Potential ausgesetzt, dies gehört zu ihrem Business dazu. Umso bemerkenswerter ist die Aufmerksamkeit, die diesem jüngsten Angriff beigemessen wird.

Der Angriff begann am 18. März 2013. Das Spamhaus-Team wandte sich an CloudFlare (ein CDN Anbieter), da ihre Internetanbindung bald überlastet und die Systeme somit offline waren. Durch das Einschalten von CloudFlare kamen die Services von Spamhaus bald wieder online. CloudFlare veröffentlichte daraufhin verschiedene Informationen zum Angriff in ihrem Blog. Die Abbildung 1 stammt von einem System von CloudFlare und stellt das Verkehrsvolumen dar, welches sie über alle Kunden feststellen. Es ist also nicht der gesamte Traffic der Spamhaus-Attacke zuzuschreiben.

(Abbildung 1, Quelle: blog.cloudflare.com)

(Abbildung 2, Quelle: blog.cloudflare.com)

• Erste Angriffswelle mit einem Verkehrsvolumen von ca. 10Gbps
• 19.03.2013 16:30 UTC; Erster Peak als CloudFlare übernahm (Grafik 1)
• 19.03.2013 21:30 UTC: CloudFlare registriert ein enorm hohes Verkehrsaufkommen (Abbildung 1)
• Angriff lief weiter bis 21.03.2013 01:15 UTC (Verkerhsvolumen ca. 30-90 Gbps)
• Ruhetag bis 22.03.2013 18:00 UTC; Neuer Angriff über 4h mit Werten um 120 Gbps
• Angriffe auf Netzinfrastruktur; z.B. LINX: ca. 300 Gbps (Abbildung 2)

Auswirkungen

Aus dem Angriff hat man sicher einiges gelernt. Einerseits, welches Potential in einer DNS Amplification Attack steckt. Andererseits, wie man reagieren und was man verbessern kann.

Das Internet kollabierte jedoch nicht. Ich habe auch von niemandem in der Schweiz gehört, der eine signifikante Verlangsamung des Netzes bemerkt hatte. Die Abbildung 2 zeigt, dass es am London Internet Exchange (LINX) zu einem Drop im Traffic kam, der auf die Attacke zurückführbar wäre. Auswirkungen hatten also vor allem jene, welche über den LINX routen. Anhand der Grafik würde ich dies aber nicht als dramatisch bezeichnen.

DNS Amplification Attack

Eine Amplification Attack zielt darauf ab, mit der eingesetzten Bandbreite eine höhere Bandbreite beim Angriffsziel zu belegen. Als Beispiel nehmen wir an, der Angreifer A kontrolliert ein Botnet mit einem Upstream von 1Gbit/s und möchte aber Verkehr grösser als 1Gbit/s generieren um B zu attackieren. A handelt nach dem Maximalprinzip der Betriebswirtschaftslehre. Sein Ziel: Mit seinen Mitteln möchte er den Output maximieren.

Kriterien

Wie im vorliegenden Fall kann man zwei Kriterien für eine erfolgreiche Amplification Attack identifizieren:

• Grössenunterschied Anfrage/Antwort: A benötigt ein Weg, wie seine Anfrage eine grössere Antwort generiert. Je grösser das Verhältnis zwischen Anfrage und Antwort ist, desto besser erfüllt er das Maximalprinzip. Im Fall von Spamhaus wurde DNS verwendet. Der Request dig ANY iana.org x.x.x.x@ ist 64 Byte lang und generiert eine 2689 Byte lange Antwort. Die Antwort ist um mehr als das vierzigfache grösser als die Anfrage. A kann bei der Verwendung mit der Verwendung von DNS seinen Output leicht maximieren.

• Spoofing: Die Antwort auf A’s Anfrage sollte nicht zurückkommen, sondern an B geleitet werden. Andernfalls blockiert er sich selbst, da die angesprochenen grossen Antworten auch auf ihn zurückkämen. Durch IP-Spoofing kann A die IP-Adresse von B als Quelladresse definieren. Der DNS-Server wird seine Antwort nicht mehr an A retournieren, sondern an B. Protokolle, welche by Design kein Handshake durchführen, ermöglichen grundsätzlich Spoofing. Hier zu nennen ist UDP, das als statusloses Protokoll interessiert es nicht ob die Anfrage von einer korrekten Stelle kommt.

Public DNS-Server

Normalerweise konfiguriert ein ISP seinen DNS-Server so, dass nur Zugriffe aus seinem eigenen Netz beantwortet werden. Es gibt jedoch genügend DNS-Server, welche diese Einschränkung nicht kennen. Sei es da bei der Konfiguration Fehler gemacht wurden, oder dass der Betreiber dies bewusst zulassen möchte. Das Open DNS Resolver Project sammelte über 27 Millionen offene DNS-Server. A nutzt nun diese public (offenen) DNS-Server und sendet vielen von ihnen Anfragen mit einer gespooften Quelladresse von B. Die DNS-Server senden ihre Antwort daraufhin an B zurück und füllen die verfügbare Bandbreite aus.

DNSSEC

Amplification Attacken sind eigentlich nichts Neues. Was jedoch neu ist, ist die Effizienzsteigerung durch die Verwendung von DNS. Dies ist wohl nicht zuletzt der sicherheitsrelevanten Erweiterung DNSSEC zu verdanken. Durch die Verwendung von DNSSEC wurden neue Record Types definiert RRSIG (Resource Record Signature) und DNSKEY beide Enthalten Base64 encodierte Informationen, welche um einiges grösser sind, als die ursprünglichen DNS Records. Je mehr DNSSEC Informationen eine Zone enthält, desto grösser werden die Responses sein. In unserem Beispiel möchte daher A Zonen mit möglichst vielen und vor allem DNSSEC relevanten Einträgen erhalten.

Mögliche Lösung

Amplification Attacken, die seit den 90er Jahren existieren, wird es wohl auch weiterhin geben. Das Problem dahinter ist simpel. Gewisse Protokolle erfüllen einfach die oben genannten Kriterien und sie auf TCP umzustellen würde einen enormer Overhead bedeuten. Konkret auf DNS Amplification bezogen gibt es durchaus einen Ansatz, um gegen diese Vorzugehen.

Es ist kaum vorstellbar, dass die verfügbaren offenen DNS-Server alle diese Funktionalität aufweisen sollten. Vielmehr handelt es sich dabei wohl um Fehlkonfigurationen des DNS-Servers. Aus welchem Grund sollte der DNS-Server einer Firma Anfragen aus fremden Netzwerken verarbeiten? CloudFlare veröffentlichte in einem Blogpost eine Liste mit den von Ihnen am meist gesehenen öffentlichen DNS-Resolvern und einem Konfigurationshinweis für ISC BIND, um diese zu schliessen. Würden also die DNS-Server Betreiber ihre Konfiguration weniger offen gestalten, wäre ein erster und effektiver Schritt gemacht. In Zukunft könnte ein Angreifer nicht mehr auf die DNS Infrastruktur zurückgreifen.

Fazit

Der Vorfall bei Spamhaus hat gezeigt, dass mit der richtigen Methode effizient eine DDoS-Attacke ausgeführt werden kann, ohne ein teures, grosses Botnet zu unterhalten. Der Vorfall hat aber auch gezeigt, dass die Infrastruktur und vor allem die Betreiber einen solchen Angriff ohne grössere Probleme abwenden können.

Dass DDoS Attacken in diesem Ausmass möglich sind, verdanken wir wohl nicht zuletzt der laschen Konfiguration der DNS-Server. Es gibt Lösungen, um das Problem einzudämmen und den Angreiffern in ihren Mitteln zu beschränken. Wir dürfen aber nicht vergessen, dass das Abschalten von Public DNS-Servern auch zu einem Problem führen kann. Der Benutzer ist nicht mehr frei in der Wahl seines DNS-Servers und muss sich auf jenen seines Netzbetreibers verlassen. Fallen diese aus, kann er keine Domainnamen mehr auflösen. In der Regel betreiben die Netzbetreiber diese redundant, was das Risiko des Totalausfalls miniert. Durch das Management des DNS-Servers kann aber auch kontrolliert werden, was die entsprechenden Benutzer seines Dienstes auflösen können. Demzufolge wäre eine Internet-Zensur leichter durchzusetzen.

Oliver Kunz | G+ (1622 words)

All Postings

• Latest Postings
  • Sicherheitsverantwortlichkeiten und Risikosteuerung
  • Computer Forensik – Ein Überblick
  • Vortrag zu Security Testing an SGRP Veranstaltung
  • Staatstrojaner – Kritik am neuen Bundesgesetz
  • Overview of Microsoft’s security toolkit EMET
  • Blog Digest April 2013
  • Wie statisch sollten Sicherheitsrichtlinien sein?
  • Timing für effiziente unentdeckte Portscans
  • Interpreting a Logfile with Grok
  • Spamhaus DDoS mit DNS Amplification
• Archive
  • 2013 | 2012 | 2011 | 2010 | 2009 |

• Blog Digest

• Blogroll
  • abuse.ch
  • c22.cc
  • computec.ch
  • darkreading.com
  • infosecisland.com
  • krebsonsecurity
  • metasploit.com
  • schneier.com
  • securiteam.com
  • stfn.ch
  • zeltser.com
  • 5e4n.ch
• Syndication
  • RSS
  • Twitter