В това интервю за Help Net Security Кунал Модасия, старши вицепрезидент и генерален мениджър в Qualys, обсъжда защо правилното инсталиране на корекции за сигурност все още е трудно постижимо. Той обяснява как натискът от страна на бизнеса, критичните за приходите системи и корекциите, които нарушават работата на приложенията, пречат на навременното прилагане на решенията. Модасия твърди, че скоростта сама по себе си има граници и че екипите трябва да разглеждат цялостния работен процес по отстраняване на уязвимости.
Той разглежда как проактивните екипи оценяват риска, защо интервалът между времето на експозиция и времето за създаване на работещ зловреден код е по-важен от MTTR (средно време за отстраняване), както и кога автоматизираното инсталиране на корекции има смисъл в производствени мрежи.
Първият проблем при инсталирането на корекции за сигурност е, че процесът включва много повече от една кръпка за един проблем. Едно обновяване може да изисква няколко корекции, за да бъде напълно отстранен проблемът, или да разчита на конфигурационни промени, за да се неутрализира изцяло уязвимостта. Затова „простото инсталиране на корекция“ може да се окаже по-сложно, отколкото звучи, особено в големи мащаби.
Вторият проблем е причината, поради която понякога корекциите изобщо не могат да бъдат внедрени. Повечето екипи по сигурност са се сблъсквали с това: те знаят за съществуването на проблема и разполагат с готово обновяване, но бизнесът не им позволява да го приложат. Защо? Често тези приложения са критично важни и са пряко свързани с генерирането на приходи. Спирането на подобно приложение означава спиране на приходите, а получаването на подкрепа за такова решение е изключително трудно.
ИТ екипите са добре запознати и със ситуации, при които внедряването на корекции за сигурност предизвиква непредвидени последствия или странични ефекти, които не са били забелязани предварително, оставяйки системата неработеща за по-дълго от очакваното. Критичните обновления се нуждаят от подкрепата на ръководството и управителния съвет, а получаването на това одобрение може да изисква по-убедителни аргументи от простото посочване на проблем със сигурността. Необходимо е да се вземе предвид финансовото въздействие и аргументите да бъдат представени на език, който бизнесът разбира и подкрепя.
Измерването на скоростта при коригирането на уязвимости преди се свеждаше до това колко бързо екипът може да разработи скриптове или друга автоматизация за задачите, но отговорността за скоростта на внедряване на тези корекции все пак оставаше тяхна. Съществуваше ограничение за това колко бързо може да се извърши мащабно разгръщане, дори с автоматизация, тъй като целият работен процес продължаваше да зависи от човешки действия. Изкуственият интелект може да помогне тук, улеснявайки тестването на корекциите или проверката за проблеми преди внедряване, но неговото въздействие е най-голямо, когато се разглежда работният процес в неговата цялост.
Например може да поискате да внедрите някои корекции автоматично. Може да предпочетете първо да тествате част от тях в малка подгрупа от работни среди, докато други да приложите навсякъде едновременно. Това решение се взема въз основа на това доколко корекцията намалява риска спрямо потенциалните последици, ако нещо се обърка. Преминаването през този процес с помощта на изкуствен интелект може да ускори изпълнението и да направи разпространението на корекциите по-ефективно. Скоростта на внедряване е само част от уравнението, а цялостното разглеждане на процеса е мястото, където ефективността може да бъде подобрена.
За екипите по ИТ сигурност предоставянето на такъв тип информация ги прави по-ценни за останалата част от бизнеса. Вместо само да отбелязват къде съществуват проблеми и колко сериозни са те, специалистите по сигурност могат да дават преки препоръки как да се направят тези промени и какви стъпки да се предприемат. Този екип може също да поеме отговорността за отстраняване и елиминиране на рисковете, вместо да прехвърля задачата на друг екип.
Проактивните екипи оценяват риска за своя бизнес, вместо да се ограничават със стандартните дефиниции на CVSS. Тези екипи анализират комбинацията от разузнаване на заплахите, инвентаризация на активите и потенциалното бизнес въздействие, като при поява на проблем в тяхната среда, който би могъл сериозно да засегне операциите, те са готови и способни да действат бързо. Този проактивен подход към управлението на риска им позволява да изпреварват всякакви кампании, стартирани от атакуващи.
Достигането до този етап изисква разбиране какво наистина означава рискът за бизнеса и къде се намира той. Не е достатъчно просто да има критичен проблем – къде точно се намира този критичен проблем? Достъпен ли е от интернет? Съществува ли наличен експлойт и могат ли атакуващите лесно да го използват в своите кампании? Можем ли бързо да смекчим потенциалния риск чрез промени в конфигурацията, а след това да инсталираме корекция за цялостно отстраняване на проблема?
Екипите по сигурност с напредничаво мислене вече са преминали през този процес и са го операционализирали, така че да могат да прилагат същия подход към всеки проблем по всяко време. Те могат да използват този процес и за да реагират на промени в средата на заплахите – например когато дадена уязвимост, считана за сравнително безобидна, внезапно се окаже част от по-широка верига на атака и се издигне в списъка с приоритети за отстраняване. Способността за гъвкавост и бърза реакция е от съществено значение.
Типичната метрика, която екипите следят, е средното време за отстраняване (Mean Time To Remediation – MTTR) – колко време е необходимо на екипа да внедри корекция за сигурност след публикуването на първоначалния проблем. Макар че MTTR все още може да бъде полезна, тя не е метриката, която бих препоръчал да се използва днес. Вместо това предлагаме да се обърне внимание на ефективността на отстраняване на уязвимостите.
Проследяването на първоначалното издаване на корекция е полезно, но не е най-същественият елемент. Вместо това екипите трябва да вземат под внимание своя среден прозорец на експозиция (Average Window of Exposure – AWE). Той обхваща времето, през което организацията остава изложена на потенциален експлойт след неговото появяване. В случай на уязвимости от тип нулев ден (zero-day) или когато даден атакуващ използва експлойт много преди публикуването на корекция за сигурност, организацията може да бъде уязвима дни преди откриването и оповестяването. Наред с това екипите трябва да следят и прозореца за превръщане в оръжие (Window of Weaponization – WOW) – той описва колко бързо атакуващият е превърнал потенциалната уязвимост в напълно работещ експлойт. Разликата между AWE и WOW е най-критичният показател за защитниците, тъй като показва колко дълго тяхната организация е била потенциално изложена на заплаха. Тази разлика в ефективността на отстраняване е ключова, защото определя точния прозорец, в който атакуващите имат предимство.
Автоматизираното отстраняване на уязвимости е възможно, но много екипи не желаят да преотстъпят пълен контрол на изкуствения интелект. Както всичко в сигурността, това не е решение от типа „всичко или нищо“. Вместо това екипите трябва да класират проблемите според тяхната сериозност, потенциалното им въздействие върху бизнеса при поява на експлойт и възможните последици от внедряването, ако нещо се обърка.
Логиката тук е, че критичните проблеми в приложения, генериращи приходи, трябва да получават най-голямо лично внимание от страна на екипа по сигурност. При нискорисковите приложения, където корекциите са с висока вероятност за надеждност, а рискът за потребителите при евентуален проблем е минимален, те могат да бъдат внедрявани автоматично. Добър пример в случая е обновяване за Google Chrome. За случаите, които не са толкова еднозначни, екипите могат да разделят внедряванията на нива според фирмената политика за риск и скоростта, с която могат да инсталират корекциите за сигурност.
Внедряването на тези процеси изисква съвместна работа между различни екипи. ИТ сигурността може да предостави анализи и препоръки на екипите по ИТ операции, а тези данни могат да се развиват във времето, за да отговарят на възникващите или променящите се проблеми.
Поглеждайки към бъдещето, стремежът ни е агентният изкуствен интелект (agentic AI) да поеме повече от тези практически сценарии в SecOps и отстраняването на дефекти, тъй като това позволява по-бързо и по-интелигентно намаляване на риска. Да вземем за пример „Вторника на корекциите“ (Patch Tuesday), когато Microsoft публикува своите обновления за сигурност всеки месец. За да определят кои корекции да приоритизират, повечето екипи преглеждат официалната информация в бюлетина и се концентрират върху тези с оценка „критично“ или „високо“. Тези официални класификации обаче може да не са подходящи за конкретната ви среда – възможно е вече да сте защитени срещу този сценарий чрез други мерки за смекчаване или обновления, докато друг проблем да е много по-неотложен за вашата специфична инфраструктура.
Агентният изкуствен интелект ще може да прави препоръки върху какво да се съсредоточи екипът ви, за да насочите вниманието си там, където съществува реален риск. След като приоритизирате уязвимостите си, можете да споделите тази информация и да определите кои от тях могат да бъдат коригирани автоматично и кои са отговорност на конкретни бизнес звена, като „Човешки ресурси“, „Финанси“ или „Маркетинг“. Определянето на отговорността е от ключово значение за довеждането на задачите до край, а агентният подход може да направи този процес значително по-лесен и ефективен.