Z jakimi problemami boryka się branża IT? To pytanie zadaję sobie przy każdej rozmowie z doświadczonym inżynierem. Tym razem miałem przyjemność zadać to i wiele innych pytań Kamilowi Goryniowi, który pracuje na stanowisku Cyber Security Engineer & Consultant. Poznajcie jego perspektywę tego, czym jest overengineering i jak wygląda w praktyce.
“Narzut technologiczny” – tak nazwałeś sytuację, w której rozwiązanie technologiczne ma za dużo fajerwerków, bez których także działałoby prawidłowo. Z czego to wynika? Dlaczego firmy z IT robią za dużo?
Szukałem dobrego odpowiednika dla angielskiego “overengineering”, ale chyba nie do końca mi wyszło. Niemniej “przekombinowane” rozwiązania w dłuższej perspektywie są zwyczajnie szkodliwe. Ktoś musi to wszystko utrzymać i zapewnić wysoką dostępność, a im więcej zależności i bajerów tym łatwiej o spektakularną klapę skutkującą wyciekiem danych, czy np. zatrzymaniem działalności biznesowej klienta opartej o dostarczone systemy. Po czym oczywiście nikt nie chce wziąć odpowiedzialności za taki stan rzeczy, a przywrócenie do działania firmy dotkniętej poważną awarią jest wbrew pozorom niesłychanie trudne.
Zresztą możemy zadać sobie pytanie, jak często spotykamy się z ćwiczeniami z zakresu “disaster recovery”, które nie są wyłącznie przeglądem procedur działania. Czy ćwiczymy odtwarzanie danych z kopii zapasowych, czy wolimy zakładać, iż backupy są i działają?
Skąd bierze się to zjawisko i dlaczego można mieć wrażenie, iż się nasila?
Mam wrażenie, iż wynika to między innymi z tego, iż kilka osób odpowiedzialnych za kontakt z klientami, choćby w branży IT, zwraca uwagę na coś więcej niż stronę wizualną oferowanych rozwiązań. OK, ale warto też zapytać, czego poszukują klienci? Odpowiedź brzmi: “Rozwiązań swoich problemów”. Bardzo często mają to być rozwiązania przyciągające wzrok, przepełnione wodotryskami itd. Z tego względu aspekty wizualne niejednokrotnie dominują rozmowy i zapomina się, iż ogrom zadań to też praca koncepcyjna w zakresie rozwiązań obejmujących architekturę aplikacji, jej backend, czy właśnie poziom wymaganego wsparcia dla tworzonego rozwiązania. Nie wspominając oczywiście o kwestiach związanych z bezpieczeństwem, bo to jest mało sexy, a programiści nie tworzą przecież aplikacji z błędami bezpieczeństwa.
Niemniej klienci, podczas prezentacji, lubią wspomniane fajerwerki.
Gdy przychodzi do prezentacji oferty, pokazujemy klientowi interaktywne obrazki, bądź plansze i dopiero później zastanawiamy się jaki problem jest do rozwiązania. Często nikt nie zadaje pytań z kategorii: Jaki proces mamy zautomatyzować i usprawnić? Dodatkowo próbujemy klientom pokazać pełen przekrój naszych możliwości (lub możliwości osób przebywających w tej chwili na “ławce”, które musimy niezwłocznie “sprzedać na projekt”) i zapominamy w tym wszystkim o dokładnym zrozumieniu wyzwań, z jakimi należy się zmierzyć.
Nie jest tajemnicą, iż firmy IT mają swoje ulubione technologie, bądź rozwiązania, w których się specjalizują. Nie jest też tajemnicą, iż szczególnie w niepewnej sytuacji rynkowej, każdy klient jest na wagę złota. Co oznacza, iż dodatkowo może być parcie na sprzedaż czegokolwiek, choćby jeżeli nie odpowiada to na problemy, które są do rozwiązania. Jaki będzie efekt takich działań? Spróbuję przekoloryzować, ale tylko odrobinę.
Gdy pojawi się klient oczekujący prostej i schludnej strony internetowej informującej o charakterze jego działalności, zawierającej okresowo udostępniane dane np. raporty finansowe, nie powinniśmy oferować mu strony opartej o WordPress i dziesiątki (być może choćby setki) wtyczek za pół miliona USD. Dlaczego? Ponieważ można zrobić to szybciej, prościej, taniej i bezpieczniej za ułamek tej kwoty, a do tego zaoferować długookresowe wsparcie.
Klienci chcą prostych rozwiązań?
Klienci chcą rozwiązań swoich problemów. Oczywiście znalezienie odpowiedzi na pytanie, co jest ich rzeczywistym problemem, nie jest wcale takie proste. Bardzo rzadko trafiają się klienci, którzy przepracowali swoje wyzwania we współpracy z analitykami biznesowymi i wiedzą czego potrzebują. W tej sytuacji my (jako eksperci w swojej domenie) musimy przejąć odpowiedzialność za ten obszar i pomóc klientowi zrozumieć, co tak naprawdę chce osiągnąć i jakie będą najbardziej efektywne sposoby dotarcia do celu.
Przy czym cel musi być nie tylko realny, ale także mierzalny. Co to oznacza? Pełen zespół ekspertów pracujących wspólnie z klientem nad zrozumieniem kontekstu biznesowego i szukający rozwiązań dla zidentyfikowanych wyzwań. W praktyce oznacza to również mówienie klientowi, że… niektórych jego pomysłów nie ma sensu realizować, bo są nieefektywne, lub wręcz szkodliwe.
Przy czym mam pełną świadomość, iż to brzmi pięknie wyłącznie w teorii, bo przecież klienci nie lubią słuchać dobrych rad, a na projekty IT chcą przeznaczać coraz mniejsze budżety. Do tego praca koncepcyjna i warsztatowa wymaga całego zespołu ekspertów, nie przynosi takich zysków jak “sprzedanie” kilku programistów na kilkumiesięczny projekt i wymaga po prostu więcej pracy z ludźmi. A przecież nie po to studiuje się informatykę, aby później rozmawiać z ludźmi. Prawda?
Jakie widziałbyś rozwiązanie powyższego problemu? Co jako branża możemy zrobić, by wspomnianego “narzutu” było jak najmniej?
Hmm… chyba powinniśmy zacząć więcej słuchać i położyć nacisk na komunikację. jeżeli przestaniemy tworzyć nowe problemy i zaczniemy rozumieć, jakie wyzwania stoją przed klientem będzie nam łatwiej zaproponować rozwiązania odpowiadające jego potrzebom.
Nawet w sytuacji, w której jakaś firma specjalizuje się w bardzo wąskim zakresie technologii, możliwe jest wybranie z nich tych elementów, które najefektywniej pomogą w osiągnięciu zaplanowanego celu. Powinniśmy więc zaczynać od rozmowy, próby znalezienia problemów i zaproponowaniu rozwiązań technologicznych na podstawie naszych doświadczeń. Przy czym musimy mieć świadomość ograniczeń, jakie ma technologia, jak i “interfejs białkowy”.
Pokażmy to może na przykładach.
Wielu klientów, z jakimi miałem kontakt np. na etapie przygotowania oferty projektów, cyberbezpieczeństwo utożsamiało wyłącznie z testami penetracyjnymi. W pewnym sensie jest to naturalne zjawisko, jednak same testy penetracyjne mogą zidentyfikować najbardziej oczywiste, czy też najpoważniejsze luki bezpieczeństwa w kodzie aplikacji, bądź jej infrastrukturze. W zależności od ich zakresu mogą też pomóc zidentyfikować błędy w logice biznesowej. Jednak nie pomogą w prewencji, bo wykryją luki, które już istnieją.
Później należy jeszcze podjąć określone działania w celu mitygacji zidentyfikowanych zagrożeń i zapłacić za retesty. Warto jednak zadać sobie pytanie, czy pozwolą nam one poradzić sobie z zachowaniem charakterystycznym dla wielu użytkowników, a mianowicie wykorzystywaniem tego samego hasła w wielu usługach. Jestem skłonny zaryzykować stwierdzenie, iż raczej nie znajdzie się to w zakresie planowanych testów. Niestety jednak brak implementacji wieloskładnikowego uwierzytelnienia może łatwo doprowadzić do sytuacji, gdy wyciek loginów i haseł w jednym serwisie doprowadzi do incydentów bezpieczeństwa w innym miejscu, pomimo pozytywnych wyników pentestów.
Jak temu zapobiec?
Czasem wystarczy posłuchać klienta, zrozumieć jakie wyzwania generuje jego model biznesowy bądź branża, w której działa i wyjaśnić mu jak przekłada się to na wymagania techniczne, jakie powinno spełniać oferowane mu rozwiązanie. Przy czym wbudowanie zachęt, czy też wymuszenie na użytkownikach końcowych wykorzystania MFA, pozwala zapobiec wielu problemom w sposób łatwy i efektywny.
Podsumowując. Powinniśmy słuchać naszych klientów. Zadawać im pytania i zdobywać zrozumienie branży, w jakiej działają oraz charakterystycznych problemów w niej występujących. Kolejnym etapem jest zestawienie tego z naszą wiedzą domenową i zaproponowanie rozwiązań, które będą efektywne, a nie efektowne. jeżeli pomożemy naszym klientom i dzięki naszym usługom zdobędą przewagę konkurencyjną, prawdopodobnie wrócą do nas z kolejnymi projektami. W takiej sytuacji, jeżeli nie wydrenujemy im kieszeni i dowieziemy solidne i bezpieczne rozwiązanie jest olbrzymia szansa na długofalową współpracę.
Mam wrażenie, iż rozmawiamy o pięknej wizji świata nierealnego. Bo czy umiejętność proponowania adekwatnych rozwiązań, bez fajerwerków, jest dziś pożądaną umiejętnością z perspektywy pracodawcy?
Trochę idealizuję i nie będę udawał, iż jest inaczej. Mówimy o pewnym “wzorcowym modelu”, ale jeżeli będziemy mieli świadomość, co powinniśmy zrobić, łatwiej będzie nam zrozumieć, czego nie zrobiliśmy i jakie to może mieć konsekwencje.
Czy jest to umiejętność pożądana? To zależy. jeżeli ktoś chce budować długofalowe relacje z klientem, to jak najbardziej. Obszarów do cyfryzacji i automatyzacji jest z dnia na dzień więcej, więc warto pokazać, iż na współpracy z naszą firmą zyskuje się najwięcej.
Pozostańmy jednak przy pracy bezpiecznika i tym jak może ona wpłynąć na obniżenie kosztów realizacji, wdrożenia i utrzymania projektu. Pamiętajmy także o pozostawieniu odpowiednio dużego miejsca na coś efektownego i ułatwiającego działania marketingowe. Trafne zidentyfikowanie wyzwań i odpowiednie zdefiniowanie wymagań jest dopiero początkiem tej drogi, jednak jest niezbędne, aby usprawnić późniejsze etapy tworzenia oprogramowania.
Posłużmy się przykładami. Tworząc oprogramowanie wymagające wysokiego poziomu poufności i zabezpieczenia danych musimy przestrzegać nie tylko przepisów prawa, ale także dobrych praktyk przygotowanych dla określonych technologii i usług. Inżynier zajmujący się bezpieczeństwem już na tym etapie ma sporo pracy w zakresie zaproponowania odpowiedniej konfiguracji, czy też skorygowania i “utwardzenia” architektury proponowanego rozwiązania. jeżeli zrobimy to dobrze, możemy zapewnić sobie sytuację, w której najważniejsze obszary aplikacji będą odporne na zakłócenia w ich funkcjonowaniu. Natomiast taki stan rzeczy pozwala nam na większą swobodę w zakresie dorzucania i eksperymentowania z funkcjonalnościami przyciągającymi uwagę. Można powiedzieć, iż pozostawiamy sobie możliwość odpalania fajerwerków w kontrolowanych warunkach, bez ryzyka spowodowania pożaru. A sandboxing rozwiązań, które dopiero testujemy, pozwala nam je w razie potrzeby wyłączyć, bez szkody dla głównych funkcjonalności.
Oczywiście wiedza na temat tego, co można robić, a czego powinno się unikać, musi być powszechna w zespole deweloperskim, co również jest zadaniem często składanym na barki bezpiecznika. W takiej sytuacji stanowimy wsparcie zespołu, który ma do kogo się zwrócić z prośbą o poradę. Dzięki temu jest szansa, iż już na poziomie tworzenia środowiska deweloperskiego i testowego zastosowane zostaną dobre praktyki związane z bezpieczeństwem i zminimalizuje się np. ryzyko wycieku informacji, zanim jakaś aplikacja ujrzy oficjalnie światło dzienne.
Przy takim podejściu testy penetracyjne stanowią pewnego rodzaju formalność polegającą na weryfikacji, czy skutecznie zmitygowano wszelkie zidentyfikowane wyzwania. Co ostatecznie pozwala oszczędzić czas i niebagatelne sumy pieniędzy, które mogłyby być wymagane na przebudowanie aplikacji od podstaw przed wypuszczeniem jej na środowisko produkcyjne.
Kamil Goryń. Cyber Security Engineer & Consultant. Bezpiecznik z zamiłowania i wykształcenia (co może potwierdzić makulaturą w formacie A3 i zdobionej okładce*). Zawodowo związany z branżą IT i szkolnictwem wyższym (mówi, iż płacą ZUSy, więc to niezły deal ¯_(ツ)_/¯). Na przestrzeni lat pełnił rolę konsultanta ds. cyberbezpieczeństwa, lidera zespołu pentesterów oraz freelancera. Udziela lub udzielał się w organizacjach pozarządowych (CERT.ngo, dawniej również SJSI.org), a także współorganizuje meetupy (BiałQA). Po godzinach okazjonalnie strzela, wysiada z całkiem sprawnych samolotów oraz szkaluje (j)elitarne ściśle tajne „firmy” państwowe.
