Webmakers talks - Jak dbać o bezpieczeństwo oprogramowania?

Na co zwracać uwagę w kwestii bezpieczeństwa oprogramowania, jak właściwie zabezpieczać swoje projekty i jakie podjąć kroki, kiedy padniemy ofiarą ataku hakerskiego? O tym, w odcinku podcastu WebMakers Talks rozmawiali: Damian Maślanka, Paweł Lewandowski, Maciej Kadziewicz, Sebastian Depta oraz Łukasz Szatkowski.

Damian:

Cześć, witam Was na dzisiejszym podcaście. Ja jestem Damian - CTO WebMakers, razem ze mną są lead developerzy: Sebastian, Maciek, Paweł oraz Łukasz. Będziemy dzisiaj rozmawiać na temat podchodzenia do kwestii bezpieczeństwa w projektach. Pokrótce przedstawię agendę, którą będziemy się dzisiaj kierowali. Rozbiliśmy sobie cały temat na kilka takich podtematów. Pierwszy z nich omówimy ogólnie, czym jest bezpieczeństwo oprogramowania. Następnie opowiemy sobie, na co zwracać uwagę, aby oprogramowanie było bezpieczne. Opowiemy również o szukaniu luk bezpieczeństwa i sposobach zabezpieczania oprogramowania, w tym, jak stosować dobre praktyki. Następnie przedstawimy sytuację, gdy już doszło do włamania i co w takiej sytuacji należy zrobić. A na sam koniec przejdziemy do podsumowania, gdzie omówimy jeszcze raz wszystkie kluczowe rzeczy, które się pojawią w trakcie podcastu.

Czym jest bezpieczeństwo oprogramowania?

Na początek opowiemy sobie ogólnie, czym jest bezpieczeństwo oprogramowania. To jest, można podsumować, jeden z najistotniejszych czynników, na równi ze stabilnością działania, gdzie, tak naprawdę jakiekolwiek błędy czy niedopatrzenia, mogą doprowadzić do wielomilionowych strat, czy nawet pogrążenia danego przedsiębiorstwa czy danego projektu. Czy ktoś z Was kojarzy jakiś taki głośny case, gdzie właśnie jakieś niedopatrzenie, jakieś niebezpieczeństwa doprowadziły do dużych strat?

Łukasz: Ja pamiętam taki przypadek, to było jakieś 10 lat temu, bodajże 2013 bądź 2014 rok, gdy po włamaniu z Yahoo wyciekły blisko 3 miliardy kont użytkowników. To był gigantyczny blamaż jednego z największych gigantów technologicznych. No i ten wyciek przez to, że wpłynął na wizerunek firmy, sprawił, że kapitalizacja całego przedsiębiorstwa mocno spadła i podczas przejęcia, właściciele dostali dużo mniej pieniędzy niż zakładali pierwotnie.

Damian: Tutaj właśnie pokazana jest skala, jak tak naprawdę coś, jakieś niedopatrzenie, może doprowadzić do nawet położenia miliardowej spółki, a co dopiero firmy, która nie ma aż takich zasobów, żeby przeznaczać nie wiadomo jakie środki na bezpieczeństwo. Po prostu to są też pewne sytuacje, o których się głośno nie mówi, a skala jest potężna, więc warto zawsze zwracać mocną uwagę na to, jak zabezpieczamy projekty i myślę, że to jest właśnie taki dosyć kluczowy punkt, o którym możemy teraz porozmawiać, czyli na co zwracać uwagę, aby oprogramowanie było bezpieczne. Ja ze swojej strony mogę powiedzieć, że najlepiej kierować się zawsze polityką ograniczonego dostępu. Lepiej, żeby dany użytkownik miał mniejszy dostęp do zasobów, aniżeli w drugą stronę. No i przede wszystkim robić tak oprogramowanie, aby było odporne na wszelkie nietypowe zachowania.

Tutaj trzeba mocny nacisk położyć na odpowiednią walidację danych wejściowych i filtrowanie, tak aby niewłaściwe dane nie przedostawały się do docelowego systemu. Nie wiem, jakie wy macie praktyki, doświadczenia, co zalecacie stosować w oprogramowaniu, aby było ono zawsze bezpieczne. Wymieńmy się tutaj doświadczeniami. Jak z waszej perspektywy, z waszego doświadczenia, co uważacie za najbardziej istotne, na co warto zwracać uwagę, podczas pisania oprogramowania, a następnie jego rozwijania?

Paweł: To może ja przejdę do tej walidacji. Ja zawsze spotykałem się z tym, że kluczowa była walidacja plików wejściowych. I na to należy szczególnie zwrócić uwagę, żeby faktycznie patrzeć i sprawdzać, jakie pliki wchodzą do systemu, a także testować i kontrolować dostęp do tych plików. Czyli, jeżeli mamy jakieś pliki, powiedzmy, że nie do końca takie, które powinny być widoczne publicznie, na przykład jakieś dokumenty, fakturę i tak dalej, trzymajmy je poza obszarem publicznym, a dostęp niech się odbywa przez proxy, która zabezpiecza nam ten dostęp, gdzie też możemy walidować, czy faktycznie dany użytkownik powinien mieć dostęp do danego zasobu. Kolejny temat, czyli autentyfikacja użytkownika i podwójna autentyfikacja, czyli jeżeli mamy sekcje takie, jak admin, to myślę, że warto pokusić się o to, żeby skorzystać nawet z gotowych bibliotek.

Na przykład do Symfony mamy bibliotekę z PHP, która umożliwia nam w łatwy sposób podpięcie dodatkowej autentyfikacji, na przykład za pomocą e-maila. I wtedy każdy użytkownik logujący się do sekcji admina dostaje kod na maila i ten poziom bezpieczeństwa danej sekcji systemu znacząco się zwiększa.

