Wie wird man Penetration Tester? Die 10 wichtigsten Fragen: https://www.digicomp.ch/blog/2021/12/01/penetration-tester
… und ein Video: https://youtu.be/-JhR67m52FY

• Definieren was getestet werden darf
• Nicht ohne Genehmigung testen
• Integrität, alles an Sicherheitslücken melden und alle Vorkommnisse melden
• Mach nichts kaputt
• Nicht zu tief eindringen, PoC genügt
• Nicht die gesamte Datenbank absaugen
• Fair Play auch gegenüber Teammitgliedern
• Datenschutz beachten

Die Planung von Pentests kann mitunter sehr komplex werden. Daher ist die Planungsphase sehr wichtig. Es stellen sich vier Fragen:

• Was soll getestet werden? Über welche IT-Assets (Systemlandschaften oder Applikationen) sprechen wir. Basierend darauf, mit Hinblick auf einer Risikoabschätzung wird entschieden, was mit welcher Priorität und in welcher Prüftiefe getestet werden muss. Es ist durchaus Best Practice nach einem risikobasierten Ansatz vorzugehen.
  • Wie soll getestet werden? Wenn wir wissen, was getestet wird, kann im nächsten Schritt ein geeigneter Prozess zur Durchführung definiert werden. Wichtig ist der grundsätzliche Ablauf und die Rollen und Verantwortlichkeiten festlegen:
    • Soll es eine zentrale Stelle geben, die den Prozess initiiert?
    • Wer muss in die Planung eingebunden werden?
    • In welchem zeitlichen Rahmen soll alles getestet sein?
    • Welche Eskalationsprozesse sind nötig?
    • Wer erhält am Ende die Prüfberichte
    • Wie geht es dann weiter?
    • Wie sollen Findings klassifiziert werden?
    • Wer ist für die Behebung der Findings verantwortlich?
    • Wie behalten wir den Überblick über die identifizierten Schwachstellen und den Durchführungsstatus der Analysen?
    • Wie findet ein Rückfluss ins Risikomanagement statt?
  • In welchen Abständen soll getestet werden? Es ist empfehlenswert einen groben Zeitplan für den definierten Prüfzeitraum festzulegen und entsprechende Puffer für Vorbereitung, Abstimmung oder Verschiebung einzuplanen.

Nicht nur in der ISO 31000, dem ISO Standard für das Risikomanagement (Risk management – Principles and guidelines) oder der ISO/IEC 27001 – Managementsystem für Informationssicherheit, ist das Risiko folgendermaßen definiert:

Risiko           = Schaden x Eintrittswahrscheinlichkeit
maximales Risiko = Sehr hoher Schaden x sehr hohe Eintrittswahrscheinlichkeit

Common Vulnerability Scoring System (CVSS) → https://www.first.org/cvss/calculator/3.0

