Cyberbezpieczeństwo w IoT, czyli Europejska Agencja ds. Bezpieczeństwa Sieci i Informacji publikuje dobre praktyki. Cz. 1 – podstawowe wymagania dla oprogramowania
Jednym z największych wyzwań gospodarki cyfrowej, w tym również sektora finansowego, jest kwestia bezpieczeństwa przetwarzanych danych. Nowe technologie, w tym wykorzystanie chmury obliczeniowej (po więcej zapraszam tutaj), powodują że stajemy przed wieloma wyzwaniami. Jeżeli dołożymy do tego możliwość skorzystania z tzw. Internetu Rzeczy (IoT), o którym pisałem m.in. tutaj, to ilość potencjalnych zagrożeń jeszcze wzrasta. Europejska Agencja ds. Bezpieczeństwa Sieci i Informacji opublikowała przedwczoraj dokument “Good Practices for Security of IoT. Secure Software Development Lifecycle”, który wspiera tworzenie bezpiecznych i efektywnych aplikacji pod IoT. Rekomendacje nie odnoszą się wprawdzie do rozwiązań stosowanych w sektorze finansowych, ale ich uniwersalnych charakter pozwala na wykorzystanie również i w tym obszarze. Przejdźmy przez najważniejsze elementy dokumentu.
Nie będę tutaj wracał do definicji IoT, ale bazując na raporcie “IoT w polskiej gospodarce. Raport Grupy Roboczej ds. internetu rzeczy przy Ministerstwie Cyfryzacji”, możemy stwierdzić, że to całokształt rozwiązań stosowanych na potrzeby “ożywienia” przedmiotów. Przykładem może być chociażby asystent głosowy czy systemy rozpoznawania tablic rejestracyjnych, a w branży finansowej – np. Wykorzystanie biometrii na urządzeniach typu Alexa (więcej na ten temat w tym artykule).
Na wstępie warto zwrócić uwagę na trzy podstawowe dobre praktyki, które zdaniem ENISA warunkują dalsze “dobre” tworzenie rozwiązań w oparciu o IoT. Zdaniem Agencji, aby to osiągnąć należy zwrócić uwagę na:
- Czynnik ludzki – czyli zaangażowanie wszystkich stakeholderów (zainteresowanych), w tym także użytkowników końcowych (np. beta testy czy testy na poziomie proof of concept);
- Procesy – bezpieczeństwo jako najważniejszy element każdego etapy cyklu życia;
- Technologie – zastosowane rozwiązania muszą być najbardziej aktualne, aby mogły spełnić wysokie wymagania w zakresie bezpieczeństwa.
Bardziej szczegółowo rekomendacje zostały opisane na str. 51-56 dokumentu ENISA.
Cykl życia, czyli Software Development Life Cycle
Jest to punkt wyjścia dla dobrych praktyk opracowanych przez ENISA, co ma związek z silnym przekonaniem, że oprogramowanie jest podstawowym elementem IoT, który odpowiada za jego efektywność, ale i bezpieczeństwo. Z tego względu przy jego tworzeniu (ENISA rekomenduje tutaj, aby od samego początku patrzeć na bezpieczeństwo przetwarzanych danych (security and privacy by design and by default).
Sam cykl życia obejmuje:
- Stworzenie konceptu oraz określenie podstawowych wymogów;
- Zaprojektowanie oprogramowania;
- Jego utworzenie oraz implementacja;
- Testowanie i zaaprobowanie;
- Uruchomienie i integracja oraz
- Utrzymanie i “likwidacja” (wyłączenie).
Na każdym etapie naważniejsze będzie zapewnienie, że wszystkie dane są należycie chronione przed nieuprawionym użyciem, w tym skopiowaniem czy też wykasowaniem.
Określenie wymagań jako punkt wyjścia
Obejmuje to nie tylko wymagania techniczne, ale również biznesowe czy funkcjonalne. Nie mniej istotne będą również regulacje stricte prawne, np. Rozporządzenie 2016/679 (RODO) czy Rozporządzenie 2018/389. Ma to o tyle znaczenie, że będzie stanowiło podstawę do opracowania specyfikacji technicznej, które powinna odzwierciedlać te wymagania. Przykładowo, jeżeli jako dostawca technologii dla banku chcielibyśmy stworzyć asystenta głosowego, który pozwala na dokonywanie zakupów przez internet i z możliwością “wzięcia” kredytu, to musimy rozważyć szereg aktów prawnych i regulacji, w tym Prawo bankowe, ustawę o usługach płatniczych, ww. RODO czy Rozporządzenie 2016/679, ale również rekomendację D KNF dla banków i rekomendację KNF SecurePay. O outsourcingu nie wspominam, bo choć na początku może wydawać się że ma to znaczenie wyłącznie dla operacjonalizacji procesu, to w praktyce może wpływać na to w jaki sposób oprogramowanie powinno zostać zaprojektowane.
Ogromne znaczenie, zdaniem ENISA, będzie tutaj miało określenie wymagań oraz ryzyk w zakresie 
bezpieczeństwa, które na tym etapie powinny zostać zidentyfikowane i należycie opisane. ENISA wymienia przykładową listę wymagań w tym zakresie, do których zalicza m.in. polityki w zakresie zmiany hasła (jak często, jakie wymagania co do maskowania i szyfrowania), potrzebę zaimplementowania tzw. Business Recovery Plan czy też czynniki zewnętrzne (np. związane z typami oszustw). Ważne będzie dokonanie oceny czy wprowadzenie określonego rozwiązania nie wymaga dodatkowych certyfikacji i spełnienia standardów międzynarodowych. ENISA wskazuje tutaj, że istotna będzie współpraca pomiędzy analitykami biznesowymi oraz inżynierami oprogramowania, ale ja dodałbym, że w dzisiejszych czasach również ważny będzie udział prawników oraz inspektorów compliance.
Nie mniej istotna będzie również analiza ryzyk, które mogą powstać w związku z korzystaniem z IoT oraz określenie jakie zagrożenia mogą pojawić się na dalszych etapach “życia” produktu. Ciekawa jest tutaj analiza przedstawiona przez OWASP. ENISA podkreśla również, że lista wymagań powinna obejmować:
- Wymagania bezpieczeństwa związane z przeznaczeniem IoT oraz
- Wymagania związane z konkretnymi funkcjonalnościami.
Przy tej okazji należy również dokonać oceny (identyfikacji) wymagań dla konkretnego urządzenia, aby oprogramowanie z nim należycie współpracowało. Rozumieć to należy szeroko. Gromadzenie i przetwarzanie danych wymaga zazwyczaj odpowiedniej mocy obliczeniowej, ale i przestrzeni dyskowej, nawet jeżeli dochodzi do przetwarzania w chmurze (co nota bene jeszcze bardziej komplikuje kwestię wymagań w zakresie bezpieczeństwa).
To na co jeszcze zwróciła uwagę Agencja to konieczność takiego tworzenia oprogramowania, które można szybko dostosować do zmieniającego się otoczenia (IoT), również w zakresie bezpieczeństwa.
Co w kolejnej odsłonie?
Pozostałe etapy SDLC.