Damian: Ja bym też dodał, że niezwykle istotne jest zwracanie uwagi na biblioteki, które ładujemy do projektu. Często, gdy piszemy sami kolejne linijki kodu, to staramy się zwracać uwagę na to, żeby było to bezpieczne, były odpowiednie walidacje. W bibliotekach zewnętrznych tak naprawdę nie wiemy, co tam siedzi w środku. Bardziej polegamy na zaufaniu, bo jest jakieś community, jest to rozwiązanie open source, ale trzeba zawsze mieć tutaj też tą zasadę ograniczonego zaufania, o której wspominałem wcześniej. I nawet, gdy chodzi o biblioteki zewnętrzne, to starać się to jakoś audytować, zorientować, czy nie wiszą jakieś issues na GitHubie, jakieś otwarte wątki, gdzie ktoś tam sygnalizuje, że coś działa niewłaściwie albo że jest jakaś luka bezpieczeństwa, bo niestety się zdarza, że autor czasami tę bibliotekę porzuca. Czasem to widać, bo już nie jest rozwijana od lat.

Czasem to może być tak naprawdę nierozwijane od trzech miesięcy, a właśnie w tym krótkim okresie czasu już jakieś luki bezpieczeństwa się pojawiły.

Łukasz: To tutaj płynnie przechodzimy do kontrowersyjnego pytania. Czy używać open source'a czy nie używać open source'a, bo tutaj zwykle zdania są podzielone. Plusem na pewno jest to, że jeżeli wybierzemy sobie jakąś bibliotekę, bądź narzędzie open source'owe z dużą społecznością, ono jest właśnie utrzymywane i ludzie pilnują na bieżąco, żeby łatki i jakieś tam luki bezpieczeństwa były łatane. Natomiast nie mamy gwarancji, że w zamkniętym oprogramowaniu, nawet utrzymywanym przez wielką firmę, takie działania mają miejsce. Co wy sądzicie na ten temat?

Maciej: Z drugiej strony masz sytuację, że ten błąd może tak cały czas wisieć. I może być już przegapiony przez ileś lat. Może ta aplikacja też może korzystać z czegoś innego. I w związku z tym nigdy też nie masz takiego zabezpieczenia. I też nie wiesz, czy osoba, która znajdzie tą lukę w open source będzie uczciwa i zgłosi do community, czy będzie chciała wykorzystać to sama do swoich celów. Więc z jednej strony tu jest duże community, które działa na korzyść, ale wystarczy jedna czarna owca i nagle robi się problem.

Damian: Ja uważam, że open source, szczególnie te popularne i mocno rozwijane, gdzie też community jest bardzo duże, to są w miarę bezpieczne systemy, bo na bieżąco właśnie jest wszystko łatane, przeglądane, skanowane na wszelkie sposoby. Jedyne zagrożenie jest takie, że jeżeli pojawi się zero day, to tak naprawdę liczy się szybkość łatania, bo jeżeli pojawi się jakaś ogólnodostępna luka, to nawet, że to jest open source, mocno zadbany, na bieżąco aktualizowany, to jeżeli właściciel danego systemu nie zaktualizuje danej biblioteki czy danego systemu, to po prostu nie uniknie tego i bardzo szybko zostanie zhackowany, pomimo tego, że system dosyć mocno jest zabezpieczony.

Sebastian: Ja uważam podobnie. Też jestem zwolennikiem open source'a. Przede wszystkim dlatego, że czuwa tam społeczność. W zamkniętych rozwiązaniach tak naprawdę nigdy nie wiemy, co jest w środku, co, gdzie jest wysyłane, kto z tych danych gdzieś tam później korzysta. Dlatego myślę, że nawet jeżeli jest ryzyko, że coś nie zostało zauważone, to też szansa, że prędzej czy później zostanie to zauważone i problem zostanie rozwiązany, jest dużo większa niż w zamkniętych rozwiązaniach, gdzie po prostu takie furtki mogą być robione celowo.

Paweł: I tutaj też się z wami zgodzę i pewnie audytorzy bezpieczeństwa też by się z nami zgodzili, że dużo łatwiej wykonuje się testy typu whitebox, gdzie masz pełny dostęp do kodu niż testy typu blackbox, gdzie szukasz podatności, ale szukasz w sumie w ciemno. Tak więc, tutaj dostęp do kodu i to, że można ten kod poprzeglądać i poszukać takich luk bezpieczeństwa, plus jeszcze dodatkowe community, które potęguje tą moc wyszukiwawczą. To automatycznie powoduje, że moim zdaniem przeważnie te biblioteki są bezpieczne. Natomiast też tutaj należy zaznaczyć taką gwiazdkę, że trzeba to weryfikować. Czym większe biblioteki, czym mają większe community, moim zdaniem są bezpieczniejsze. To znaczy, że więcej osób wyłapuje wszelkie zmiany, większość z tych osób to przegląda. I finalnie ta biblioteka wydaje mi się, że jest bezpieczniejsza.

Łukasz: My tutaj też wpisujemy się w taką bardzo starą zasadę, że to metoda powinna być bezpieczna i algorytm, a nie to, że ona jest tajna. Czyli to, że jakieś metody czy algorytmy są jawne, nie powinny wpływać na bezpieczeństwo.

Środowiska testowe i produkcyjne

Damian: Myślę, że możemy przejść do kolejnego zagadnienia. Chciałbym, abyśmy porozmawiali teraz na temat separacji środowisk testowych, deweloperskich i produkcyjnych. Każdy z nas pewnie słyszał o różnych fuckupach firm, gdzie te dane nie były odpowiednio odseparowane. Środowiska produkcyjne były sklonowane, np. na środowisku testowym i produkcyjnym dochodziło do różnych niewłaściwych zachowań. Ja kojarzę taki głośny przypadek, który napotkał tutaj mBank, gdzie ze środowiska testowego zostały wysłane powiadomienia do wszystkich użytkowników, które na pewno nie miały trafić do nich. Wiem, że ty, Paweł, też tutaj ostatnio wspominałeś o pewnym przypadku firmy medycznej, o ile dobrze kojarzę.

