| Willkommen 38.107.191.100 | |
| Online | Gäste: 9
Mitglieder: 0
Auf dieser Seite: 1
Mitglieder: 3046, neuestes ist murthag |
| Neueste 5 Downloads |  Sophos A bis Z der Computersicherheit
Sophos, Allgemein (Dokumente), 20. Jul 08 : 12:10
Dieses Büchlein wird von Sophos zu Werbezwecken verdient. Es stellt in einem ersten Teil die Bedrohungen von A bis Z, wie man sie im Internet antrifft, vor. In gleicherweise werden im zweiten Teil Schutzmassnahmen erwähnt. Kurz und bündig wird so der Leser an die Materie herangeführt. Technische Details und weiterführende Diskussionen fehlen, so dass es wirklich nur als seichte Unterhaltung und Einführung gedacht ist.
eBay Hack (S.M.)
S.M. (aka. SevenUp), Social Hacking (Dokumente), 20. Jul 08 : 12:03
Dieses nicht unumstrittene Dokument bespricht Schritt für Schritt, wie ein technisch gestütztes Phishing per HTML-Email und PHP-Skript durchgeführt werden kann, um Login-Informationen für eBay abzufangen. Der Beitrag weist einige technische Fehler auf und ist zu grossen Teilen veraltet. Aus diesem Grund wird ihm primär nur noch historisches Interesse entgegengebracht.
Angriff und Verteidigung in Computernetzen
Alexander Koch, Allgemein (Dokumente), 20. Jul 08 : 11:57
Die leider etwas karge Präsentation beleuchtet verschiedene Gesetzesartikel, die auf Computerangriffe und Strike-Back-Verfahren angewendet werden können. Dabei werden sowohl die deutsche als auch die schweizerische Rechtssprechung berücksichtigt. Ein interessanter Beitrag, der die Gefahren von automatisierten Schutzmechanismen auf einer nicht-technischen Ebene zu verdeutlichen in der Lage ist.
Cross-Site Scripting (Compass)
Ivan Bütler, Webserver (Dokumente), 20. Jul 08 : 11:49
In diesem einfachen Artikel werden die Grundlagen von Cross Site Scripting-Attacken aufgezeigt. Dabei werden sowohl serverseitige als auch clientseitige Varianten besprochen und zudem darauf hingewiesen, dass sich dies mit jeglicher Art von Scripting (JavaScript, VBscript, etc.) durchsetzen lässt. Die Einfachheit des Papiers macht es vor allem für Einsteiger leicht zu lesen.
Internet Networking - Measuring Distance and Bandwidth between Hosts
Werner König, Netzwerke (Dokumente), 01. Apr 08 : 21:43
In dieser Seminararbeit werden diverse Algorithmen zur Berechnung von Bandbreiten bestimmter Verbindungen zwischen Hosts besprochen. Es werden Troughput, Pathchar und vor allem Packet Pair beschrieben sowie ihre Vor- und Nachteile dargestellt. Ein interessantes Gebiet, welches ausserhalb akademischer Bereiche fast keine Beachtung findet.
Zeige alle Downloads (902 Total) |
| Schon gewusst, dass... | ...das Hauptquartier der NSA ist Fort George G. Meade in Maryland ca. 16 km nordöstlich von Washington D.C. liegt? Die NSA hat eine eigene Ausfahrt auf der Autobahn Baltimore–Washington, gekennzeichnet mit "NSA Employees Only" (nur NSA-Angestellte). Zivilisten/Besucher sollen ausschliesslich die Exit Canine Road zum frei zugänglichen National Cryptologic Museum wählen.
Zeige alle Trivias (244 Total) |
| Zitat des Augenblicks (id 155) | "Alles ist eins - ausser der Null." - Wau Holland (1951-2001), Mitbegründer des Chaos Computer Club, als Panelteilnehmer der Veranstaltung "BerlinBeta", September 2000
Zeige alle Zitate (246 Total) |
| An diesem Tag... |  1927: Geburtstag von John McCarthy
1970: Geburtstag von Dave Buchwald
2002: Julien Bordet veröffentilcht den Artikel "Remote SMTP Server Detection"
2006: In der Schweiz wird der biometrische Pass eingeführt
Zeige alle Einträge (711 Total) |
| Buchtipp | 
Advanced Programming in the UNIX Environment
von W. Richard Stevens |
| | Sie sind zur Zeit nicht angemeldet und haben deshalb nur Gast-Privilegien. Einige Funktionen (z.B. Postings, Kommentare, Bewertungen, Statistiken) sind deshalb deaktiviert. Zudem ist für Gäste in einigen Bereichen Werbung geschaltet.
Melden Sie sich an und loggen Sie sich ein, um Zugriff auf sämtliche Bereiche zu erhalten. |
| Geschlossene Systeme und ihre Zukunft am Beispiel des iPhone (Montag, 23. August 2010 - 09:22:52) |
 [Marc's Blog] Kein Unternehmen hat sich je in derartiger Weise wie Phönix aus der Asche erhoben, wie dies Apple in der Lage war. In den 80er und 90er Jahren durch andere Hersteller und Plattformen belächelt - am lautesten gelacht hat Microsoft -, gilt das Unternehmen um Steve Jobs mittlerweile neben Google als Branchenriese mit der erfolgträchtigsten Zukunft.
Es sind die Produkte iPod, iPhone und iPad, die Apple zu neuer Marktstärke verholfen haben. Rückblickend sind zwei Dinge für diesen Erfolg massgeblich verantwortlich. Einerseits ist dies eine durchdachte und hochgradig moderne Marketing-Strategie, an der sich ganze Lehrbücher orientieren werden. Andererseits ist es die unglaubliche Einfachheit und hohe Ergonomie, die die jeweiligen Produkte mitzubringen in der Lage sind. Wer ein aktuelles Modell eines iPhone in der Hand gehabt hat, der will nur ungern zurück zur hakeligen und ungestümen Funktionsweise von Windows Mobile, BlackBerry und Symbian.
Apple hat aber nicht nur in Bezug auf diese Eigenarten ein komplett neues Zeitalter für technische Geräte eingeläutet. Ebenso sind iTunes und der AppStore ein wichtiges Instrument, um den bestmöglichen Gewinn für den Hersteller herauszuwirtschaften. Durch die zentrale Steuerung wird es möglich, an jedem Download - sei dies nun Musik, Podcast oder Anwendungen - mitzuverdienen. Die Produzenten und Entwickler stellen ihr Erzeugnis Apple zur Verfügung, die es wiederum im Store zum Download anbieten.
Dadurch kann gleichzeitig ein Qualitätsmanagement durchgesetzt werden. Denn entspricht ein Produkt nicht den Wünschen und Anforderungen von Apple, wird es einfach zurückgewiesen. Dabei können technische, funktionale und ergonomische Gründe verantwortlich sein. Oder es können wirtschaftliche, politische oder gar moralische Einschränkungen mitschwingen. Da die Endgeräte dank der geschlossenen Plattform und der DRM-Einschränkungen nicht ohne weiteres Produkte aus anderen Quellen beziehen können, sind sowohl Entwickler als auch Endanwender der Gunst des Übervaters Apple unterworfen.
Es gibt eine schier unendliche Anzahl an Apps, die im AppStore angeboten werden. Eine Vielzahl an Entwicklern buhlt mit ihren Tools und Gadgets um die Gunst der Anwender. Die meisten Entwickler haben dabei mehr früher als später das grosse Geld im Blick. Wird eine App für 2 EUR angeboten und diese 10'000 Mal heruntergeladen, dann hat man schon mal schnell 20'000 EUR verdient. Nicht schlecht für eine Handy-Applikation ... Es gibt wohl nur wenige Hobby-Programmierer, die in der Vergangenheit mit ähnlichem Gewinn aufwarten konnten. Eine regelrechte Goldgräberstimmung hat sich damit entwickelt.
Doch die meisten Entwickler merken früher oder später, dass eine qualitativ gute App nicht zwingend Geld einspülen wird. Viel mehr muss man sich zuerst mit der Gängelung von Apple herumschlagen. Sind dies einerseits technische Einschränkungen, die die Zielplattform nunmal mit sich bringen (z.B. bis iOS4 keine speicherresidenten Prozesse). Andererseits aber auch die willkürlich erscheinende Politik von Apple in Bezug auf die Freigabe von Produkten: Mal muss man ewig auf Feedback warten. Mal kriegt man eine Absage ohne ersichtlichen Grund (z.B. falsche Verwendung eines Objekts). Und mal konkurriert man zwangsläufig mit einem Produkt von Apple selbst.
Auf die Goldgräberstimmung folgt bei vielen die Katerstimmung. Man beginnt sich zu fragen, warum man sich diese Unterwürfigkeit überhaupt antut. Schliesslich gibt es so viele populäre, effiziente und offene Plattformen, auf denen man sich nach Herzenslust austoben kann. Man braucht kein OS X, kein Objective-C, kein Xcode/Cocoa. Man kann für die Entwicklung das Betriebssystem, die Programmiersprache und die Technologie - also das Werkzeug seiner Wahl - nehmen. Niemand schreibt einem vor, was und wie man zu programmieren hat. Man kann sein Produkt gratis, kostenpflichtig, vorkompiliert oder quelloffen veröffentlichen. Wie es einem beliebt.
Durch geschlossene Systeme werden junge Programmierer in ihrer Entfaltung gehemmt. Sie werden gezwungen, sich in die Abhängigkeit eines grossen Unternehmens zu begeben, das in erster Linie seinen Aktienkurs im Blick hat. Apple ist deshalb massgeblich mitverantwortlich, dass eine ganze Generation von Entwicklern ein komplett schiefes Weltbild in Bezug auf die Software-Entwicklung entwickeln wird. So sehr ich den Verdienst von Apple zu würdigen weiss, schliesslich haben sie eine ganze Branche wach gerüttelt, so sehr hoffe ich, dass sie durch weltoffene und weitsichtige Entwickler und Kunden wieder in ihre Schranken verwiesen werden.
Man darf es sich dabei nicht zu einfach machen, und pauschal ein gesamtes Unternehmen vergöttern oder verdammen. Stattdessen liegt es daran Kompetenz dafür zu entwickeln, welche Aspekte positive und welche negative Auswirkungen haben werden. Das iPhone überzegt noch immer in Bezug auf seine Ergonomie. Aber dass nach dem iPad nun ebenfalls OS X mit AppStore/DRM eingeschränkt werden soll, das lässt sich definitiv nicht mehr rechtfertigen.
|
| Die Angst eines jeden Penetration Testers (Montag, 9. August 2010 - 08:31:47) |
[Marc's Blog] In meinem privaten Umfeld gibt es so manchen, der sich nicht einfach im Umgang mit seiner Familie tut. Da wird gestritten, bei jeder Gelegenheit. Sei dies nun mit Mutter, Vater, Geschwister, entfernten oder angeheirateten Verwandten. Meine Beobachtungen in dieser Hinsicht ist - und dies lässt sich grundsätzlich auf die meisten Streitereien in unserer Hochkultur übertragen -, dass der Groll in erster Linie dann entsteht, wenn sich jemand nicht ernst genommen und seine Bedürfnisse mit Füssen getreten fühlt. Auch wenn es vielen nicht bewusst ist, so ist doch mitunter durch Anerkennung genährter Stolz eine wichtige Komponente eines jeden Charakters.
Ein solcher Stolz findet sich natürlich und manchmal ganz besonders im Wesen eines Penetration Tester wieder. Als Prüfinstanz wird er von vielen als letzte Kompetenz wahrgenommen, die über Gedeih und Verderb eines Projekts zu entscheiden hat - Ein No-Go kann das Aus für ein Produkt bedeuten. Penetration Tester, leisten sie denn konsequent gute Arbeit, geniessen einerseits diese ihnen zugetragene Anerkennung. Gleichzeitig kann sie sich aber auch schnell in eine Bürde wandeln.
Ich kann mich noch sehr gut an meine Anfänge in diesem Bereich erinnern. Jede Prüfung war ein Abenteuer. Jede Rückantwort, die ich von einem Server provozieren konnte, liess noch mehr Adrenalin in meinem Körper ausschütten. Es war pure Freude, sich erstmals mit Grossrechnern in umfangreichen Netzwerken und geschützten Server-Räumen auseinanderzusetzen. Und jedes Finding, jede gefundene Schwachstelle, sollte das eigene Ego stärken.
Doch irgendwann kam der Moment, bei dem man vor einem Prüfobjekt steht, in dem man einfach keine Schwachstellen finden kann. Ein Server, der in derartig umfassender Weise gehärtet ist, dass man selbst mit dem Umsetzen eines zuverlässigen Portscan Probleme hat. Oder ein Netzwerkgerät, das man einem Blackbox-Test unterziehen soll, das schlichtweg keine erweiterte Funktionalität und damit auch keine Angriffsfläche offenbart. Sowas ist schlimm.
Bei mir war es ein Windows NT 4, das mich fast zur Verzweiflung getrieben hat. Wir schrieben das Jahr 2001 und mittlerweile hatte sich langsam dessen Nachfolger Windows 2000 etabliert. Als konsequenter Linux-User (zwischen 1998 und 2002 habe ich privat ausschliesslich offene Betriebssysteme benutzt) liess ich es mir bei Beratungsprojekten nicht nehmen darauf hinzuweisen, dass ich selbst niemals freiwillig einen NT-Server ins Internet stellen würde: Zu gross sei die Angriffsfläche, zu schwierig die Möglichkeit, ein wirklich sicheres System erreichen zu können. Und in den meisten Fällen hatte ich Recht.
Doch da war es nun: In meiner Konsole versuchte ich wie wild ein NT4 im Internet anzugreifen und es tat keinen Mucks. Ich habe alle Arten von Portscans probiert, konnte jedoch noch nicht einmal die typischen Ports eines solchen Systems - halt die klassischen NetBIOS-Dienste - ausmachen. Mir wurde gesagt, dass das System direkt im Internet steht und ohne Zuhilfenahme von 3rd Party Software abgesichert wurde. Ich konnte es nicht glauben. Dieses System verhielt sich wie ein gehärtetes Debian - Doch es war ein NT4 ... Ich konnte es einfach nicht glauben!
Verzweifelt habe ich versucht am System zu rütteln - Im übertragenen Sinn. Doch ich scheiterte. Jeder meiner Zugriffe scheiterte. Ich konnte keine Dienste ausmachen. Keine Angriffsfläche. Was sollte ich bloss tun? Was sollte ich dem Kunden erzählen? Wie sollte ich rechtfertigen, dass ich eine für seine Unsicherheiten bekannte Plattform nicht mal ansatzweise tangieren konnte? Ich hatte das Gefühl, als stünde mein Ruf auf dem Spiel. Ein Ruf, den ich mir über die Jahre mühsam versucht habe aufzubauen ...
In den kommenden Nächten tat ich kein Auge zu. Mein drohendes Scheitern liess mir keine Ruh'. Doch irgendwann realisierte ich, dass ich ja eigentlich gar nichts falsches tat. Ich verstand, dass meine Prüfung einem wissenschaftlichen Prozess gleicht. Zwar versuche ich durch meine Tests die vermutete Unsicherheit zu "verifizieren". Eine wissenschaftliche Untersuchung kann eine Vermutung jedoch auch "falsifizieren". Die Validierung, dass eine Annahme falsch ist, ist fast so wertvoll, wie das Gegenteil - Sofern man denn der triadischen Prinzip von These-Antithese-Synthese (Dialektik) folgt. Ich schien gerettet, wenigstens ein bisschen.
Im Rahmen des Reportings machte ich mich also daran, das Projekt umfangreich zu dokumentieren. Es ging zum ersten Mal aber nicht primär darum, die Resultate bzw. Sicherheitslücken schön aufzubereiten. Stattdessen fokussierte ich mich darauf aufzuzeigen, welche Angriffsversuche ich unternommen hatte und wieso sie gescheitert sind (die abgeschotteten Ports kamen übrigens durch Tweaking von IPsec-Regeln zustande). Das ist so, wie wenn ein Arzt seinem Patienten mittels Ausschlussdiagnose erklärt, warum er gesund ist und die erwartete Krankheit eben nicht haben kann.
Während ich die angestrebten Angriffsversuche dokumentierte, wurde mir bewusst, dass nicht ich als Penetration Tester versagt hatte. Viel mehr hatten die Tests als solche versagt, Schwachstellen zu identifizieren. Da ich jedoch sämtliche bekannten Tests im Zeitrahmen des Projekts angewandt und quergeprüft hatte, konnte ich jedoch eine umfassende und qualifizierte Aussage treffen. Und darum geht es bei einer Sicherheitsprüfung. Das Finden von Sicherheitslücken ist damit nur eine Form davon, dieses Ziel zu erreichen. Das Verstehen, warum man eine Schwachstelle nicht vorfindet, ist ein mindestens so wichtiges Werkzeug eines guten Penetration Testers.
|
| Das Pentesting Experten System (Montag, 26. Juli 2010 - 10:39:51) |
[Marc's Blog] Seit meinem Eintritt in den Bereich der Netzwerksicherheit haben mich Vulnerability Scanner zur automatisierten Identifikation von Sicherheitslücken fasziniert. Erste Gehversuche mit einer eigenen Implementierung habe ich im Jahr 2000 mit dem Dante Projekt umgesetzt. Der auf modularen Shell-Skripten basierende Security Scanner sollte über eine Weboberfläche bedienbar und deshalb durch jedermann benutzbar sein.
Rund vier Jahre später habe ich mit einer konkreten Implementierung für das Attack Tool Kit (ATK) begonnen. Dieses sollte noch einen Schritt weitergehen und neben dem Identifizieren von Schwachstellen eben jene auch gleich Ausnutzbar machen. Dies geschah in jener Zeit, als das MetaSploit Framework (MSF) entwickelt und damit der Begriff des Exploiting Frameworks geprägt wurde.
Sowohl Dante als auch das ATK sollten mir bei meiner täglichen Arbeit als Penetration Tester helfen können. Sie sollten mich dabei unterstützen, Sicherheitsüberprüfungen automatisiert durchführen zu lassen. Dadurch sollte sich sowohl die Effizienz als auch die Qualität der Tests erhöhen lassen. Dies ist, natürlich unter Miteinbezug vergleichbarer Lösungen wie Nessus und Qualys, möglich gewesen. Doch nie habe ich mich so richtig wohl mit diesem Flickwerk aus Werkzeugen gefühlt.
Ein ursprünglich mit dem Arbeitstitel ATK.NET angefangenes Projekt sollte die Defizite bestehender Produkte, und dazu zählen selbstverständlich auch meine Ansätze, eliminiert werden. Diese Lösung sollte sowohl die Möglichkeiten eines umfangreichen Vulnerability Scanners, als auch eines intelligenten Fuzzing-Tools sowie eines Exploiting-Frameworks bieten. Eine Analyse sollte sich dabei in unterschiedlicher Genauigkeit (diese hat ebenso Auswirkungen auf die Dauer der Ausführung) als auch in unterschiedlichen und stufenlosen Graden an Automatisierung durchführen lassen (von nahezu manuellen Tests bis hin zu komplett automatisierten Scans).
Insgesamt 10 Jahre meiner Entwicklungszeit wurde in diese Lösung investiert. Davon über 8 Jahre zusammen mit meinen hervorragenden Arbeitskollegen bei scip AG. Durch eine hochgradig modulare Lösung sehen wir uns in der Lage, anhand eines Expertensystems unsere hochgesteckten Ziele zu erreichen. Wir vereinen dabei die Möglichkeiten der unterschiedlichen Lösungsansätze, ohne auf Flexibilität verzichten zu müssen.
Wir unterscheiden dabei zwischen verschiedenen Engines. Die Scan-Engine ist für das (semi-)automatisierte Zusammentragen der potentiellen und ausgemachten Schwachstellen verantwortlich. Dabei wird in einer ersten Phase versucht, den grundlegenden Aufbau eines überprüften Objekts (Netzwerk, System, Dienst, Applikation oder Daten) zu identifizieren. Anhand verschiedener Mechanismen wird versucht die eingesetzten Technologien und die angewandten Konfigurationseinstellungen auszumachen. Da es sich hierbei um dynamische Module handelt, lassen sich damit auch komplett unbekannte Lösungen und Eigenentwicklungen analysieren.
Die durch die Scan-Engine gesammelten und als XML-Dateien bereitgestellten Daten werden durch einen Parser bearbeitet. Im Pre-Parsing wird es möglich, anhand der ermittelten Mechanismen erste statistische Auswertungen vorzutragen. Da das Parsing besonders effizient umgesetzt wird, lässt sich dies in Echtzeit an den Scanning-Prozess knüpfen. Theoretisch kann der Kunde in jedem Augenblick eines Projekts über den aktuellen Stand informiert werden.
Das Pre-Parsing erlaubt jedoch ebenfalls eine erste Moderation der Resultate. Damit kann Einfluss auf den iterativen Prozess des Scannins, aber auch auf die Weiterverarbeitung der gesammelten Daten, ausgeübt werden. Zum Beispiel lassen sich On-The-Fly neue Tests generieren, bekannte False-Positives markieren (Flagging) oder weiterführende Validierungen anstreben.
Durch das effektive Parsing werden die Daten in eine Datenbank geschrieben. Dort lassen sich erste Planspiele anstreben. Durch statistische Auswertungen können Hochrechnungen für die anstehenden Tests getätigt werden. Oder es lassen sich Delta- sowie Trendanalysen, auf der Basis vorangegangener Sicherheitsüberprüfen des gleichen Kunden oder vergleichbarer Kunden, umsetzen.
Werden die Daten in der Datenbank abgelegt, kann eine feste Moderation umgesetzt werden. Dabei erlaubt das System eine durch unterschiedliche Analysten in unabhängiger Weise umgesetzte Moderation. Es können also verschiedene Leute die Einträge kontrollieren, beglaubigen und validieren. Dies müssen nicht zwingend die gleichen Personen sein, die die initialen Scans durchgeführt haben. Damit lässt sich ebenso ein Vieraugenprinzip anwenden, indem potentielle Schwachstellen nur dann als gegeben akzeptiert werden, wenn mindestens zwei Auditoren ihr "Accepted" abgegeben haben.
Die Datenbank fungiert sodann als Expertensystem. Dieses weist die Analysten darauf hin, wie hoch die Chancen für False-Positives (und False-Negatives) sind, wie sich diese erkennen und eliminieren lassen. Durch Schritt-für-Schritt Anleitungen bzw. dynamisch generierte Scan-scripte können sodann weiterführende Tests oder Validierungen durchgeführt werden. Der Tester muss sodann nich zwingend im Detail mit der Zielumgebung und den eingesetzten Technologien vertraut sein, da er sich auf den gesammelten Erfahrungsschatz unseres Unternehmens bzw. der anderen Analysten verlassen kann.
Dieser Prozess des Prüfen, Validieren, Parsen, Moderieren und Dokumentieren kann iterativ und beliebig oft wiederholt werden. Zu jedem Zeitpunkt sind sämtliche Daten vorhanden und können auf Knopfdruck ausgegeben werden (Report, Statistiken, Trends). In der Regel wird ein Ablauf der Form Scan-Moderation-Scan-Moderation-Dokumentation angestrebt. Dadurch kann gewährleistet werden, dass Schwachstellen, die bei den ersten Tests nicht identifiziert werden konnten (da sämtliche Angriffsflächen so noch nicht bewusst waren) doch noch identifiziert werden können.
In der Datenbank werden umfangreiche Informationen zu den jeweiligen Schwachstellen abgelegt. Neben einer Charakterisierung des Problems findet sich ebenfalls mindestens eine Schritt-für-Schritt Anleitung zur Ausnutzung des Problems und verschiedene Gegenmassnahmen (priorisiert nach ihrer Effektivität). Ebenso wird eine umfangreiche Attributisierung durchgesetzt. So werden Phase eines Angriffs (z.B. Auswertung), Angreifertyp (z.B. Skript-Kiddie), Schwachstellenklasse (z.B. Cross Site scripting), betroffenes Objekt (z.B. Webapplikation) und Parent-Bug (die für die Existenz dieser Schwachstelle erforderliche Voraussetzung) festgehalten. Zusätzlich sind Referenzen auf andere Scanner (inklusive Deren Beschreibungen, Einstufungen und Testverfahren), Verwundbarkeitsdatenbanken, Webseiten und Bücher in dieser Wissensdatenbank festgehalten.
Werden sämtliche Daten in der Datenbank eingetragen und moderiert, kann ein Report generiert werden. Durch die umfangreiche Report-Engine wird es möglich, verschiedene Ausgabeformen und Dateiformate zu unterstützen. Dies reicht von klassischen Word-/PDF-Reports mit allen Details über Excel-Dokumente mit den wichtigsten Gegenmassnahmen (Checklisten) bis hin zu XML-Dateien zur automatisierten Weiterverarbeitung (z.B. in einem Bugtracking-System).
Das grundlegende Ziel des Reportings ist dabei, keine der gesammelten und vorhandenen Informationen zu verlieren. In einem Report sind also stets alle Daten enthalten, die von Nutzen sind. Zu jeder gefundenen Schwachstelle werden projektbezogene Informationen, wie die IP-Adresse des Scan-Systems und der Zeitpunkt der Identifikation, bereitgestellt. Damit kann ein Höchstmass an Transparenz und Nachvollziehbarkeit gewährleistet werden. Ganze Tests lassen sich also auch nach Abschluss bis auf die Sekunde genau rekonstruieren.
|
|
