• Über uns
    • Dominik Sauer
    • Patrick Sauer
  • Kategorien
    • binsec
    • Datenschutz
    • Informationssicherheit
    • IT-Forensik
    • IT-Sicherheit
    • Netzpolitik
    • PCI DSS
    • Pentest
    • Presse
    • Studium
    • Unkategorisiert
    • Vorlesung
      • HDA
      • THB
    • Vorträge
    • Zertifizierung
  • Lehrveranstaltungen
    • Hochschule Darmstadt (HDA)
      • Internet-Sicherheit
      • IT-Sicherheitsmanagement & Compliance
      • Penetration Testing
      • Security of Web Applications
    • Technische Hochschule Brandenburg (THB)
      • PCI DSS
    • Technische Hochschule Mittelhessen (THM)
      • WK_2620 Secure Coding
      • WK_2621 Penetration Testing
      • WK_2622 Digitale Forensik
  • Impressum / Datenschutzerklärung
InfoSec Blog | Patrick Sauer & Dominik Sauer

Blog - IT Security - Pentest - Fun

Erfolgsfaktoren für den PCI DSS Audit und die Zertifizierung

22. August 2013 by Patrick Sauer Leave a Comment

Um Audits erfolgreich und möglichst schnell abzuwickeln, benötigt man

  • einen guten Auditor, der viel Erfahrung im Bereich Security besitzt und auch vor technischen Diskussionen nicht zurückschreckt.
  • eine interne zuständige Person, die PCI DSS kennt, versteht und ausreichend Erfahrung mit dem Standard hat. Idealerweise einen CISO mit sehr starkem technischen Hintergrund. Alternativ einfach das Know-How von außen einkaufen und dabei auf eine CISSP-Zertifizierung achten. Der Berater muss aber nicht nur PCI DSS verstehen, sondern auch Security mit Business kombinieren können.
  • eine Reduzierung des Scopes. In der Regel ist es sehr ungünstig, wenn alle Bereiche eines Unternehmens unter PCI DSS fallen. Das erhöht nicht nur den Dokumentationsaufwand, sondern verringert auch die allgemeine Produktivität.
  • Unterstützung vom Management. Ohne Unterstützung von oben geht es nicht. Eine PCI-Zertifizierung kostet nicht nur Geld, sondern wird im Unternehmen am Anfang garantiert unbequem sein. PCI DSS hat in der Praxis nicht den besten Ruf und es gibt zugegeben angenehmere Zertifizierungen. Insbesondere Softwareentwickler scheinen PCI DSS schnell als Feindbild zu sehen. Das muss nicht sein.
  • Sicherheit als kontinuierlichen Prozess. Vor dem Audit ist nach dem Audit. PCI DSS hört nicht nach dem Audit auf, und fängt nicht zum nächsten Audit wieder an. Beim ersten Audit muss man weniger nachweisen, dass man „pci lebt“. Beim zweiten sollte man besser nicht wieder von vorne anfangen. Hierzu werden Prozesse notwendig sein. Mitarbeiter müssen mitgenommen werden. Ohne eine Person, die hierfür explizit die Zuständigkeit besitzt, wird der nächst Audit meist so schwierig wie der erste.
  • eine gute Vorbereitung. Man sollte bereits vor dem eigentlichen Audit wissen, ob alles compliant ist und wenn nicht, wo die eigenen Schwachstellen liegen.
Posted in: PCI DSS Tagged: Audit, Compliance, QSA

Navigating PCI DSS

22. August 2013 by Patrick Sauer Leave a Comment

Wer PCI DSS nicht kennt, aber plötzlich davon betroffen ist, sollte sich das Dokument Navigating PCI DSS von der offiziellen Website des PCI Security Standards Council herunterladen. Es lohnt sich. Im eigentlichen PCI DSS Dokument werden nur Anforderungen und Testprozeduren definiert. In Navigating PCI DSS wird erklärt, was überhaupt mit den einzelnen Anforderungen erreicht werden soll. PCI DSS zu verstehen ist das A und O bei einem Audit: Das Dokument Navigating PCI DSS hilft dabei.

Posted in: PCI DSS Tagged: Audit, Compliance, Requirement

Wie man unsichere Software schreibt

21. August 2013 by Patrick Sauer Leave a Comment