Paweł: Dokładnie tak. Na potrzeby testów, czyli w środowisku tzw. stage'owym były przechowywane rzeczywiste dane użytkowników. Mimo że już od dawna ich tam nie powinno być, bo już od dawna nie byli ze swoimi klientami związani umowami. Natomiast te dane, powiedzmy, były takie zapomniane, sobie tam leżały i czekały na anonimizację, która pewnie nigdy by nie nastąpiła, gdyby nie to, że ktoś się do tych danych dostał i wyciągnął pełen zestaw danych medycznych wielu użytkowników tego systemu. I tutaj nie mówimy tylko o takich danych osobowych, ale pełnych, istotnych danych medycznych z wielu lat. Tak więc tutaj to pokazuje, jak jest to ważna kwestia, żeby trzymać na takich środowiskach dane niepełne i powinny one być zanonimizowane. Natomiast też ważne jest to, co ty Damian wspomniałeś, czyli ta separacja tych środowisk, czyli żeby żadne dane nie mogły wyjść na zewnątrz w żaden sposób, czy to mailowo, czy SMS-owo.

Damian: Ja bym tutaj też dodał, że często taką złą praktyką jest to, że gdy korzystamy z usług trzecich, to też nie oddzielamy sobie tam kont na testowe czy produkcyjne i często na tych środowiskach stage czy testowych, po prostu są zaciągane configi produkcyjne tych narzędzi, co też może powodować różne nieprzyjemności. Wszystko zależy od pewnych ustawień, które mogą powodować, że na przykład użytkownicy dostają wiadomości, których nie powinni dostać. Pomimo tego, że baza na stage'u jest całkowicie inna. Może się powielić np. ID takiego użytkownika, gdzie na stage'u i na produkcji jest taki sam. Są to dwa niezależne rekordy. Mimo wszystko usługa trzecia wyśle to do produkcyjnego użytkownika, będzie działał w oparciu o ID.

Paweł: Dokładnie tak. I nawet jeżeli fejkujemy jakieś dane, czyli np. tworzymy losowy numer z telefonu, to należy pamiętać, że te dziewięć losowych liczb przeważnie, co któraś kombinacja, faktycznie istnieje. I ten SMS np. wysyłany przypadkowo na takie numery z telefonów może faktycznie dojść do użytkownika, który nigdy nie był związany z naszym systemem. Tak samo, jeżeli macie środowiska devowe, to też należy się zastanowić, czy na przykład maile powinny być podpięte. U nas przeważnie, czy w większości przypadków nie są w ogóle podpięte, tylko są stworzone wirtualne skrzynki pocztowe typu Mailhook, czyli stawiamy sobie taką instancję narzędzia, która za pomocą SMTP wyłapuje wszystkie maile i wyświetla je w sposób na tyle intuicyjny, że zapewne klient może je przeglądać, jak i nasi testerzy.

Sebastian: Myślę, że jeszcze istotną kwestią, może nie tyle od strony kodu samego, co od po prostu codziennej takiej higieny pracy jest to, żeby oznaczać sobie różne środowiska. Czy to na przykład w postaci favikony, innego koloru twarzy, czy jeżeli na przykład korzystamy z jakiegoś klienta, do łączenia się z bazą danych, żeby sobie w nim odpowiednio ustawić na przykład kolor tła albo tryb tylko do odczytu, bo kiedy pracujemy na kilku środowiskach, w tym gdzieś lokalnym, to bardzo łatwo o pomyłkę. Żeby gdzieś wywołać jakąś komendę, nie na tej instancji, na której chcemy.

Łukasz: Ja też tutaj sugeruję korzystanie z jakichś dodatkowych haseł zabezpieczających, że jeżeli chcę wykonać coś na środowisku produkcyjnym, to zawsze muszę wpisać jakieś hasło i zwykle, żeby ono było inne niż te, które używam na środowiskach testowych backstage, żeby zawsze trzeba było tego poszukać i zawsze się zastanowić, czy na pewno wykonuję poprawną operację w tym miejscu.

Jak sprawdzać luki bezpieczeństwa?

Damian: Dobrze, to może porozmawiamy teraz generalnie jak podchodzić najlepiej do szukania luk bezpieczeństwa. Wiadomo, że nic nie zastąpi profesjonalnego audytu bezpieczeństwa, gdzie, tak naprawdę, analizujemy ich kod źródłowy i jednocześnie są przeprowadzane testy penetracyjne, które usiłują tam przełamać różne zapory bezpieczeństwa. Ja zalecam tutaj, niezależnie właśnie od tych testów penetracyjnych czy takiego profesjonalnego audytu, przeprowadzenie nawet takich prostych testów na zasadzie automatycznych skanerów bezpieczeństwa. To są oprogramowania, gdzie tak naprawdę definiujemy, w jaki sposób ma być przeprowadzany ten audyt. Następnie wybieramy - jeżeli to jest projekt stricte webowy, to które adresy URL mają być przeskanowane. No i taki skaner po prostu leci po tych adresach i próbuje tam wszystkie takie znane techniki bezpieczeństwa przełamać.

Wiadomo, nie jest to coś, co daje nam 100% gwarancję, że wszystko jest okej, ale raz, że wskaże nam miejsca, gdzie zostały przeoczone jakieś kwestie i warto się nad nimi pochylić, jak też daje taki ogólny wgląd, czy wszystko jest okej. Więc - wiadomo, nie traktowałbym tego jako jakieś stuprocentowe zabezpieczenie, ale jako taki, można powiedzieć, pierwszy etap przeprowadzenia testu bezpieczeństwa.

Paweł: No to ja to uzupełnię o testy nie właśnie blackboxowe, tylko whiteboxowe, gdzie ważne jest, żeby sobie stworzyć taką listę podstawowych luk w systemie. Czy to mamy CSS, czy SQL injection, który pewnie nie występuje w większości nowych frameworków, czy testy właśnie walidacji, sprawdzenie, czy faktycznie ta walidacja została nałożona. Sprawdzenie dostępu do plików, czy wszystko mamy wyciągnięte poza katalog publicznie dostępny. Czy, na przykład, sprawdzanie twigów: co tam wyświetlamy, jakie obiekty tam wchodzą, czy przypadkiem nie ma szansy, żeby pojawiło się coś, co nie powinno się pojawić. Tak więc, dla mnie podstawą dla testów, poza właśnie tym, co powiedziałeś, czyli testami takim blackbox, są testy whitebox i przejrzenie całego systemu względem takiej listy, checklisty nawet, potencjalnych błędów.

Sebastian: Myślę, że taka checklista jest dobrym rozwiązaniem dla każdego przedsiębiorstwa, które produkuje oprogramowanie albo ma z nim styczność, żeby zawsze był to jakiś powtarzalny proces, kiedy sobie sprawdzamy, czy wszystkie te najpopularniejsze błędy nie zostały przypadkiem popełnione.

Damian: Ja bym tutaj też dodał, że silną bronią na wszelkie bezpieczeństwo, jest logowanie wszelkich zdarzeń, błędów, no i też bieżąca obserwacja tego, monitoring. Z tego można naprawdę bardzo dużo informacji wyczytać. Można zobaczyć, że jakieś boty nas ciągle atakują, że skanują jakieś określone pule adresów. Wszystko można później odgórnie na firewallu poblokować, gdzie tak naprawdę minimalizujemy ilość tych wszystkich skanów. Możemy też obserwować, które endpointy są często odpytywane, w jaki sposób i się też mocniej nad nimi pochylić, sprawdzić czy tam na pewno nie ma jakichś potencjalnych luk. Jak też i wszelkie błędy spowodowane wysypywaniem się kodu, bo ktoś przesłał jakiś parametr, który nie do końca był gdzieś tam walidowany.

Albo jakiś plik, który przeszedł walidację i coś tam wysypał dalej w kodzie, to są zawsze takie cenne informacje, które pozwalają dodać kilka dodatkowych linii kodu, które mogą po prostu zniwelować czy zapobiec właśnie jakimś gorszym problemom.

Maciej: Z jednej strony tak, a z drugiej jest jeszcze takie coś, że praktycznie każdy z tych adresów takich serwerowych, można mieć pewność, że w ciągu 24 godzin zostanie zeskanowany, nawet jak tam nic nie ma uruchomionego za bardzo, to jakiś skan pójdzie i wyłapiemy.

Łukasz: Wydaje mi się, że warto podkreślić to, że podawaliśmy przykład jakiegoś giganta typu Yahoo czy Microsoft, gdzie te wycieki bądź ataki były. Natomiast kwestia bezpieczeństwa dotyczy każdego, każdej firmy, każdej strony, która pojawia się w Internecie. Nawet jak jest to mały sklep, który sprzedaje widelce na Dolnym Śląsku, to też musimy walczyć o swoje bezpieczeństwo. Duże serwisy zabezpiecza się w inny sposób, natomiast problemy są bardzo podobne i musimy pamiętać, że dotyczą wszystkich.

Paweł: Jak też należy zaznaczyć, że to, co Damian powiedział jest mega słuszne, dlatego że to jest podstawa do tego, żeby określić, czy faktycznie ktoś się dostał do naszego systemu. Jeżeli mamy podpięty jakiś system, taki monitorujący, no to jasne, widzimy, że nagle zaczyna się skanowanie. Natomiast bez logowania wszystkich czynności użytkowników nie jesteśmy w stanie powiedzieć, czy faktycznie ktoś się dostał i to jest kluczowy case. Jeżeli my, np. włączamy nowy sklep, dokładnie tak, jak Maciek powiedział, po godzinie, po dwóch nagle zaczynają się ataki, to pierwsza czynność jaką najczęściej ja wykonuję w tym sklepie to jest to, że wchodzę i patrzę, czy faktycznie jakiś admin się nie logował czy nagle nie były wykonywane jakieś dziwne czynności w systemie, czy nie było jakiegoś logowania klientów z dziwnych IP, żeby jakby móc w ogóle powiedzieć czy faktycznie ktoś się dostał do systemu, czy nie.

Na szczęście jeszcze się nie zdarzyło, żeby ktoś się dostał, ale jest to taki podstawowy schemat działania w przypadku takich ataków. I potem kolejny element to odcinanie tych ataków, czyli blokowanie albo na proxy, albo u nas bezpośrednio dostępu takim gagatkom.

Maciej: I wszelkie domyślne ustawienia nie zawsze są tymi bezpiecznymi. Przykładem jest powiedzmy tam ElasticSearch sprzed iluś lat, który nie miał wogóle logowania i on był zawsze otwarty na wejście, więc takim jedynym zabezpieczeniem było umieszczenie go powiedzmy w sieci, takiej odizolowanej od Internetu, zamknięcie portu do niego, żeby tylko wewnętrznie można było się komunikować, bo nie było po prostu tam obsługi w darmowej wersji użytkownika i hasła, żeby się dostać.

Damian: Ja bym jeszcze dodał, że największą luką bezpieczeństwa, jest tak naprawdę czynnik ludzki. Tutaj też jako jeden z takich sposobów zabezpieczania systemu to też jest uświadamianie administratorów, klientów, wszystkich użytkowników, którzy mają jakieś większe uprawnienia w aplikacji, o zagrożeniach, jakie czyhają i w jaki sposób przed nimi się chronić. Tutaj przede wszystkim: silne hasła, to też jest dobra praktyka, aby system już na tym etapie to wymuszał, żeby weryfikował te hasła, że one naprawdę muszą mieć minimum x znaków. One też nie powinny być słownikowe, czyli takie ogólne można powiedzieć. Szkolenie na bieżąco wszystkich użytkowników, którzy mają jakieś większe uprawnienia. Doskonali hakerzy, pierwsze co, to zawsze podejmują próby tak naprawdę przełamania tej bariery ludzkiej, a dopiero gdy to się im nie udaje, to próbują obejść system od strony technicznej.

