Standard aplikacji WWW Urzędu Miasta Olsztyna

Transkrypt

1 Standard aplikacji WWW Urzędu Miasta Olsztyna Dokument wydrukowany i nie podpisany jest dokumentem nienadzorowanym. Opracowali: Sprawdzili: Zatwierdzili: Mariola Iciak Andrzej Dziewit Rafał Ruchlewicz przy współpracy firmy ARTSYSTEMS Artur Cieślik Mariusz Kalista Data: Data: Data: Pełny zakres dostępu do dokumentu odczyt, modyfikacja, usuwanie, dodawanie: 1. Główny Administrator Bezpieczeństwa Systemów 2. Administrator Bezpieczeństwa Informacji. Zakres dostępu do dokumentu odczyt: 3. Podmioty i instytucje upoważnione na podstawie przepisów prawa. 4. Pracownicy Wydziału Informatyki. Strona 1 z 7

2 KARTA ZMIAN: Nr Opis dokonanej zmiany w treści dokumentu Data zmiany Podpis uprawnionego pracownika Strona 2 z 7

3 Spis treści Spis treści Cel Zakres Terminologia Realizacja Wymagania aplikacji Lista dokumentów związanych Załączniki... 7 Strona 3 z 7

4 1 Cel Celem dokumentu jest określenie minimalnych wymagań dotyczących bezpieczeństwa aplikacji webowych. Standard określa minimalne wymagania techniczne dla aplikacji oraz wymagania dotyczące przeprowadzenia testów penetracyjnych i konfiguracyjnych. 2 Zakres Dokument powinien stanowić załącznik SIWZ, dla wszystkich nowych aplikacji opartych o przeglądarkę webową. Dokument może być dostosowany pod względem technicznym do konkretnego SIWZ. Wszystkie posiadane aplikacje w miarę możliwości powinny spełniać wymagania niniejszego dokumentu. Kolejność spełniania wymogów należy wyznaczyć opierając się o analizę ryzyka. 3 Terminologia Brak. 4 Realizacja W przypadku realizacji nowego projektu zaleca się, aby wdrożenie aplikacji zgodnie z niniejszymi wymaganiami było audytowane przez inny podmiot zewnętrzny. Realizacja wymogów standardu odbywa się według następującej kolejności: 1. Wdrożenie aplikacji zgodnie z niniejszymi zaleceniami i uwzględnieniem wymogów stawianych Systemowi Teleinformatycznemu. 2. Audyt zgodnie z punktem 5.2 niniejszego dokumentu. 3. Poprawa błędów wynikających z audytu. 4. Audyt wdrożonych poprawek. 5. Wykonanie raportu końcowego oraz oddanie aplikacji do celów produkcyjnych. W uzasadnionych przypadkach audytu może dokonać podmiot wykonujący aplikację, przy czym powinien on złożyć szczegółowy raport z wykonanych prac. Raport powinien uwzględniać m.in: 1. Wykaz zastosowanych aplikacji testujących aplikację oraz środowisko wdrożeniowe zgodnie z punktem 5.5 niniejszego dokumentu. 2. Zakres audytu. 3. Wyniki audytu. 4. Zalecenia pokontrolne w przypadku, gdy problemy nie wynikają z prac wykonywanych przez podmiot dostarczający aplikację. 5 Wymagania aplikacji WWW 5.1 Wymagania budowy aplikacji Aplikacja oparta o przeglądarkę internetową powinna być zbudowana zgodnie z niżej wymienionymi zaleceniami: 1. W przypadku, gdy aplikacja ma współpracować z już istniejącymi aplikacjami, technologia może być taka sama lub kompatybilna w zakresie współpracy z aplikacjami i bazami danych istniejącymi już w środowisku produkcyjnym. 2. Dla aplikacji należy napisać politykę przed przystąpieniem do prac projektowych. Aplikacja powinna być zgodna z założeniami polityki (np. spełniać wymagania w zakresie możliwości zbierania logów, spełniać wymagania dotyczące haseł). Strona 4 z 7