Wie schreibt man unsichere Software? Nichts einfacher als das:

  1. Anforderungen an die Software nicht schriftlich festhalten. Somit kann man auch gar nicht in die Verlegenheit kommen, Sicherheitsanforderungen definieren zu müssen.
  2. Tests sind etwas für Weicheier. Ohne Sicherheitsanforderungen braucht man Sicherheit ohnehin nicht zu testen. Sie ist schließlich kein zwingender Bestandteil einer Software.
  3. Code-Review ist viel zu aufwendig und kostet nur Arbeitszeit. Echte Männer und Frauen schreiben sofort guten und sicheren Code. Alle anderen sind einfach unfähig.
  4. Penetration Tests sind zu teuer. Wer schon einmal einen in Auftrag gegeben hat, weiß das. Software reift ohnehin beim Kunden. Die Penetration Tests übernehmen somit die Angreifer kostenlos.
  5. Weiterbildungen im Bereich sicherer Softwareentwicklung braucht niemand. Know-how hat man, oder man hat es nicht. Basta.

Die Umsetzung der fünf Punkte erfolgt auf eigene Gefahr ;-).

Posted in: Informationssicherheit Tagged: Ironie

Erfahrungen zum Studiengang Master of Science in Security Management an der FH Brandenburg – Teil 9: Lohnt sich das Studium?

21. August 2013 by Patrick Sauer Leave a Comment

Ob sich das Studium lohnt, hängt natürlich vom individuellen Fall ab. Ich versuche die Fragestellung von der anderen Seite anzugehen. Für wen lohnt es sich nicht? Für alle, die einen CISSP, CISM, CISA, TISP usw. besitzen und keinen Master als weiteren Abschluss benötigen. Es ist ganz klar, auch ein aufbauendes Studium richtet sich nicht an Professionals. Im Umkehrschluss kann es sich für alle lohnen, die nach einem Diplom oder Bachelor noch einen Master machen möchten und eine formale Qualifikation im Bereich Security Management  anstreben.

Dennoch muss man klar sagen, dass man im Sicherheitsumfeld Berufserfahrung benötigt. Ein Abschluss kann helfen, muss aber nicht. Ich halte es für unwahrscheinlich, dass ein Absolvent des Studiums Security Management ohne mindestens ein paar Jahre Berufserfahrung in die Position eines CISOs mit Verantwortung kommt. Ausnahmen bestätigen sicherlich die Regel. Und es gibt immer noch genug Unternehmen in Deutschland, bei denen „Studierte“ höher angesehen werden als „Praktiker“. Für realistischer halte ich eher eine fachliche Mitarbeit in einer größeren Security-Abteilung. Aber auch für einen tieferen Einstieg in den Bereich IT-Security wie z.B. Penetration Testing kann das Studium sinnvoll sein. Man sollte dann eben seine Semesterarbeiten, die Projektarbeit und die Master-Thesis geschickt wählen.

Ich selbst trug bereits zu meinem Beginn des Studiums die Verantwortung für den Bereich Security & PCI-Compliance bei einem internationalen Internet Payment Service Provider in Frankfurt. Fachlich hat mir das Studium dennoch weitergeholfen und ich würde es nochmal machen. Einzig negativ ist der mit einem Studium verbundene extrem hohe Aufwand. Dagegen ist die Vorbereitung für die CISSP-Prüfung ein Witz. Den persönlichen Aufwand sollte man am besten vor der Immatrikulation abschätzen. Einen Master gibt es weder ohne großen Aufwand noch umsonst. Wer neben einer Vollzeitstelle einen Master of Science in Security Management anstrebt, kann seiner Freizeit für einige Zeit lebe wohl sagen. Lohnen kann es sich natürlich trotzdem ;-).

Posted in: Studium Tagged: Erfahrungsbericht, FH Brandenburg, Master

Erfahrungen zum Studiengang Master of Science in Security Management an der FH Brandenburg – Teil 8: Vorkenntnisse

20. August 2013 by Patrick Sauer Leave a Comment

Im Studium werden bei den Studenten keine speziellen Vorkenntnisse voraus gesetzt. In allen Vorlesungen steigt man inhaltlich am Anfang ein und steigert sich mal mehr, mal weniger schnell. Soweit entspricht das auch den üblichen Erwartungen an ein Studium. Security Management ist vom Schwierigkeitsgrad ähnlich mit Wirtschaftsinformatik zu vergleichen.

