Jaki jest cel szkolenia, które poprowadzisz w Hexcode?

Szkolenie, które poprowadzę w Hexcode ma przede wszystkim rolę prewencyjną. Chodzi o to, aby poprawnie skonfigurować serwer lub farmę serwerów Web, które wystawiamy do świata. Zadaniem mojego szkolenia jest uwrażliwianie administratorów na ryzykowne sytuacje, również na takie, które na pierwszy rzut oka nie wydają się groźne.  Zależy mi na budowaniu świadomości wśród administratorów, że platforma Web, mimo iż wydaje się prosta, jest w rzeczywistości dość skomplikowana. Zdarza się, że podjęcie złej decyzji w pozornie błahej sprawie dotyczącej konfiguracji określonej usługi może pociągnąć za sobą poważne konsekwencje w obszarze bezpieczeństwa. Dlatego zarządzanie środowiskiem powinno koncentrować się nie tylko na kwestiach związanych z utrzymaniem systemu, ale również powinno obejmować analizę infrastruktury pod kątem bezpieczeństwa stosowanych rozwiązań.

Jaki styl pracy na szkoleniu preferujesz?

Podczas moich szkoleń zawsze pracuję na żywych przykładach. Zajęcia mają formę warsztatu, podczas którego konfigurujemy określone usługi. Dzięki temu mogę w najlepszy możliwy sposób pokazać, jakie obszary są potencjalnie niebezpieczne. Oczywiście podpowiadam uczestnikom szkolenia, jakie działania należy podjąć, aby obniżyć szansę powodzenia ataku. Uczestnik mojego szkolenia otrzyma wystarczającą liczbę informacji, aby zabezpieczyć swój Web serwer. Inną kwestią jest to, czy administrator potraktuje to, czego dowie się na szkoleniu, jako coś użytecznego, czy raczej jako interesujące ciekawostki, które potem nie zostaną nigdzie wdrożone.

Rozumiem, że testy penetracyjne, które przeprowadzasz, odbywają się zgodnie z prawem?

Testy penetracyjne wykonuję oczywiście legalnie, po uprzednim podpisaniu całego szeregu oświadczeń i dokumentów, a administracja infrastruktury poddawanej testowi jest o moich działaniach uprzedzona. Powodem, dla którego firmy decydują się na zlecenie przeprowadzenia takiego testu jest najczęściej chęć sprawdzenia, czy ich system jest bezpieczny. Taki test trwa do tygodnia, najdłuższy trwał dwa tygodnie, ale była to naprawdę duża infrastruktura. W 99 proc. przypadków testy penetracyjne kończą się znalezieniem przeze mnie punktów wejścia.

Gdy przeprowadzam test penetracyjny albo audyt IT widzę, że architektura została zaprojektowana w taki lub inny sposób i są zaaplikowane określone sposoby przeciwdziałania atakom, które występują bądź nie - np. dobry firewall lub skuteczne rozwiązania antywirusowe. Bardzo często jednak obserwuję, że architektura jest zbudowana bez poświęcenia dostatecznej uwagi zależnościom między komponentami infrastruktury. Aby wiedzieć, jak zarządzać infrastrukturą w sposób efektywny kosztowo, trzeba rozumieć, jak ta infrastruktura działa. Jak funkcjonuje system operacyjny, co może być dla niego realnym zagrożeniem, co jest zagrożeniem dla konkretnej usługi i jak ją można przed nim skutecznie zabezpieczyć.

Kto zamawia testy penetracyjne?

Testy penetracyjne najczęściej zamawiają osoby odpowiedzialne w firmie za IT, chcące sprawdzić bezpieczeństwo swojej infrastruktury. Czasami zdarza się, że administratorzy nie boją się weryfikacji swojej pracy i sami proszą o test. Dzięki temu mogą dowiedzieć się, czy dobrze zarządzają środowiskiem IT. Bywa jednak, że niektórzy administratorzy podczas testu sceptycznie podchodzą do jego idei.  Przeszkadzają w jego przeprowadzeniu.  Potrafię jednak przekonać ich, że przeprowadzenie testu penetracyjnego jest w ich interesie. W końcu lepiej wcześniej wykryć wszelkie możliwe "dziury" w infrastrukturze.

Co Twoim zdaniem jest piętą achillesową administratorów IT?

