В това интервю за Help Net Security Бранди Уитяк, вицепрезидент по сложни въпроси в LevelBlue, обяснява какво се случва в часовете след инцидент, свързан с нерегламентиран изкуствен интелект (shadow AI).

Тя описва колко бързо се презаписват регистрационните файлове (логовете), защо записите от защитната стена за изходящия трафик към AI платформи често са изчезнали преди пристигането на екипите за реагиране и какво търсят регулаторите, когато оценяват дали дадена компания е направила достатъчно. Уитяк също така обсъжда разликата между политика за ИИ, записана в уики, и механизъм за контрол, който компанията може действително да защити, както и кога документацията помага или вреди.

Най-първият актив, който трябва да бъде изискан, е крайното устройство на потребителя, което следва да бъде обезопасено. Всяко регистриране на събития, което би могло да покаже потребителско действие, също трябва да бъде запазено, за да се предотврати презаписването му.

Обикновено това води до ситуация, в която дадена организация не знае или не разбира с какви регистрационни файлове разполага или къде точно ги съхранява.

При многобройни случаи сме искали логове, само за да ни отговорят три дни по-късно, че не могат да ги намерят или че всъщност не ги съхраняват, въпреки че са си мислели обратното. В някои случаи те изобщо не са регистрирали определени събития, въпреки убеждението си, че го правят. Разликата между това как една организация си представя своята среда за регистриране на събития и как изглежда тя в действителност е едно от най-често срещаните неща, на които се натъкваме.

Този прозорец започва да се затваря в момента, в който възникне инцидентът. Регистрационните файлове имат ограничен период на съхранение и веднага започват да се презаписват. Първото нещо, което вероятно вече е изчезнало, са логовете от защитната стена, показващи изходящи връзки към AI платформи като api.openai.com, claude.ai, gemini.google.com. Тези връзки често са най-ясното доказателство за това какви данни са напуснали организацията и кога, като те често вече не са налични до момента, в който биваме ангажирани.

Ако данните изобщо не са напускали крайното устройство, ситуацията е още по-критична от гледна точка на времето. Времевият прозорец се скъсява допълнително, ако доказателствата съществуват само на потребителското устройство и се съхраняват в оперативната памет. Всяко действие, което потребителят предприема на това устройство след инцидента, крие риск от трайно презаписване на тези данни. В такива ситуации скоростта, с която се обезопасява крайното устройство, е от решаващо значение.

Малко вероятно е регулаторен орган да заключи, че организацията просто не е имала късмет. Инцидентът ще бъде оценяван спрямо регулаторните стандарти, с които организацията е обвързана. Съгласно изискванията на GDPR в Обединеното кралство и ЕС това означава дали са били въведени подходящи технически и организационни мерки съобразно риска.

Използването на нерегламентиран ИИ от служител никога не се разглежда като малшанс от регулаторна гледна точка – може да се установи, че организацията не е изпълнила задълженията си и да бъде подведена под отговорност. Централният въпрос при инциденти с нерегламентиран ИИ вероятно ще бъде дали организацията е предприела мерки в рамките на своите възможности, за да ограничи дейността на служителите и да смекчи риска. Обикновено в тази посока се насочват заключенията.

В момента вярваме, че повечето компании са в самото начало на своя път към зрялост по отношение на управлението на ИИ и техническия контрол. Въпросът не е просто дали разполагат с конкретен контрол – независимо дали става въпрос за писмена политика, план за управление или техническо ограничение. Въпросът е дали действията на организацията за смекчаване на риска от нерегламентиран ИИ са били подходящи.

Регулаторът ще посочи случаи, при които организациите не са представили доказателства (или те са били недостатъчни) защо не са приложили определен контрол. Организациите, които имат добра практика да документират своите решения и причини за неизпълнението на някои мерки, ще имат предимство при изграждането на своята защита впоследствие. Това е особено важно за въпроси като остарели системи (legacy systems), които може да не са в състояние да съответстват напълно на настоящите насоки – задълбоченото проучване на смекчаващите мерки и компенсаторния контрол ще бъде от съществено значение. Повечето организации все още не са постигнали това, поради което разликата между наличието на политика и способността тя да бъде защитена пред регулатор остава голяма.

Виждали сме сценарии, при които дадена организация е документирала, че се изискват определени контроли, но те просто не са били внедрени, което засяга не само регулаторните резултати, но и застрахователното покритие. Почти всеки инцидент, с който се справяме, включва организация, която ни казва, че подобрението или съответната корекция за сигурност са били в техния план за развитие (roadmap) и са щяли да бъдат внедрени съвсем скоро.

Решението на това противоречие е по-добро управление на процесите след документирането на дадено решение, а не по-малко писане. Ако е взето решение да не се обърне внимание на даден риск веднага, запишете защо. Отбележете какви смекчаващи контроли са въведени междувременно и кога ще бъде разгледан въпросът отново. Документална следа, която показва аргументирано и обмислено решение, е защитима. Документална следа, която показва, че даден проблем е бил маркиран и след това забравен, не е.

  • Изтеглете: Абсолютното ръководство за управление на мрежови операции