5 3. Aplikacja przed wdrożeniem powinna przejść pozytywnie wszystkie testy wymienione w punktach 5.4 i Bezpieczeństwo aplikacji należy zapewnić wdrażając możliwie dużo zabezpieczeń zgodnych z prawem (np. CAPTCHA, klawiatura ekranowa do wprowadzania hasła, klucze generujące hasło użytkownikom, hasła maskowane itp.). Zaleca się uwzględnienie innych okoliczności towarzyszących budowie aplikacji (np. niepełnosprawności użytkowników). 5.2 Wymagania wstępne przeprowadzenia audytu Wymagania wstępne przeprowadzenia audytu aplikacji WWW powinny zawierać m.in. następujące etapy: 1. Określenie obszaru ataku (np. warstwa aplikacji, serwera www, bazy danych, systemu operacyjnego, aplikacje związane, interfejsy sieciowe i związane z nimi urządzenia sieciowe). 2. Określenie obszarów podwyższonego ryzyka (np. dostępu z uprawnieniami administracyjnymi). 3. Określenie zgodności ze standardami organizacji (napisanie planu audytu zgodnie z wymogami niniejszego dokumentu, oraz innymi standardami towarzyszącym wdrożeniu aplikacji). 4. Określenie planu (kolejności) przeprowadzenia audytu. 5. Uzyskanie zgody na przeprowadzenie audytu od Kierownictwa Urzędu Miasta Olsztyna. 6. Przeprowadzenie audytu. Zaleca się audytowanie elementów infrastruktury krytycznej przeprowadzać w okresach najmniejszego wykorzystania serwerów. 5.3 Analiza kodu aplikacji Wymagania dotyczące audytu kodu zamawianej aplikacji WWW powinna zawierać m.in. następujące etapy: 1. Analiza aplikacji pod kątem niepotrzebnego kodu (w tym kodu z komentarzy) oraz obsługi błędów. 2. Analiza kodu pod kątem przesyłania przez użytkownika danych, parametrów, zapytań itp. (analizę należy przeprowadzić przy świadomym braku zaufania dla użytkownika). 3. Analiza kodu pod kątem uprawnień, jakie aplikacja nadaje użytkownikowi. 4. Analiza systemu delegowania uprawnień użytkowników do bazy danych - o ile został zastosowany. 5.4 Analiza aplikacji z sieci wewnętrznej Analiza aplikacji ze strony sieci wewnętrznej powinna być zgodna z wymaganiami wstępnymi opisanymi w punkcie 5.1, w szczególności z obszarem ataku. Testom powinny zostać poddane wszystkie urządzenia biorące udział w połączeniu między klientami aplikacji, a serwerem na którym jest ona zainstalowana. Wymagania dotyczące audytu dostępu z wewnątrz sieci do aplikacji WWW powinny zawierać m.in. następujące etapy: 1. Test uwierzytelniania sieciowego. 2. Test szczelności VLAN-ów i poufności przesyłanych informacji. 3. Testy dotyczące ujawniania informacji o środowisku hostującym. 4. Testy penetracyjne systemów operacyjnych, baz danych, serwerów www, serwerów na których zainstalowana jest aplikacja www. 5. Testy typu DoS (np. flooding). 6. Ataki typu spoofing. 5.5 Analiza aplikacji z siec zewnętrznej sieci Aplikacja powinna zostać poddana testom w środowisku testowym. Testy powinny być przeprowadzane z poziomu: 1. Anonimowego dostępu do aplikacji. 2. Uwierzytelnionego dostępu do aplikacji. W skład testów wchodzą: Strona 5 z 7

