Możliwe, iż wynika to z potencjalnie trudnej tematyki. Dostępne materiały pisane są zwykle specjalistycznym językiem, który wymagałby poświęcenia czasu i wykazania chęci zrozumienia, na co nie ma przecież czasu w tym szalonym tempie życia. Z drugiej strony, będąc adwokatem diabła, czy można dziwić się tak biernej postawie konsumenta?
Czy gdybym kupował “smart” rozwiązanie wiedząc o istniejącej liście potencjalnych zagrożeń, byłbym skłonny namówić sam siebie, iż dokonałem adekwatnego zakupu? Czy spodziewając się ataków DDoS, które mogą przyjąć różne formy (ICMP flooding, amplification, jamming) byłbym przez cały czas gotów kupić “smart” urządzenie? W jaki sposób zareagowałbym na fakt istnienia malware do produktów IoT (wirusy, trojany, ransomware, scareware), które mogłyby nabrać i zmusić mnie do ściągnięcia niebezpiecznego systemu zagrażającego mojemu bezpieczeństwu? Czy byłbym równie chętny do zakupów wiedząc, iż mój sprzęt można w prosty sposób złamać przy użyciu rootkitów, manipulując software lub hardware lub generując nieprawidłowe certyfikaty?
Jak klienci mogą bez strachu kupować produkt, który potencjalnie jest niezwykle prosty do złamania i nie spełnia podstawowych kryteriów bezpieczeństwa nagłaśnianych przez OWASP? Ile razy byliśmy świadkiem fizycznych modyfikacji smart produktów, a to dzięki sabotażu środowiska (ultrasonic sensor jamming, spoofing, cancellation) lub fizycznego rozmontowania produktu? Ile jeszcze takich historii musimy wysłuchać?
Ataki na użytkowników stają się coraz bardziej przebiegłe i osobliwe. Wliczając zarówno te odważne i aroganckie (identity fraud, nadużycie uprawnień, nieautoryzowany dostęp do osobistych danych), przebiegłe i sprytne (phishing, spearphishing, reverse social engineering, impersonation, baiting), przypadkowe (naturalne klęski -- powodzie, pożary, ekstremalne warunki -- które odsłaniają dostęp do wnętrza urządzenia) jak i wyrachowane (man in the middle, communication protocol hijacking). A gdzie w tym wszystkim miejsce na problemy natury stricte technicznej (błędy wynikające z konfiguracji, błędna aktualizacja, niedziałające serwery, słaba kryptografia, niedostateczna autentykacja)? Gdzie możliwość pomyłki ze strony firm trzecich wspierających „egzystencję” produktu (mam tu na myśli dostawców serwisów, sprzedawców usług SaaS, administratorów chmur)?
Niecałe trzy akapity, kilkanaście przykładów zagrożeń, a nie zdołałem wymienić choćby wszystkich problemów (rekonesans sieci? Nieuprawnione zbieranie danych? Wycieki informacji? Session hijacking?). Jak wobec tego nawału informacji miałby odnaleźć się teraz konsument? Nie wierzę, aby istniał ktokolwiek niezwiązany z branżą IT, kto po usłyszeniu powyższej tyrady, którą trzeba by było najpewniej przedstawić w jeszcze prostszych słowach, byłby skłonny nabyć jakiekolwiek narzędzie, które łączy się z siecią i przekazuje innym produktom dane na jego temat. Przecież to brzmiałoby jak absurdalne, niedorzeczne zachowanie. Autodestruktywne działania na własną szkodę. Jak ktokolwiek przy zdrowych zmysłach mógłby chcieć świadomie kupować i podłączać takie produkty w swoim otoczeniu?
## No właśnie -- kto?
Na tym polega ten swoisty paradoks, którego jesteśmy świadkami. Z jednej strony konsumenci są niedostatecznie poinformowani i nieświadomi (co pozwala na coraz prostsze ingerowanie w ich życie), z drugiej przez swoją ignorancję kupują coraz to więcej smart rzeczy.
## "I co dalej?" -- mógłbym teraz zapytać.
Odpowiedzialność za ten i przyszły stan rzeczy zależy w tym momencie i w głównej mierze od nas -- testerów i developerów. o ile bowiem nie zaczniemy głośno dyskutować na temat istoty testów bezpieczeństwa i nie zaczniemy wprowadzać i stosować inteligentnych rozwiązań, to będziemy brnąć w tym szaleństwie dalej, nie bacząc na konsekwencje.
Naprawdę nie wymaga to wiele wysiłku, aby przeczytać i zapoznać się z dostępnymi standardami (ISO27001, NIST SP 800-53, OWASP, IETF RFC 7452, Cybersecurity Policy For IoT by wymienić kilka ogólnodostępnych) i zacząć wprowadzać je do swoich cyklów wytwarzania oprogramowania. Zagrożenia można redukować zarówno dzięki bardziej świadomej polityki firmy (konserwatyzm produkcyjny, privacy-by-design, threat modeling), przy pomocy odpowiedzialnych pracowników (wsparcie i monitorowanie urządzeń w całym cyklu, zarządzanie incydentami, treningi i szkolenia) jak i dzięki zdroworozsądkowego wytwarzania produktu (szczególnie w takich obszarach jak np. uwierzytelnienie i autoryzacja).
Zdaję sobie sprawę, iż zaczynając temat od złej strony (np. kryptografia), sami możemy poczuć się równie przytłoczeni co konsumenci. Szczególnie jeżeli w tak krótkim czasie musimy zapoznać się z dziesiątkami nowych pojęć często ignorowanych w normalnych warunkach produkcyjnych.
A może wystarczyłoby zacząć dużo prościej? Może powinniśmy wrócić do stołu kreślarskiego, zadając sobie cztery podstawowe pytania:
- Co budujemy?
- Co może pójść nie tak?
- Co zamierzamy z tym zrobić?
- Czy dotychczas wykonaliśmy dobrą robotę?
Poświęćmy to jedno daily na odpowiedzenie sobie na postawione przez nas pytania -- tak szczerze i od serca i zobaczmy czy w tym momencie nie popełniliśmy już błędów naruszających sferę bezpieczeństwa.
W zamyśle są to proste i banalne wątpliwości, ale jestem przekonany, iż w większości przypadków mogłyby rozpocząć one interesującą dyskusję skierowaną właśnie na tematykę bezpieczeństwo.
I choć zdaję sobie sprawę, iż tej trudnej kwestii nie naprawimy jednym spotkaniem lub artykułem, tak chciałbym wierzyć, iż przysporzy ono okoliczności do tego, by zacząć częściej i śmielej spoglądać w kierunku tematyki zagrożeń.
Każdy krok w tę stronę i każde odpowiednio postawione pytanie zmuszające do niewygodnych odpowiedzi jest moim zdaniem dobrze wykonanym ruchem.
