19:20
11/9/2011

Często podczas wykonywania testów bezpieczeństwa słyszymy, że bezpieczeństwo bezpieczeństwem, ale tak naprawdę klient wynajmuje nas, żeby niezależnie potwierdzić zgodność jego projektu z jakimiś konkretnymi wymaganiami dotyczącymi bezpieczeństwa…

Czasem chodzi o którąś z polskich norm, czasem o wymogi związane z innymi standardami, np. PCI DSS, albo — ostatnio coraz bardziej popularną, choć mało sensowną z punktu bezpieczeństwa — weryfikację, czy dana webaplikacja nie jest podatna na któryś z kilku “popularnych” błędów opisanych przez organizację A lub B (np. OWASP TOP 10).

Aby zobrazować klientowi, dlaczego produkt, choć zgodny z konkretnymi wymaganiami, nie zawsze jest 100% bezpieczny, warto odwołać się do tego krótkiego filmiku:

P.S. Nie od dziś wiadomo, że tzw. “biznesowi” przede wszystkim chodzi o dupochrony certyfikaty, przekładające się niekoniecznie na bezpieczeństwo produktu i jego użytkowników, ale raczej na bezpieczeństwo i stabilność stanowiska osoby odpowiedzialnej za dany projekt ;)

Wracając do przykładu z OWASP TOP 10 — to dobrze, że wzrasta świadomość tego typu dokumentów (wśród zamawiających jak i odbierających projekty), ale warto, żeby wraz ze wzrostem świadomości szła jeszcze następująca wiedza: zbiór popularnych ataków != zbiór wszystkich ataków. Czasem aplikacja, która nie jest podatna na żaden z błędów wylistowanych np. w OWASP TOP 10 (i uzyskuje ten magiczny “certyfikat/potwierdzenie zgodności”) dalej może zostać “zhackowana”, błędem numer 42, który do popularnej dziesiątki po prostu w tym roku się nie załapał…

Przeczytaj także:


21 komentarzy