Uważam, że administratorzy, na co dzień powinni poświęcać więcej czasu na zapoznanie się z możliwymi zagrożeniami IT, które wynikają bezpośrednio z profilu biznesowego firmy. Rozumiem też, że nie zawsze jest to możliwe, ponieważ rozliczani są oni z ciągłości działania, rzadko ze stanu zabezpieczeń. Mimo wszystko zawsze jest dobrze wiedzieć więcej. Zwłaszcza, kiedy jest to sprawa jednego czy dwóch kliknięć.

Jakich ataków jest więcej? Zewnętrznych czy wewnętrznych?

Statystyki mówią, że mniej jest ataków z zewnątrz. Wdrożone i dobrze skonfigurowane rozwiązanie 'edge' zwykle stanowi zaporę nie do przejścia dla osób podejmujących taki atak.

Najbardziej narażoną usługą na atak, jest usługa typu Web. To, czy atak się powiedzie, zależy od wielu czynników. Największy wpływ na to ma ilość możliwych punktów wejścia oraz ile informacji jesteśmy w stanie uzyskać będąc tylko zwykłym użytkownikiem witryny. Zdecydowanie częściej jednak zagrożenie może pojawić się wewnątrz, szczególnie, jeśli mamy do czynienia z dużą organizacją, gdzie jest wielu użytkowników, zwłaszcza, że ich intencje bywają różne.

Jakie formy mogą mieć ataki wewnętrzne?

Jestem fanem usunięcia użytkownika z tzw. 'chain of trust'. Użytkownik zna wartość przetwarzanych przez niego informacji, nie musi natomiast wiedzieć, jakich technologii użyć, żeby te informacje zabezpieczyć. Dlatego też warto zastanowić się nad wdrożeniem technologii, która będzie pozwalała na zautomatyzowane aplikowanie żądanego poziomu zabezpieczeń. Przykładów, kiedy użytkownik otworzył jakiś załącznik, makro, skorzystał z jakiegoś oprogramowania i w efekcie naruszył bezpieczeństwo organizacji, można by mnożyć. Takie sytuacje są zależne od tego, jaki jest kontekst bezpieczeństwa danego użytkownika.

A jak zabezpieczyć infrastrukturę przed wyciekiem informacji na płytach CD, kartach pamięci itd.?

Zwykle użytkownik nie jest świadomy tego, że informacja może wyciec. Bez wątpienia dla każdego pracownika najbardziej komfortową sytuacją jest, gdy to technologia czuwa nad tym, aby żadna niepożądana sytuacja nie miała miejsca. I właśnie tak wygląda moim zdaniem prawidłowe podejście do kwestii bezpieczeństwa informacji. Niestety wiele firm obawia się ciągle szyfrowania. Ten problem zauważam konsultując firmy na całym świecie.  W rezultacie niewiele firm wykorzystuje takie rozwiązanie. Odpowiedzialność za odpowiednie zabezpieczenie dokumentów, które są wytwarzane w danym środowisku, ponosi administrator lub osoba zajmująca się architekturą bezpieczeństwa w firmie. Czasem jednak zdarza się, że odpowiedzialność ponosi właściciel informacji, czyli użytkownik.

Użytkownik jest zawsze najsłabszym ogniwem, więc dlaczego w ogóle mielibyśmy na nim polegać? Ufajmy technologii, polegajmy na konkretnych rozwiązaniach technicznych. Błędem jest przerzucanie odpowiedzialności za bezpieczeństwo danych na użytkowników.

Czy potrafisz wskazać jakiś błąd, który jest powielany przez wielu administratorów?

Tak, jest parę rzeczy, które zdarzają się częściej niż inne. Zapraszam na szkolenie. Chętnie opowiem o szczegółach.

Dziękuję za rozmowę.

Marcin Dulnik

O Pauli Januszkiewicz

Jako jedna z dwóch osób w Polsce, należy do programu Microsoft Security Trusted Advisor. Jest osobą opiniotwórczą w obszarze bezpieczeństwa, swoją wiedzą dzieli się na wielu światowych konferencjach m.in. TechEd North America, TechEd Europe, TechEd Middle East, RSA, TechDays, CyberCrime i innych znaczących na rynku 'security'. Zawodowo przeprowadza audyty bezpieczeństwa, wykonuje testy penetracyjne, konsultuje firmy, począwszy od korporacji, skończywszy na małych firmach, z zakresu budowania bezpiecznej infrastruktury oraz rozwiązywania bieżących problemów. We wrześniu 2013 poprowadzi dla Hexcode intensywny warsztat z IIS 8 /Advanced Internet Information Services Management/.