Security Management wird an der FH Brandenburg ganzheitlich gelehrt, d.h. es handelt sich im Studium nicht primär um IT-Security. So werden alle Aspekte von IT-Security bis Gebäudesicherheit behandelt. Komplett ohne grundlegende IT-Kenntnisse wird es dennoch schwierig, bei Vorlesungen wie Netzwerksicherheit mitzuhalten. Wer z.B. den Unterschied von tcp zu udp kennt, wird in ein paar Fächern einen Vorteil besitzen. Voraussetzung für das Studium ist es aber nicht. Ich habe Studenten gesehen, die nicht wie viele aus der IT-Ecke kamen und das Studium trotzdem erfolgreich abgeschlossen haben. Man sollte sich also davon nicht abschrecken lassen.

Abgesehen von IT gibt es noch einen Bereich, in dem Vorkenntnisse helfen: Wissenschaftliches Arbeiten. Anscheinend – und ich nehme mein vorheriges Studium nicht aus – scheint das Schreiben wissenschaftlicher Arbeiten an manchen Hochschulen bzw. Studiengängen keine große Relevanz zu besitzen. Schlimm. In diesem Master-Studium muss man mindestens zwei wissenschaftliche Arbeiten schreiben: Semesterarbeit 1 und 2. Dazu kommt noch die Projektarbeit und bei mir eine umfangreiche Arbeit für die Vorlesung Recht. Man muss sich hier schon anstrengen, um bei seiner Master-Thesis immer noch grundlegende Fehler beim wissenschaftlichen Arbeiten zu machen. Wenn man das wissenschaftliche Schreiben bereits bei seinem Diplom oder Bachelor gelernt hat, wird das von Vorteil sein. Leider ist das meiner Erfahrung nach nicht die Regel.

Posted in: Studium Tagged: Erfahrungsbericht, FH Brandenburg, Master

Threema: Sichere Alternative zu WhatsApp

20. August 2013 by Patrick Sauer 1 Comment

Nachdem Whistle.im ein gutes Beispiel dafür ist, wie man Verschlüsselungstechniken nicht in der Praxis umsetzt, scheint es hingegen bei Threema gelungen zu sein: Threema setzt eine Ende-zu-Ende-Verschlüsselung ein, bei der die kryptographischen Schlüssel auf dem Endgerät des Benutzers liegen. Die Entwickler von Whistle.im sind im Gegensatz dazu auf die wahnsinnige Idee gekommen, alle Schlüssel zentral auf ihren eigenen Servern zu speichern.

Threema ist leider nicht Open Source, sodass man nicht wie bei Whistle.im zur Analyse den kompletten Zugriff auf den  Quelltexts besitzt. Ausgehend von den offiziellen Informationen von Threema scheint das Sicherheitskonzept durchdacht zu sein. Threema generiert das eigene Schlüsselpaar lokal und geheime Schlüssel werden niemals übertragen. Besonders gut finde ich die drei verschiedenen Stufen, in denen die Echtheit des Absenders eingeteilt wird. Die höchste Sicherheitsstufe erreicht man, wenn man dem Absender zuvor persönlich begegnet ist und die beiden beteiligten Smartphones sich per QR-Code verifiziert haben. Ein persönliches Treffen ist jedoch nicht zwingend Voraussetzung für eine verschlüsselte Kommunikation.

Die verwendeten kryptographischen Verfahren dürften als sicher angesehen werden. Die schlimmsten Fehler entstehen im Einsatz von Krypto wie bei Whistle.im eher im grundsätzlichen Design einer Anwendung. Solange man nicht auf die blöde Idee kommt, kryptographische Verfahren selbst zu implementieren, sollte man auf der sicheren Seite sein. Das ist ohnehin weder bei Whistle.im noch bei Threema der Fall. Dafür ist die Sicherheit in Whistle.im broken by design.

Ausgehend von den vorliegenden Informationen, kann man Threema als sicher betrachten. Die Verschlüsselung wird eher nicht angreifbar sein. Der einzige offensichtlich mögliche Angriffsvektor besteht in der Applikation selbst: Ist sie nicht Open Source, lässt sich nur sehr schwer nachvollziehen, was im Hintergrund passiert. In wie weit man ihr vertraut, muss jeder selbst wissen. Sicherer als WhatsApp oder das security broken by design Whistle.im wird es sein.

Posted in: IT-Sicherheit Tagged: Instant Messaging, Kryptografie, Threema, Verschlüsselung, Whistle

Whistle.im ist unsicher

