Bezpieczeństwo aplikacyjne

  • View
    213

  • Download
    1

Embed Size (px)

Transcript

  • Bezpieczeostwo aplikacyjne

    Aleksander P. Czarnowski

    AVET Information and Network Security Sp. z o.o.

  • Agenda

    Kilka sw o SDL

    Przypadki

    Cloud a bezpieczeostwo aplikacyjne

    Podsumowanie

  • SECURE DEVELOPMENT LIFECYCLEJak wytwarzad bezpieczne aplikacje

  • Podstawowe elementy skadowe bezpiecznej aplikacji

    Zaoenia biznesowe

    Projekt

    Architektura

    Bezpieczne programowanie

    Standardy i procedury

    Testowanie

    Scenariusze testw

    rodowiska wykonania

    Procedury eksploatacyjne

  • SDL

    Secure Development Lifecycle (SDL/SDLC)

    Dowiadczenia Microsoft z ostatnich 10 lat prowadzenia programu

    Rnice pomidzy programami prowadzonymi w Polsce a na wiecie

    Zastosowanie SDL w praktyce

  • Secure Development Lifecycle

  • SDL czy warto?

    Przypadek Microsoft

  • Rnice w realizacji SDL

    Polska

    Bezpieczeostwo staje si wan funkcj lub wymaganiem

    Jakod nie jest jeszcze postrzegana jako problem

    Zastpy testerw nie nadaj z testami tymczasem jakod oprogramowania nie ronie wraz ze wzrostem liczby testw

    Relatywnie niski budet na SDL Brak staego zespou

    programistw

    USA/Europa

    Bezpieczeostwo jest istotn funkcjonalnoci

    SDL moe mied odpowiedni budet i zesp

    Silny outsourcing, czsto w Indiach = istotne rnice kulturowe

    Stae zespoy programistyczne

  • Modelowanie zagroeo

    Usystematyzowana metoda identyfikacji zagroeo charakterystycznych dla danego systemu

    Aby zapewnid rzeczywist wartod dodan proces musi speniad minimum nastpujce warunki:

    Sowniki: pojd, zagroeo, podatnoci i komponentw

    Powtarzalnod

    Efektywnod czasow

  • Modelowanie zagroeo

    Identyfikacja problemw w obszarze projektu

    Identyfikacja problemw w obszarze architektury

    Identyfikacja konfliktw w procesie uwierzytelnienia

    Identyfikacja konfliktw w procesie zarzdzania bezpieczeostwem

    Identyfikacja minimalnych wymaganych uprawnieo (zazwyczaj jednak bardzo wysokopoziomowo)

    Zrozumienie i nadanie priorytetw zidentyfikowanemu ryzyku

  • Przykad

    rdo: http://msdn.microsoft.com/en-us/windows/hardware/gg487497Threat Modeling for Drivers

    http://msdn.microsoft.com/en-us/windows/hardware/gg487497http://msdn.microsoft.com/en-us/windows/hardware/gg487497http://msdn.microsoft.com/en-us/windows/hardware/gg487497

  • USUWAJ PODATNOCI U ICH RDA

    Przypadek #1: ochrona aplikacji w rodowisku produkcyjnym

  • Podstawowe zaoenia

    Aplikacja webowa

    Projekt dotyczy istniejcej aplikacji

    Aplikacja dziaa ju na rodowisku produkcyjnym

    Brak dobrego i zgranego zespou programistycznego

    Nieaktualne wersje w repozytorium

    Brak dokumentacji projektowej

    Fatalne udokumentowanie kodu

    Okoo 2 tygodni kalendarzowych na uporzdkowanie sytuacji

  • Wyniki wstpnego audytu Baagan w repozytorium kodu = baagan w kolejnych releasach = problem

    rollbacku

    Moliwod dostpu programistw do rodowiska produkcyjnego z prawami administratora Edycja kodu w ramach poprawek w trybie online Nikt nie wie, ktra tak naprawd wersja oprogramowania dziaa w

    rodowisku produkcyjnym

    Brak systemu ledzenia zgoszeo Brak procedury zarzdzania poprawkami

    Modelowanie zagroeo: Nie ma na to czasu (nawet w przypadku metody rapid threat

    modeling) Nie ma sensu prociej jest uyd gotowego modelu dla aplikacji

    webowej (pod warunkiem, e taki akurat istnieje) Selekcja oczywistych obszarw kodu do audytu

  • Przed audytem kodu

    1. Ustalenie procedur dostpu do kodu rdowego2. Ustalenie procedur zgaszania i naprawiania bdw

    1. Kady bd wymaga naprawy2. Nie ma znaczenia czy podatnod jest w tym momencie do wykorzystania czy

    te nie kada jest naprawiana3. Podatnoci ktrych nie mona naprawid w prosty sposb na poziomie kodu

    rdowego zostan zaadresowane tymczasowo przez inne zabezpieczenia

    3. Uporzdkowanie repozytorium kodu4. Checkout z repozytorium do audytu5. Zastpienie tradycyjnych ticketw zgoszeniami z systemu Barracuda6. Programici nie uywaj adnego narzdzia do statycznej lub

    dynamicznej analizy kodu 7. Przystosowanie platformy SecureCode do wymagao projektu

  • Gotowy model zagroeo

    Walidacja danych wejciowych / wyjciowych

    Autoryzacja i uwierzytelnienie uytkownikw

    Zarzdzanie sesj i stanem

    Styki rnych komponentw Serwer aplikacyjny baza danych

    Serwer HTTP serwer aplikacyjny

    Konfiguracje rnych komponentw

    Standard OWASP Top 10 dobry punkt wyjcia, ale nie zoty rodek

  • Walidacja danych wejciowych

    Podstawowe zasady

    Nigdy nie ufaj danym z zewntrznego (niezaufanego) rda

    Nigdy nie przetwarzaj stanu / sesji po stronie uytkownika

    Nigdy nie ufaj ograniczeniom formularzy

    Obszary

    Formularze

    Protok aplikacyjny Zapytania GET, POST

    Pozostae metody

    Cookies

    Trzymanie stanu

    Sesja (ze szczeglnym uwzgldnieniem jej kooczenia)

  • Walidacja danych - problemy

    Procedury walidacji danych nie s atwe i szybkie do napisana (zwaszcza danych wyjciowych)

    Czd stanu zawsze jest przetwarzana po stronie uytkownika:

    Ajax

    ActiveScript

    JavaScript

  • Styk rnych komponentw: przypadek MySQL

    Typowe problemy

    Konto aplikacyjne ze zbyt wysokimi uprawnieniami

    Brak adekwatnej ochrony interfejsw sieciowych

    Brak fuzzingu na poziomie zapytao SQL

    Przykadowe zapytania

    CVE-2008-3963: select b'';

    CVE-2010-2008: alter database `#mysql50#.`

    alter database `#mysql50#../`

    CVE-2009-2446: %s%s%s%s%s

    CVE-2010-3833: LEAST()

    GREATEST()

  • Styki rnych komponentw: przypadek MS SQL Server

    Typowe obszary zagroeo

    Uytkownik aplikacyjny ze zbyt wysokimi uprawnieniami

    Brak adekwatnej kontroli intefejsw sieciowych

    Procedury skadowe

    Rozszerzone procedury skadowe

    Nadal naduywanie konta sa

    Nadal zakadanie e konto sa jest bez hasa

    Przykady nietypowych atakw

    SQL Server 2000: 3 bajtowy patch wyczajcy kontrol dostpu

    Uywanie procedur skadowych do dalszego ataku

    Przepenienia bufora w procedurach skadowych

  • Konfiguracje rnych komponentw: przypadek PHP

    allow_url_fopen disable_functions display_errors enable_dl error_reporting file_uploads log_errors magic_quotes_gpc memory_limit open_basedir register_globals Safe_mode

  • ZAPROJEKTUJ OD POCZTKU JAKO BEZPIECZNY SYSTEM

    Przypadek #2: Stworzenie modelu bezpieczeostwa

  • Podstawowe zaoenia

    Biznes rozumie rol bezpieczeostwa

    Compliance jest istotnym elementem dla projektowanego systemu

    Projekt ma zdefiniowad pojcie bezpiecznego systemu ju na etapie projektu

    Gotowa, wysokopoziomowa lista kontrolna dla audytu

  • Podstawowe ryzyka projektowe

    Dostawca aplikacji posiada ju pewn baz kodu i architektur, ktra nie bya projektowana zgodnie z wynikiem projektu

    Koszty i czas wdroenia modelu umowa zostaa podpisana z Dostawc przed podpisaniem modelu

    Edukacja biznesu biznes musi zrozumied pewne istotne elementy zarzdzania bezpieczeostwem

    Edukacja ekspertw ds. bezpieczeostwa - musz oni zrozumied zaoenia biznesu

  • Model zagroeo

    Zaoenia biznesowe zmapowane na ryzyko biznesowe

    Ryzyko biznesowe definiuje zagroenia biznesowe

    Zagroenia biznesowe maj wpyw na zagroenia techniczne

    Rne modele zagroeo ze wzgldu na wykorzystanie cienkiego i grubego klienta

    Wicej ni jeden profil uytkownika

  • DAJ SZANS DEVELOPEROMPrzypadek #3: System developerski

  • Podstawowe zaoenia Biznes rozumie rol bezpieczeostwa

    Produkowane oprogramowanie ma byd bezpieczne

    Developerzy maj mied zapewnione rodowisko, ktre speni oczekiwania biznesu

    Wykorzystanie metodyki Agile

    XP odpado z kilku powodw: najwaniejszym by brak wasnoci wybranych obszarw kodu rdowego

  • Oglna architektura z wykorzystaniem koncepcji stepping stone

    Kontrola dostpu do

    systemu

    Kontrola dostpu do

    systemu ledzenia zgoszeo

    System ledzenia zgoszeo i

    przegldarka repozytorium

    Kontrola dostpu do

    repozytorium

    Repozytorium w modelu

    rozproszonym

    Automatyzacja procesu build

  • Rozproszony system kontroli wersji

    Zalety

    atwod zapewnienia cigoci

    atwod pracy w chmurze

    atwod wsppracy z systemem

    Wady

    Odmiejscowienierepozytorium

    Wymagana dodatkowa dyscyplina

  • Statyczny audyt koduOperacja clone

    Operacja add

    Audyt kodu w lokalnym

    repozytorium

    Poprawki

    Operacja add

    Audyt kodu w lokalnym

    repozytorium

    Operacja push

    Audyt kodu w zdalnym

    repozytorium

    Weryfikacja

    Akceptacja

  • Inne istotne aspekty

    Zestaw regu tworzenia kodu

    Unit-testy

    Scenariusze testowania

    Proces testw

  • BEZPIECZEOSTWO APLIKACYJNE W CHMURZE

    Zmiana paradygmatu bezpieczeostwa

  • Wane pytania

    Czy rodzaj chmury ma znaczenie dla bezpieczeostwa?

    Czy technologia chmury ma znaczenie dla bezpieczeostwa?

    Czy technologia aplikacji ma znaczenie dla bezpieczeostwa?

    Czy aplikacje tradycyjne wyrzucone do chmury staj si bardziej (nie)bezpieczne?

    Czy aplikacje tworzone z myl o chmurze s bezpieczniejsze od tradycyjnych?

    Compliance

  • Zmiana paradygmatu bezpieczeostwa

    Jak wygrad wojn jeli nie mamy nawet komputera? Kto bdzie mia komputer: Amazon, IBM, NASA,

    NSA