Bezpieczeństwo AI nie jest złamane, po prostu bronią się niewłaściwych rzeczy

Branża cyberbezpieczeństwa ma wzorzec, kiedy pojawia się nowa technologia, natychmiast zaczynamy budować wokół niej mury. Zrobiliśmy to z chmurą, zrobiliśmy to z kontenerami, a teraz robimy to z AI, tylko tym razem mury, które budujemy, są w całkowicie niewłaściwych miejscach.

Wejdź do dowolnej przeglądarki bezpieczeństwa przedsiębiorstwa dzisiaj, a usłyszysz te same priorytety: zabezpieczanie modeli AI, ochrona danych szkoleniowych, walidacja danych wyjściowych i wdrożenie AI-pomocników. Dostawcy są w pośpiechu, aby sprzedać “narzędzia bezpieczeństwa AI”, które koncentrują się wyłącznie na kontrolach na poziomie modelu, takich jak barierki, obrona przed wstrzyknięciem podpowiedzi i platformy monitorowania modeli.

Jednak atakujący używają Twoich integracji AI jako autostrad do wszystkiego innego.

Rzeczywista powierzchnia ataku, której nikt nie obserwuje

Jeden wzorzec, który obserwujemy stale w środowiskach przedsiębiorstw, opowiada niepokojącą historię zespołów bezpieczeństwa, które inwestują dużo w zabezpieczanie swoich środowisk rozwoju AI: kontrolę dostępu do modeli, ramy zarządzania danymi, bezpieczeństwo narzędzi MLOps. To daje fałszywą pewność, że ich AI jest “zabezpieczona”.

Gdy jednak mapujesz rzeczywistą powierzchnię ataku, widzisz, że boty czatu AI często posiadają tokeny OAuth dla dziesiątek platform SaaS, klucze API z nadmiernymi uprawnieniami w chmurze i relacje zaufania tożsamości, które mogą tworzyć bezpośrednie ścieżki od prostego wstrzyknięcia podpowiedzi do infrastruktury produkcyjnej. Sam model może być bezpieczny, ale ekosystemy, w których żyją, są często całkowicie otwarte, i to nie jest przypadkiem brzegowym.

Przedsiębiorstwa używają obecnie średnio 130+ aplikacji SaaS, z integracjami AI obejmującymi dostawców tożsamości, infrastrukturę chmury, bazy danych i systemy krytyczne dla biznesu. Każda integracja jest potencjalną ścieżką ataku, a każde połączenie API jest granicą zaufania, którą atakujący aktywnie sprawdzają.

Problem nie polega na tym, że nasze narzędzia bezpieczeństwa AI są złamane. To, że zabezpieczamy poszczególne składniki, podczas gdy atakujący wykorzystują połączenia między nimi.

Dlaczego bezpieczeństwo oparte na modelu mija się z celem

Obecne podejście do bezpieczeństwa AI opiera się na podstawowym niezrozumieniu, jak działają współczesne ataki. Traktujemy AI jako samodzielny aktyw, który wymaga ochrony, podobnie jak zabezpieczamy bazę danych lub aplikację webową. Ale AI w produkcji nie istnieje w izolacji. Jest to węzeł w złożonej sieci tożsamości, uprawnień, API i przepływów danych.

Rozważ typowe wdrożenie AI w przedsiębiorstwie. Masz agenta AI z dostępem do Twojego Google Workspace. Jest on połączony z Salesforce za pomocą API. Jest zintegrowany ze Slackiem do powiadomień. Pobiera dane z bucketów AWS S3. Jest uwierzytelniony za pomocą Okta lub Azure AD. Uruchamia przepływy pracy w ServiceNow.

Tradycyjne bezpieczeństwo AI koncentruje się na samym modelu: jego poście, walidacji podpowiedzi, bezpieczeństwie danych wyjściowych. Atakujący koncentrują się jednak na integracjach: co mogą osiągnąć za pomocą skompromitowanych kont usług, gdzie mogą przenieść się za pomocą manipulacji API, które granice zaufania mogą przekroczyć za pomocą wykorzystanych integracji.

Atak nie zaczyna się ani nie kończy na modelu AI. Model jest tylko punktem wejścia.

Ścieżki ataku nie szanują granic produktów

To jest miejsce, w którym większość organizacji utknęła. Wdrożyły narzędzia bezpieczeństwa, które każde zapewniają widoczność w jednej domenie. Jedno narzędzie monitoruje uprawnienia w chmurze. Inne śledzi konfigurację SaaS. Trzecie zarządza rządzeniem tożsamości. Czwarte zajmuje się zarządzaniem lukami w zabezpieczeniach.

Każde narzędzie pokazuje Ci swoją część układanki. Żadne z nich nie pokazuje, jak części się łączą.

Według Gartner, organizacje używają obecnie średnio 45+ narzędzi bezpieczeństwa. Mimo tego ogromnego inwestowania, atakujący łączą skutecznie błędy konfiguracji w tych domenach, ponieważ żadne pojedyncze narzędzie nie może zobaczyć całej ścieżki ataku.

Atakujący nie muszą znaleźć krytycznej luki w Twoim modelu AI. Muszą tylko znaleźć łańcuch. Może to być źle skonfigurowana rola IAM dołączona do Twojej usługi AI, która ma uprawnienia do bucketu S3, który zawiera poświadczenia do aplikacji SaaS, która ma dostęp administracyjny do Twojego środowiska produkcyjnego.