19. August 2013 by Patrick Sauer Leave a Comment

Whistle.im soll eine sichere Alternative zu WhatsApp sein. Whistle wirbt mit der Aussage: „Sichere Sofortnachrichten. Made in Germany.“ Wir wissen ja auch dank Wirtschaftsminister Rösler, dass wir bei Verschlüsselungstechnologien einen technischen Vorsprung besitzen.

Leider ist es total blöd, dass sich jemand mit Know-How Whistle angesehen hat: Die Jungs vom CCC Hannover. Sofern die beschriebene Analyse dort auch nur einen Funken Wahrheit besitzt, kann man auch gleich weiter WhatsApp benutzen. Whistle ist unsicher und offenbar wurden grundsätzliche Prinzipien beim Einsatz von Verschlüsselungstechnologien nicht beachtet. Ein gutes Beispiel für jeden Anwendungsentwickler, wie man Kryptographie nicht einsetzt. Sicherheit ist etwas anderes. Die Analyse vom CCC ist absolut lesenswert.

Posted in: IT-Sicherheit Tagged: CCC, Instant Messaging, Kryptografie, Schwachstelle, Verschlüsselung, Whistle

PCI DSS Requirement 8.5.9 bei Endkundenzugängen

19. August 2013 by Patrick Sauer Leave a Comment

Die PCI DSS Anforderung 8.5.9 besagt, dass Benutzerpasswörter mindestens alle 90 Tage gewechselt werden müssen. Unter Requirement 8 existiert jedoch eine Notiz im Standard, die den Umfang der Anwendbarkeit präzisiert:

„Note: These requirements are applicable for all accounts, including point of sale accounts, with administrative capabilities and all accounts used to view or access cardholder data or to access systems with cardholder data. However, Requirements 8.1, 8.2 and 8.5.8 through 8.5.15 are not intended to apply to user accounts within a point of sale payment application that only have access to one card number at a time in order to facilitate a single transaction (such as cashier accounts).”

Hier wird u.a. die Anwendbarkeit der Anforderung 8.5.9 deutlich eingeschränkt. Exakt beschreibt der Hinweis im Standard dennoch nicht, wie mit Accounts von Endkunden verfahren werden soll. Hier hilft die zweite Testing Procedure zur Anforderung 8.5.9 etwas weiter:

„For service providers only, review internal processes and customer/user documentation to verify that non-consumer user passwords are required to change periodically and that non-consumer users are given guidance as to when, and under what circumstances, passwords must change.”

Hierdurch wird nun klar, dass sich die Prüfung der 90-Tage-Regelung primär an „non-consumer user passwords“ richtet. Kombiniert man die zuvor zitierte Notiz inhaltlich mit der zweiten Testprozedur der Anforderung 8.5.9, richtet sich der Zwang zur Änderung eines Passworts alle 90 Tage primär nicht an Benutzer-Accounts von Endkunden. Nachdem Endkunden keinen Zugang zu Kreditkatendaten besitzen (z.B. bei Amazon, Paypal), weder zu anderen noch zur eigenen, besteht kein Risiko für einen Diebstahl von Kreditkartendaten. Das PCI DSS Requirement 8.5.9 zum Wechsel des Passworts alle 90 Tage findet hier keine Anwendung.

Posted in: PCI DSS Tagged: Compliance, Passwörter, Requirement

Erfahrungen zum Studiengang Master of Science in Security Management an der FH Brandenburg – Teil 7: Der E-Mail-Verteiler

18. August 2013 by Patrick Sauer Leave a Comment

Ich bekomme eigentlich genug E-Mails, privat sowie beruflich. Auch über SPAM kann ich mich nicht beschweren, meine Filter haben genug zu tun. Sobald man an der FH Brandenburg studiert, erhöht sich das Mailaufkommen nochmals. Und zwar subjektiv gefühlt enorm. Es kommen regelmäßig Mails in das eigene Postfach, z.B. über:

  • AStA-Sitzung am xx.xx.2013 um 13:00 Uhr
  • [Ferienkurs Segeln] Beginn So, xx. Aug ++ Jetzt Anmelden ++
  • Amtliche Mitteilungen Nr. XX
  • GründungsMelder XX.2013
  • Fwd: WICHTIGE MITTEILUNG
  • Fwd: [BrandStuVe] E i n l a d u n g BbgHG-Konferenzen XX.XX.13
  • WLAN Sprechstunde Freitag, den XX.XX. wird verschoben auf Dienstag, den .XX.