Łukasz: To jest właśnie fajny przykład, bo to jest wyzwanie dla administratorów, żeby zabezpieczenia, które przygotowują, były z jednej strony możliwie bezpieczne, a z drugiej możliwie wygodne dla użytkowników. Bo jeżeli coś jest bardzo bezpieczne, ale niewygodne, to ludzie, jak to ludzie, zaczną obchodzić te zabezpieczenia i naklejać sobie hasła na karteczkach, bądź obchodzić problemy w taki sposób, żeby procedura przeszła, natomiast użytkownik nie miał problemu.

Paweł: No tak, ale ja bym jeszcze dorzucił coś pobocznego, co jest w sumie niezwiązane z naszymi systemami, ale na przykładzie YouTube'a. Mimo że są potężne zabezpieczenia, w tym autoryzacja dwuskładnikowa, to mimo wszystko, jeżeli użytkownik kliknie w ten link, ktoś się dostaje do jego urządzenia, zostanie wykradziony ten plik cookie, związany właśnie z weryfikacją dwuetapową, czyli jakby wykradziona zostanie sesja, no to wtedy wszystkie te nasze zabezpieczenia idą w kosz. Tak więc, jeżeli użytkownik nie jest świadomy tego, jak powinien działać w sieci, no to niestety - nie ma takich zabezpieczeń, które pozwolą zabezpieczyć system w odpowiedni sposób.

Maciej: Tak, nawet sam pamiętam do gier chyba, a weź mi tutaj otwórz, tam konsolę czy tam coś i pokaż coś albo przekopiuj to i coś, co się wydaje taką nieszkodliwą czynnością powoduje to, że to konto powiedzmy do gry było tracone.

Paweł: Nie wiem, czy to nie jest taki offtopic, ale też mocno związany z tematem bezpieczeństwa. Ja miałem w zeszłym tygodniu taką sytuację: dostałem telefon z dziwnego numeru telefonu, gdzie jeden pan się przedstawił jako współpracownik banku, że moje konto zostało namierzone, został wykonany jakiś przelew. Finalnie skończyło się to tak, że ten atakujący, czyli ktoś, kto spróbował się podszywać pod bank, został przeze mnie zignorowany. Natomiast w rzeczywistości, moje konto zostało zablokowane.

Okazało się, że bank ma takie zablokowane potwierdzenia, że prawdopodobnie skanuje telefony wykonywane do nas, pewnie przy okazji instalacji aplikacji. I z automatu określi, że mógł to być atak phishingowy na mnie i z automatu zablokowali mi konto. Więc to jest przykład, jakie można zabezpieczenia stosować i jakie, np. banki stosują zabezpieczenia, aby chronić swoich klientów przed potencjalną stratą funduszy.

W jaki sposób zabezpieczać swoje oprogramowanie?

Damian: Myślę, że tutaj płynnie przeszliśmy do sposobu zabezpieczenia oprogramowania i właśnie to, co powiedziałeś Paweł, to myślę, że to jest taki automatyczny detektor anomalii zachowań i to też jest dosyć obszerny temat, który warto poruszyć. Systemy właśnie powinny, oprócz tego, że monitorujemy i sprawdzamy te logi, błędy i tak dalej, to też starać się wyłapywać wszelkie anomalie, czyli właśnie jakieś nietypowe zachowania tych użytkowników, śledzić wszelkie jakieś podejrzane akcje, bo to też raz, że zabezpiecza naszych klientów, naszych docelowych użytkowników, a jednocześnie też pozwala wykrywać jakieś schematy, które są stosowane, które właśnie mogą służyć jako phishing czy jakiś scam.

Warto się na tym zawsze pochylić i to przyblokować albo odciąć, żeby tego typu ścieżki nie były możliwe. Tak a propos jeszcze właśnie skanowania, dobrym zaleceniem też jest stosowanie GUID zamiast standardowych ID'ków, które są inkrementowane zazwyczaj co jeden.

Zapobiega to właśnie wszelkim takim skanerom na to, że są w stanie, inkrementując tą liczbę, zaciągnąć wszystkie dane z naszego serwisu, a gdy mamy bardziej generyczną, to wiadomo, tutaj szansa, żeby trafić na taki adres jest prawdopodobnie niemożliwa. Jak też wszelkie ukrywanie paneli administracyjnych, przykładowo, żeby to też nie były publiczne adresy URL, albo zawarte na innej domenie, pod całkowicie innym adresem, przede wszystkim też zablokowane na firewallu, względnie jakimiś dodatkowymi zabezpieczeniami, tak żeby ten dostęp nie był publiczny. Jak też bieżąca aktualizacja oprogramowania. To już to, co wspomnieliśmy wcześniej. Nawet rozwiązania, które są mocno bezpieczne jak open source, gdy nie będą na bieżąco aktualizowane, to wiadomo, że prędzej czy później te przestarzałe wersje będą mieć dziury, które tylko czekają na to, że jakiś haker wykorzysta pierwszy, lepszy exploit i będzie w stanie się włamać do naszego serwisu.

Tak naprawdę zabezpieczanie aplikacji to jest proces, a nie działanie. Tutaj musimy nieustannie o to dbać, na bieżąco doglądać, aktualizować, szukać, weryfikować, bo jeżeli w którymś momencie zaprzestaniemy, to relatywnie przez jakiś czas będzie się wydawało, że wszystko jest okej, ale to jest tak naprawdę tykająca bomba, jak po jakimś czasie po prostu spotka nas niemiła niespodzianka, że doszło do włamania wycieku danych, no i stwarza nam to już wtedy niezwykle problemy.