Dodaj komentarz
  1. Dobra to ja może nieco inaczej. Oto co się stanie gdy zostanie popełniony fail (upadek, błąd projektu, cokolwiek) -> bez dobrej ochrony.

    • Wydaję mi się, że cytowany przez Ciebie film, to również dobra alegoria odnośnie tego, co dzieje się z rzecznikami firm, które zaliczą security faila.

  2. W biznesie liczy się kasa i firmom nie chce się dbać o bezpieczeństwo jeśli nie przynosi im to dochodu, smutne jest to że klienci nie wiedzą że certyfikat to nie wszystko i powinni żądać bardziej wiarygodnych dowodów np w postaci waszych testów penetracyjnych

  3. audytor to ma łatwo, zawsze coś tam musi znaleźć, bo inaczej mu nie zapłacą. co z sensownymi checklistami (zapomnieliście o OWASP Testing Guide?) nie jest takie trudne.

    z drugiej strony architekt aplikacji albo bezpiecznik ze znajomością aplikacji: interfejsy z/do firm trzecich, kod albo komponenty powstające w outsourcingu, ograniczone zaufanie do własnych programistów i ciśnienie ze strony produktu (“weź mi zrób szybko ten code review bo deadline”). podsumować to można tak jak na tym filmiku: “i give up” :)

    dzisiaj w telewizji mówią cały dzień m.in. o zabezpieczeniach na lotniskach i mądrzy ludzie mówią: nie da się wykluczyć ryzyka, można tylko minimalizować. tak samo jest z sensownymi normami zgodności (sensownymi, a nie w stylu naszego rozporządzenia MSWiA) – z założenia mają ogarniać największe ryzyko.

  4. I dlatego OWASP Top10 nie jest dobrym punktem odniesienia. Zdecydowanie lepszy, moim zdaniem, jest OWASP ASVS. W tym przypadku sprawdza się nie samo istnienie dziur, co (konsekwentne) stosowanie właściwych praktyk.

    • Tylko że o ile OWASP Top10 ludzie zaczynają już powoli kojarzyć to ASVS-a (prawie) nikt nie zna… :-( (Aha, i żebyśmy się dobrze zrozumieli, artykuł opisuje sytuacje kiedy to klient zwraca się z prośbą o X (np. weryfikacje pod kątem OWASP Top10).

    • Ja tutaj mam dwa podejścia. Z jednej strony to, co ja uważam za sensowne i wartościowe dla klienta (i w tym momencie zakończmy ten wątek).

      Z drugiej strony to, co chce klient. Jeśli klient po wytłumaczeniu nadal chce właśnie TO, to (być może) TO dostanie. Być może akurat założył, że z produktu usunie podatności, przykładowo, z Top10 i chce zweryfikować, czy udało mu się osiągnąć ten cel. Albo ma mocno ograniczone środki i chce w jakiś sposób określić zakres prac. Albo (…)

      Podobnie z “certyfikatami”. Jeśli zasady przyznawania certyfikatu są jasne, weryfikowalne a sam proces powtarzalny, to jest to dla mnie akceptowalne. Nawet widzę w tym pewną wartość.

      Zupełnie nieakceptowalne dla mnie jest natomiast wszelkiego rodzaju “wyolbrzymianie”. Czyli jeśli testy dotyczyły tego Top10, to twierdzenie, że “absolutne bezpieczeństwo naszej aplikacji zostało potwierdzone przez niezależnych ekspertów” jest sporym nadużyciem.

  5. To co proponujecie? Przetestowanie pod kątem top 100 lub top 1000?

    aaa już kumam… chcecie by wynająć was do tej roboty =3

  6. Swoją drogą, zastanawia mnie, czy zalecenia W3C w dokumencie WCAG 2.0 mogą być przyczynkiem do zmniejszenia bezpieczeństwa aplikacji web? http://www.w3.org/TR/WCAG/ Szczególnie zastanawia mnie punkt dotyczący limitu czasowego, oraz o ponownej autoryzacji bez utraty wprowadzonych danych.

    • Ale co to ma do rzeczy? To że SERWER zapamięta w sesji usera dane z formularza i po (re-)autoryzacji będzie je traktował serio, to jest jakiś problem?

  7. no popatrzcie, bardzo dobry filmik, chyba wykorzystam zeby co poniektorym firmom/lientom uswiadomic co tak naprawde jest wazne
    a tak wogole, wina lezy po obydwu stronach barykady, firmy nie chca zabezpieczac klientow bo nie widza w tym kasy [ co akurat jest nieprawda bo kase maja wlasnie z wprowadzania takich zmian ] po drugie klienci nie chca placic za cos czego nie “widza”
    thx, za obrazowe podejscie do tematu

  8. Pamiętam, że w czasach, kiedy w najlepsze można było przeglądać hurtowo “Naszą Klasę” i wywlekać z niej seryjnie np. numery gg albo dane adresowe, odbył się audyt bezpieczeństwa tej firmy, o którym pisano w prasie. Audyt został zaliczony pozytywnie. W podsumowaniu autor artykułu pisał, że kontrolerzy zadowoleni, ponieważ stwierdzili, że “wszyscy pracownicy są przeszkoleni pod względem bezpieczeństwa i przestrzegają procedur.”
    Pokazuje to dokładnie, jak różni się teoria od praktyki.

  9. A prawda jak zwykle jest pośrodku :-)

    Wiadomo, że niemożliwe jest, aby aplikacja/system/whatever miało certyfikat 100% bezpieczeństwa. Więc jedynym wyjściem jest sprawdzenie tego maksymalnie dogłębnie. Ale jak dogłębnie? 10 najpopularniejszych dziur? 100? A może 1000? A jak system się wyłoży na exploicie nr 10017?

    Wcale się nie dziwię, iż wymagane jest bezpieczeństwo zgodna z takim-a-takim certyfikatem. Co w praktyce oznacza “na chwilę obecną zaświadczamy, iż większych niż norma przewiduje błędów nie ma”. Klient zadowolony, biznesmen zadowolony i świat się kręci.

    Bo czy da się to załatwić inaczej?

  10. A tak swoją drogą to w Polsce musi być pełen kask który ogranicza widoczność. I to jest dość dobra metafora niektórych mechanizmów bezpieczeństwa ;)

  11. Wielu już sam certyfikat chroni wystarczająco,takie +20 do ochrony,wypadało by tylko jeszcze np w stopce strony opisać dokładnie jak dany portal jest chroniony a nie tylko na czym stoi tak aby faktycznie te +10 pozystać i aby wszyscy się bali atakować :P

  12. Heh, myślałem, że na filmiku koleś założy wszystkie wymagane + dodatkowe ochraniacze, ale po chwili np. przejedzie go walec kpiąc sobie z jego bezpieczeństwa. ;)

    • No… ja sądzę, że generalnie chodziło o to, że jak już mamy mieć luki, to chociaż łeb chrońmy.

  13. Dziwny wyda się fakt iż ja też tego oczekiwałem?

  14. AVE… W pewnej amerykańskiej korporacji manager programistów postanowił rozwiązać problemy z dziurami w oprogramowaniu i webaplikacjach. Zaproponował 100 dolarów za każdą znalezioną dziurę lub błąd, oraz drugie sto za jej usunięcie. W jedno popołudnie powstał czarny rynek w dziurach. Program anulowano po tygodniu, gdy jeden z pracowników zarobił dwa i pół tysiąca dolarów… Audyt bezpieczeństwa na sens wtedy, gdy sprawdza się wszystkie możliwe luki, oraz kilka niemożliwych. Robienie list top-ileśtam może być pomocne dla twórców, gdyż mogą uniknąć najpopularniejszych luk i błędów, lecz dopiero bezlitosna i brutalna próba penetracji systemu danej firmy może pokazać, jak dobrze jest zbudowany. A to, że pracownicy przestrzegają procedur przy kontroli nie oznacza, że robią to na codzień. Z doświadczenia wiem, że często jest to dla nich zbyt męczące. Razu pewnego, mając prawie dwadzieścia wiosen na karku dostałem się do serwerowni w miejscu, gdzie nie miałem prawa być, i mogłem się spokojnie tam rozejrzeć przez dwa kwadranse. Wystarczyła postawa Recedite, plebes! Gero rem imperialem!…

  15. Przejdźmy do konkretów.

    1) O jakie polskie normy chodzi? (te przetłumaczone przez PKN? GIODO?)
    2) W jakich kręgach mówi się o “certyfikacji” pod kątem OWASP Top10?
    3) Wszyscy chętnie prze(pen)testują, a co robicie by tych błędów unikano, co proponujecie y było lepiej? – już jasno zostało powiedziane, że pentesty wszystkiego nie pokażą palcem. To nie jest panaceum. Może ktoś już próbował coś zmienić w firmie by tworzone oprogramowanie i systemy były bardziej szczelne?

    Testy bezpieczeństwa to mały krok, w dodatku ten na samym końcu, do bezpieczniejszych systemów teleinformatycznych. Póki tutaj nie wzrośnie świadomość, chęci, realna potrzeba to nic się nie zmieni. Zakończmy marudzenie na “zgodność”, rozsądnie wykonana certyfikacji zgodności zazwyczaj może dać więcej niż pentest jednego systemu.

    • dać mu wódki!

Twój komentarz

Zamieszczając komentarz akceptujesz regulamin dodawania komentarzy. Przez moderację nie przejdą: wycieczki osobiste, komentarze nie na temat, wulgaryzmy.

RSS dla komentarzy: