Rozmowa z Wojciechem Dworakowskim z firmy SecuRing, od kilkunastu lat specjalizującej się w testowaniu i doradztwie dotyczącym bezpieczeństwa aplikacji. Rozmawiamy m.in. o tym, dlaczego bezpieczeństwo wciąż jest wyzwaniem, nawet dla nowoczesnych i świadomych organizacji, jak formułować założenia i cele dla działań długofalowych mających podnieść poziom ochrony systemów i danych, jak zdobywać budżety na niezbędne inwestycje w bezpieczeństwo, jak zamawiać rozwiązania informatyczne, by zapewnić im przyzwoity poziom bezpieczeństwa, a także jak koncepcje bezpieczeństwa na platformach mobilnych różnią się od tego, co znamy z komputerów osobistych.

O tym, że bezpieczeństwo informacji nie polega na zabezpieczeniu obrzeża sieci mówi się co najmniej od dziesięciu lat. Czas mija, a większość inwestycji wciąż idzie w takie czy inne filtrowanie ruchu na styku z innymi sieciami…

Zagrożenia, które niegdyś uchodziły za egzotyczne, dzisiaj są powszechne, dlatego filtrowanie na brzegu sieci jest niezbędne. Nie może jednak stanowić jedynej linii obrony. Wymagania wobec tego obszaru stale rosną – filtry muszą „widzieć” i „kojarzyć” coraz więcej i szerzej, ponieważ ataki są coraz bardziej wysublimowane, łączą działania w warstwie sieciowej z działaniami w warstwach aplikacyjnych. Stąd właśnie, zapory sieciowe stale ewoluują – i tak zapewne będzie w przewidywalnej przyszłości.

Załóżmy więc, że na obrzeżu mamy względny spokój. Co z wnętrzem sieci?

O, tu jest znacznie gorzej, z bardzo prozaicznych powodów. W dużych organizacjach platformy sieciowe zwykle nie są wymieniane hurtowo, lecz partiami, na przestrzeni dłuższego czasu. Nowe rozwiązania mają zwykle więcej możliwości w dziedzinie bezpieczeństwa. Ich uruchamianie nie ma jednak sensu, skoro wciąż działające w sieci rozwiązania starszej generacji nie są w stanie współpracować z nimi, by stworzyć łącznie skuteczną warstwę ochronną. Poziom bezpieczeństwa jest więc w praktyce determinowany przez możliwości rozwiązań najsłabszych – stosowany jest najmniejszy wspólny mianownik. I tak, zamiast zwartej tarczy, mamy sito.

A co z tradycyjnymi, prostymi metodami zabezpieczeń, jak listy dostępowe czy VLAN-y?

One wciąż są niedoceniane, a szkoda, bo są całkiem skuteczne. Zdarza się też, że np. VLAN-y są zdefiniowane, ale reguły dostępu do nich nie mają wiele wspólnego z zasadą minimalnych potrzebnych uprawnień.

Krótko mówiąc, wydatki na bezpieczeństwo nie przekładają się automatycznie na wysoki poziom ochrony…

Przekładają się, ale wtedy, jeśli za ilością pieniędzy idzie całościowy model bezpieczeństwa. Wysoki poziom ochrony nie jest efektem samego wdrożenia takich czy innych urządzeń, ale spójnej koncepcji współgrania ze sobą różnych funkcji i warstw.

W jaki sposób firmy tworzą założenia dla budżetów na cele związane z bezpieczeństwem?

Wydatki na bezpieczeństwo trzeba uzasadnić, jak wszystkie inne. W przypadku bezpieczeństwa twarde dane to jednak pewna pułapka. Po pierwsze, statystyki oficjalne nie są do końca miarodajne, bo raportowany jest tylko niewielki odsetek faktycznych naruszeń bezpieczeństwa. Dla wielu firm i instytucji ukrywanie faktu zaistnienia problemów jest zdecydowanie bardziej opłacalne, niż ich ujawnianie – i o tym trzeba pamiętać. Po drugie, statystyki nie odzwierciedlają czynnika jakościowego, że się tak wyrażę. Jeden atak celowany, wykonany przez zdeterminowanego włamywacza, zwany APT – Advanced Persistent Threat, jest nieporównywalnie bardziej groźny, niż dowolnie duża liczba ataków zautomatyzowanych. Budżetowanie najczęściej dotyczy ochrony przed powszechnymi, ale relatywnie niezbyt groźnymi atakami – takimi, które mają podparcie w statystykach. Czy to jednak znaczy, że te środki są dobrze wydane z punktu widzenia celu, jakim jest rzeczywista skuteczność ochrony, albo z punktu widzenia faktycznych celów atakującego?