Maciej: Tutaj można też wrócić tak faktycznie do tego open source'a, bo tu jest szansa, że faktycznie to będzie załatane dość szybko i wszyscy zostaną poinformowani. A jeżeli oprogramowanie jest zamknięte, no to mimo że powiedzmy jest ta luka, no to dalej firma będzie martwić się o swój wizerunek i będzie to trzymać dłużej. Więc będą osoby, które, powiedzmy, będą wtajemniczone, będą o tym wiedzieć i z jednej strony, to jest częściowo bezpieczniejsze, bo jest mniej osób, które o tym wie i może wykorzystać. Ale wystarczy tylko, że jedna wykorzysta. I też jest dłuższy czas reakcji zawsze przy tych zamkniętych oprogramowaniach, bo jednak community ma ten plus, że potrafi bardzo szybko zadziałać. Tam nie ma całych tych procedur, czy faktycznie ujawniać, czy nie ujawniać, tylko jest działanie.

Paweł: Dokładnie tak. Dodałbym też temat przeglądania tego, co się dzieje na maszynach i dostępu do nich, bo wiele jest takich przypadków, że atakujący na przykład od kilku lat byli w danej infrastrukturze, nikt ich nie zauważył i przez wiele lat mieli dostęp do pełnych, poufnych danych. Tak więc tutaj bieżący monitoring jest mega ważny i to w takiej zewnętrznej aplikacji samej, ale też w maszynach, na jakich ta aplikacja działa.

Łukasz: Trzeba, żebyśmy powiedzieli, że Pawła przypadek był chyba skrajny. Pesymistyczny przypadek jest taki, że nie to, że ktoś się włamał, tylko że my o tym nawet nie wiemy. Taka sytuacja może trwać długie lata, aż wydarzy się coś naprawdę niedobrego.

Maciej: Tutaj mi się przypomina opowiadanie, które jakiś czas temu czytałem. Klątwa 5.0 z cyklu Wędrująca Ziemia i właśnie ona zaczyna się od tego, że ta klątwa 5.0 to już jest piąta wersja, a jedyneczka zaczynała się od jakiegoś drobnego wirusika, który był nieszkodliwy i wszyscy go zignorowali, a później problem eskalował.

Co zrobić w przypadku włamania?

Damian: Możemy płynnie przejść w zasadzie już do ostatniego punktu, czyli doszło do włamania. Co w takiej sytuacji teraz robić? Jak reagować? Co jest najbardziej kluczowe?

Paweł: Ja jestem fanem natychmiastowego odcięcia. W sensie, jeżeli już mamy pewność, że faktycznie doszło do tego włamania, to odcinamy, co możemy. Najlepiej przenieść użytkowników w inne miejsce, na jakąś taką tzw. zaślepkę, gdzie oni dostaną informację o tym, że system prawdopodobnie działa. Natomiast my musimy zabezpieczyć login, bo jeżeli ktoś się do nas włamuje, no to nie jest głupi. I automatycznie, on też będzie starał się, żeby zatrzeć za sobą ślady włamania do systemu, bo to jest podstawa każdego etapu, żeby schować w ogóle taką informację, że mamy ten dostęp, plus to, żeby nie powiedzieć adminom, w jaki sposób się do tego systemu dostaliśmy. Tak więc ja bym od tego zaczął, żeby zabezpieczyć wszystkie logi, zabezpieczyć maszyny, zabezpieczyć dostęp, żeby zminimalizować skutki tego ataku.

Damian: Ja bym tutaj dodał, że tak naprawdę istotne jest, żeby taki mechanizm zaślepki i wyłączenia całego projektu po prostu był wcześniej zaimplementowany, bo, jeśli tego nie mamy, a dochodzi do tego ataku, wiemy, że doszło do włamania, to tutaj każda sekunda się liczy i teraz musimy na szybko coś wygrzebać, przekierowywać ruch, a nie mamy na to procesu, bo to są po prostu cenne sekundy, minuty, gdzie tracimy albo ewentualnie po prostu włączamy wszystko, ale wtedy też jest ryzyko, że znowu możemy stracić część logów. Myślę, że tutaj kluczowe jest też to, żeby takie mechanizmy, zaślepek, wyłączania całego projektu, były nie od strony bazy danych, czy jakiejś tam administracyjnej, tylko typowo właśnie od strony takiej infrastruktury czy kodowej, żeby to po prostu było wcześniej przygotowane.

Łukasz: Myślę, że możemy iść nawet trochę dalej, bo rozmawialiśmy o checklistach rzeczy, które trzeba sprawdzić, zweryfikować, to równie dobrze możemy mieć checklistę na wypadek ataku. Możemy postępować zgodnie z procedurą, którą wcześniej przemyśleliśmy, bez paniki i chaotycznego działania.

Sebastian: Myślę, że trochę tak, że jeżeli mielibyśmy taką checklistę, to byśmy się prędzej zabezpieczyli już na dany typ ataku. Najczęściej problemem są rzeczy, których nie przewidzieliśmy, i których nie byliśmy w stanie przewidzieć. Ja ze swojego doświadczenia mogę powiedzieć, że na przykład często nie doceniamy tego, jak użytkownicy końcowi korzystają z systemów, na ile oni zabezpieczają swoje konta. Projektując system, projektując zabezpieczenia, zawsze powinniśmy ich w tym wyręczać. Na przykład złożoność haseł jest taką istotną rzeczą, natomiast to też nie może być tylko uzależnione od długości hasła i np. dodania znaku specjalnego, bo wtedy użytkownik też zacznie qwerty i doda znak specjalny. Tutaj się zgodzę z Pawłem w tym, że przede wszystkim, w momencie już kiedy wystąpi atak trzeba też myśleć o zabezpieczeniu logów. Raz, że na analizę, a dwa na wszystkie rzeczy związane z tłumaczeniem się później z tego, co się stało.

