Когато базата данни казва „критично“, но средата казва друго

Години наред екипите по киберсигурност имаха сравнително ясен ориентир: CVE номер, CVSS оценка, засегнат продукт и препоръчан пач. Националната база данни за уязвимостите на САЩ (NVD) беше един от основните източници на този контекст.

Този модел обаче вече се променя.

Заради огромния ръст на броя уязвимости NIST промени начина, по който обогатява записите в NVD. Пълният контекст вече се приоритизира основно за уязвимости, включени в каталога KEV на CISA, засягат софтуер, използван от федералната администрация на САЩ, или са свързани с критичен софтуер.

Това има сериозно практическо последствие: самото наличие на CVE вече не казва достатъчно за това колко бързо трябва да реагира конкретната организация.

Една и съща уязвимост може да означава различен риск

Представете си две компании с един и същ уязвим сървър.

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

CVSS оценката може да бъде една и съща. Рискът не е.

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

Приоритизацията трябва да започне не от въпроса „Колко е критична тази уязвимост?“, а от „Какво означава тази уязвимост в нашата конкретна среда?“

За MSP проблемът се умножава

При управляваните услуги ситуацията е още по-сложна.

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

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

Затова съвременната оценка трябва да комбинира поне няколко слоя информация:

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

Това превръща управлението на уязвимости от статичен списък в динамична оценка на риска.

Пачът не винаги е първата стъпка

Това е един от най-важните практически изводи.

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

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

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

Единното виждане става конкурентно предимство

Точно тук се появява ролята на унифицираните платформи за сигурност.

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

Това струва време – а при активно експлоатирана уязвимост времето е ресурс, който нападателят използва срещу организацията.

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

За MSP това е още по-важно, защото позволява приоритизирането да се извършва според реалния риск на всеки клиент, вместо всички среди да бъдат третирани по един и същи шаблон.

Следващият етап е риск-базираното управление на уязвимости

Промените в NVD не означават, че CVE и CVSS губят значение. Те остават важна отправна точка.

Но отправна точка не означава решение.

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

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

За MSP и MSSP доставчиците това е още по-съществено. Клиентът вече не се нуждае от още един отчет с червени CVSS оценки. Той има нужда от отговор на много по-практичния въпрос:

„Кое трябва да защитим първо и защо?“

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