Wojciech Ciemski – jest entuzjastą bezpieczeństwa systemów oraz szeroko pojętego Blue Teamu. Od 2021 roku prowadzi bloga Security Bez Tabu. Jest autorem pierwszej polskiej książki o Blue Team – Wejść w BlueTeam. Wojciech jest niezależnym konsultantem ds. bezpieczeństwa IT i Administratorem utrzymania systemów. Audytorem wew. SZBI wg ISO27001. Członkiem ISSA Polska. Prelegentem i pasjonatem dzielenia się wiedzą, który nieustannie podnosi swoje kompetencje.
W tym artykule znajdziesz odpowiedź na pytania:
- Jakie są najpopularniejsze standardy bezpieczeństwa, które powinieneś wdrożyć w Twoim projekcie?
- Jak opisywać wymagania dotyczące bezpieczeństwa w specyfikacji wymagań?
- Czy można zmierzyć poziom bezpieczeństwa w IT?
- Ile kosztuje zapewnienie bezpieczeństwa w projektach IT?
Artur Guła: Cześć Wojciech, obserwując Twoją aktywność domyślam się, że masz obecnie bardzo zajęty kalendarz – blog, książka, wystąpienia. Dlatego cieszę się, że znalazłeś czas na tę rozmowę.
Z tematami bezpieczeństwa w IT musi się zmierzyć każdy Project Manager już od pierwszego dnia trwania projektu. Temat jest jednak na tyle szeroki, że bez specjalistycznej wiedzy czy wsparcia nie wiadomo nawet od czego zacząć.
Co więc zrobić, gdy po stronie zamawiającej oprogramowanie brakuje jakiejkolwiek wiedzy, a może bardziej świadomości na temat bezpieczeństwa? Czy masz przykłady, lub statystyki, które jednoznacznie wskazują, że w bezpieczeństwo powinien inwestować każdy?
Wojciech Ciemski: Szczerze powiedziawszy naprawdę zdziwiłbym się, gdyby taka sytuacja miała miejsce. Informacje o awariach, naruszeniach i wyciekach są już na tyle powszechne, że wręcz niektórzy z nas przyzwyczaili się, że to tak po prostu „od czasu do czasu jest” i „zdarza się”. Myślę, że ten sposób myślenia jest o wiele gorszy niż brak świadomości. Do biznesu najbardziej będą przemawiać liczby. Jednym z takich miejsc uświadamiających biznes o konsekwencjach finansowych może być zestawienie: https://resilia.pl/blog/rejestr-kar-rodo-polskie-firmy/ . Z drugiej strony niemierzalne bezpośrednio konsekwencje wycieku lub kompromitacji danych jak straty wizerunkowe, czy strata zaufania również dają dużo do myślenia. Właściwie powinniśmy jako organizacja zamiast zadawać sobie wciąż pytanie „czy zostaniemy zhackowani?” sformułować je: „kiedy zostaniemy zhackowani?” i „czy wiemy co wtedy zrobimy?”, a następnie zadbać o to, aby się to nie wydarzyło, albo konsekwencje były jak najmniejsze dla naszej organizacji.
AG: Analizując te liczby może pojawić się głos, że “nie jesteśmy bankiem, nie opłaca nam się inwestować w wysokie bezpieczeństwo”. Czy są jakieś poziomy, które jasno określają, jaki jest odpowiedni poziom bezpieczeństwa dla konkretnej branży?
WC: Banki inwestują w „wysokie bezpieczeństwo”, ponieważ podlegają pod wiele ustaw i wytycznych. Wymagane jest od nich również stosowanie wielu standardów ze względu na rodzaj informacji, jakie przetwarzają i w jakich krajach to robią. Dla przykładu, banki będą podlegać pod RODO, GDPR (General Data Protection Regulation) i ze względu na przetwarzanie danych posiadaczy kart płatniczych, będzie ich dotyczyć standard PCI-DSS (The Payment Car Industry Data Security Standard). Jeżeli mówimy o branżach związanych z przetwarzaniem danych wrażliwych związanych ze zdrowiem pacjentów, będziemy musieli przestrzegać standardu zgodnego z HIPAA (Health Insurance Portability and Accountability Act).
Są też oczywiście standardy dobre dla każdej organizacji takie jak Zarządzanie SZBI wg normy ISO/IEC27001, NIST, COBIT, czy CIS Controls. Nie musimy być koniecznie certyfikowani oficjalnie przez organizacje audytujące. Sama świadomość organizacji i dążenie do realizacji praktyk opartych o te standardy z pewnością wyeliminuje wiele z ryzyk. Prawdopodobnie natomiast będzie tu problem natury kadrowej aby posiadać specjalistę, który będzie potrafił nie tylko wskazać, co należy wykonywać zgodnie z standardem ale i będzie potrafił porozumieć się i dotrzeć do najwyższego kierownictwa.
Standardy związane typowo z zarządzaniem takie jak ITIL czy PRINCE2 również bardzo pomagają organizacji w eliminacji potencjalnych zagrożeń, również tych z domeny cyberbezpieczeństwa. Tak podsumowując to wszystko – nawet jeśli jakieś standardy nas nie obowiązują z powodu przetwarzania danych, warto jest działać wg jakiegoś.
Być może zapominamy, że standardy jak i metodyki są opracowywane na podstawie best practices, doświadczeniach i błędach dziesiątek, jeśli nie setek osób i organizacji. Lepiej nie wymyślać koła na nowo licząc, że my sami damy radę.
AG: Czy standardy i wytyczne, o których mówiłeś do tej pory, różnią się w zależności od kraju lub regionu, a czy to nie ma znaczenia? Zastanawiam się, czy pracując nad międzynarodowym projektem powinienem rozpatrywać różne standardy?
WC: Myślę, że możemy się zgodzić w tym, że jedną z najlepszych rad jaką możemy dać przed wdrażaniem czegokolwiek, jest najpierw zastanowienie się.
Większość standardów jakie wymieniłem w odpowiedzi na poprzednie pytanie, są międzynarodowe. Część standardów pomimo obowiązywania przede wszystkim w USA również często pojawia się w Europie. Prawdopodobnie ze względu na globalny zakres działań wielu organizacji. Mamy również standardy obowiązujące w Unii Europejskiej. Tych o globalnym lub kontynentalnym zasięgu obowiązywania przede wszystkim bym się trzymał. Resztę brałbym pod uwagę w zależności od projektu w jakim biorę udział i kto jest moim kontrahentem. Praca w tym samym standardzie może być czymś co znacznie ułatwi komunikacje i wyeliminuje niezrozumienie w komunikacji między dostawcami.
Tak więc standardami międzynarodowymi będą: COBIT, ITIL, ISO/IEC 27001, CIS Controls, PCI-DSS, GDPR, AICPA-SOC, PRINCE2
Natomiast standardami obowiązującymi w Stanach Zjednoczonych i podmiotach powiązanych: NIST, SOX, HIPAA, CCPA, GLBA, FISMA, FedRAMP, FERPA, ITAR, COPPA.
Jak widzisz jest tego trochę.
Kolejną wartą wzięcia pod uwagę kwestią może być miejsce przetwarzania danych. Jeśli przetwarzasz je na przykład w chmurze, to czy masz pewność w jakim centrum danych i na terenie jakiego kraju one się fizycznie znajdują. Może mieć to bardzo duży wpływ na to, z jakich dostawców w ogóle będziesz mógł korzystać. Standardem przy bardziej wrażliwych danych są umowy, na terenie jakich państw dane w systemach rozproszonych mogą być przechowywane.
AG: To całkiem spora lista. Powiedzmy więc, że wiemy o możliwych zagrożeniach i w firmie jest świadomość cyberbezpieczeństwa, tylko że nikt nie ma czasu, żeby czytać obszerne standardy. Zwyczajnie brakuje kompetencji. W specyfikacjach zamówień pojawiają się czasami ogólniki, typu: “Moduł musi zapewniać bezpieczny dostęp do przechowywanych informacji oraz funkcjonalności”. Jakie pytania warto zadać, żeby doprecyzować tak zapisane wymaganie?
WC: Tu całe szczęście możemy być techniczni jak tylko się da i wymagać tego w doprecyzowaniu się. 🙂 Oczywiście część standardów będzie zawierać informację bardziej lub mniej ogólnikowe. Same standardy jak np. CIS Controls i NIST zawierają techniczne wytyczne odnośnie realizacji danych zabezpieczeń. Jeśli potrzebujemy stricte technicznej instrukcji odnośnie konfiguracji danego rozwiązania, a zwłaszcza systemu, to polecam zainteresowanie się CIS Benchmark.
Z drugiej strony możemy się zastanawiać, co oznacza świadomość bezpieczeństwa, jeśli pracownicy nie potrafią od samego początku doprecyzować, czego oczekują lub chociażby sprawdzić tego. To już pozostawiam bez odpowiedzi.
AG: Podrążę jednak temat dalej. Nawiązując do powyższego zapisu, czy jest w ogóle możliwe zmierzenie poziomu bezpieczeństwa i wyrażenia go wartościami liczbowymi? To by było najlepsze wyjście, gdyby zamawiający i wykonawca wiedzieli dokładnie co jest oczekiwane i jak to będzie mierzone.
WC: Niestety ale nie znam takiej możliwości. Nie wiem, czy takowa istnieje w ogóle. Problematyka w tym miejscu jest taka, że tak jak w przypadku szacowania ryzyka, ogranicza nas nasze własne postrzeganie i wiedza. Niektórych zagrożeń możemy nie być świadomi, a inne pojawią się znienacka jak chociażby Zero Day-e, na które nie jesteśmy w stanie się przygotować.
Nawet jeśli jesteśmy zgodni z danym standardem nie znaczy to, że jesteśmy bezpieczni.
Sprawia to wyłącznie, że ryzyko związane z popełnieniem błędu, jest minimalizowane.
Myślę, że jeśli mielibyśmy jakkolwiek zdecydować się na mierzenie bezpieczeństwa, to zdecydowałbym się na analizę ryzyka związanego z nim. Ile będzie tych ryzyk? Ile jesteśmy w stanie zminimalizować? Jakie inne przy tej okazji powstają? Ile musimy zaakceptować? Jaki jest nasz apetyt na ryzyko jako organizacji? Ile ryzyk mogliśmy zmitygować? Na te wszystkie pytania musimy sobie jako organizacja szczerze odpowiedzieć, a i tak istnieje ryzyko błędu, że czegoś nie wzięliśmy pod uwagę.
Jeżeli mamy konkretniejsze potrzeby, to sugeruję się zainteresować CIS Controls i CIS Benchmarks jeśli chodzi o systemy, a w przypadku aplikacji webowych projektem OWASP ASVS i innymi projektami od OWASP. Sam framework NIST bardzo często daje już naprawdę zadowalający poziom bezpieczeństwa Jest on również jednym z bardziej obszernych standardów.
AG: Dzięki za sporo konkretnych wskazówek.
A teraz przejdźmy do tego, co jest kluczowe w projektach, czyli budżetu. Jak wyceniać prace projektowe związane z bezpieczeństwem? Czy to jest raczej jednorazowa aktywność, napisanie kawałka kodu i już? Czy należy uwzględnić jeszcze inne czynności?
WC: Na początku ważne jest określenie, jakie dane będziemy przetwarzać i przetrzymywać w ramach naszej aplikacji. Dopiero na tej podstawie powinniśmy uwzględnić potencjalne ryzyko wiążące się z kompromitacją lub naruszeniem tych danych.
I wtedy otrzymamy ogólną odpowiedź – to zależy. Na pewno właściwym będzie przy produkcji oprogramowania korzystanie z OWASP ASVS. Są tam określone konkretne poziomy bezpieczeństwa, jakie chcemy osiągnąć. Jeżeli projekt przetwarza dane osobowe, zasadnym będzie nie tylko korzystanie i tworzenie go zgodnie z standardami i frameworkami, ale i przeprowadzenie testów penetracyjnych przed dostarczeniem do klienta.
Zasadnym wydaje się również wzięcie pod uwagę odpowiedniej liczby MD do późniejszego monitorowania potencjalnych zagrożeń. Jesteśmy świeżo po incydencie związanym z log4j. Powinno nas to nauczyć, że w trakcie wsparcia, powinniśmy również dostarczać na bieżąco informacje odnośnie nowo pojawiających się podatności, czy incydentów związanych z technologią, w której stworzyliśmy nasze oprogramowanie. Można to zrobić najprościej konfigurując RSS Feeds z strony cvedetails.com
Tak więc w zależności od danych przetwarzanych uzależniłbym ilość MD na wsparcie i testy bezpieczeństwa.
AG: Monitorowanie czy testowanie – to wszystko wymaga narzędzi. Jakie aplikacje byś polecił zespołom wytwarzającym oprogramowanie, które chcą dostarczać przynajmniej podstawowy poziom bezpieczeństwa?
WC: Burp Suite sprawdza się w testowaniu bezpieczeństwa aplikacji webowych. Jeżeli nasze oprogramowanie działa na naszym serwerze, to warto go cyklicznie sprawdzać skanerem podatności. Polecam Nessus, ale często GVM (dawny OpenVas) będzie wystarczający do tego zadania. Pamiętajmy tylko, aby ustawić możliwość skanowania systemu po zalogowaniu się agentem – da nam to dokładniejszy wgląd w sam serwer, a nie tylko usługi wystawiane na zewnątrz. Przydatne również może się okazać narzędzie lynis do audytu systemów linuxowych.
Poleciłbym także sprawdzenie, jak oprogramowanie przetwarza dane w kontekście konkretnych norm lub frameworków. Na myśl oczywiście od razu nasuwa się OWASP ASVS, ale polecam również sprawdzenie chociażby z CIS Controls i ISO/IEC 27001.
AG: Wymieniasz całą masę standardów, serwisów czy narzędzi. Można się w tym pogubić. Jeżeli kierownik projektów IT chce rozwijać swoje kompetencje z zakresu bezpieczeństwa, to co byś mu polecił?
WC: Zakładam, że kierownik projektu zna i stosuje się do best practices prowadzenia projektu np. zgodną z PRINCE2. Jeśli miałbym coś polecić to, sugerowałbym holistyczne podejście do tematu i po prostu interesowanie się nim. Udział w konferencjach, śledzenie blogów branżowych, podcastów, czy nawet prenumerata czasopism to bardzo dobry początek, bo buduje świadomość tego, co dzieje się obecnie. Nie głupią radą zdaje się też polecenie przyswojenia wiedzy, a nawet zdania certyfikatu CompTIA Security+. Tak, jest to egzamin teoretyczny, ale właśnie chodzi tu o budowanie świadomości zagrożeń i umiejętność nazywania ich technicznie. Jeśli ma zacięcie, to polecam przeczytać i przyswoić sobie NIST.
AG: Dziękuję za rozmowę i życzę dalszych sukcesów w budowaniu świadomości na temat cyberbezpieczeństwa.
A jeżeli interesuje Cię ten temat, to zapraszam do zgłębiania wiedzy na Security Bez Tabu.
Sprawdź inne wywiady z ekspertami