Tutaj też bardzo ważną rzeczą, którą trzeba mieć z tyłu głowy jest to, że taki atak powinniśmy zgłosić do odpowiednich instytucji związanych z RODO. Tam również pytania czasami są bardzo szczegółowe. Po prostu musimy dokładnie wyjaśnić, co się stało. Dlatego zabezpieczenie jakichkolwiek logów jest bardzo ważne.

Damian: I tak bym też dodał, że tak naprawdę logi, co się wydarzyło, to jedno, ale też trzeba mieć logi, żeby wiedzieć, co tak naprawdę wypłynęło. Żeby wiedzieć też, jaka skala jest tego ataku i z czym się teraz mierzymy, co tak naprawdę musimy teraz zrobić, żeby bezpieczeństwo użytkowników wróciło do stanu sprzed ataku.

Sebastian: Też ważne jest skupić się w tym momencie na rozwiązaniu problemu, na kontakcie z wszystkimi zainteresowanymi osobami, bo często też musimy pamiętać, że np. nasza aplikacja działa w połączeniu z innymi aplikacjami. Kiedy my ją wyłączymy, może się tak zdarzyć, że inne też przestaną prawidłowo działać. Albo, jeżeli ktoś włamie się u nas, to być może eskaluje to gdzieś indziej. Więc komunikacja w całym tym ekosystemie danej aplikacji, z wszystkimi odpowiedzialnymi osobami, jest również bardzo ważną rzeczą, żeby oni już wiedzieli, że coś się dzieje.

Paweł: I to jest mega ważna kwestia, jak Sebastian mówisz, czyli to, że my często w ustawieniach systemowych mamy pewne dane. I tak de facto, ten atakujący zyskuje dostęp do wszystkich tych też aplikacji zewnętrznych. Często przez API mogą zwracać dane, do których nie miałby u nas lokalnie dostępu. O tym też trzeba pamiętać, żeby w odpowiedni sposób dane zabezpieczyć, ewentualnie też te wszystkie hasła z systemów satelickich zmienić, żeby on nie mógł przejść dalej.

Sebastian: Ogólnie zmiana dostępów, to powinna już być część tej procedury po zdarzeniu. Kiedy już wiemy, co się stało, kiedy już to zabezpieczyliśmy, zmieniamy wszędzie dostępy. Czy uważamy, że był do nich dostęp, do danego zasobu, czy nie. I tak zmieniamy te hasła, klucze i wszystkie związane z tym rzeczy.

Damian: Dobrze, myślę, że możemy przejść już do podsumowania. Przypomnijmy sobie jeszcze takie najważniejsze kwestie, które poruszaliśmy i takie ogólne zalecenia dla wszystkich osób, które nas słuchają. Przede wszystkim powinniśmy patrzeć na bezpieczeństwo przez pryzmat nieustannego procesu, a nie jako pojedynczego taska, który raz zrobimy. Wiemy, że jest bezpiecznie i tak naprawdę temat zostawiamy. Tutaj musimy nieustannie monitorować, analizować, sprawdzać i przede wszystkim aktualizować wszelkie zewnętrzne biblioteki, przeprowadzać cykliczne audyty bezpieczeństwa, wszelkie jakieś zmiany w systemie również weryfikować, czy wpływają na bezpieczeństwo. Generalnie, traktować to procesowo. Z pewnością sprawi to, że poziom ogólnego bezpieczeństwa projektu znacząco wzrośnie. Tutaj bym jeszcze dodał, że wraz z rozwojem naszego projektu, zwiększeniem się popularności, tak naprawdę coraz bardziej się narażamy na wszelkie niebezpieczeństwa - co za tym idzie, jest on bardziej łakomym kąskiem dla wszelkich hakerów, czy po prostu instytucji, osób, które chciałyby jakieś dane pozyskać.

Wraz z rozwojem, wraz ze zwiększaniem się skali, musimy te środki na bezpieczeństwo przeznaczać coraz większe. Przede wszystkim traktować ogólnie kwestie bezpieczeństwa jako politykę ograniczonego zaufania, czyli nigdy tak naprawdę nie ufać temu, co mamy, tylko zawsze patrzeć rygorystycznie na wszelkie mechanizmy, które zaimplementowaliśmy, bo dziś one mogą działać. Wydaje nam się, że działają, a sytuacja może się diametralnie zmienić, gdy po prostu pojawi się jakieś nowe narzędzie, jakiś nowy sposób, czy po prostu przegapimy jakąś aktualizację i całe zabezpieczenie już nie będzie tak silne, jak do tej pory.

Łukasz: Jeżeli chcielibyśmy dać już dobrą radę albo gotowe rozwiązanie - załóżmy, że prowadzę jakąś firmę i chcę zadbać o to, żeby aplikacje, czyli narzędzia, z których korzystam ja i moi pracownicy, były dobrze zabezpieczone. Czy powinny być procesy wewnątrz mojej firmy? Czy osoba, która dba o to? Czy powinienem te odpowiedzialność autoryzować do jakiejś firmy zewnętrznej, która ma specjalistów, którzy na bieżąco pilnują wszystkiego i się rozwijają? Które rozwiązanie jest bezpieczne? Może jakaś hybryda?

Sebastian: I ja myślę, Łukasz, że tutaj przede wszystkim trzeba zabezpieczyć sobie budżet na ten proces dbania o bezpieczeństwo aplikacji, że na równi z wprowadzaniem nowych funkcjonalności musimy również cały czas pracować nad bezpieczeństwem. I to, co mówi Damian, kiedy nasza aplikacja rośnie i coraz więcej użytkowników z niej korzysta, kiedy stajemy się coraz bardziej popularni, z mojego doświadczenia wynika, że często zapominamy o tym bezpieczeństwie, że ciągle działamy jakby z niego korzystały dwie osoby.