„Budżetowanie najczęściej dotyczy ochrony przed powszechnymi, ale relatywnie niezbyt groźnymi atakami – takimi, które mają podparcie w statystykach. Czy to jednak znaczy, że te środki są dobrze wydane z punktu widzenia celu, jakim jest rzeczywista skuteczność ochrony, albo z punktu widzenia faktycznych celów atakującego?”

Jeśli nie na historii i statystykach, na czym się oprzeć? Możliwych wektorów ataku i kombinacji metod jest bardzo wiele…

W pewnym sensie, to pojedynek na siłę wyobraźni. Trzeba próbować postawić się w sytuacji atakującego i zadawać sobie pytania: co może być celem ataku, jakie scenariusze działania atakujący może przyjąć, oraz jakie kierunki myślenia na temat obrony można potencjalnie obrać. Pocieszające jest to, że są już w Polsce banki, firmy i instytucje publiczne, które potrafią myśleć o bezpieczeństwie w tych kategoriach.

Co zrobić, jeśli nawet bardzo realistyczne scenariusze ataków nie przemawiają do osób decyzyjnych? Pytam, bo budżety zależą ostatecznie od osób nie znających się szczegółowo na zagadnieniach bezpieczeństwa…

Spotykamy się z tym dość często. Nic nie działa na poprawę wyobraźni tak dobrze, jak prezentacja tego, co atakujący jest w stanie zrobić w bardzo krótkim czasie, np. 4 godzin, czyli przygotowanie proof of concept. Mówimy o pracy zwykłego inżyniera, a nie zdeterminowanego, chętnego na dużą „nagrodę” włamywacza. Takie ćwiczenie działa na decydentów bardzo trzeźwiąco. Pokazuje, że po drugiej stronie sieci są ludzie mający określony sposób myślenia oraz wiedzę, pozwalającą im przechytrzyć nawet bardzo wyrafinowane systemy zabezpieczeń. Dzięki temu osoby decyzyjne zaczynają dostrzegać, że bezpieczeństwo jest dla biznesu wyzwaniem dużo większym i trudniejszym, niż byli skłonni dotychczas myśleć. Trzeba pamiętać o tym, że osoby decyzyjne interesuje to, czy coś da się zrobić, a nie to, jak to się robi. Dowód musi być zaprezentowany przekonująco, by nie było cienia wątpliwości, że dany scenariusz jest możliwy.

„Nic nie działa na poprawę wyobraźni tak dobrze, jak prezentacja tego, co atakujący jest w stanie zrobić w bardzo krótkim czasie, np. 4 godzin, czyli przygotowanie proof of concept. Mówimy o pracy zwykłego inżyniera, a nie zdeterminowanego, chętnego na dużą „nagrodę” włamywacza. Takie ćwiczenie działa na decydentów bardzo trzeźwiąco”

W każdej firmie czy instytucji są takie dane, które absolutnie nie powinny zostać wykradzione: plany biznesowe, dane osobowe, numery kart kredytowych itd. Mimo to, wciąż słyszymy, że takie sytuacje zdarzają się. Jakoś nie chce się wierzyć, że te dane nie są właściwie chronione. Czy to niedopatrzenie, czy też właśnie determinacja atakujących?

Chyba jednak to drugie. Bardzo dobitnym przykładem takiej determinacji jest ujawniony nie tak dawno przypadek kradzieży numerów kart kredytowych w amerykańskiej sieci detalicznej Target. Po wstępnej analizie wiadomo już, że pierwotnym celem ataku była firma serwisująca klimatyzatory. Z jej systemów włamywacze przedostali się do sieci detalisty, na tyle skutecznie, że byli w stanie podmienić firmware systemów kasowych. Był to prawdopodobnie jeden z najbardziej dochodowych „skoków” w historii cyberprzestępczości. Dziesięć lat temu to byłby scenariusz na film sensacyjny, a tu mamy jego realizację w praktyce. Wniosek jest taki, że jeśli potencjalna nagroda jest bardzo duża, zabezpieczenia muszą być naprawdę solidne.

Włamanie do sieci Target to memento dla tych, którzy sądzą, że partnerzy biznesowi dbają o bezpieczeństwo tak samo, jak my…

