Bei der Bereitstellung von Sicherheit empfiehlt es sich häufig, mehrere Ebenen anzuwenden. Nur weil Sie ein Schloss an Ihrer Schlafzimmertür haben, heißt das nicht, dass Sie kein Schloss an der Haustür Ihres Hauses anbringen. Sie können auch einen generischen Satz von WAF-Regeln vor mehreren Anwendungen anwenden.

Eine WAF kann Teil einer größeren Suite für IDS / IPS sein. Dies kann auch zur Leistung der Anwendung beitragen, wenn die WAF ist inline, damit die Anwendung keine Ressourcen für das Blockieren, Protokollieren, Datenbankabfragen usw. verschwendet.

Sie gehen auch davon aus, dass die Organisation über die Ressourcen und Fähigkeiten verfügt, um angemessene Sicherheit zu erlangen die Sicherheit ihrer Anwendung. Wenn es sich um eine Drittanbieteranwendung handelt oder Module von Drittanbietern enthält, können diese Komponenten möglicherweise nicht einfach aktualisiert werden oder es handelt sich um Closed Source oder gegen die Lizenz zum Ändern des Programms.

Viele Organisationen sind mit Legacy-Anwendungen ausgestattet, die von längst vergangenen Entwicklern geschrieben wurden. WAFs sind eine Möglichkeit für diese Organisation, sich vor Angriffen auf diese Anwendungen zu schützen.

WAFs sind auch beim Bereitstellen von Fixes viel schneller. Das Aktualisieren komplexer Anwendungen kann Wochen oder Monate dauern. Der Schutz von WAFs wird häufig innerhalb von Stunden aktualisiert.

Es ist auch Kosten-Nutzen-Verhältnis. Einige WAFs sind sehr gut darin, Anwendungen zu schützen. Warum also Millionen für das Umschreiben älterer Anwendungen ausgeben, die in einem Jahr auslaufen werden?

Nein, aber nur wenige Anwendungen sind vollständig sicher. Ein WAF ist eine Möglichkeit, Angriffe abzuwehren, bevor sie tatsächlich Ihre Anwendung erreichen. Darüber hinaus können Sie böswillige Benutzer leicht identifizieren und automatisch blockieren.

WAFs dienen nicht dazu, Ihre Anwendung zu reparieren. Sie dienen dazu, Angriffe zu verhindern und manchmal abzuschwächen. Wenn Ihre Anwendung sicher ist, die Sprache jedoch nicht geschrieben ist, können manchmal mildernde Maßnahmen ergriffen werden, um Angriffe zu verhindern, bis ein Fix veröffentlicht wird.

Unternehmen müssen sich die Funktionen ansehen, die WAFs bieten können, die herkömmliche Webanwendungen nicht bieten (oder die im Allgemeinen nicht codiert sind).

Beispielsweise haben WAFs im Allgemeinen eine Art "Antwort" Mechanismus eingebaut. Im Falle eines Angriffs können sie automatisch reagieren, um die Anwendung zu schützen. Dies kann Brute-Force-Schutz, DOS (bis zu einem gewissen Grad) und das Sperren von Anforderungen von bestimmten IP-Adressen umfassen. Sie könnten Ihre Anwendung dazu codieren, aber ein WAF befindet sich an Ihrem Umfang. Es ist am besten, böswilligen Datenverkehr dort und dann weiter in Ihrem Netzwerk zu stoppen. Darüber hinaus kann eine netzwerkbasierte WAF mehrere Websites schützen und möglicherweise die erforderliche Entwicklungszeit verkürzen.

Ein wesentlicher Vorteil liegt in der Erkennung von Angriffen / Protokollierung. Wenn Ihre WAF einen Angriff erkennt, kann sie diese Informationen an eine SIEM-Lösung weitergeben. Die WAF verfügt über Signaturen, um Angriffe auf eine Vielzahl von Backends zu erkennen, nicht nur auf das von Ihnen erstellte. Ihr Sicherheitspersonal könnte diese Informationen dann verwenden, um die beste Vorgehensweise zu ermitteln. Vielleicht korrelieren sie es mit anderen Angriffen usw.

Ein weiteres wichtiges Merkmal ist, dass die WAF sowohl zum Schutz des Webservers als auch der Webanwendung verwendet werden kann. Beispielsweise können WAFs so konfiguriert werden, dass Pufferüberlaufangriffe gegen IIS selbst gestoppt werden. Ihre Webanwendung kann dies nicht.

Schließlich können WAFs zum "virtuellen Patchen" verwendet werden. Angenommen, Sie stellen fest, dass Ihre Webanwendung eine Sicherheitslücke aufweist, wenn eine bestimmte Anfrage gesendet wird. Sie können den Code natürlich ändern. Dies kann jedoch einige Zeit dauern (Änderungsmanagement, Aufforderung an den Entwickler, etwas zu schreiben, Tests usw.). Während Sie auf einen Patch vom Entwicklungsteam warten, kann eine Signatur erstellt werden, um die Website vor diesem Angriffsvektor zu "schützen".

