Автор: Никола Петрович

Ускоряващи се атаки. Нашите процеси на засичане все още работят с темпото на човешкото време.

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

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

Но все повече се чудя дали този модел все още ще работи в икономиката на изкуствения интелект. Инстинктът ми подсказва, че не.

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

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

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

Атаката се ускорява. Процесът на реагиране често не се ускорява.

Истинският проблем вероятно е забавянето при засичането

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

Колко бързо можем да изолираме засегнатата машина? Колко бързо можем да отстраним уязвимостта и колко бързо можем да възстановим услугата (което е най-важното)?

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

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

По-голямото забавяне може да се случи след това:

  • Анализаторът се опитва да разбере дали това е фалшиво положителен сигнал.
  • Някой пита дали ограничаването на инцидента може да повлияе на производствената среда.
  • Едва тогава организацията предприема действия.

Всяка отделна стъпка може да е разумна. Заедно обаче те могат да създадат опасно забавяне. И те действително забавят реакцията.

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

Един скорошен пример направи това много осезаемо за мен.

Anthropic съобщи, че системата им Mythos Preview е идентифицирала хиляди уязвимости с висока степен на сериозност в основен софтуер с отворен код, включително софтуер, използван в основни операционни системи и браузъри. Един от анализите се позовава на приблизително 6202 констатации с висока или критична степен на сериозност, като към онзи момент се съобщава, че е обърнато внимание само на малка част от тях. Важното в случая не е дали всяка констатация се превръща в реален експлойт.

Важното е, че самото откриване на уязвимости се индустриализира.

Софтуер, който съществува от години, преглеждан е многократно и се счита за надежден, сега може да бъде изследван отново с напълно различна скорост и в съвсем друг мащаб. Говорим за хиляди засечени проблеми.

Същите възможности могат да помогнат и на защитниците. Това е добрата страна.

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

„Стабилен“ софтуер не означава автоматично безопасен софтуер.

„Широко използван“ не означава, че никой няма да открие друга слабост.

И „преди сме коригирали подобни проблеми“ не означава, че следващият проблем ще ни даде същото време за реакция.

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

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

Много екипи за сигурност вече имат достатъчно предупреждения. В някои случаи те имат твърде много.

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

Влизане от ново местоположение може да не е критично. Голямо изтегляне на данни може да не е критично. Новорегистриран токен за достъп може да не е критичен. Но когато тези събития се случат заедно, в кратък период от време, около една и съща идентичност (друга голяма празнина, която трябва да бъде запълнена с AI агенти), картината се променя напълно.

Атакуващите не действат като изолирани предупреждения. Те действат чрез последователности. Нашето засичане също трябва да разбира последователностите.

Не можем да чакаме пълна сигурност

Екипите за корпоративна сигурност разбираемо са предпазливи по отношение на автоматизираните действия.

Заключването на акаунт, деактивирането на услуга или изолирането на производствена машина може да причини реални бизнес щети. Никой не иска системата за сигурност да предизвика срива, който се опитва да предотврати.