6 1. Testy podstawowe (w których powinna znaleźć się zawsze aktualna lista dziesięciu najpopularniejszych ataków sieciowych- tzw. TOP 10 OWASP): a) Test penetracyjny styku z Internetem (przy konfiguracji produkcyjnej) w tym skuteczności urządzeń IDS/IPS. b) Manipulacje parametrami. c) Techniki podsłuchu i manipulowania transmisją (w tym Man in The Middle). d) Wywołanie strony serwisu spoza ścieżki przewidzianej przez projektantów aplikacji (Forcefull browsing). e) Atak Path Traversal. f) Technika Google Hacking (dotyczy aplikacji opublikowanych w sieci Internet). g) Filtrowanie danych wejściowych. h) Omijanie filtrowania danych wejściowych i wyjściowych. i) Ataki na sesję aplikacji webowej (session fixation i session adoption). j) Ataki typu Injection (np. SQL/XML/XPath/HTML/LDAP oraz innych zgodnie z technologią aplikacji) i Blind SQL Injection. k) Ataki XSS - Cross Site Scripting (persistent, reflected, itp.). l) Niepoprawna obsługa uwierzytelniania i sesji. m) Niezabezpieczone bezpośrednie odwołanie do obiektu (Insecure Direct Object References). n) Fałszowanie żądań (CSRF - Cross Site Request Forgery). o) Niepoprawne ustawienia (Security Misconfiguration). p) Brak zabezpieczeń dostępu przez URL (Failure to Restrict URL Access). q) Brak walidacji przekierowań (Unvalidated Redirects and Forwards). r) Błędy szyfrowania danych (Insecure Crytptographic Storage). s) Niedostateczne zabezpieczenia wymiany danych (Insufficent Transport Layer Protection). t) Atak typu brute force (sprawdzenie czy konto lub adres IP zostanie zablokowane). u) Testy dotyczące ujawniania informacji o środowisku hostującym. v) Testy typu DoS (np. flooding). w) Ataki typu spoofing. x) Ocena kompletności zbieranych informacji w logach. y) Ataki w celu rozpoznania aplikacji i platformy z) Próba podniesienia uprawnień 2. Środowiska hostujące powinny zostać zbadane pod kątem dobrze znanych luk w oprogramowaniu za pomocą testera podatności (vulnerability scanner). 5.6 Raport z audytu Raport z przeprowadzonego audytu stanowi podstawę do wdrożenia poprawek w aplikacji. 1. Opis skrócony dla kierownictwa. 2. Lista przeprowadzonych testów. 3. Metody testowania. 4. Zalecenia dla producenta aplikacji. 5.7 Audyt po wdrożeniu poprawek Audyt po wdrożeniu poprawek może swym zakresem obejmować całość analizy aplikacji opisanej w punktach 5.4 i 5.5. Minimalnie powinien zawierać testy sprawdzające, czy zalecenia dla producenta aplikacji z pierwszego raportu z audytu zostały spełnione. 5.8 Testy wydajnościowe Osoba odpowiedzialna za określenie wymagań technicznych (w szczególności SIWZ) dla aplikacji, powinna wyznaczyć planowane obciążenie serwerów (minimum dla czterech podstawowych parametrów fizycznych procesorów, pamięci fizycznej, dysków twardych oraz kart sieciowych) oraz łącza internetowego. Rozwiązanie powinno uwzględniać zapas wydajności sprzętu w każdej warstwie na poziomie minimum 100% od założonego obciążenia. Test Strona 6 z 7

7 wydajnościowy powinien wykazać, że platforma spełnia założenia projektu. Zaleca się określenie trzech punktów pośrednich pomiędzy obciążeniem planowanym, a maksymalnym. Raport z testu powinien być częścią Raportu końcowego oraz składać się z części: 1. Danych wyrażonych wartościami przy danym obciążeniu. 2. Danych przedstawionych na wykresie podsumowujący badanie wydajnościowe. 3. Opis wyników. Obciążenie należy badać przy planowanej konfiguracji platformy (np. konfiguracji logowań pracy). 5.9 Raport końcowy Raport końcowy powstaje po pozytywnym przejściu przez aplikację audytu po wdrożeniu poprawek. Raport końcowy powinien zawierać: 1. Opis skrócony dla kierownictwa. 2. Lista przeprowadzonych testów. 3. Metody testowania. 4. Określenie poziomu zgodności przez audytora. 6 Lista dokumentów związanych 7 Załączniki Strona 7 z 7