Web Application Firewall

WAF chroni aplikacje internetowe, kierując je na ruch związany z protokołem HTTP (Hypertext Transfer Protocol). Różni się to od standardowego firewalla, który stanowi barierę między zewnętrznym i wewnętrznym ruchem sieciowym.

WAF znajduje się pomiędzy użytkownikami zewnętrznymi a aplikacjami internetowymi i analizuje całą komunikację HTTP. Następnie wykrywa i blokuje złośliwe żądania zanim dotrą one do użytkowników lub aplikacji internetowych. W rezultacie WAF chroni krytyczne dla biznesu aplikacje i serwery internetowe przed zagrożeniami zero-day i innymi atakami w warstwie aplikacji. Jest to coraz ważniejsze, ponieważ firmy rozwijają nowe inicjatywy cyfrowe, które mogą sprawić, że nowe aplikacje internetowe i interfejsy programowania aplikacji (API) będą podatne na ataki.

Firewall sieciowy chroni zabezpieczoną sieć lokalną przed nieautoryzowanym dostępem, aby zapobiec ryzyku ataków. Jej głównym zadaniem jest oddzielenie strefy zabezpieczonej od mniej zabezpieczonej i kontrolowanie komunikacji między nimi. Bez niej każdy komputer z publicznym adresem IP jest dostępny poza siecią i potencjalnie narażony na atak.

Kluczową różnicą techniczną pomiędzy firewallem na poziomie aplikacji a firewallem na poziomie sieci jest warstwa bezpieczeństwa, na której działają. Są one definiowane przez model OSI (Open Systems Interconnection), który charakteryzuje i standaryzuje funkcje komunikacyjne w systemach telekomunikacyjnych i obliczeniowych.

WAF-y chronią przed atakami w warstwie 7 modelu OSI, czyli na poziomie aplikacji. Obejmuje to ataki na aplikacje, takie jak Ajax, ActiveX i JavaScript, a także manipulacje plikami cookie, wstrzykiwanie kodu SQL i ataki na adresy URL. Ich celem są również protokoły aplikacji internetowych HTTP i HTTPS, które są wykorzystywane do łączenia przeglądarek internetowych z serwerami WWW.

Na przykład, atak DDoS warstwy 7 powoduje zalew ruchu do warstwy serwera, gdzie strony internetowe są generowane i dostarczane w odpowiedzi na żądania HTTP. WAF łagodzi ten problem działając jako odwrotne proxy, które chroni docelowy serwer przed złośliwym ruchem i filtruje żądania w celu zidentyfikowania użycia narzędzi DDoS.

Zapory sieciowe działają w warstwach 3 i 4 modelu OSI, które chronią transfer danych i ruch sieciowy. Obejmuje to ataki na system nazw domen (DNS) i protokół transferu plików (FTP), a także protokół SMTP (Simple Mail Transfer Protocol), Secure Shell (SSH) i Telnet.

1. Zła organizacja projektu, brak rozpisania i omówienia poszczególnych faz projektu. Wdrożenie powinno być podzielone na przynajmniej pięć kroków:

• Określenie oczekiwań związanych z nowym systemem
• Wybór dostawcy
• Doprecyzowanie modelu współpracy, podpisanie umów
• Faktyczne wdrożenie (instalacja, szkolenia)
• Podsumowanie i wnioski

2. Złe określenie oczekiwań

Częstym błędem jest skupienie się na zakupie i wdrożeniu systemu informatycznego, a nie na określonych funkcjach bezpieczeństwa.

3. Brak dokładnych analiz funkcjonalności systemu.

WAF który ma chronić zasoby organizacji musi być dokładnie przemyślany. Jeśli przewidujemy zwiększenie obciążenia systemu lub jego komponentów, przetestujmy wcześniej możliwości poszczególnych rozwiązań.

4. Brak menedżera projektu

Ważną sprawą jest wyznaczenie osoby odpowiedzialnej za prowadzenie projektu. Jeśli wybieramy do tego osobę, która ma również inne obowiązki, to ryzykujemy niepowodzenie tego projektu.

5. Za słabe umocowanie menedżera

Klasyczny problem zarówno nowych osób (nie znają struktury i nieformalnych zwyczajów w firmie), jak i awansowanych. Menedżer od początku musi mieć bardzo mocną pozycję i silne wsparcie sponsora projektu (najczęściej zarządu). Brak takiej pozycji może spowodować ucieczkę ludzi do innych prac poza wdrożeniem.

6. Brak odpowiedniej liczby osób zaangażowanych w projekt

Jeśli przy wdrożeniu mają pracować osoby, które jednocześnie muszą zająć się bieżącymi sprawami, to na pewno najpierw będą wykonywać te bieżące sprawy, a później … zabraknie czasu na wdrożenie. Pod żadnym pozorem nie można na tym oszczędzać.

7. Zła komunikacja wewnętrzna

Informatycy i przedstawiciele biznesu często mówią innymi językami. Jeśli menedżer projektu nie rozumie obu należy zadbać o taką integrację przedstawicieli obu pionów, aby po wdrożeniu nie okazało się, że tylko jeden z działów jest zadowolony (najczęściej zupełnie nie ten, który miał w założeniu na tym zyskać).

8. Pozorne oszczędności

Często ze względów politycznych wybiera się opcję, która jest tańsza w chwili wdrożenia, jednak łączne koszty są większe. Te dodatkowe koszty można jednak ukryć i określić jako niezwiązane z wdrożeniem. Przykładem może być zakup tańszego oprogramowania na końcówki zamiast terminalowego, który wymaga wymiany stacji roboczych. Oszczędności na systemie nie rekompensują kosztów wymiany komputerów, jednak wykonuje się tą wymianę pozornie bez związku z zakupem systemu.

9. Wymuszenie na dostawcy prac, których się nie chce podjąć

Przy wyborze dostawcy ważne jest dokładne słuchanie tego, co dostawca chce nam zaoferować. Czasami propozycje dostawcy wynikają z większej niż nasza wiedzy o procesach biznesowych, a czasami z braku możliwości zaimplementowania pewnej funkcjonalności w swoim systemie. Generalnie największym błędem jest zmuszenie dostawcy (np. ceną) do podjęcia się realizacji funkcjonalności lub terminu, który z góry uważają oni za zagrożony. Niemal na pewno zaowocuje to błędami wdrożenia.

10. Założenie, że czas jest z gumy

Jeśli prowadzący lub sponsor projektu już przy jego starcie zakłada, że w razie opóźnień pracownicy podgonią pracując po godzinach, czy w soboty, to na pewno projekt się przedłuży. Planując harmonogram należy zakładać ortodoksyjne podejście do czasu pracy. Nieprzewidzianych wypadków będzie na tyle dużo, że i tak trzeba będzie zaangażować ludzi ponad miarę.