Dlaczego tożsamość urządzenia jest pomijanym zagrożeniem wewnętrznym.
Nie brakowało myśli i pomysłów na temat zarządzania i ograniczania ryzyka wewnętrznego, które wiąże się z posiadaniem ludzi jako części ekosystemu.
To prawda, człowiek jest zarówno siłą, jak i słabością. Są oni wezwani do ograniczenia ryzyka i złagodzenia działań wrogiego lub nieostrożnego pracownika. Tam, gdzie dyskusja była rzadka, dotyczy roli tożsamości maszyny/urządzenia w zarządzaniu ryzykiem wewnętrznym.
„Potrzebne jest częstsze stosowanie ram zagrożeń wewnętrznych w stosunku do urządzeń na tym samym poziomie, co w przypadku ludzi” — mówi Rajan Koo, dyrektor ds. obsługi klienta w firmie DTEX Systems.
Yash Prakash, dyrektor ds. strategii w firmie Saviynt, zauważa: „Zagrożenia wewnętrzne w coraz większym stopniu stwarzają ryzyko dla organizacji, przede wszystkim dlatego, że w ostatnich latach tożsamość osób poufnych wzrosła, obejmując tożsamości ludzkie i tożsamości maszynowe (tj. interfejsy API, boty, konta dostawców itp.) .
„Wzmacniając program tożsamości organizacji, firmy mogą skuteczniej ograniczać to ryzyko i ograniczać wpływ złośliwych osób poufnych poprzez wczesne wykrywanie oszustw i zapobieganie eksfiltracji krytycznych danych”.
Bot jako użytkownik uprzywilejowany
W dalszym wyjaśnianiu, w jaki sposób zaangażowanie człowiek-maszyna może być wykorzystywane w szkodliwy sposób, Prakash podaje przykład działu finansowego, odpowiedzialnego za zatwierdzanie i płatność bonami.
Kierownik ma przygotowany skrypt, który automatyzuje proces zatwierdzania, w przypadku bardziej rutynowych zadań, dzięki czemu kierownik ma więcej czasu na skoncentrowanie się na bardziej złożonych zadaniach. Z punktu widzenia wydajności jest to zwycięstwo na wielu poziomach. Z punktu widzenia ryzyka cybernetycznego bot programowy — robotyczna automatyzacja procesów (RPA) — jest teraz uprzywilejowanym użytkownikiem w procesie finansowym i stwarza nowe zagrożenia.
Wprowadzenie RPA, z uprzywilejowanym dostępem, do workflow niesie ze sobą ryzyko. Bot musi być uwierzytelniony, aby wykonać wymagany proces biznesowy — uzyskać dostęp do systemu, skanować, analizować i przetwarzać. Te poświadczenia są zakodowane na stałe w procesie i rzadko, jeśli w ogóle, aktualizowane.
Następnie mamy pracowników, którzy tworzą własne boty, wywodzące się z procesów CISO, w podobny sposób, w jaki pracownicy rozwijają swoje ukryte procesy IT. Po prostu starają się, aby ich praca została ukończona dla ich wiceprezesa, lub w przykładzie podanym przez Koo poniżej, próbowali oszukać przedsiębiorstwo, jeśli chodzi o ich zaangażowanie w swoją pracę.
Koo opowiada, jak w jednym ze swoich dochodzeń natknęli się na pracownika, którego dostęp do sieci przypominał falę sinusoidalną — logowanie 0700, uzyskiwanie dostępu do aplikacji, otwieranie i zamykanie, odświeżanie dostępu do aplikacji w porze lunchu, a następnie zamykanie aplikacji i wylogowywanie o godzinie 18:00. , wszystko kontrolowane przez skrypt stworzony przez pracownika, aby sprawiać wrażenie pracy w te dni, kiedy pracownik chciał się pobawić.
W osobnym przypadku Koo opowiedział, w jaki sposób zachowanie inne niż ludzkie lub skrypty/boty eksfiltrowało dyrektora finansowego z prezentacji finansowych firmy. Kiedy opadł kurz, potwierdzono, że dyrektor finansowy padł ofiarą ukierunkowanego ataku phishingowego, a jego dane uwierzytelniające zostały naruszone.
Kompromis otworzył przeciwnikowi uprawnienia udzielone dyrektorowi finansowemu na włączenie wielu botów RPA. Co ciekawe, przeciwnik w tym przypadku nie stosował żadnego złożonego złośliwego oprogramowania. Używali niskoprofilowych, gotowych komercyjnych aplikacji do przesyłania na serwer FTP informacji dostępnych za pośrednictwem instancji dyrektora finansowego.
Potrzebna lepsza widoczność
Oczywiste pytanie dla CISO brzmi: „Jaki poziom widoczności ma zespół infosec nad botami RPA w ich sieci i jakie są procesy otaczające ich troskę o zapewnienie, że w przypadku naruszenia poświadczeń nie można użyć do podniesienia uprawnień poza te, które były zamierzone ?”
Poza botami RPA istnieje potrzeba, w miarę możliwości, usunięcia „na zawsze” wystąpień danych uwierzytelniających w urządzeniach w ekosystemach i we wszystkich przypadkach zapewnienie, że proces uwierzytelniania odbywa się przed skryptami, maszynami lub innymi formami automatyzacji uruchamiany.
Podsumowując, Koo ma rację: urządzenia i procesy muszą być traktowane z taką samą uwagą, jaką poświęca się poszczególnym osobom, zajmując się strategią zarządzania ryzykiem wewnętrznym.
