Накратко: Управлението на уязвимостите в средния и малкия бизнес е стегнат, повтарящ се цикъл: познаване на системите, целенасочено следене на съобщенията, оценка по риск, решение, изпълнение и доказателства. Решаващи не са скъпите инструменти, а ясните отговорности и приоритизация, която отчита достъпността, данните и положението с атаките. PHP2Shell е добър пример за упражнение, защото в него присъстват всички стъпки.
Стотици съобщения, малко персонал
Всяка седмица се публикуват нови уязвимости в операционни системи, езици за програмиране, приложения и добавки. Един концерн има за това екип. Една средна фирма често има ръководител на ИТ, един-двама администратори и няколко външни доставчици. Никой не може да прочете всяко съобщение и това не е и нужно.
Нужен е филтър: кои съобщения засягат нашите системи, кои от тях са спешни и кой се грижи за тях? Когато този филтър липсва, се случва едно от две неща. Или всичко се пренебрегва, докато нещо не се случи, или всяко съобщение предизвиква паника и наистина критичното се губи в шума.
Цикълът на управление на уязвимостите
Работещ процес за малкия и средния бизнес може да се опише в шест стъпки:
- Да се отчете какво работи. Без инвентар няма сверяване. Кои уебсайтове, сървъри, версии на PHP и приложения стопанисвате и къде? Как се постига това, показва статията Да знаем какво работи: инвентар на всички уебсайтове и сървъри.
- Да се следят съобщенията. Абонирайте се за малко на брой надеждни източници: предупрежденията на BSI (Федералната служба за информационна сигурност на Германия), съобщенията на производителите на Вашия софтуер, страниците за сигурност на Вашата Linux дистрибуция, а за PHP началната страница на php.net.
- Да се оцени. Засяга ли ни съобщението? Ако да, колко е спешно? Повече за това по-долу.
- Да се реши. Да се отстрани, временно да се обезопаси, системата да се изолира или рискът съзнателно да се поеме. Кой какво има право да решава?
- Да се изпълни. Да се инсталира актуализация, да се зададе временна мярка, да се възложи на доставчик.
- Да се докаже и проследи. Наистина ли е затворена уязвимостта? Кога временното решение ще бъде заменено?
След това цикълът започва отново. Появяват се нови системи, старите отпадат и излизат нови съобщения.
При втората стъпка помага просто правило: по-добре да четете редовно малко източници, отколкото от време на време много. За типична среда на средна фирма с уеб системи обикновено са достатъчни предупрежденията на CERT-Bund (германския правителствен CERT) към BSI, съобщенията за сигурност на използваната Linux дистрибуция, страниците на производителите на CMS и магазинни системи и началната страница на php.net. Определете кой чете тези източници и създайте за целта обща пощенска кутия или канал, който не зависи от един-единствен човек.
Като допълнение си заслужава поглед отвън. Редовното сканиране за уязвимости на публично достъпните системи показва дали се виждат остарял софтуер или ненужно отворени услуги. То не замества нито инвентара, нито актуализациите, но разкрива системи, които не фигурират в никой списък.
Оценка: какво е на ред първо
Стойността CVSS, стандартизирана оценка на степента на тежест, е добра отправна точка. За реда във Вашата фирма тя обаче не е достатъчна. Решават още три въпроса:
| Въпрос | Увеличава спешността | Намалява спешността |
|---|---|---|
| Достъпна ли е системата от интернет? | публичен уебсайт, магазин, портал | само вътрешна, зад VPN |
| Нужен ли е вход, за да се използва уязвимостта? | не, без удостоверяване | да, само за администратори |
| Какви данни обработва системата? | данни на клиенти, плащания, достъпи | публично съдържание без акаунти |
| Има ли съобщения за атаки? | съобщени опити за атака | няма известни опити |
| Има ли временна мярка? | не | да, с доказано действие |
PHP2Shell показва как всичко това се съчетава. И двете уязвимости имат стойност CVSS v4.0 9,2, позволяват изпълнение на код без вход и засягат публично достъпни уеб сървъри. Cloudflare и Patchstack според медиите съобщиха за опити за атака, BSI определи положението като предупредително ниво 3. Временните мерки на php.net изрично не предлагат пълна защита. Всички въпроси сочат в една посока: действайте веднага. Какво конкретно препоръча BSI, е описано в Какво препоръчва BSI за PHP2Shell.
Решение и документиране
Не всяка уязвимост може да се затвори веднага. Една стара система работи на PHP 8.1, за който вече няма официални актуализации (вижте PHP 8.1 и по-стари: какво важи сега), а едно специализирано приложение още не понася актуализацията. Тогава е нужно решение и то не принадлежи единствено на техниката.
Добрата бележка за решение съдържа засегнатата система, уязвимостта, оценката, избрания вариант, временните мерки, отговорното лице и срок за повторна проверка. Когато рискът се поема съзнателно, решава ръководството, а не администраторът сам. OWASP Cheat Sheet за работа с уязвими зависимости също препоръчва приемането на риска изрично да се закрепи на ниво ръководство.
Водете един-единствен списък на отворените уязвимости със статус, отговорник и срок. Достатъчна е една таблица. Важно е тя да се преглежда редовно, например на месечната среща с управителя.
Каква е връзката с NIS2 и доставчиците
За фирмите, които попадат под NIS2, работата с уязвимости е част от задълженията за управление на риска. Подробностите описва NIS2 и сигурност на уеб сървърите. Но и без законово задължение документираният процес е предимство, например пред клиенти, застрахователи и собственото ръководство.
Много стъпки могат да се възложат на външни изпълнители, например следенето на съобщенията или инсталирането на актуализации. Решението за рисковете и общата картина обаче трябва да останат във фирмата. Който предаде целия цикъл напълно на доставчик, в критичен момент вече не знае кои системи изобщо притежава. Как изпълнението се организира като рутина, описва Управление на пачовете като процес, а не като гасене на пожари.
Как помага PHP SOS конкретно?
- Изготвяме с Вас инвентара на Вашите уебсайтове и сървъри като основа за всяко сверяване.
- Следим за Вашите системи съответните съобщения и предоставяме оценка на ясен език с препоръка.
- Подготвяме бележки за решения за случаите, в които актуализацията не е възможна веднага.
- Чрез Security-Monitoring постоянно проверяваме дали системите стават подозрителни, докато една уязвимост е още отворена.
Извод: Управлението на уязвимостите в средния бизнес не трябва да е голямо, но трябва да е обвързващо. Който познава своите системи, чете малко добри източници и записва решенията си, реагира бързо и правилно при следващото критично съобщение.
Често задавани въпроси
Какво е управление на уязвимостите?
Повтарящ се процес, чрез който фирмата научава за пропуски в сигурността на своите системи, оценява ги, отстранява ги или съзнателно ги приема и документира резултата. Не става дума за инструмент, а за отговорности и решения.
Достатъчна ли е оценката CVSS за приоритизиране?
Тя е добра отправна точка, но не е достатъчна. Допълнително е важно дали засегнатата система е достъпна от интернет, какви данни обработва и дали вече се наблюдават атаки. Уязвимост с висока оценка на вътрешна тестова система може да почака, на магазина не може.
Нужен ли е на малка фирма отделен инструмент за това?
Първоначално не. Достатъчни са поддържан списък на системите, абонирани съобщения за сигурност и таблица с отворените точки. Скенерите за уязвимости се оправдават, когато броят на системите расте или проверките трябва редовно да се доказват.
Може ли съзнателно да не се отстрани една уязвимост?
Да, ако рискът е оценен, решението е взето от отговорното ръководство и е записано писмено, в идеалния случай с временни мерки и срок за повторна проверка.