Dokładnie. Kiedyś firma mogła być twierdzą, ale dziś bezpieczeństwo dotyczy całego otoczenia – i w zasadzie nie ma przed tym ucieczki. Trzeba zachować ostrożność. Sugeruję przyjąć założenie robocze, że każda sieć, nad którą nie mamy kontroli jest traktowana jako niezaufana. Przypadek z serwisem klimatyzacji jest wymowny, ale w sumie bardzo prosty. Obecnie powszechnie zdarza się, że firmy udostępniają sobie nawzajem systemy i dane o naprawdę dużym znaczeniu – bazy klientów, systemy magazynowe itd. Z doświadczenia wiemy, że aplikacje biznesowe są pełne luk i podatności. Do tego, ich modele bezpieczeństwa bywają słabe, bo ich twórcy zakładają,  że będą one działać tylko w sieci wewnętrznej. Zabezpieczenia typu brama VPN czy wzmocnione mechanizmy uwierzytelniania użytkowników zawsze są pożądane, ale w przypadku udostępniania aplikacji partnerom biznesowym, ich skuteczność jako środka zapobiegającego np. kradzieży ważnych danych lub atakowi na inne systemy firmy, jest jednak ograniczona.

„Aplikacje biznesowe są pełne luk i podatności. Do tego, ich modele bezpieczeństwa bywają słabe, bo ich twórcy zakładają,  że będą one działać tylko w sieci wewnętrznej. Zabezpieczenia typu brama VPN czy wzmocnione mechanizmy uwierzytelniania użytkowników zawsze są pożądane, (…) ich skuteczność jako środka zapobiegającego np. kradzieży ważnych danych lub atakowi na inne systemy firmy, jest jednak ograniczona”

Wprowadzanie bezpieczeństwa do aplikacji biznesowych to temat bardzo trudny. Rozumiem, że doszliśmy do etapu, w którym nie czas na wymówki i trzeba zacząć działać…

Zdecydowanie tak, nie ma co z tym zwlekać. Aplikacje własne są obecnie najpoważniejszym obszarem ryzyka dla wszystkich organizacji.

Do tej pory mówiło się o ochronie danych, np. baz zdanych czy zbiorów plików. Coś się zmieniło?

To wciąż ważne, ale obecnie można powiedzieć, że same dane są chronione dość dobrze. Współczesne rozwiązania do przechowywania danych mają silne mechanizmy kontroli dostępu, a same dane, jeśli są istotne, zazwyczaj są szyfrowane. Cóż jednak z tego, skoro np. aplikacja służąca do generowania raportów z tych danych zawiera trywialne do nadużycia błędy logiczne? Wystarczy je znaleźć i wykorzystać, zazwyczaj nikt nie zauważy.

A zatem aplikacje własne…

Przez aplikacje własne rozumiem wszystko to, co nie jest produktem pudełkowym, a więc zarówno aplikacje tworzone samodzielnie, jak i kupowane i wdrażane systemy biznesowe. Mamy tu do czynienia z kilkoma wzmacniającymi się wzajemnie źródłami problemów. Systemy biznesowe żyją w firmach wiele lat, są więc rozwijane przez wiele „pokoleń” pracowników. Po kilku latach nikt już nie pamięta pierwotnych założeń i skrótów myślowych, w związku z czym to, co kiedyś było bezpieczne, może przestać takie być, bo zmieniają się warunki. Systemy kiedyś „wewnętrzne” są udostępniane na zewnątrz, np. w ekstranecie, lub też są integrowane z systemami frontowymi. Równolegle rośnie ryzyko ataku na aplikacje prowadzonego od wewnątrz, np. z „zarażonego” komputera. Ponadto, historycznie, bezpieczeństwo prawnie nigdy nie było elementem specyfikacji. Przyjmowało się, i często nadal się przyjmuje, że „ma być bezpiecznie”. To bardzo pokutuje, bo każdy rozumie przez to co innego.

„Systemy biznesowe żyją w firmach wiele lat, są więc rozwijane przez wiele „pokoleń” pracowników. Po kilku latach nikt już nie pamięta pierwotnych założeń i skrótów myślowych, w związku z czym to, co kiedyś było bezpieczne, może przestać takie być, bo zmieniają się warunki. Systemy kiedyś „wewnętrzne” są udostępniane na zewnątrz, np. w ekstranecie, lub też są integrowane z systemami frontowymi”