Mindestens 95% der Informationen in den Mails sind für mich wertlos. Nachdem jedoch alle Mails an offizielle Verteiler der FH geschickt werden, kann man nicht einfach alle per Filter in den Papierkorb verschieben. Es könnte etwas wirklich Wichtiges dabei sein.

Ich finde es total sinnlos, z.B. alle FH-Angehörige über einen Ausfall der WLAN-Sprechstunde zu informieren. Man muss auch nicht den 3. in der Woche verlorenen bzw. gefundenen USB-Stick an alle melden. Kann man solche Informationen nicht einfach auf der Homepage der FH unter Fundstelle veröffentlichen? Man stelle sich mal vor, man würde in einem Unternehmen jede Kleinigkeit an ALLE verschicken. Das macht man einfach nicht. Nur weil Mails nichts kosten, kann man sie als Werkzeug dennoch sinnvoll einsetzen. Bitte ändert das zukünftig und lehrt euren Studenten lieber einen sinnvollen Umgang mit Mailverteilern!

Posted in: Studium Tagged: Erfahrungsbericht, FH Brandenburg, Master

ISSECO Certified Professional for Secure Software Engineering

18. August 2013 by Patrick Sauer Leave a Comment

Ich hatte meinen CPSSE vor ein paar Jahren gemacht. Im Gegensatz zum CSSLP von Isc² kommt der CPSSE sowie die dazugehörige Organisation ISSECO (International Secure Software Engineering Council) aus Deutschland. Die ISSECO wurde 2008 in Potsdam gegründet. Inhaltlich beschäftigt sich der CPSSE mit der Sicherheit im Softwarelebenszyklus:

  • Viewpoints of attackers and customers
  • Trust & threat models
  • Methodologies
  • Requirements engineering with respect to security
  • Secure design
  • Secure coding
  • Security testing
  • Secure deployment
  • Security response
  • Security metrics
  • Code & resouce protection

Für die Prüfung zum CPSSE muss ein dreitägiger Schulungskurs absolviert werden. Die Kurse werden von mehreren Anbietern durchgeführt. Für die Vorbereitung gibt es zusätzlich auch ein Buch „Basiswissen Sichere Software“ von Sachar Paulus, welches meiner Meinung nach recht gut ist. Ich hatte keinen Kurs der Anbieter besucht, sondern mir wurde als Kurs die Vorlesung „Sichere Softwareentwicklung“ an der Fachhochschule Brandenburg anerkannt. Die Vorlesung hielt Prof. Dr. Sachar Paulus.

Ich fand den CPSSE leichter als die aus den USA stammenden Zertifikate von Isc² (CISSP) und ISACA (CISM), dennoch sollte man schon über Erfahrung im Bereich Security und Softwareentwicklung besitzen, wenn man die Prüfung zum CPSSE bestehen möchte. Nachdem ich den CSSLP von Isc² nicht habe, kann ich die beiden Zertifizierungen CPSSE und CSSLP nicht vergleichen. Der „deutsche“ CPSSE ist nicht speziell auf deutsche Bereiche ausgerichtet, wie z.B. der T.I.S.P., sondern ist thematisch länderunabhängig. Nachdem ohnehin nur wenige Angebote zur Weiterbildung bzw. Zertifizierung existieren, kann ich den CPSSE durchaus empfehlen.

Posted in: Zertifizierung Tagged: CPSSE, Erfahrungsbericht, FH Brandenburg, ISSECO, Weiterbildung
« Zurück 1 … 18 19 20 … 22 Weiter »

Sprachen

  • Deutsch
    • English

Search

Categories

  • binsec
  • binsec.tools
  • blackhole pentesting
  • Datenschutz
  • Fragen und Antworten (Q & A)
  • Informationssicherheit
  • ISO27001
  • IT-Forensik
  • IT-Sicherheit
  • Lehraufträge
  • Netzpolitik
  • PCI DSS
  • Pentest
  • Presse
  • Regulatorik
  • Reuning
  • Studium
  • Unkategorisiert
  • Vorlesung
    • HDA
    • THB
    • THM
  • Vorträge
  • Zertifizierung

Copyright © 2025 InfoSec Blog | Patrick Sauer & Dominik Sauer.

Omega WordPress Theme by ThemeHall

  • Deutsch
  • English (Englisch)