Każdy poszczególny błąd konfiguracji może uzyskać wynik “średni” lub “niski” w Twoich narzędziach bezpieczeństwa. Ale połączone? To jest krytyczne narażenie. I jest to całkowicie niewidoczne, jeśli spoglądasz na każdą domenę bezpieczeństwa w izolacji.

Imperatyw zarządzania narażeniem

To jest powód, dla którego konwersacja musi się przerzucić z “bezpieczeństwa AI” na ciągłe zarządzanie narażeniem zagrożeń dla środowisk zintegrowanych z AI.

Nie wystarczy zapytać, czy nasze modele AI są bezpieczne. Zespoły bezpieczeństwa muszą zrozumieć, co atakujący może rzeczywiście osiągnąć, jeśli skompromitują konto usługi AI. Muszą mieć widoczność, jak błędy konfiguracji w chmurze, SaaS i systemach tożsamości mogą być łączone. Muszą wiedzieć, jak integracje AI zmieniają ich powierzchnię ataku w czasie rzeczywistym. I muszą priorytetizować ryzyka na podstawie rzeczywistej możliwości ataku, a nie tylko ocen severności.

Większość programów bezpieczeństwa nadal priorytetizuje ryzyka w izolacji, używając ocen CVSS i list sprawdzania zgodności, które całkowicie ignorują, czy luka w zabezpieczeniach jest naprawdę wykorzystywana w Twoim konkretnym środowisku.

Ta luka jest jeszcze bardziej wyraźna w systemach AI, ponieważ zmieniają się one ciągle. Nowe integracje są dodawane co tydzień. Uprawnienia ewoluują. Połączenia API zmieniają się. Twoja powierzchnia ataku z ostatniego miesiąca nie jest Twoją powierzchnią ataku dzisiaj, ale Twoja ocena bezpieczeństwa prawdopodobnie tak.

Co tak naprawdę wygląda bezpieczeństwo świadome ścieżek ataku

Zabezpieczanie AI w produkcji wymaga fundamentalnie innego podejścia, i sprowadza się do czterech kluczowych zmian w myśleniu.

Po pierwsze, potrzebujesz jednolitej widoczności w całych domenach bezpieczeństwa. Przestań pytać każde narzędzie bezpieczeństwa, aby działało w swojej własnej izolacji. Twoje narzędzia bezpieczeństwa chmury, zarządzania tożsamości, zarządzania SaaS i skanowania luk w zabezpieczeniach wszystkie posiadają części układanki ścieżki ataku. Muszą dzielić się danymi w czasie rzeczywistym, abyś mógł zobaczyć, jak błędy konfiguracji łączą się.

Po drugie, przyjmij symulację ciągłej ścieżki ataku. Nie czekaj na testy penetracyjne lub ćwiczenia czerwonego zespołu, aby odkryć wykorzystywane ścieżki. Ciągle testuj, jak atakujący może poruszać się przez Twoje środowisko, koncentrując się na rzeczywistej wykorzystywalności, a nie polegając na teoretycznych ocenach severności.

Po trzecie, priorytetizuj na podstawie kontekstu. Źle skonfigurowany bucket S3 nie jest krytyczny tylko dlatego, że jest publiczny. Jest krytyczny, jeśli jest publiczny i zawiera poświadczenia, a te poświadczenia mają uprawnienia administratora, i są dostępne z internetu. Kontekst jest ważniejszy niż jakakolwiek indywidualna ocena.

Czwartym, przechodź do prewencyjnej rekompensaty. Zanim Twoje SOC zacznie śledzić alert, już straciłeś cenny czas odpowiedzi. Współczesna obrona wymaga możliwości zamknięcia wykorzystywanych ścieżek, zanim zostaną uzbrojone, a nie po incydencie.

Ostrzeżenie, którego nie możemy zignorować

Gdy AI staje się wbudowane w każdą warstwę stosu przedsiębiorstwa, powierzchnia ataku rozprzestrzenia się szybciej, niż zespoły bezpieczeństwa mogą ręcznie rozumieć ją. Dodajemy integracje AI w 10 razy szybszym tempie, niż je zabezpieczamy.

Jeśli zabezpieczasz AI w izolacji, chroniąc model, a ignorując ekosystem, w którym działa, jesteś już w tyle. Atakujący nie myślą w kategoriach narzędzi, myślą w kategoriach ścieżek. Nie wykorzystują poszczególnych luk w zabezpieczeniach. Łączą błędy konfiguracji w całym Twoim środowisku.

Przedsiębiorstwa, które pomyślnie zabezpieczą AI, nie będą tymi, które mają najwięcej narzędzi bezpieczeństwa AI. Będą to te, które rozumieją, że bezpieczeństwo AI jest nierozłączne z zarządzaniem narażeniem na całej powierzchni ataku.

Bezpieczeństwo modelu jest podstawą. To, co się liczy, to zrozumienie, co atakujący może osiągnąć, jeśli skompromitują integrację AI. Dopóki zespoły bezpieczeństwa nie będą mogły odpowiedzieć na to ciągle, w czasie rzeczywistym, na całej powierzchni ataku, nie zabezpieczają AI. Po prostu mają nadzieję, że mury, które zbudowali, są w odpowiednich miejscach.