W trakcie codziennej pracy z klientami często spotykamy się z brakiem wiedzy na temat tego w jaki sposób można oceniać bezpieczeństwo aplikacji i systemów IT. To z kolei generuje dwa duże problemy oraz szereg problemów pomniejszych.
Celem tej serii artykułów jest poprawa tego stanu rzeczy. Dzisiaj spojrzymy na sposoby oceny bezpieczeństwa z lotu ptaka, a w kolejnych częściach przyjrzymy się każdej z nich bardziej szczegółowo.
Zapraszamy do lektury.
Znaczenie różnic w ocenach bezpieczeństwa
Na początku dobrze jest zadać sobie pytanie: Skąd w ogóle wynikają różnice w sposobach oceny bezpieczeństwa? Odpowiedź jest prosta – wynikają one z cech różnicujących, które pozwalają zbudować spójny model oceny bezpieczeństwa.
Do cech różnicujących jeszcze wrócimy, ale teraz można zadać sobie kolejne pytanie: Czemu zbudowanie spójnego modelu jest ważne? Spójny model jest ważny ponieważ bez niego trudno jest implementować cyberbezpieczeństwo na poziomie strategicznym. Ta trudność wynika z dwóch dużych problemów.
Problem 1: CO, KIEDY i GDZIE zastosować
Pierwszy duży problem to określenie CO, KIEDY i GDZIE zastosować. Przykładowo jeśli wchodzimy do klienta i chcemy zrobić audyt procesu wytwórczego SDLC pod kątem bezpieczeństwa to nie mając jasnych i niesprzecznych ze sobą definicji sposobów oceny bezpieczeństwa nie wiemy CO, KIEDY i GDZIE wbudować.
Weźmy pod lupę ocenę podatności i testy penetracyjne. Oba te sposoby można używać na różnych etapach procesu wytwórczego SDLC, ale największą stopę zwrotu otrzymamy z ciągłej oceny podatności w fazach pre-release oraz punktowych testów penetracyjnych wykonywanych w fazie post-release na środowisku pre-produkcyjnym lub produkcyjnym.
Problem 2: Mierzenie postępu w czasie
Drugi duży problem to mierzenie postępu w czasie i to w szczególności, gdy wspierają nas zewnętrzni dostawcy. Z naszego doświadczenia wynika, że bardzo często klient zamawia usługę X (np. pentest) i dostaje efekt usługi Y (np. oceny podatności).
Powyższe jest problemem samo w sobie, ale co gorsze jeśli klient w późniejszym czasie zamówi usługę X (pentest) u innego dostawcy i tym razem faktycznie otrzyma efekt usługi X (pentestu) to nie może porównać stanu obecnego ze stanem przeszłym. Byłoby to porównanie jabłek do pomarańczy – cel i efekt pentestów jest inny niż cel i efekt oceny podatności (pomijamy tutaj jakość usług).
Problemy pomniejsze
Nie posiadając jasnych definicji mamy również inne trudności. Przykładowo nie wiemy co można, a czego nie można automatyzować. Trudno jest również unikać problemów związanych z samopoczuciem naszych zespołów operacyjnych – pentesterzy nie lubią po raz setny raportować prostych podatności, a inżynierzy bezpieczeństwa nie lubią być zmuszani do udowadniania impaktu biznesowi.
Przegląd metod oceny bezpieczeństwa
No dobrze, powiedzieliśmy czemu to wszystko jest ważne, ale dalej nie przedstawiliśmy jakie faktycznie mamy te sposoby oceny bezpieczeństwa.
A więc z lotu ptaka standardowymi sposobami oceny bezpieczeństwa aplikacji i systemów IT są:
- Modelowanie zagrożeń (Threat Modeling, Threat Assessment),
- Audyt bezpieczeństwa (Security Audit),
- Ocena podatności (Vulnerability Assessment),
- Test penetracyjny (Penetration Test),
- Red Teaming.
Kolejność w jakiej wymieniamy te wszystkie rodzaje nie jest przypadkowa i można na nią popatrzeć jak na gradient – każdy kolejny rodzaj jest progresją względem poprzedniego. Oczywiście stopniowo zwiększa się również złożoność całego ćwiczenia, ale wraz z nim podnosi się poziom bezpieczeństwa aplikacji, systemu, czy nawet organizacji (jeśli mówimy o ćwiczeniach red team).
Powyższy podział logiczny wziął się ze wspomnianych wcześniej cech różnicujących. Takich cech w rzeczywistości jest wiele, ale my skupimy się na kilku najważniejszych. A konkretnie:
- Cel. Co chcemy osiągnąć? Co innego chcemy osiągnąć modelowaniem zagrożeń, co innego audytem, a co innego oceną podatności czy testem penetracyjnym.
- Zakres. Co bierzemy pod uwagę? W przypadku modelowania zagrożeń czy audytu będziemy patrzeć na system z innego punktu widzenia niż przy ocenie podatności. Z kolei przy ocenie podatności będziemy patrzeć na system inaczej niż przy penteście (chociażby dlatego, że ocenę podatności zwyczajowo wykonuje się podejściem white-box, a pentest podejściem black-box).
💡 Jeśli nie kojarzysz terminów white-box czy black-box to przeczytaj artykuł Czym jest testowanie White-box, Black-box i Gray-box w cyberbezpieczeństwie?, gdzie omówiliśmy ten temat szczegółowo.
- Czas. Ile mamy czasu? Na ocenę podatności czy pentest przeznaczymy inny kawałek czasu niż na audyt czy modelowanie zagrożeń.
- Rozmiar zespołu. Ilu ludzi musimy zaangażować, aby osiągnąć zadowalającą stopę zwrotu? Ocena podatności czy audyt wymaga mniejszych nakładów w postaci ludzi niż pentest czy red teaming.
- Możliwość automatyzacji. W jakim stopniu jesteśmy w stanie automatyzować prace? I tutaj o ile ocenę podatności czy audyt jesteśmy w stanie automatyzować w sporym zakresie to już modelowanie zagrożeń czy pentest są trudniejsze do automatyzacji (pentest wręcz niemożliwy, ale do tego jeszcze wrócimy).
Analogia budowy domu i ogrodzenia
Lubimy używać analogii w celu upraszczania abstrakcyjnych i tak się składa, że tutaj również mamy taką analogię.
Wyobraź sobie, że stawiasz dom i przyszedł czas na budowę ogrodzenia. W takim wypadku CO, KIEDY i GDZIE wykonasz?
- Modelowanie zagrożeń wykonasz jeszcze przed budową płotu po to, aby zdać sobie sprawę z zagrożeń jakie musisz brać pod uwagę. To działanie ma Ci pomóc w uniknięciu potencjalnych podatności zarówno architektonicznych jak i implementacyjnych. Dodatkowo wynikowy model zagrożeń możesz wykorzystać do weryfikacji założeń w późniejszych etapach.
- Audyt bezpieczeństwa wykonasz po wybudowaniu płotu w momencie, gdy zechcesz sprawdzić czy Twoje ogrodzenie spełnia jakąś normę czy standard (np. ISO 7900). Wynikowy raport z audytu możesz później przedstawić jako dowód na spełnienie danej normy.
- Ocenę podatności wykonasz również po wybudowaniu płotu, jednak motywacją będzie wykrycie jak największej ilości problemów bezpieczeństwa w naszym ogrodzeniu, ale bez wchodzenia w szczegóły tego czy (i jak!) można je wykorzystać. Poprzez ocenę podatności chcesz wyeliminować nisko wiszące podatności.
- Na sam koniec zarówno test penetracyjny jak i red teaming zlecisz firmie zewnętrznej specjalizującej się w takich działaniach. Zrobisz to po wykonaniu co najmniej kilku iteracji oceny podatności. Zadaniem w obu przypadkach będzie emulacja realnego atakującego po to, aby zweryfikować skuteczność obecnych mechanizmów obronnych oraz poznać łańcuchy ataków. Tym działaniem chcesz zobaczyć w jaki sposób można połączyć różne problemy bezpieczeństwa Twojego ogrodzenia w celu uzyskania określonego efektu (np. kradzieży auta).
🚨 Jako klient nie musisz się na tym wszystkim znać. Jesteśmy tutaj po to, żeby Ci pomóc w myśl zasady, że jak sami idziemy do mechanika to oczekujemy, że to on nam doradzi co trzeba zrobić i liczymy, że zrobi to uczciwie.
Analogicznie to naszą rolą jako ekspertów w domenie cyberbezpieczeństwa jest pomoc Tobie w doborze odpowiedniego rodzaju oceny bezpieczeństwa do Twojego zadania i celu. Zobacz nasze usługi doradcze →
Podsumowanie
Różne sposoby oceny bezpieczeństwa pasują do różnych punktów zarówno organizacji jak i samego procesu wytwórczego SDLC. Jeśli nie wiemy czym się od siebie różnią to nie wiemy CO, KIEDY i GDZIE robić.
Z kolei jeśli wiemy na jakie efekty możemy liczyć z każdego rodzaju oceny bezpieczeństwa to możemy sprawnie nimi zarządzać (np. delegować je do odpowiednich zespołów wewnętrznych czy zewnętrznych).
Z naszych obserwacji wynika, że największe problemy z jednakowym zrozumieniem po obu stronach (klientów i dostawców) dotyczą oceny podatności i testów penetracyjnych. Właśnie dlatego omawianie szczegółowe rozpoczniemy właśnie od nich.