Jak znaleźć wspólny język w sprawie bezpieczeństwa z dostawcami rozwiązań informatycznych na etapie ich zamawiania?

Mam dobre doświadczenia z włączaniem bezpieczeństwa do wymagań w obszarze jakości. Moim zdaniem liczba defektów bezpieczeństwa jest silnie skorelowana z liczbą błędów funkcjonalnych, bo bezpieczeństwo to element jakości. Jeśli zespół nie dba o jakość, to jest wysoce prawdopodobne, że również w obszarze bezpieczeństwa nie będzie najlepiej. Proponuję specyfikować wymagania w dziedzinie bezpieczeństwa najwcześniej jak się da – najpóźniej na etapie projektu funkcjonalnego. Od razu należy też zadbać o założenia do testów, i paralela jakościowa jest w tym względzie bardzo pomocna, ponieważ pozwala myśleć o testach bezpieczeństwa jak o jeszcze jednej domenie do testowania. Tak, czy owak, piłka jest zwykle po stronie zamawiającego. Jeśli dopilnuje wymagań i utrzyma nacisk na bezpieczeństwo podczas całego procesu wytwórczego, rozwiązanie ma szanse być wolne przynajmniej od najpoważniejszych podatności.

Kto zapłaci za wyższe bezpieczeństwo aplikacji? Bo przecież w projekcie czas to pieniądz…

Można by przekornie zapytać: a kto zapłaci za niższe bezpieczeństwo? Ale serio, te koszty rzeczywiście będą, ponieważ deweloperzy nie traktują bezpieczeństwa jako priorytetu, i muszą poświęcić przynajmniej trochę czasu, żeby podnieść swoje kwalifikacje w tej dziedzinie. Nie mówię o certyfikacji – raczej o zapoznaniu się z dobrymi praktykami. To może być kilka dni, a więc już niezupełnie „przy okazji”. Z drugiej strony, wysokie wymagania w dziedzinie bezpieczeństwa dostawca może potraktować jako inwestycję – szansę na podniesienie standardów pracy, które w przyszłości będzie mógł wykorzystać jako element rozwoju swojego biznesu, czy budowania przewagi konkurencyjnej. Tak zresztą naprawdę się dzieje. Zachęcam, by standardowo pytać potencjalnych dostawców o stosowane przez nich praktyki dotyczące bezpieczeństwa w procesie produkcji oprogramowania. Dyskusja na ten temat powinna wywiązać się jak najwcześniej.

„Wysokie wymagania w dziedzinie bezpieczeństwa dostawca może potraktować jako inwestycję – szansę na podniesienie standardów pracy, które w przyszłości będzie mógł wykorzystać jako element rozwoju swojego biznesu, czy budowania przewagi konkurencyjnej. Tak zresztą naprawdę się dzieje”

Czy istnieją jakiekolwiek standardy, na które można powołać się przy kreśleniu wymogów dla poziomu bezpieczeństwa aplikacji?

Standardów sensu stricte nie ma, istnieją natomiast dobre praktyki. OWASP, czyli Open Web Application Security Project wytworzył coś, co stanowi analogię do modelu dojrzałości organizacji w dziedzinie wytwarzania oprogramowania. OWASP OpenSAMM – Security Assurance Maturity Model jest, jak sama nazwa wskazuje, modelem dojrzałości w zakresie uwzględnienia bezpieczeństwa w produkcji oprogramowania. Pierwszym elementem jest ankieta, dzięki której organizacja – i po stronie zamawiającego, i po stronie dostawcy, może dokonać samooceny w dziedzinie bezpieczeństwa. To zwykle bardzo użyteczne ćwiczenie. Szerszy opis i samą ankietę self-assessment można znaleźć na stronie www.opensamm.org. Oprócz tego, istnieją metodyki, np. BSIMM – Building Security in Maturity Model, oraz Microsoft SDL – Secure Development Lifecycle. W tym ostatnim przypadku bardzo ważną korzyścią jest wsparcie metodyki na poziomie narzędzi dla platformy .NET. Warto o tym pamiętać, ponieważ bardzo wiele aplikacji biznesowych powstaje w tej właśnie technologii.

Co z aplikacjami mobilnymi? To jednak trochę inny świat, jeśli chodzi o wymogi w dziedzinie bezpieczeństwa…

