Frage:
Was sollte ein Sicherheitsauditbericht enthalten?
Adi
2013-01-24 22:02:05 UTC
view on stackexchange narkive permalink

Hintergrund

Ich bin für die Prüfung einer mittelgroßen Webanwendung verantwortlich. Ich habe bereits mehrere Male Webanwendungen geprüft, aber ich habe immer ein kurzes PDF geschrieben, in dem schnell erklärt wird, worauf ich gestoßen bin. Normalerweise bin ich derjenige, der diese Sicherheitsanfälligkeiten behebt, sodass ich mich nie um den tatsächlichen Inhalt des Berichts gekümmert habe. p>

In meinem aktuellen Job werden die Dinge organisierter erledigt. Zuerst muss ich den Bericht schreiben, dann wird der Projektmanager ihn überprüfen und dann entscheiden, ob ich derjenige bin, der die Probleme behebt, oder jemand anderes.

Frage

Was sollte ein solcher Bericht enthalten? Ich suche nach einem allgemeinen Überblick über die Organisation.


Update : Da ich hier auf Security.SE nichts über Überwachungsberichte finden konnte, Ich habe mich entschlossen, diese Frage etwas weiter zu vertiefen und jede Art von Sicherheitsüberprüfung einzuschließen, anstatt nur Webanwendungen. Ich denke, dass es in diesem Fall für mehr Menschen nützlich sein wird.

Ich möchte hinzufügen, dass GIAC einen [Sicherheitsüberprüfungsbericht auf ihren Systemen] hat (http://www.giac.org/paper/gcux/67/security-audit-report/101128) ([Spiegel ] (https://archive.org/download/security-audit-report_67_/security-audit-report_67_.pdf)). Es ist ein sehr detaillierter Bericht mit guten Referenzen und Anhängen. Es sind fast 70 Seiten, aber es lohnt sich auf jeden Fall zu lesen
Neun antworten:
Rory McCune
2013-01-24 23:42:05 UTC
view on stackexchange narkive permalink

Es gibt verschiedene Möglichkeiten, wie ich dies gesehen habe. Jede hat ihre Vor- und Nachteile.

Wie von @RoryAlsop unten erwähnt, ist ein gemeinsamer Punkt für beide Ansätze, dass die Zusammenfassung wie folgt sein sollte Schreiben Sie so viel wie möglich für ein Unternehmenspublikum (vorausgesetzt, es handelt sich um einen Test, den Sie für einen Drittanbieter durchführen, oder der Bericht wird an das Management weitergeleitet).

  • Berichterstellung durch Finden. Hier listen Sie die Ergebnisse auf, die normalerweise nach Schweregrad geordnet sind (z. B. CVSS-Score oder eine andere Skala wie Schweregrad / Wahrscheinlichkeit). Sie listen dann die technischen Details des Befundes und mögliche Abhilfemaßnahmen auf, wenn Sie über diese Informationen verfügen. Diese Art von Bericht kommt ziemlich schnell auf den Punkt und spielt gut mit der Werkzeugausgabe.
  • Berichterstellung nach Methodik. Unter der Annahme, dass Sie hier einer definierten Testmethode folgen, ist der Bericht nach dem Vorbild der Methodik strukturiert und enthält einen Abschnitt für jeden Bereich der Überprüfung. In den Abschnitten wird detailliert beschrieben, welche Tests durchgeführt wurden und welches Ergebnis erzielt wurde (z. B. entweder ein Befund oder die Tatsache, dass in diesem Abschnitt kein Befund vorhanden war). Der Vorteil hierbei ist, dass Sie Ihre Arbeitsweise zeigen und dass jemand, der den Bericht liest, eine gute Vorstellung davon bekommen kann, dass Sie tatsächlich etwas getestet haben und es in Ordnung war, anstatt es einfach verpasst zu haben. Der Nachteil ist, dass der Bericht tendenziell länger ist und schwerer zu automatisieren ist. Ein weiteres Problem ist, dass Sie sicherstellen müssen, dass die Tester nicht nur der Methodik folgen und das Gehirn tatsächlich dazu bewegen, nach anderen Dingen zu suchen.

In Bezug auf das Format für die Ergebnisse: Normalerweise füge ich den folgenden

  • Titel hinzu (Beschreibung wird in der Tabelle verwendet und mit dem Detail verknüpft)
  • Beschreibung - technische Beschreibung des Problems und vor allem unter welchen Umständen Es ist wahrscheinlich, dass dies ein Sicherheitsproblem verursacht (z. B. beim Cross-Site-Scripting besteht eines der potenziellen Probleme darin, Sitzungstoken abzurufen, die es einem Angreifer ermöglichen könnten, unbefugten Zugriff auf die Anwendung zu erhalten)
  • Empfehlungen - Wie das Problem behoben werden soll, enthalten nach Möglichkeit spezifische Details zur Herstelleranleitung, um es zu beheben (z. B. Dinge wie das Entfernen von Webserverversionen aus Headern enthalten spezifische Anweisungen für Apache / IIS usw.)
  • Verweise - Alle Links zu zusätzlichen Informationen, die für den Befund relevant sind (z. B. Links zur relevanten OWASP-Seite für Web-App-Probleme).
  • Schweregrad. Wie oben erwähnt, kann dies CVSS oder etwas allgemeineres wie Hoch / Mittel / Niedrig sein, basierend auf Auswirkung und Wahrscheinlichkeit.
  • Andere Klassifizierung, wie vom Kunden benötigt. Zum Beispiel könnten einige Kunden Dinge benötigen, die gegen einen Standard oder eine Richtlinie oder etwas wie OWASP Top 10 ausgerichtet sind.

Ein weiterer Punkt ist, dass es sich lohnt, wenn Sie viele Tests durchführen Eine Datenbank mit früheren Ergebnissen, um zu vermeiden, dass Referenzen wiederholt nachgeschlagen werden müssen, und um sicherzustellen, dass die Schweregrade konsistent sind.

Alle Antworten ergänzen sich, aber ich muss sagen, ich mag die Art und Weise, wie dies erklärt wurde. Wenn Sie Zeit haben, können Sie bitte ein Beispiel dafür geben, was Ihrer Meinung nach ein guter Eintrag für einen Befund wäre? Bald werden die Suchergebnisse bei Google in dieser Angelegenheit die besten sein (fast nirgendwo anders), daher wäre es schön, dies in der akzeptierten Antwort zu sehen. Vielen Dank
Die eine andere Sache, die ich hier hinzufügen möchte (und die möglicherweise aufgrund meiner Arbeit in den letzten 10 Jahren voreingenommen ist), ist, dass eine Interpretation der Bedeutung des Berichts in ** Geschäftssprache ** von entscheidender Bedeutung ist, wenn Sie möchten, dass die Organisation dies tut Verstehe das wahre Risiko für sie. Dies führt (hoffentlich) zu einer korrekten Reaktion auf den Bericht.
@RoryAlsop, ein sehr wichtiger Punkt, Geschäftssprache. Dies kann eine wichtige Rolle bei der Entscheidung des Managements zur Behandlung dieser Probleme spielen.
@Adnan Aktualisiert mit einigen Details zum Format der Ergebnisse. Ist das die Art von Dingen, an die Sie gedacht haben?
@RoryAlsop guter Punkt, hinzugefügt.
@RoryMcCune Genau richtig !!
Sie können auch Schritte zum Reproduzieren hinzufügen. Es hilft dem Leser, durch Ihren Bericht zu gehen und die Probleme selbst zu reproduzieren, zumal der Leser normalerweise nicht als Sicherheitsexperte oder notwendigerweise sogar als Sicherheitssinn angesehen wird
Wenn Sie anstelle eines Standards wie cvss Ihre eigene Risikoklassifizierung verwenden, fügen Sie deren Definition ebenfalls in das Dokument ein
Oh, und ich mag es normalerweise, ein Angriffsszenario für alles zu sehen / einzuschließen, was als kritisch oder hoch eingestuft wird, damit ein Laie das Risiko verstehen kann.
Awhitehatter
2013-01-25 04:12:25 UTC
view on stackexchange narkive permalink

Spannende Frage! Zu oft habe ich das Gefühl, dass unsere Branche nach der neuesten und größten Modeerscheinung im Bereich Sicherheit strebt. Wir gehen den neuesten Exploits nach, geben viel Geld für die neuesten Tools aus und machen Schicht 8 für die Lücken verantwortlich. Ich weiß, dass dies eine grobe Verallgemeinerung ist, aber ich wollte die Bedeutung dieses Themas unterstreichen - Berichterstattung!

Ich habe meine Meinung dazu, was in einem Schwachstellenbericht enthalten sein sollte. Aus struktureller Sicht enthält ein ausführlicher Bericht Folgendes:

  • Eine Titelseite : Hier wird der Name des Berichts, die Agentur oder Abteilung angegeben, für die er bestimmt ist , das Datum, an dem der Bericht veröffentlicht wurde.

  • Ein Inhaltsverzeichnis : Scheint offensichtlich, aber diese Dokumente können langwierig werden.

  • Eine Zusammenfassung : Dies ist eine allgemeine Zusammenfassung der Ergebnisse, der gefundenen Ergebnisse und des Endergebnisses.

Eine Einführung : Eine einfache Erklärung Ihrer Qualifikationen, des Zwecks des Audits und des Umfangs.

  • Ergebnisse : Dieser Abschnitt enthält Ihre Ergebnisse und listet die Schwachstellen oder Probleme auf, die behoben werden sollten. Diese Auflistung sollte nach kritischen Ebenen geordnet sein, von denen hoffentlich durch interne Richtlinien definiert wird (dh wenn Ihr Schwachstellenscanner eine hochkritische Schwachstelle findet, basierend darauf, wie diese Schwachstelle in Ihrer Umgebung implementiert ist, ist sie möglicherweise nicht wirklich hochkritisch Interne Richtlinien sollten bei der Definition der kritischen Ebenen hilfreich sein.

  • Methoden : Hier werden die verwendeten Tools erläutert, wie Fehlalarme ausgeschlossen wurden und welche Prozesse abgeschlossen wurden diese Prüfung. Dies dient dazu, Konsistenz zu gewährleisten und zu ermöglichen, dass Ihre Audits wiederholt werden können, falls eine Feststellung bestritten wird oder vom Management als nicht berichtenswert erachtet wird.

    li

    Schlussfolgerung : Grundlegende Schlussfolgerung: Fassen Sie die Informationen zusammen, die Sie bereits zusammengestellt haben.

  • Anhänge : Dies sind alle zusätzlichen Anhänge, die als Referenz benötigt werden.

  • Einige der Leute, die an der PTES arbeiten, legen einige gute Grundlagen. Während der Schwerpunkt dort auf Penetrationstests liegt, würde ich denken, dass viele der Methoden, insbesondere die Berichterstattung, für eine Prüfung umgesetzt werden könnten. Sie können sie unter http://www.pentest-standard.org/index.php/Reporting überprüfen.

    Diese Antwort ist zusammen mit @RoryMcCune's die vollständigste und sollte wirklich mehr Up-Votes erhalten als derzeit meiner Meinung nach. Dieser PTES-Link, den Sie einfügen, war auch das erste, woran ich beim Lesen der Frage dachte. Ich bin sicher, dass viele Gedanken und Erfahrungen in die Vorbereitung gesteckt wurden, umfassend sind und einen guten Einblick in den Umfang der Pen-Tests im Allgemeinen geben. Es sollte auch ein guter Anfang für Sicherheitsüberprüfungen sein, wenn auch möglicherweise ein wenig überwältigend für LOL. Ebenfalls relevant: http://www.pentest-standard.org/index.php/Intelligence_Gathering (und ehrlich gesagt das meiste von diesem Wiki).
    rook
    2013-01-24 22:24:11 UTC
    view on stackexchange narkive permalink

    Nach einem Penetrationstest oder einer Hybridanwendungsanalyse konzentriert sich der resultierende Bericht auf die Ergebnisse. Es sollte eine allgemeine Übersicht geben, in der die Fehler und ihre kollektiven Auswirkungen auf das System erörtert werden.

    Eine Feststellung ist eine Sicherheitsverletzung. Dies schließt alle CWE-Verstöße ein, aber die häufigsten Ergebnisse von Webanwendungen fallen unter die OWASP-Top 10. Jede Feststellung sollte Schritte zur Reproduktion des Problems, einen Schweregrad, die Auswirkungen dieses Fehlers und Empfehlungen zur Behebung des Problems enthalten Ausgabe und Links mit weiteren Informationen. Wenn Sie beispielsweise eine XSS-Sicherheitsanfälligkeit feststellen, zeigen Sie eine Bildschirmkappe eines Warnfelds und die URL an, mit der Sie das Problem ausgelöst haben, und verknüpfen Sie die OWASP-Seite in XSS. Wenn Sie mit XSS auf das Cookie zugreifen können, kann das Problem zum Entführen einer Sitzung verwendet werden. Andernfalls kann der CSRF-Schutz untergraben werden.

    Was ist, wenn Sie nichts finden können? Weiter suchen! Das CWE-System ist massiv und selbst die erfahrensten Entwickler machen Fehler. Es gibt Schwachstellen, die sich auf jede Anwendung auswirken, die ich berührt habe. Clickjacking, mangelnder Brute-Force-Schutz und Offenlegung von Informationen sind wahrscheinlich am häufigsten. Zum Beispiel die Offenlegung von Benutzername / E-Mail-Adresse über das vergessene Passwort oder die Anmeldefunktion. Anzeigen von Versionsnummern (http-Header oder irgendwo anders). Ausführliche Fehlermeldungen, lokale Pfade, interne IP-Adressen ... alles, was für einen Angreifer nützlich sein könnte.

    Zuallererst +1 für die geschätzte Anstrengung. Aber die meisten Antworten sind hier irrelevant. Sie schlagen Dinge vor, nach denen Sie suchen sollten. Mein Problem ist nicht, wie ich das Audit durchführen soll, sondern die Ergebnisse selbst auf professionelle Weise auszugeben. Ich denke, der hilfreiche Teil dieser Antwort ist der zweite Absatz. Könnten Sie das bitte näher erläutern? Vielen Dank.
    Lex
    2013-01-24 22:32:18 UTC
    view on stackexchange narkive permalink

    Ich denke, was Rook sagt, ist sehr wahr, obwohl es mehr um den Kern des Berichts als um seine Struktur geht, die nach dem Entwurf des Berichtsformats platziert werden soll.

    Probieren Sie das STAR-Modell aus ( Situation, Aufgabe, Aktion & Ergebnis): Ich habe großartige Berichte gesehen, die mit diesem Modell unter der Haube geschrieben wurden. Das Tolle daran ist, dass es in fast allen Kontexten verwendet werden kann: Sie müssten sich nur an das anpassen, was für Sie relevant ist. In diesem Fall können Sie Ihren Bericht um dieses Modell herum strukturieren und das, was Rook beschrieben hat, verwenden, um die Struktur auszufüllen.

    Auch wenn Sie keine tatsächlichen Ergebnisse haben, können Sie dennoch einen vollständigen Bericht auf der Grundlage des STAR-Modells verfassen und dennoch etwas liefern, das professionell und kohärent ist.

    Ausgezeichnet, das geht eher in die Richtung, nach der ich suche.
    Colin Cassidy
    2013-01-25 17:46:44 UTC
    view on stackexchange narkive permalink

    Ich habe noch nie einen Sicherheitsüberprüfungsbericht geschrieben, obwohl ich ihn in meiner Rolle eher erhalte. Das Beste, was wir über unser gesamtes Produkt in bestimmten Bereichen von Interesse untersucht hatten. Der Bericht wurde in diese Bereiche unterteilt. Insgesamt lautete das Format:

    1. Titel
    2. Zusammenfassung - eine kurze Übersicht über Zweck und Umfang der Prüfung. Und hochrangige Kommentare zu den Hauptproblembereichen und vor allem zu den Bereichen, die gut gemacht sind.
    3. Bewertungsmethode
    4. Systembeschreibung - für die untersuchte Bereitstellung
    5. Dann wurden Abschnitte zu jedem Bereich / Ziel
    6. Zusammenfassung und Empfehlungen
    7. ol>

      Abschnitt 5 für jedes Ziel wie folgt aufgeteilt:

      1. Einführung
      2. Ziel
      3. Bedeutung
      4. Bewertung (unter Berücksichtigung von Methoden und tatsächlichen Schwachstellen)
      5. Schlussfolgerung
    F. Hauri
    2013-01-25 19:03:47 UTC
    view on stackexchange narkive permalink

    Zuerst: Es ist wie beim Schreiben eines Buches, die erste Zeile hält den Leser oder nicht. (Das Intro soll mindestens schreiben.)

    So etwas wie Intro, Anfang, Inhalt, Ende.

    • Einführung
    • Ziele
      • Vertragsbedingungen aktualisieren.
      • Beschreibung der Ziele
      • Beschreibung der Methoden
    • Ausführung
      • Schritt für Schritt: Ziel, Aktion, Reaktion
      • Beobachtungen -> Fragen
      • weitere Operationen, Schritt Schritt für Schritt
      • Neue Beobachtungen ...
      • wieder weiter ... und noch einmal, falls
    • Schlussfolgerung
      • Erfolg oder nicht
      • was eindeutig falsch ist, geändert werden muss
      • was fehlschlägt, korrigiert werden muss
      • Zwecke

    Einige Tricks, die Sie beachten müssen:

    1. Ihre Arbeit ist nicht dazu gedacht, von technischen Mitarbeitern gelesen zu werden. Versuchen Sie also, einfach zu bleiben, aber
    2. Ihre Arbeit muss von Fachleuten gelesen werden, um Ihre Empfehlungen zu validieren oder anzuwenden. Vergessen Sie also nichts !! Ihre Arbeit muss genau, umfassend und unanfechtbar sein.
    3. Da es sich bei Ihrem Job um Sicherheitsfehler handelt, müssen Sie einige Verschleierungen vornehmen, z Paar Benutzername, Passwort kann eine gute Praxis sein, sie müssen im Intro erwähnt werden, aber dies könnte nützlich sein, um weiter zu diskutieren.
    4. ol>

      Also, um für die Administratoren leicht zu bleiben, Einführung und Schlussfolgerung müssen auf einfache Weise erklärt werden, möglicherweise in Bildsprache, und

      , um für technische Leute, die Ihren Text umgehen müssen, leicht zu bleiben, müssen genau und detailliert sein. Vielleicht könnte ein einfacher Konsolendump mit einigen Kommentaren ausreichen.

    GdD
    2013-01-24 22:32:33 UTC
    view on stackexchange narkive permalink

    Das klingt vielleicht wie eine Ausrede, ist es aber nicht, und das heißt, Sie müssen einfach fragen, welches Format sie mögen. Ich habe alle möglichen Überprüfungen durchgeführt und die meisten Unternehmen haben ein Format dafür, welche Informationen sie mögen und wie sie es mögen. Wenn Sie frühere Berichte als Vorlage anzeigen möchten, sparen Sie viel Zeit.

    Ich muss Ihnen nicht zustimmen, obwohl das Unternehmen eine eigene Vorlage für bestimmte Aufgaben hat. Ich bin jedoch der Meinung, dass ein Sicherheitsüberprüfungsbericht ein mehr oder weniger standardmäßiges Format haben sollte. Was wäre, wenn das Unternehmen einen Dritten beauftragen würde, das Problem zu beheben?
    @Adnan, als Dritter, der häufig Sicherheitsbewertungen durchführt Ich kann Ihnen sagen, dass ich immer versuche, das Berichtsformat des Kunden zu verwenden. Vielleicht hat Ihr Unternehmen keine, aber es lohnt sich zu fragen, da Sie viel Zeit sparen könnten.
    Ich muss diesem zustimmen. Ich verstehe den Einwand von @Adnan's, aber der *** Zweck *** für einen solchen Bericht ist (oder sollte), das Unternehmen dazu zu bringen, *** Probleme *** so schnell wie möglich zu verstehen *** und *** zu beheben. Jedes Unternehmen hat eine aufgebaute Unternehmenskultur und entwickelt gemeinsame Kommunikationsmethoden. In guten Fällen sprechen die verschiedenen Geschäftsbereiche alle "dieselbe Sprache", einschließlich der schrittweisen Annahme ähnlich aussehender Berichte, ähnlich aussehender Memos usw. Wenn Sie möchten, dass das Unternehmen schnell handelt, geben Sie es ihnen in dem Format, das sie möchten müssen es nicht in etwas "übersetzen", das sie verstehen.
    Trotzdem stimme ich auch zu, dass ein Bericht immer einige Dinge enthalten sollte. Die "Anpassung an das Geschäft" bezieht sich darauf, wie die Informationen präsentiert werden, nicht darauf, welche Informationen präsentiert werden.
    Auf diese Weise kann ich jetzt beide Seiten davon sehen. Vielen Dank, David & GdD.
    Shritam Bhowmick
    2017-05-03 08:32:53 UTC
    view on stackexchange narkive permalink

    Wie rekonstruiere ich diese Situation? &, was genau spreche ich an?

    Ich konstruiere Sicherheitsoperationen für &-Architekten, um meinen Lebensunterhalt zu verdienen. Ich habe mich seit einem Jahrzehnt mit Anwendungssicherheitsberichten befasst. & war sich ziemlich sicher, was aufgenommen werden soll. &, wo sie aufgenommen werden sollen. Präsentation wird wichtig sein.

    Ich habe mir ziemlich viele Gedanken darüber gemacht. Wenn ich mir alle Antworten ansehe, denke ich, dass die fehlenden Teile zusammen mit der definitivsten Antwort & das Wissen fokussieren sollten.

    Zunächst möchte ich sagen: - Bitte verwechseln Sie nicht zwischen einem Assessment & und einem Audit . Das Audit verfügt über Audit-Trails, ein Assessment enthält wichtige technische Details. Der Originalbeitrag besagt, dass ein Audit für die Anwendungen durchgeführt wurde, was nicht möglich war. Technisch gesehen waren es Assessments.

    Ich habe einige davon aufgegriffen, einschließlich der am CERN verfolgten Methodik, Ref: http://pwntoken.github.io/enterprise-web -Anwendungssicherheitsprogramm /. Zu meinem Erstaunen sind die technischen Details, die als Sicherheitsbewertung dienen, meistens eher für den Entwickler & It Operations als für die Geschäftsinteressenten hilfreich. Wenn Sie versuchen, eine Anwendung oder einen Satz von Anwendungen auf einer öffentlichen Schnittstelle zu prüfen, bringen Sie sie zum Stakeholder der Anwendung.

    An den Punkten meines Beispiel-Anwendungsberichts sehen Sie folgendermaßen aus (ich entschuldige mich dafür die Kritzeleien waren sozusagen absolut notwendig, mussten aber gemäß den NDA-Normen abgenommen werden):

    enter image description here enter image description here enter image description here

    Lassen Sie uns erklären, was diese Komponenten in Schlüsselzeigern sind:

    1. Die erste ist die Schwachstellenklassifizierung : z. für XSS könnte es als Code Injection geschrieben werden. Für Shell Injection ist Interpreter Injection ein genauerer Begriff. In ähnlicher Weise sollte für SQL Injections anstelle von MS-SQLi oder MySQli die Klassifizierung Database Injection sein.
    2. Der nächste Titel lautet Vulnerability Title : Für Database Injection kann er in einem Liner immer genauer sein, z. B. UNION-BASIERTE MySQL-Injection führt zu Kompromissen auf Befehlsebene .
    3. Als nächstes folgt Risikobewertung : Meiner Meinung nach würde ich WASC oder irgendetwas anderes verwenden, aber ich habe unsere eigene benutzerdefinierte Bewertungsschaltung bevorzugt. Sie können nach OWASP , WASC oder anderen suchen, wenn Sie aufgefordert wurden, sich an eine bestimmte Methode zu halten. NIST ist einer, wenn Sie sich hauptsächlich mit Netzwerksicherheit befassen.
    4. Beschreibung : Dies sollte so detailliert wie möglich sein. Es kann manchmal vorkommen, dass ein Klassifizierungssatz aufgrund der Bedrohung durch Business Logic nicht gefunden wird. Für diese ist es notwendig, ein gutes Verständnis für den Kontext & zu haben, warum das Angriffsszenario als solches dargestellt wird.
    5. Auswirkung : Auch hier würde ich sagen, dass dies harte Hinweise sind in Kugeln. Das ist gesund. & ist auch für Geschäftsinteressenten hygienisch.
    6. Proof Of Concept : Ich denke, das ist ziemlich selbsterklärend. Fügen Sie jedoch Details einschließlich Screenshots hinzu. Eine weitere Eingabe wäre, dass Sie betroffene Parameter einschließen. & notiert auch den Endpunkt, falls es sich um eine API handelt, die zusammen mit den POST-Parametern betroffen ist, falls vorhanden.
    7. Empfehlung & Remediation : Ich denke, das ist auch erklärend. Behalten Sie eine generische Vorlage für die OWASP Top 10 , SANS 15 & WASC Top 26 . Verwenden Sie im Übrigen manuell geschriebene kontextbasierte Empfehlungen, um Ihren IT-Betrieb zu unterstützen.
    8. Verantwortung übernehmen : Wer repariert? In Ihrem Fall sind Sie es!
    9. ol>

      Hoffe, dies wird helfen.

    Anthony
    2017-04-05 08:39:49 UTC
    view on stackexchange narkive permalink

    Wenn das Ziel eines Sicherheitsüberprüfungsberichts darin besteht, das Management davon zu überzeugen, festgestellte Sicherheitslücken zu beheben, möchten Sie die Auswirkungen einer Nichtbehebung der Probleme beschreiben. Als IT-Prüfer stoße ich häufig auf Widerstand von nicht-technischen Mitgliedern des Managements zu Empfehlungen, die ich mache, wie zum Beispiel:

    1. Die Implementierung ist zu kostspielig.
    2. Es gibt nicht genug Rendite für das Unternehmen, um den Aufwand zu rechtfertigen.
    3. Kein greifbarer wirtschaftlicher Nutzen
    4. ol>

      Sie möchten in Ihrem Bericht beschreiben, welche Auswirkungen die Nichtbehebung von Sicherheitslücken auf geschäftliche Begriffe wie:

      1. Die Kosten für verlorene Geschäfte betragen ungefähr X Dollar, wenn eine Sicherheitslücke von einem Gegner ausgenutzt wird.
      2. X Stunden Ausfallzeit (RTO) werden sich ergeben, während derer wir werden Sie können unsere Kunden aufgrund einer Bedrohung, die eine Sicherheitsanfälligkeit für die Verfügbarkeit unserer Systeme ausnutzt, nicht bedienen.
      3. ol>

        Zusammenfassend ist es Ihr Ziel, Business Buy-i zu erzielen n damit die Sicherheit von einer reinen IT-Funktion in eine Funktion mit negativen wirtschaftlichen und nichtwirtschaftlichen Auswirkungen (z. B. Reputationsschäden) umgewandelt wird, wenn Schwachstellen nicht beachtet werden.



    Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 3.0-Lizenz, unter der er vertrieben wird.
    Loading...