В това интервю за Help Net Security Брайън Блекли, CISO в Bellini Capital, обяснява защо изкуственият интелект прави откриването на уязвимости по-бързо, докато отстраняването им все още изисква време. Той твърди, че подходът „по-бързо инсталиране на корекции за сигурност“ не е достатъчен и че екипите трябва да ограничават излагането на риск, докато трае процесът по отстраняване на уязвимостите.
Блекли описва споделена метрика за CIO и CISO, как неговият екип тества за скрити обновления на моделите, кой носи отговорност за щетите, когато даден AI агент допусне грешка, и защо блокирането на инструменти с изкуствен интелект без одобрена алтернатива води до обратен ефект.
Преди две години вярвах, че изкуственият интелект ще даде приблизително сравними предимства както на атакуващите, така и на защитниците. Напълно се отказах от тази гледна точка, а това, което промени мнението ми, беше ръководенето на сигурността за платформа за управление на уязвимости.
Нашите инженери използват AI в работната среда за разработка (IDE) и вътре в самия продукт, така че наблюдавам от първа ръка как откриването се ускорява. Докато намирането на уязвимости става по-бързо за всички, отстраняването им не се ускорява. Един атакуващ може да премине от открит дефект до работещ експлойт почти безпрепятствено. От другата страна, защитникът все още трябва да оцени въздействието върху бизнеса, да валидира корекцията за сигурност, да тества съвместимостта, да получи одобрение за промяната и да договори прозорец за техническа поддръжка с бизнеса.
Като бивш CISO на финтех компания, обработваща 50 милиарда долара годишно в онлайн трансакции, научих, че една платформа за разплащания не спира работа просто защото екипът по сигурност е намерил спешна уязвимост. Отложената корекция за сигурност там обикновено е умишлена и е стандартна оперативна процедура. Това беше съзнателен компромис между риска от експлоатация и риска от прекъсване на приходите.
Като цяло, „по-бързото инсталиране на корекции за сигурност“ е необходимо, но е недостатъчно като дългосрочна стратегия. По-правилният въпрос е колко бързо можем да намалим излагането на риск, докато трае отстраняването на уязвимостта, чрез сегментация, изолация, компенсиращи контроли и много по-бързи бизнес решения за управление на риска. Това дава на CIO и CISO обща цел: поддържане на критичните услуги активни, докато прозорецът за експлоатация се затваря.
Виждал съм как разделени показатели позволяват на CIO и CISO да постигат своите цели, докато бизнесът губи, тъй като техните стимули са разминати. Един CIO може да внедри или достави проект навреме и в рамките на бюджета, като същевременно внесе съществен риск и излагане на заплахи. Един CISO може да намали риска с контроли, които блокират проект, без да докаже, че забавянето си е струвало.
Най-добрият модел, който съм виждал, съществува в свързана със застраховането компания на стойност милиарди долари, която финансира AI чрез малки пилотни проекти за доказване на ползата с ясна цел: увеличаване на приходите при запазване на разходите за труд непроменени. Нашият Комитет по управление на AI и данните събира ръководителите на бизнес звена и оперативните екипи заедно с CIO, CTO и CISO, за да оценят всяка инициатива спрямо този резултат. Споделената мярка е процентът на критичните инициативи, реализирани в рамките на договорените финансови и оперативни ограничения, със съществени рискове, които са адресирани или изрично приети от отговорния собственик на бизнес процеса.
Предлагам три предпазни механизма, които могат да помогнат за предотвратяване на манипулации. Първо, дефинирайте успеха ПРЕДИ старта на пилотния проект, а не по време на анализа след приключването му. Второ, никога не оценявайте приемането на риск като отстраняване на риск; в повечето случаи подписът документира решение, но не премахва излагането на бизнеса на риск. И трето, преоценявайте след пускането в реална експлоатация, ако стартирането впоследствие създаде разходи за сигурност или оперативни затруднения. Когато всеки ръководител може да постигне индивидуалните си цели, докато организацията търпи предотвратима загуба, вие измервате оперативна, ИТ и дейност по сигурността, без да измервате бизнес успеха.
В моя опит традиционното управление на промените приема, че ако нищо видимо не се е променило, не се е променило нищо съществено или значимо. Изкуственият интелект нарушава това предположение със скорост и мащаб. Интерфейсът, конфигурацията и номерът на версията могат да останат същите, докато моделът под тях започва да разсъждава по различен начин. За компания, разработваща решения за управление на уязвимости, това не е абстракция. Ако моделът зад определянето на приоритети се промени, дефект, маркиран вчера за незабавно отстраняване, днес може да бъде класиран с нисък приоритет, без нищо в уязвимостта, средата или контролите да се е променило. Продуктът работи по проект; решението на клиента обаче се е променило съществено. Същото важи и за асистентите за програмиране, които нашият инженерен екип в Индия използва ежедневно. Промяна в модела може да измени кода, който те предлагат, без никой да е докосвал каквато и да е настройка.
Нашият отговор е регресионно тестване, базирано на риска. Поддържаме сценарии, изградени около критични активи, известни уязвимости и бизнес зависимости, и сравняваме резултатите с валидирани базови линии за отклонения в интерпретацията на риска, препоръчаните действия, обработката на данни и правата за достъп. Фиксираме конкретни версии там, където доставчиците го позволяват, без да приемаме за даденост, че винаги ще имаме тази възможност. Не мога да посоча скрито обновление, което да е причинило инцидент при нас, и съм внимателен относно това какво доказва това. Може просто да означава, че не сме измервали правилното нещо. Прекарахме десетилетия в обучение как да управляваме промените в софтуера. Сега трябва да решим как да управляваме промените в интелигентността, която стои зад него.
Организациите могат да делегират правомощия на даден AI агент, но не могат да делегират отговорност. Скорошен пилотен проект направи това напълно очевидно. Внедрихме агентен изкуствен интелект за провеждане на изходящи обаждания, обучен върху хиляди часове записани разговори с хора, а служителите, които провеждаха тези обаждания, преминаха към дейности с по-висока добавена стойност. Това беше успех за бизнеса. Но преди агентът да набере дори един клиент, основаният от нас Комитет по управление на AI и данните трябваше да отговори на въпроса: когато агентът каже нещо погрешно, кой поема отговорността?
Нашият отговор разграничава три роли. Финансовата отговорност следва източника на финансиране — независимо дали е бизнес звено, технологичният бюджет, резерв за инциденти или застраховка. Оперативната отговорност се носи от екипите, които възстановяват системите, разследват инцидентите и управляват регулаторните задължения: ИТ, сигурност и правен отдел. Ръководната отчетност се възлага и принадлежи на собственика на бизнес процеса, който е упълномощил агента да действа, докато CIO, CTO и CISO отговарят за собствените си контроли за сигурност. Тази рамка води до практичен тест: ако човек, провеждащ обаждания, се нуждае от одобрение, за да направи оферта или да разкрие клиентски данни, агентът не получава това правомощие само защото действа по-бързо. Много организации не са разписали тези правила. От моя опит най-лошият момент да решите кой носи отговорност за решенията на даден агент е след като той вземе решение, което не можете да отмените.
Блокирането на инструмент с изкуствен интелект може да бъде правилното решение, когато рисковете от него не са разбрани. Това, което отличава успеха от провала, е какво прави ръководството след това, а според моя опит съм виждал организации да грешат в това по-често, отколкото да постъпват правилно.
Walmart е добър пример за блокиране, което проработи. Технологичното му звено ограничи ChatGPT, след като забеляза дейност, оценена като рискова, след това анализира инструмента, издаде насоки за употреба и отново отвори достъпа в своята мрежа. Блокирането спечели време за изграждане на по-добър и по-контролиран подход. То послужи на стратегията, вместо да я замести.
Блокирането, което доведе до обратен ефект, е докладваното широко разпространение на „сенчест изкуствен интелект“ (shadow AI), при което служителите продължават да използват ChatGPT през лични профили въпреки корпоративните ограничения. Това може да се класифицира като заобикаляне на правилата и загуба на видимост, така че не представлява непременно пробив, НО компаниите затварят одобрения вход, без да се замислят защо служителите изобщо прибягват до него. В инженерно ориентирана култура този риск е особено изострен. Инженери, които са видели на какво е способен AI асистентът в средата за разработка (IDE), няма да спрат работа само защото прокси сървър или писмена политика забранява това. Това са блестящи инженери и повярвайте ми, те ще намерят друг начин.
Ето защо добре структурираният Комитет по управление на AI и данните съчетава ограниченията с проверена и одобрена алтернатива: бизнес ръководителите и CIO определят нуждите от производителност, CTO оценява техническата приложимост, а CISO задава защитните бариери и граници. Табло за управление, показващо почти нулева неоторизирана употреба на AI, доказва малко. Екипът по сигурност може да спечели спора за това кои инструменти са забранени и въпреки това да загуби контрол върху начина, по който бизнесът върши работата си.