Eine Sache, die hinzugefügt werden muss, entspricht der Antwort von @Lucas Kauffmans. Bei Sicherheit dreht sich alles um Schichten. Sie können nicht sicher sein, dass Ihre Webanwendung "vollständig" sicher ist. Das Hinzufügen einer weiteren Ebene davor tut nicht weh.

WAFs waren ein heißes Thema, seit sie zum ersten Mal mit vielen Sicherheitsleuten auf beiden Seiten der Debatte "brauche es / brauche es nicht" eingeführt wurden . Ich denke, dass alles auf die Fähigkeiten ankommt, die Sie für Ihre gegebene Situation benötigen.

WAFs sind eine Reaktion auf die Verantwortungslosigkeit, alles auf Web-Ebene ausführen zu lassen. Sagen wir es so: Früher hatten wir Dienste, die in verschiedenen Ports ausgeführt wurden. Schon bald mussten Firewalls erstellt werden, um zu verhindern, dass bestimmte Dienste wahllos für jeden geöffnet werden, der sie prüfen wollte. Also wurden Dienste gefiltert und das einzige, was Ihnen erlaubt wäre, wäre beispielsweise über Port 80. Also, was machen die Leute? Dienste über Port 80 verfügbar machen. Jetzt haben Sie die Möglichkeit, Dienste über Port 80 zu verwenden, die zuvor über eine normale Firewall über ihre spezifischen Ports gefiltert wurden.

Die Geschichte scheint sich zu wiederholen: Menschen erstellen unsichere Dienste, sicherheitsbewusste Menschen setzen Sicherheitsbeschränkungen ein, die die Benutzerfreundlichkeit beeinträchtigen. Daher versuchen die Menschen, Dinge auf andere Weise zu öffnen (in diesem Fall) , "Lass uns alles über 80 setzen"); Dies wiederum zwingt die sicherheitsbewussten Personen, das Thema erneut zu behandeln und in diesem Fall die Firewall auch für das Web anzupassen. Dies ist ein ständiger Kompromiss zwischen Sicherheit und Benutzerfreundlichkeit.

Die Frage, ob heutzutage ein WAF verwendet werden soll, entspricht der Frage, ob vor fünfzehn Jahren eine Firewall verwendet werden sollte.

No. In fact, implementing a WAF increase the attack surface making your infrastructure vulnerable now to also the attacks against the WAF.

Deploying a WAF is a pragmatic measure because you suppose that the application may have vulnerabilities that the WAF may protect against, but here we are in a field where nobody is completely sure of nothing and administrators do what they feel is right.

In my opinion, the really right thing to to is implement in the site the necessary security measures and processes. If you have this control over the application code and development process you don't need a WAF. But this situation is not always possible.

Wenn es 100% sicher ist, benötigen Sie theoretisch keine Firewall. In der Praxis können Sie nicht 100% sicher sein, dass die App nicht anfällig ist. Sie sollten der App nur die erforderlichen Berechtigungen erteilen. Wie Sie eine Such-App haben, können Sie nur eine bestimmte Tabelle durchsuchen. Es wird einen Angriff nicht stoppen, aber einen begrenzen.

Hinweise zu Lebenszyklen und Bereitstellungszeit.

Wie oben erwähnt, wirken sich die Lebenszyklen von Anwendungen erheblich auf die Reparaturzeit aus.

Webanwendungen in Ein Unternehmen oder eine andere Organisation gibt es in allen Formen und Größen.

• Werbung von der Stange, derzeit unter aktiver Unterstützung.
• Werbung von der Stange, alt und veraltet, Versionen dahinter.
• Kommerziell von der Stange, vom Hersteller nicht unterstützt.
• Selbst entwickelt, derzeit unter aktiver Unterstützung.
• Selbst entwickelt, aber ohne Support-Crew oder ausgelagert Support mit anfallenden Kosten.
• Open Source ohne Supportvereinbarung / ohne Patches.
• Benutzerdefinierte Webanwendung ohne aktuelle Supportvereinbarungen.

Und Die Webanwendung kann in einer Organisation unterschiedliche Verwendungszwecke haben.

• Kritisches / Kernsystem.
• Wichtiges System.
• Einmaliges System ohne aktuelle Bedeutung .
• Legacy-System ohne eindeutigen Geschäftsinhaber.
• Schneller und schmutziger Bereitstellungswitz Hout-Management-Aufsicht.

Bei all diesen Variablen kann es also viel Zeit und Mühe kosten,

• Sicherheitsprobleme zu untersuchen und den Pfad zu aktualisieren Auswirkungen des Upgrades.
• Starten Sie ein Entwicklerteam / vereinbaren Sie einen Vertrag / erhalten Sie Unternehmensfinanzierung.
• Beschleunigen Sie die Anwendung.
• Holen Sie sich die Sicherheitsupdates entwickelt / getestet und auf Regression getestet.
• Um es dann bereitzustellen, stellen Sie Support-Vereinbarungen usw. sicher.

Die Verwendung einer Web-App-Firewall kann also alle diese Ebenen durchschneiden und a implementieren schnell und ohne viel Geld / Zeit / Mühe zu beheben.

Always, WaF'a add an extra layer of security which can be updated as new vulnerabilities are discovered.. your application may be secure today but broken tomorrow