Wir kennen jetzt unsere Schadensklassen und Eintrittswahrscheinlichkeiten, die wir bei der Bewertung zur Verfügung stellen. Daraus ergibt sich das mögliche Risiko. Da wir den größten Schaden mit „sehr hoch“ und die größte Eintrittswahrscheinlichkeit mit „sehr hoch“ beziffert haben, ist unser maximales Risiko: ^{Quelle: https://regina-stoiber.com/2019/04/28/risikoanalyse-durchfuehren-mit-muster-vorlage-und-beispiel/}

Das Risiko soll so weit wie möglich vermindert werden. Dazu gibt es verschiedene Methoden

• Risk Reduction – Reducing the risk by implementing one or more countermeasures.
• Risk Sharing – Sharing the risk with another entity.
• Risk Transference – Transferring the risk to another entity.
• Risk Avoidance – Modifying or ceasing the risk-causing activity.
• Risk Accepttance – Some residual risk is necessary to do business in the modern world.

Die Risk Accepttance gehört nur bedingt zu den anerkannten Methoden Risiken zu vermindern.
Siehe: https://foundershield.com/blog/risk-management/

Sammeln von Informationen, Systeme inspizieren, Schwachstellen feststellen und prüfen. Wie reagiert der technische Stack des Unternehmens auf Systemverletzungen. Die gesuchten Informationen reichen von Namen und E-Mail-Adressen der Unternehmensmitarbeiter bis hin zu Netzwerktopologie, IP-Adressen und vielem mehr. Es ist zu beachten, dass die Art der Informationen oder die Tiefe der Untersuchung von den für die Prüfung festgelegten Zielen abhängt. Zu den Methoden der Informationsbeschaffung gehören Social Engineering, Dumpster Diving, Netzwerk-Scanning und das Abrufen von Domänenregistrierungsinformationen.

Siehe: https://pentestwiki.org/reconnaissance/

Auf Grundlage der Erkenntnisse aus der Planungsphase setzen die Penetrationstester Scanning-Tools ein, um die Schwachstellen des Systems und des Netzwerks zu erkunden. In dieser Testphase werden die Systemschwächen ermittelt, die für gezielte Angriffe ausgenutzt werden können. Die korrekte Beschaffung all dieser Informationen ist von entscheidender Bedeutung, da sie über den Erfolg der folgenden Phasen entscheidet.

Nachdem die Pentester die Schwachstellen des Systems erkannt haben, dringen sie in die Infrastruktur ein, indem sie die Sicherheitslücken ausnutzen. Anschließend versuchen sie, das System weiter auszunutzen, indem sie ihre Privilegien ausweiten, um zu demonstrieren, wie tief sie in die Zielumgebung eindringen können.

In diesem Testschritt werden die potenziellen Auswirkungen einer Schwachstellenausnutzung durch die Ausnutzung von Zugriffsrechten ermittelt. Sobald sie in einem System Fuß gefasst haben, sollten die Penetrationstester den Zugriff aufrechterhalten und den simulierten Angriff lange genug aufrechterhalten, um die Ziele der böswilligen Hacker zu erreichen und zu replizieren. Daher versuchen wir in dieser Testphase, ein Höchstmaß an Privilegien, Netzwerkinformationen und Zugang zu möglichst vielen Systemen zu erhalten, indem wir ermitteln, welche Daten und/oder Dienste uns zur Verfügung stehen.

In dieser Phase müssen wir zeigen, was diese Sicherheitsverletzung für den Kunden bedeuten könnte. Sich Zugang zu einem alten Computer zu verschaffen, der nicht einmal Teil der Domäne ist, ist nicht dasselbe wie der direkte Zugang zu Passwörtern oder kompromittierten Daten.

Dies ist das Ergebnis eines Penetrationstests. Im letzten Schritt erstellt das Sicherheitsteam einen detaillierten Bericht, in dem der gesamte Ablauf des Penetrationstests beschrieben wird. Einige Informationen oder Details, die darin enthalten sein sollten, sind:

• Die Schwere der Risiken, die von den entdeckten Schwachstellen ausgehen → CVSS Calculator
• Die Werkzeuge, mit denen erfolgreich in das System eingedrungen werden kann
• Hervorhebung der Punkte, an denen die Sicherheit korrekt umgesetzt wurde
• Die Schwachstellen, die behoben werden müssen und wie künftige Angriffe verhindert werden können (Empfehlungen zur Behebung)

Dieser Schritt ist möglicherweise der wichtigste für beide Parteien. Da dieser Bericht wahrscheinlich sowohl von IT Mitarbeitern als auch von nicht-technischen Managern gelesen wird, ist es ratsam, den Bericht in einen allgemeinen Erläuterungsteil und einen eher technischen Aspekt aufzuteilen, d. h. in einen Executive-Bericht und einen technischen Bericht. ^{Quelle: https://crashtest-security.com/de/pentrationstest-schritte/}

Was ist in einem Vertrag im Detail geregelt:

• Zeitlicher Rahmen für den Test, Vorbereitung und Abschlussbericht
• Ressourcen auf Seiten der Tester (Teamgröße), und aufseiten der Kunden
• Zu testendes System, Prüfobjekte (etwa URLs) und Verbindung zum System (vor Ort, über Proxy, VPN)
• Test-Scope — zum Beispiel „OWASP Top 10“ — und besonders wichtige Bereiche, z.B. Neuentwicklungen, Neukonfigurationen
• Einschränkungen, was darf nicht getestet werden auf Seite des Kunden, was kann nicht getestet werden auf Seite der Tester
• Ansprechpartner, Erreichbarkeit, Eskalationspfade auf beiden Seiten

Es ist ratsam, zu dem Vertrag ein weiteres Dokument zu erstellen. In diesem Rules of Engagement wird, vom restlichen Vertrag abgekoppelt, genau definiert:

• Zeitrahmen
• Ort des Tests
• Kommunikationswege
• Sicherheitseinrichtungen, die den Test beeinträchtigen
• IP-Adressen oder Netzwerke, von denen aus der Test entspringt
• Erkennbarkeit der Tester

veranschaulicht den zeitlichen Rahmen ⇾ https://www.gantt.com/ge/

Ein Non-Disclosure Agreement ist ein Vertrag, bei dem sich verschiedene Vertragspartner zu einem streng vertraulichen Umgang mit allen Informationen und zum Schutz von Geschäftsgeheimnissen verpflichten. Er regelt die Permission to test und Permission to attack

• Siehe: https://www.bito.com/de-at/fachwissen/artikel/was-ist-ein-nda-und-wozu-dient-es/

Leistungsbeschreibung SOW (Statement of work). Die Leistungsbeschreibung ist das Dokument, das alle Aspekte Ihres Projekts (Erwartungen, Ergebnisse, Zeitplan, Preise) erfasst und definiert. Es ist die Grundlage für den Projektplan und sollte daher sehr detailliert sein. Ohne wäre es, als würde man zu einem Bauunternehmer sagen: „Bau mir ein Haus“, ohne ihm zu sagen, wann, welche Art oder wie groß.

• Siehe: https://www.triaxiomsecurity.com/what-to-look-for-in-a-penetration-testing-statement-of-work/
• Bedingungen für die Zusammenarbeit MSA (Master Service Agreement) → eine Vorlage und Beschreibung

Service Level Agreement (SLA) bezeichnet eine Vereinbarung zwischen Anbieter und Kunde und dient der Qualitätssicherung. In dieser Vereinbarung werden die genauen Leistungseigenschaften und Gütestufen (Service Levels) des Produktes bzw. der Dienstleistung festgelegt und versucht die Leistung auf diesem Wege zu objektivieren. Die Gütestufen können je nach Auftragnehmer variieren und unter betriebswirtschaftlichen Gesichtspunkten vom Auftraggeber ausgewählt werde. Durch den klar definierten Leistungsumfang und -qualität, wird mehr Transparenz für den Auftraggeber geschaffen und eindeutige Leistungsansprüche festgelegt.

• Siehe: http://www.softselect.de/business-software-glossar/sla

• Was kann nicht getestet werden (z.B. keine invasive SQL-Injection, da es sich um eine Produktivdatenbank handelt)
• Spezifische Technologien und Anforderungen des Kunden
• Einschränkungen bei den Fähigkeiten der Tester
• Known Issues
• Out of Scope — Systeme

• Geheimhaltung - wie müssen Informationen über Sicherheitslücken behandelt werden, wer bekommt Zugriff, wie werden diese kommuniziert
• Invasiv / Nicht invasive Überprüfungen
• Budget und ROI (Return on Investment)
• Disclaimers
• Informationen und Dokumentationen einholen: API-Dokumentation, SDK, Source Code

Weitere Infos:

• https://www.dgri.de/index.php/fuseaction/download/lrn_file/161028-vortragsfolien-dr.-keppeler.pdf
• https://docplayer.org/46581819-Angebot-penetrationstest.html

Zeit- und Budgetbeschränkungen können oft die Frage aufwerfen, ob ein Black-Box-, Grey-Box- oder White-Box-Penetrationstest verwendet werden soll.

Ein Black-Box-Penetrationstest ist ein Anwendungs-Pentest, bei dem dem Tester nichts anderes als der Zielort der Anwendung zur Verfügung gestellt wird. Dies wird normalerweise gegen eine Anwendung durchgeführt, die eine Authentifizierung erfordert, dem Tester werden jedoch keine Anmeldeinformationen bereitgestellt. Das Hauptziel besteht darin, festzustellen, Kann ein externer Angreifer ohne vorherigen Zugriff Zugriff auf die Anwendung oder Daten erlangen

Ein White-Box-Penetrationstest umfasst den Umfang eines Grey-Box-Penetrationstests, ermöglicht aber auch den Zugriff auf Quellcode, Designdokumente, Codekommentare und so ziemlich alles, was ein Entwickler normalerweise hat. Dies ermöglicht den aufschlussreichsten Einblick in das Innenleben der Anwendung und kann möglicherweise die meisten Sicherheitsergebnisse aufdecken. Diese Bewertung ist jedoch auch die arbeitsintensivste und zeitraubendste. Nicht alle Bewerbungen sind für eine solche Bewertung geeignet.

Es wird ein Grey-Box-Penetrationstest mit Zugangsberechtigung durchgeführt. Dadurch kann der Pentester die Rolle von legitimen Benutzern aller Berechtigungsstufen übernehmen. Der Tester kann dann Angriffe aus der Perspektive der Benutzer durchführen, um die Auswirkungen eines Angreifers zu bestimmen.

Weitere Infos: https://www.virtuesecurity.com/black-box-vs-gray-box-vs-white-box-pentesting-explained/

Information von Medien- Anwalt Solmecke:

• https://youtu.be/Y33PnTO2POI
• Ethische u rechtliche Richtlinien bei der Arbeit als Hacker, ggü. Team‚ Arbeitgeber, Kunde, Drittparteien (z.B. ISP, Lücken die man zufällig bei Dritt-APIs findet)
• Bug Bounties:
  • https://de.vpnmentor.com/blog/die-komplette-liste-mit-bug-bounty-programmen/
  • https://www.hackerone.com/
  • https://hackerone.com/hacktivity?order_field=popular

Der „Hacker-Paragraph“ § 202c StGB: http://www.it-recht-onlinekommentar.de/%C2%A7-202c-stgb/

• Bestimmte “Hacks” verletzten Federal und State Laws
• Computer Fraud and Abuse Act (CFAA)
• Wiretap Act, Unlawful Access to Stored Communications Law, Identity Theft and ‚Aggravated Identity Theft Laws, the Access Device Fraud Law, CAN-SPAM Act, Communication Interference Act
• US Patriot Act
• Cyberhacker können als Terroristen verfolgt werden
• State-level: Gesetze zu Phishing und Spyware

• PII — Personally Identifiable Information
• PHI — Personal Health Information
• PFI - PIFI - Personally Identifiable Financial Information
• Anderes

Siehe: https://blog.box.com/pii-vs-phi-vs-pci

Information und Beratung des unternehmensinternen Krisenteams

• Beschreibung des Problems, zügige Aufklärung des Sachverhalts
• Welche Risiken bestehen
• Gibt es rechtliche Vorgaben die zu erfüllen sind?
• Information der Geschäftsleitung mit Vorschlag zum weiteren Vorgehen

Siehe: https://www.smartlaw.de/rechtsnews/e-commerce/hilfe-wir-wurden-gehackt-wie-sie-auf-eine-datenpanne-richtig-reagieren und der Wiki-Text Vorbereiten des Ausspähens und Abfangens von Daten

Rechtliche IT-Sicherheit im Zusammenspiel mit IT-Compliance

• Deutscher Regelungsraum
  • EU-DSGVO
  • IT-Sicherheitsgesetz
  • KonTraG: Gesetz zur Kontrolle und Transparenz im Unternehmensbereich
  • GoBD: Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern, Aufzeichnungen und Unterlagen in elektronischer Form sowie zum Datenzugriff

Rechtliche IT-Sicherheit im Zusammenspiel mit IT-Compliance

• Deutscher Regelungsraum
• Gesetze mit konkretem IT-Bezug
• Verträge: an die Anforderungen und Wünsche der Kunden denken
• Auf individuelle Anforderungen und Wünsche eingehen

Siehe: https://www.pcisecuritystandards.org/document_library und im Buch CompTIA Pentest+ Seite 31f

There are four PCI compliance levels, which are determined by the number of transactions the organisation performs. Find out more.

• Level 1: Merchants that process over 6 million card transactions annually.
  • The assessment should consist of an external audit performend by a QSA (Qualified Security Assessor) or ISA (Internal Security Assessor). They’ll perform an on-site evaluation of your organisation to: —
    • Validate the scope of the assessment;
    • Review your documentation and technical information;
    • Determine whether the PCI DSS’s requirements are being met;
    • Provide support and guidance during the compliance process;
    • Evaluate compensating controls.

The auditor will then submit an RoC (Report on Compliance) to the organisation’s acquiring banks to demonstrate its compliance.

• Level 2: Merchants that process 1 to 6 million transactions annually.
• Level 3: Merchants that process 20,000 to 1 million transactions annually.
• Level 4: Merchants that process fewer than 20,000 transactions annually.

Levels 2-4 can complete an self-assessment questionnaire (SAQ) instead of an external audit. Level 2 organisations must also complete an RoC

Siehe:

• A guide to the 4 PCI DSS compliance levels
• https://www.itgovernance.co.uk/pci-audit-and-roc

Die BSI-Standards sind ein elementarer Bestandteil der IT-Grundschutz-Methodik. Sie enthalten Empfehlungen zu Methoden, Prozessen und Verfahren sowie Vorgehensweisen und Maßnahmen zu unterschiedlichen Aspekten der Informationssicherheit. Anwender aus Behörden und Unternehmen sowie Hersteller oder Dienstleister können mit den BSI-Standards ihre Geschäftsprozesse und Daten sicherer gestalten.
Siehe: BSI-Standards

• Title V, Section 501(b) of the Gramm-Leach-Bliley Act (GLBA) and the corresponding interagency guidelines
• The Federal Financial Institutions Examination Council (FFIEC)
• The Federal Deposit Insurance Corporation (FDIC) Safeguards Act and Financial Institutions Letters (FILS)
• The New York Department of Financial Services Cybersecurity Regulation (NYDFS Cybersecurity Regulation; 23 NYCRR Part 500)

Manche Regularien wie NYCRR and GLBA sind verpflichtend einzuhalten!

Buch ab S. 26

• Healthcare Provider
• Health Plan
• Health Care Clearinghouse
• Business Associates
• Das U.S. Department of Health and Human Services hat die HIPAA Security Rule Guides und Materialien auf https://www.hhs.gov/hipaa/for-professionals/security/guidance/index.html veröffentlicht,

Das U.S. Department of Health and Human Services hat die HIPAA Security Rule Guides und Materialien auf https://www.hhs.gov/hipaa/for-professionals/security/guidance/index.html veröffentlicht

Wiederkehrende Elemente in Regularien die man beachten sollte:

• Den Isolation (Network Segmentation)
• Passwort Management
• Key Management

Übungen