W świecie mobilnym w dziedzinie bezpieczeństwa stąpamy po bardzo cienkim lodzie. Nie wszyscy jeszcze to dostrzegają, ale aplikacje mobilne zaczynają mieć więcej funkcji, niż ich tradycyjne odpowiedniki. Więcej funkcji to potencjalnie więcej błędów, co przy tempie rozwoju aplikacji mobilnych nie jest obawą zupełnie teoretyczną. Z drugiej strony, trzeba zauważyć, że bardzo dynamicznie rozwijają się studia nad metodami ataków oraz badania mechanizmów zabezpieczeń środowisk systemowych i aplikacji mobilnych.

Jak bezpieczeństwo platform mobilnych przekłada się na aplikacje?

Wbrew pozorom, współczesne platformy mobilne są pod względem bezpieczeństwa znacznie bardziej zaawansowane, niż systemy komputerów osobistych. To są nowe konstrukcje, ich modele bezpieczeństwa są stosunkowo nowoczesne, choć, znów, zależy o którym aspekcie bezpieczeństwa mówimy. Owszem, implementacje miewają błędy, i to niedobrze, ale patrząc na te systemy z pewnej perspektywy, trzeba przyznać, że stanowią duży postęp. Niestety, na aplikacje przekłada się to raczej słabo, bo o instalacji aplikacji decyduje użytkownik, a nie administrator. Źródłem zagrożenia nie są jednak koniecznie same aplikacje, ale raczej związane z nimi nieporozumienia i fałszywe założenia. Kiedyś np. uważało się, że telefon komórkowy jest platformą zaufaną. W dobie smartfonów podłączonych stale lub prawie stale do Internetu, gdzie to użytkownik decyduje o zainstalowaniu aplikacji, takie założenie traci na aktualności. Z tej przyczyny np. treść SMS-ów może być odczytana przez wrogą aplikację, która została świadomie zainstalowana przez użytkownika. Nie ma tu żadnej „magii” czy zaawansowanego „hakowania” – po prostu użytkownik zgodził się na zainstalowanie, dajmy na to, gry umilającej czas dziecku, która to aplikacja ma uprawnienia do odczytu SMS.

„(…) programiści są przyzwyczajeni do tego, że SSL „załatwia” im przeglądarka WWW. Nie pamiętają, że na platformach mobilnych to oni odpowiadają za poprawną implementację uwierzytelnienia obu stron, oraz nawiązania przez nie bezpiecznej komunikacji. Z moich doświadczeń wynika, że niewielu programistów rozumie, jak SSL w działa w szczegółach, i jak należy obsłużyć ten protokół w aplikacji mobilnej”

Czym tworzenie aplikacji mobilnych i tradycyjnych różni się pod względem bezpieczeństwa?

Model aplikacji mobilnych jest zdecydowanie inny. W świecie komputerów mamy model przeglądarkowy jako standard, podczas gdy aplikacje na smartfonach to poniekąd powrót do ery klient-serwer, co z punktu widzenia bezpieczeństwa może mieć różne implikacje. Przykładowo, programiści są przyzwyczajeni do tego, że SSL „załatwia” im przeglądarka WWW. Nie pamiętają, że na platformach mobilnych to oni odpowiadają za poprawną implementację uwierzytelnienia obu stron, oraz nawiązania przez nie bezpiecznej komunikacji. Z moich doświadczeń wynika, że niewielu programistów rozumie, jak SSL w działa w szczegółach, i jak należy obsłużyć ten protokół w aplikacji mobilnej, by zapewnić jej bezpieczeństwo. Bez poprawnej implementacji użytkownik nigdy nie dostanie np. ostrzeżenia, że certyfikat serwera jest nieważny – zwykła przeglądarka podniosła by alarm, a na smartfonie użytkownik brnie dalej…

Czy są jakieś widoki na poprawę w tej dziedzinie?

Tylko edukacja deweloperów może coś zmienić, a to wymaga czasu.

 
Wojciech Dworakowski, partner zarządzający w SecuRing Sp.J. Był członkiem Rady Programowej, autorem warsztatów o budowaniu bezpiecznych aplikacji, oraz prelegentem konferencji Advanced Threat Summit, która odbyła się w dniach 19-20 listopada 2014 r. w Warszawie. Więcej informacji pod adresem  www.atsummit.pl.

Z Wojciechem Dworakowskim można skontaktować się pod adresem: wojciech kropka dworakowski w domenie securing kropka pl.