Łukasz: Ale jeżeli już chce zadbać o to bezpieczeństwo, czy ktoś w mojej organizacji powinien o to dbać i być dedykowany do tego, czy o to bezpieczeństwo powinien poprosić firmę zewnętrzną, która jest specjalistą?

Damian: Ja myślę, że przede wszystkim powinna być kultura w organizacji, żeby każdy zwracał uwagę na bezpieczeństwo i to na każdym szczeblu. Programista, tester, lead developer, project manager. Każdy, kto tak naprawdę ma styk z aplikacją, powinien mocno na to patrzeć i być wyczulony, a jednocześnie właśnie też od czasu do czasu, to, o czym wspominałem wcześniej, robiąc cykliczne audyty, to właśnie zlecać to osobom, które już stricte są dedykowane od kwestii bezpieczeństwa, którzy przeprowadzą jakieś testy penetracyjne, tak żeby po prostu na bieżąco mieć temat na celowniku. No i też podchodzić do całej sprawy profesjonalnie. To, co też wspomniał Sebastian, że wraz z rozwojem tak naprawdę firmy później są mocno skupione na tym, żeby powstawały nowe feature'y, bo projekt się rozwija, a jest coraz więcej użytkowników, coraz większe profity przenosi.

No i wtedy ta kwestia bezpieczeństwa trochę schodzi na dalszy plan, bo mamy takie złudne poczucie, że wszystko jest okej przecież, bo się nic nie dzieje, a projekt się rozwija. Tutaj musimy mocno na to zwracać uwagę, żeby w pewnym momencie nie przeoczyć tego, nie sprawić, że tego typu proces może doprowadzić do pierwszego włamania, co oczywiście mocno się wtedy odbije na całym biznesie.

Maciej: Tutaj, Łukasz, tak jak powiedziałeś, to są dwie zupełnie różne role, bo żadna firma zewnętrzna nie będzie ci pilnować, że ktoś pendrive'a z backup'em będzie odkładał na biurko w recepcji. Taki proces musi się odbyć wewnątrz firmy i tam musi być osoba, która takich rzeczy będzie pilnować, a firma, która zrobi ci audyt, da ci wytyczne, tylko trzeba kogoś mieć, kto będzie pilnował wytycznych.

Łukasz: Wniosek jest taki, że musimy mieć w firmie zdrowe zasady bezpieczeństwa, zdrowe procedury, a fizycznie weryfikować je na przykład z zewnątrz.

Maciej: Tak, ale same procedury, że będziesz miał spisane, nic nie dadzą, trzeba ich jeszcze przestrzegać. A to jest zawsze trudniejsze.

Paweł: Tak, ogólnie powiedzieliście o dwóch składnikach, ale jeszcze jest ten trzeci składnik, żeby w ogóle klient, czyli osoba, która zleca ten system, czy używa tego systemu, była świadoma tego, że to bezpieczeństwo musi być, a nie, że ona uświadomi sobie o tym, że system jest niebezpieczny w momencie, gdy dane już wyciekły. To już jest tak naprawdę za późno, żeby to zabezpieczać. Tak więc świadomość klientów, że jednak to bezpieczeństwo jest ważne, że jeżeli przechowujemy jakieś dane, to należy szczególnie zwrócić uwagę na to bezpieczeństwo. I to nie jest tak, że domyślnie każdy system jest bezpieczny, bo np. trzeba włożyć dużo czasu i pracy w to, żeby faktycznie ten system zabezpieczyć, żeby dostęp do tych danych był faktycznie na takim poziomie, żeby nikt z zewnątrz tych danych nie wyciągnął.

Damian: Ja bym tutaj jeszcze dodał na sam koniec, że z tym bezpieczeństwem też trzeba mimo wszystko zawsze podchodzić zdroworozsądkowo, bo, wiadomo, aplikacja dobrze zabezpieczona, to jest coś czego chcemy, ale też jednocześnie musimy pamiętać o wygodzie użytkowników. Też nie przesadzać z nadmiernymi procesami, które tak naprawdę wnoszą niewielką cegiełkę w bezpieczeństwo, a czasami wręcz nic nie wnoszą, bo już wcześniejsze mechanizmy bezpieczeństwa są na tyle dobrze zaimplementowane, że w zupełności wystarczają, a są jednocześnie utrapieniem dla użytkowników. Tutaj zawsze trzeba podchodzić trochę kompromisowo i z takim zdrowym rozsądkiem. Wiadomo, bezpieczeństwo jako najważniejszy czynnik, ale też jednocześnie pamiętać o wygodzie.

Paweł: Dokładnie tak. Jeszcze cofnę się do tego przykładu. Czy to zablokowanie mojego konta było słuszne i takie wyważone? Według mnie tak. Na pewno wielu użytkowników by się mocno zdenerwowało tym, że zostało to zablokowane, ale według mnie taki sposób zabezpieczenia, mimo że jest uciążliwy dla klientów i mimo tego, że musiałem spędzić 15 minut na infolinii, takie zabezpieczenie jest jak najbardziej słuszne. Natomiast wiele jest takich systemów, gdzie te zabezpieczenia są przesadzone, tak że mamy dostęp tylko do podstawowych swoich danych, a wymaga to na przykład uwierzytelnienia za pomocą SMS-a. To też jest przesadzenie, dlatego tak, jak Damian mówisz, tutaj ten balans zabezpieczeń jest mega ważny, żeby faktycznie nie przegiąć w żadną stronę.

Damian: Tak dobrnęliśmy do końca naszej dyskusji. Ja wam bardzo dziękuję za merytoryczną dyskusję. Mam nadzieję, że poruszone tutaj kwestie będą dla naszych słuchaczy użyteczne i część rzeczy być może zostaną wprowadzone w życie. Tak więc jeszcze raz serdeczne dzięki i do usłyszenia.