Im Master-Studium Security Management habe ich diverse Arbeiten geschrieben. Nach Recht stelle ich nun meine zweite Semesterarbeit von 2012 online:
Beim Sortieren alter Unterlagen vom Master-Studium Security Management bin ich über eine Hausarbeit aus der Vorlesung Recht gestolpert – vielleicht interessiert sich jemand dafür:
Problem Driven Project Management ist eine moderne alternative zu agilen Projektmanagement-Methoden. Während im Wasserfallmodell noch alles von oben herab durchgeplant werden muss und selbst bei agilen Methoden noch iterative Planungen durchgeführt werden müssen, fällt der Punkt Planung beim problemgetriebenen Projektmanagement einfach weg.
Durch die fehlende Planungsphase ergeben sich enorme Ressourcen- und damit auch Kosten-Einsparungen und es stellt sich automatisch eine sehr zielgerichtet Vorgehensweise ein: Aktuelle Probleme werden einfach priorisiert und danach abgearbeitet. Die Vorgehensweise ist zudem sehr intuitiv und orientiert sich direkt an den Bedürfnissen der Projektbeteiligten. Auch Kunden ziehen in der Regel einen problemgetriebenen Lösungsansatz einer ausführlichen Planung vor, die ohnehin nie eingehalten werden kann. Dadurch ergibt sich eine höhere Kundennähe und damit ultimativ eine höhere Kundenzufriedenheit.
Ausführliche Planungen, Projekt- und Teammeetings waren gestern. Das Problem Driven Project Management ist die perfekte Projektmanagement-Methode für alle, die agile Methoden immer noch für zu steif empfanden. Dieser einfache Ansatz verzichtet vollkommen auf Ausbildungen oder Zertifikate für Projektmanager – jeder kann nach dem problemgetriebenen Projektmanagement Erfolg haben!
In vielen Unternehmen wurde das Problem Driven Project Management bereits eingeführt, oftmals als direkte Reaktion auf die bisherigen komplexen planungs- und organisationsintensiven Managementmethoden. Agil war gestern, problem driven ist heute!
Jetzt einmal ohne heftigen Sarkasmus: Der obige Text ist natürlich totaler Schwachsinn – Ein Problem Driven Project Management ist nur die Verwaltung von Chaos. Wer sich darin wiedererkennt, sollte dringend handeln!
Der Security-Spezialist in mir weigerte sich jahrelang Cloud-Dienste in größerem Umfang zu nutzen. Gibt man schließlich private Daten in die Cloud, gibt man die absolute Kontrolle darüber ab. Meine Meinung darüber hat sich nicht wesentlich geändert, ich habe nur kapituliert.
Gegen die Geheimdienste bin ich ohnehin weitgehend machtlos und Krypto ist einfach für gewöhnliche private Daten viel zu aufwendig. Gegen 08/15-Hacker-Attacken wird sich Google sicherlich zu verteidigen wissen. Zumindest erscheint mir das Security-Konzept von Google auf den ersten Blick vorbildlich zu sein. Ich vertraue der Datenkrake Google unter Security-Aspekten wesentlich mehr als den Datenkraken Facebook oder Dropbox. Microsoft erwähne ich besser gar nicht erst.
Mittlerweile hat man nicht mehr nur einen PC oder Laptop, sondern einen ganzen Wildwuchs an Endgeräten: PCs, Laptops, Smartphones und Tablets. Ein paar Hundert Gigabytes an MP3s, Bildern, Vorlesungsunterlagen, uvm. kann man nur noch auf großen Datenträgern auslagern. Wenn man früher noch eine verschlüsselte externe Festplatte mitnahm, ist es heute nur noch umständlich: Wie schließe ich ein Tablet an eine verschlüsselte externe Festplatte an? Gar nicht.
Google kennt viele meiner Mails, mein komplettes Suchverhalten, synchronisiert von meinem Android-Device keine Ahnung was alles auf seine Server. Habe ich eigentlich noch wirklich eine Kontrolle, wer welche Daten von mir hat? Welche App auf meinem Smartphone welche privaten Daten von mir ins Ausland schickt? Nicht wirklich. Ich habe nur noch eine Pseudo-Kontrolle.
Ich könnte mir eine eigene Private Cloud aufbauen. Es gibt freie Software dazu, das ist nicht das Problem. Fehlt noch der Server, der schön regelmäßig Geld verschlingt. Dazu ist mir meine eigene private Zeit zu kostbar geworden, um Stunden oder gar Tage in irgendwelche Setups zu investieren, die dann nur mehr oder wenig gut funktionieren. Das ist keine Alternative mehr, der Aufwand ist zu hoch.
Ich habe mir jetzt testweise 100GB in Drive geholt, und werde vermutlich auf 1TB upgraden. Ich werde sicher keine wirklich privaten Dateien in die Cloud schieben. Für den Rest ist es einfach zu praktisch von allen Clients problemlos unterwegs auf Dateien in Drive zugreifen zu können. Ich kann nicht mehr kontrollieren, wer im Zweifel darauf zugreifen kann. Ich bin mir darüber bewusst, dass Google E-Mails scannt und ein amerikanisches Unternehmen ist.
Wenn ich aber die Risiken gegenüber den Vorteilen abwäge, ist die Entscheidung klar. Google du hast gewonnen, ich kapituliere: Technischer Fortschritt und maximale Privatsphäre lässt sich nicht vereinbaren. Man muss den persönlichen Kompromiss finden…
Ich wurde nun schon mehrmals gefragt, wie man eigentlich Penetration Tester wird und welche Vorgehensweise ich dazu empfehlen kann. Es gibt weder eine darauf spezialisierte Ausbildung noch ein darauf spezialisierter Studiengang. Ich möchte die Beantwortung der Frage von hinten aufziehen und zuerst die Frage beantworten, was ein guter Penetration Tester denn überhaupt können und wissen muss. Nun, da wären mindestens Kenntnisse und Fähigkeiten in:
Okay, die Auflistung ist umfangreich, ich möchte aber nichts streichen. Ich halte alle Punkte für relevant und notwendig. Es geht schließlich nicht um die Frage wie man Hacker wird, sondern wie man professioneller Karriere als Penetration Tester beginnt. Dazu gehört dann doch deutlich mehr als nur hacken zu können.
Ich empfehle als Grundlage entweder eine Ausbildung zum Fachinformatiker (Fachrichtung Systemintegration oder Anwendungsentwicklung) oder bei formaler Eignung (ab Fach-Abi) ein Informatik-Studiengang an einer Fachhochschule. Eine Universität würde ich für das Berufsziel Penetration Tester nicht wählen, das ginge aufgrund der Mathe- und Theorielastigkeit am Ziel vorbei. Ich würde ein Informatik-Studium an einer FH wählen, entweder reine Informatik oder zumindest etwas Vergleichbares in technischer Richtung. Medieninformatik und Wirtschaftsinformatik bieten keine idealen Vorrausetzungen für Penetration Tester, sind aber immer noch besser als gar nichts.
An der Anwendungsentwicklung kommt man in der Ausbildung und im Studium nicht vorbei und grundlegende IT-Systemadministration sollte hoffentlich auch dabei sein. Ansonsten muss man privat ein wenig nachhelfen – einfach alte Hardware nehmen und mit Linux & Windows experimentieren. Die Virtualisierungen Xen, kvm & Co erlauben auch den Aufbau eines ganzen Netzwerks auf einer physikalischen Maschine und sind kostenfrei. Hier kann man sich austoben und die Grundlagen vertiefen, wenn man ansonsten keinen Zugang zu praktischen Erfahrung bekommt. Ansonsten sollte man sicherlich noch eine vernünftige Script-Sprache lernen; ich empfehle Python (oder Perl oder Ruby oder bash, aber nicht PHP & Co).
Die theoretischen und praktischen Angriffstechniken ohne „Anleitung“ zielgerichtet zu lernen erfordert eine gewisse Selbstdisziplin. Es gibt im Netz dafür gute Online-Kurse wie z.B. den OSCP (Offensive Security Certified Professional) von Offensive Security. Der CEH (Certified Ethical Hacker) ist nur theoretisch und vermittelt keine Praxis. Das Wissen vom CEH kann man sich auch aus Büchern und dem Web anlesen, falls einem der OSCP zu „praktisch“ orientiert ist. Das zur Verfügung gestellte Hacking-Lab ist beim OSCP ist definitiv sein Geld wert und ich kann es nur weiterempfehlen.
Ansonsten gibt es im Web auch noch sehr viele frei-verfügbare & verwundbare Server-Images, an denen man kostenlos üben kann. Bücher gibt es auch einige, mit unterschiedlichem Niveau. Wer hier noch in der Ausbildung oder Studium etwas dazu lernt, dürfte ziemlich viel Glück gehabt haben. Oder er studiert direkt einen Bachelor in IT-Security und hat tatsächlich einen guten Prof für die Vorlesung erwischt. Das dürfte aber die Ausnahme sein. Ich würde ohnehin nicht bereits im Bachelor eine Spezialisierung wählen, dafür gibt es Master-Studiengänge.
Die Entwicklung eigener Tools wird mit steigender Erfahrung notwendig sein und ist mehr ein natürlicher Anpassungsprozess an eventuell nicht ausreichende oder nicht vorhandene Tools. Wer bereits Erfahrung im Programmieren oder in der Software-Entwicklung besitzt hat es hier deutlich leichter, auch wenn Penetration Testing nicht Anwendungsentwicklung bedeutet.
Professionelle Penetrationstests weisen immer eine strukturierte Vorgehensweise auf. Wer einfach „drauflos hackt“ wird vielleicht etwa finden, sicherlich nicht alles und vor allem wird der Test nicht reproduzierbar sein. Damit sinkt die Aussagekraft eines Penetrationstests enorm – eine ordentliche Vorgehensweise ist im professionellen Umfeld dringend erforderlich. Diverse Ansätze sind frei verfügbar (z.B. OSSTMM). Daran sollte man sich zumindest erst einmal orientieren, bis man in der Lage ist eventuell notwendige Anpassungen vorzunehmen.
Nach einem Penetrationstest muss noch der Bericht dazu erstellt werden. Dieser muss klar verständlich, vollständig und am Zielpublikum ausgerichtet sein (was nie einheitlich sein wird). Wichtig ist es dabei auch, schreiben zu können: Schriftlich Sachverhalte darlegen oder aufzeigen können. Konkrete Formulierungen wählen. Sichere Rechtschreibung und Grammatik.
Die Anforderungen an Pentester sind sehr hoch. Der Weg dorthin erfordert ein hohes Maß an Interesse, intrinsische Motivation und Eigeninitiative. Niemand wird einem den Weg dorthin im Detail vorgeben und ich glaube auch nicht, dass man das regelrecht planen kann. Wer gerne Sicherheitslücken entdeckt und Spaß dabei hat, der soll den Weg dorthin einschlagen.
Mittlerweile sind die Kurs-Materialien der binsec academy GmbH zum „Pentest Training“ öffentlich und kostenlos verfügbar: https://binsec.wiki/de/security/howto/pentest-training/
Der initiale Artikel stammt aus 2014 und wurde 2022 aktuallisiert:
Aus Marketing-Gründen bin ich z.B. bei LinkedIn selbst nicht besser, trotzdem nervt es so etwas in Fachzeitschriften zu lesen (fiktives Beispiel):
Der IT-Sicherheitsexperte Patrick Sauer, MSc, Diplom(FH), CISSP, CISM, OSCP, TISP, CPSSE, DSB-TÜV hat gestern mit seinem Kollegen Max Mustermann, PhD, MSc, CISSP, CISA, CISM und Frau Maxi Musterfrau, CISA, ISMS Auditor/Lead Auditor nach ISO/IEC 27001 nichts bahnbrechendes geschaffen, allerdings mussten die Titel und Zertifikate dringend einmal wieder leicht dezent in den Vordergrund gebraucht werden.
Akademische Abschlüsse wie B.Sc., M.Sc. oder Ph.D. hinter dem Nachnamen – okay. Aber muss man wirklich Zertifikate dahinten setzen? Und dann auch noch mehrere? Ganz ehrlich: Das liest sich in Fließtexten besonders – äh – suboptimal! Eins wäre ja noch ok, man könnte es auch hinter dem Nachnamen in Klammern setzen, aber diese aktuelle Unsitte Security-Zertifikate wie akademische Abschlüsse hinter dem Namen zu führen, ist in manchen Situationen nur noch peinlich.
Aufgrund meines CISM von der ISACA steht bei Post von dieser Organisation in der Anschrift direkt „Patrick Sauer, CISM“. Manchmal frage ich mich, was mein Postbote wohl denken muss. Ich sollte beim Briefkasten vielleicht einfach meine gesammelten Zertifikate aufzählen. Hat zwar kaum jemand auch nur eine Idee, was das sein soll, aber irgendwie muss man sich hochkompetent hervorzeigen.
Nur eine Meinung vom IT-Sicherheitsexperten Patrick Sauer, MSc, Diplom(FH), CISSP, CISM, OSCP, CPSSE, DSB-TÜV zur Unsitte Zertifikate hinter den Nachnamen zu setzen…..
Ein gewöhnliches IPv4-Netzwerk besteht nicht aus sonderlich vielen IP-Adressen. Ein /24er Block besteht aus 256 Adresse. Selbst bei einem wesentlich größerem /22 existieren nur 1.024 Adressen. Auch wenn nicht alle nutzbar sind (Network, Broadcast) bleiben wir einmal bei diesen Zahlen.
Relativ am Anfang eines Penetrationstests einer IT-Infrastruktur bzw. einem Netzwerk steht die Identifizierung der Live-Hosts, also der IP-Adressen, die tatsächlich einem Host zugewiesen sind. Das kann durch einen kurzen Ping-Sweep passieren oder man ignoriert ICMP und scannt den maximalen Port-Range über TCP und UDP. Vergleicht man beide Fälle anhand eines /22er-Blocks ergibt das bei einem Ping-Sweep 1.024 zu verschickende Anfragen und bei einem Scan über den gesamten Port-Bereich inkl. TCP und UDP bereits 1.024*65.535*2 = 134.215.680 – über 130 Millionen Anfragen, um absolut zuverlässig alle aktiven Hosts in einem /22 erkennen zu können.
Definitiv ist der Scan über alle Ports relativ zeitintensiv, aber noch realisierbar. Gehen wir einmal davon aus, dass ein Host jede Anfrage mit CLOSED o.ä. beantwortet und der Scanner nicht in einen Timeout läuft. Bei einer angenommenen Netzwerk-Latenz von 1ms (Gigabit-Ethernet) dauert der Scan – sofern nicht parallelisiert – ca. 37 Stunden. Wird der Scan um den Faktor 10 parallelisiert, ist er in 3,7 Stunden fertig. Selbst der komplette Scan eines etwas größeren IPv4-Netzes ist kein gigantisches Problem.
Und dann kam IPv6.
Nachdem der Adressraum bei IPv6 128bit beträgt, im Gegensatz zu 32bit bei IPv4, sind die Netze wesentlich größer. Gehen wir einmal von einem kleineren /56 IPv6-Netz aus. Das sind gerade einmal 9.223.372.036.854.775.808 Adressen. Also knapp 10^19 Adressen. Selbst wenn man nun auf einen vollständigen Scan verzichtet und nur einen Ping-Sweep zur Erkennung der Live-Hosts nutzt, sind das immernoch 10^19 Anfragen, die verschickt werden müssen. Nehmen wir an, wir verschicken (unrealistischer Weise) 100.000 Anfragen gleichzeitig, die alle in 1ms beantwortet werden. Wie lange dauert dann nur ein simpler Ping-Sweep über ein /56-Netz? 10^11 Sekunden bzw. 27.777.777 Stunden bzw. 1.157.407 Tage bzw. 3.170 Jahre. Ein Scan über ein komplettes „kleines“ IPv6-Netz – unmöglich!
Es gibt zwar verschiedene statische Häufungen, wie Netzwerk-Administratoren IPv6-Adressen vergeben, aber selbst die Berücksichtigung beliebter Bestandteile von IPv6-Adressen wie „:dead:“, „:b00b:“, „:cafe:“ oder „:babe:“ schränkt die Auswahl nicht zuverlässig genug für einen Penetrationstest ein.
Ein anderer Ansatz ist das Sniffen des gesamten IPv6-Verkehrs über Mirror/Monitoring-Ports an zentralen Core-Switche über eine gewisse Dauer. Das setzt natürlich nicht nur die grundsätzliche technische Möglichkeit voraus, sondern auch die Kooperation des Unternehmens. Sofern man einmal betriebliche oder datenschutzrechtliche Bedenken außen vor lässt – Datenschutzbeauftragte (Abgreifen von personenbezogenen Daten) und Betriebsräte (Achtung mögliche Leistungskontrolle) werden das in der Praxis sicherlich zu verhindern wissen. Technisch grundsätzlich möglich, ob wirklich umsetzbar sei einmal dahingestellt.
Bleibt eigentlich nur noch eine Liste mit IPv6-Adressen von den Administratoren des Zielnetzwerks zu erfragen. Idealerweise wird der Bestand von Hosts und verwendeten IP-Adressen in irgendeiner Datenbank oder Datei gepflegt. In wie weit solch eine Liste vollständig ist, kann man naturgemäß von außen nicht wirklich beurteilen. Es bleibt nur noch übrig, diese Liste mit möglichen weiteren IP-Adressen zu ergänzen, die man z.B. durch DNS Enumeration o.ä. gewinnen kann.
Egal wie, absolut vollständige Penetrationstests von IPv6-Netzwerken sind fast unmöglich zu garantieren. Ein Penetrationstests von IPv6-Netzwerken kann vollständig sein, muss er aber nicht. Das schlimmste daran ist, dass man nicht wissen wird, ob ein Test nun alle Hosts betrachtet hat oder nicht.
Endlich, es hat auch lange gedauert. Stimmen die Bericht auf SPON und in der FAZ, ist es chinesischen Studenten gelungen über eine Schwachstelle in einer Handy-App zur Fernsteuerung des Autos einen Tesla S während der Fahrt zu hacken: Lampen einschalten, Schiebedach öffnen & mehr.
Warum muss man eigentlich alles aus dem Internet fernsteuern können? Und muss ich wirklich mein Auto per App steuern können? Ist das wirklich die Welt, in der wir leben wollen: Haustür per App öffnen/verschließen, per App den Ofen anschalten, das Auto öffnen/schließen, die Waschmaschine starten?
Sicher, es ist bequem. Und was passiert, wenn einem das Smartphone gestohlen wird? Per Passwort-Reset über das auf dem Handy eingerichtete Mailkonto können schon die meisten Online-Accounts gekapert werden. Zukünftig wird dann noch das Auto übernommen oder gleich das Haus als Party missbraucht, wenn man im Urlaub ist.
Dabei können Hacker zukünftig über die Fernsteuerung von Autos noch viel mehr Schäden anrichten: Anonyme Morde & terroristische Attacken per Car-Hacking? An den Meistbietenden zu verkaufen. Ich hoffe zwar, dass die Autoindustrie aus diesen akademischen Hacks am Telsa S schnell genug lernt und in allen Bereichen der Fahrzeugentwicklung IT-Sicherheit einen sehr hohen Stellenwert bekommt, aber ich glaube nicht daran.
Und dabei gibt es noch ganz andere Herausforderungen: Sicherheitsupdates beim Auto! Wie lange werden Autos zukünftig mit Updates versorgt? Wie schnell werden sie ausgeteilt? Was passiert bei Software-Bugs durch das Update? Patch-Day am 1. Mittwoch des Monats bei Tesla? Gruselige Vorstellung.
Es wird sicherlich noch eine Zeit dauern, bis Autos nicht nur ständig online und per App steuerbar sind, sondern diese Features auch in den Massenmarkt kommen. Hoffentlich lernt die Autoindustrie aus den Fehlern anderer, bevor sie sie selbst begeht. Am besten werfen sie einfach mal einen Blick auf das Update-Chaos bei Android und gebrandeten Versionen der Mobilfunkprovider. Man darf gespannt sein..
Grundsätzlich müssen alle Unternehmen PCI DSS erfüllen, die Kreditkartendaten bzw. Karteninhaberdaten weiterleiten, speichern oder in irgendeiner anderen Art und Weise verarbeiten. Dies bezieht sich insbesondere auf die vollständige PAN (Personal Account Number), d.h. der Kreditkartennummer sowie auf die weiteren Authentifizierungsdaten des Karteninhabers wie z.B. Prüfsumme und PIN. Die Anforderungen sind grundsätzlich für alle Unternehmen gleich.
Allerdings gibt es enorme Unterschiede im Nachweisverfahren der PCI DSS Compliance, also im Nachweis der eigenen Konformität zum Standard. Das Nachweisverfahren unterscheidet sich zwischen VISA, MasterCard & Co zwar teilweise im Detail, jedoch ist es im Groben identisch. Ausgehend von VISA Europe[1] muss ein Händler (Merchant) seine PCI DSS Compliance durch einen unabhängigen Auditor (QSA – Qualified Security Assessor) nachweisen lassen, wenn er jährlich über sechs Millionen VISA Transaktionen abwickelt. Er ist in diesem Fall ein sogenannter Level 1 Merchant und muss einen Vor-Ort-Audit in Auftrag geben, bezahlen und auch erfolgreich abschließen. Unterhalb der Grenze von sechs Millionen Transaktionen entfällt dieser Nachweis. Ab diesem Merchant Level 2 reicht das Ausfüllen und Unterschreiben eines Selbstfragebogens (SAQ – Self Assessment Questionnaire) – ein unabhängiger Audit ist nicht mehr notwendig. Der Merchant attestiert sich sozusagen selbst die PCI DSS Compliance.
Es gibt verschiedene SAQs – SAQ A, C-VT, C und D – wobei ein Merchant in einem SAQ A bestätigt, dass er hat niemals eine digitale Zugriffsmöglichkeit auf die PANs & Co besitzt. SAQ D ist die maximale Steigerung und beinhaltet alle PCI DSS Anforderungen.
In beiden Fällen (Merchant Level 1 und Level 2) muss der Merchant zusätzlich noch einen externen Schwachstellen-Scan bei einem vom PCI Council akkreditierten ASV (Approved Scanning Vendor) durchführen lassen und ihn ohne pci-relevante Schwachstellen bestehen. Dieser Scan besitzt meiner Meinung nach allerdings keine hohe Aussagekraft: Er kann nur offensichtliche Schwachstellen von außen finden. Zusätzlich lässt sich ohne kompletten Review der IT auch nur sehr schwer beurteilen, ob wirklich der gesamte Adressbereich geprüft wurde.
Gerade Merchants, die selbst Zugriff auf die PAN haben möchten und / oder ihre Zahlungsabwicklung nicht komplett outsourcen wollen, stehen prinzipiell vor der Wahl:
Die technischen, organisatorischen, personellen und damit auch finanziellen Herausforderungen des PCI DSS annehmen oder ein (in der Tat erhebliches) Risiko akzeptieren und den SAQ C-VT, C oder D nicht wahrheitsgemäß ausfüllen.
Das SAQ-Verfahren ist für Merchants sicherlich kostengünstig, stellt aber ein großer Schwachpunkt in der nach unten verzweigten Kette der PCI DSS Compliance dar. Selbst wenn der Merchant eine korrekte Compliance beabsichtigt, braucht er unabhängige interne Kontrollverfahren zur Sicherstellung der Compliance. Die müssen zudem tatsächlich wirksam sein.
Ich halte grundsätzlich einen unabhängigen Audit oder das komplette outsourcen der Zahlungsabwicklung an einen Dienstleiter für sinnvoller. Die SAQs sind eine nicht kalkulierbare Schwachstelle im Nachweisverfahren der PCI DSS Compliance.
[1] http://www.visaeurope.com/en/businesses__retailers/payment_security/merchants.aspx
Wir schreiben das Jahr 1999. Die deutsche Regierung möchte ihre nachrichtendienstliche Abwehr aufrüsten: Jetzt soll in IT-Sicherheit investiert werden. Unser Außenministerium, unser Verteidigungsministerium und unser Justizministerium sollen ihre interne Kommunikation auf Sicherheitsmängel prüfen lassen. Und als besondere Maßnahme will der NSA-Ausschuss eine Schreibmaschine zur Spionageabwehr nutzen.
Moment. NSA-Ausschuss? Wir sind ja schon in 2014. Macht nix. Die technologische Entwicklung kann ein deutscher Nachrichtendienst auch einmal verschlafen. Die anderen Behörden sind ja auch nicht besser. Wir prüfen im Jahr 2014 einmal grundsätzlich, wie sicher die IT unserer Volksvertretung ist. Derweil wird in Untersuchungsausschüssen wieder die Schreibmaschine benutzt. Tolle Leistung.
Unsere Regierung sollte über einen „Beauftragter der Bundesregierung für Informationssicherheit“ nachdenken. Wir haben welche für die IT und für den Datenschutz. Aber einen CISO in oder unterhalb der Bundesregierung haben wir keinen.
