Неусунені прогалини в безпеці потенційно можуть призвести до успішної атаки з великою кількістю наслідків. Від неефективних виправлень вразливостей до відтермінованих патчів, багато речей може піти не так, ставлячи під загрозу захист організації.
Точно знати, чи виправлено недолік, важливо для прийняття рішень. Незалежно від того, чи йдеться про критичну вразливість, яка затримує випуск нового релізу, zero-day у продакшні чи якусь давню проблему. Для цього необхідно проводити надійне та регулярне тестування, що надає достовірну інформацію про статус вразливостей.
Щоб бути впевненим в усуненні проблеми, треба розуміти, що саме треба виправити, та як перевірити, що вразливості дійсно більше немає. Незалежно від того, чи це застосування патча до стороннього продукту, чи виправлення власного коду, шлях до усунення недоліків має багато підводних каменів.
Часткового виправлення недостатньо
Часто виправлення робиться, наприклад, щоб просто закрити тікет та продовжити роботу, а не усунути першопричини вразливостей. В ідеалі виправленням має приділятися багато уваги QA. Але є нюанс, адже тестування безпеки відрізняється від інших видів тестувань, вимагає спеціальних навичок для виконання вручну та відповідних інструментів для автоматизації.
Приміром, поверхневим виправленням на основі звіту про вразливість «SQLi на сторінці X» може бути фільтрування вхідних даних форми щодо символів, які стосуються SQL. Може здатися, що тепер можна закрити тікет і забути про це, але є багато інших способів впровадити SQL у той самий параметр, до того ж на сторінці також можуть бути інші вразливі параметри. Більш того, виправлення нашвидкуруч може навіть сприяти виникненню інших вразливостей.
Єдиний спосіб бути впевненим у якості виправлень – виконання автоматизованих тестувань безпеки й унеможливлення потрапляння коду в продакшн без його перевірки.
Зловживання тимчасовими заходами
У випадку з системами продакшну, виправлення часто починається і закінчується використанням брандмауера вебдодатків (WAF). В ідеалі це має бути лише тимчасовим заходом до повного усунення вразливості. Однак дуже часто на цьому все і завершується, попри те, що вона все ще може бути експлуатована іншим типом атаки, який брандмауер не блокує.
Блокування – це лише поверхневе виправлення, що представляє великий ризик. Обхід правил брандмауера є фундаментальною навичкою як пентестерів, так і зловмисних хакерів, тому досить ймовірно, що рано чи пізно вразливість все ж зможуть експлуатувати. Звичайно, бувають ситуації, коли не вдається повністю виправити або застосувати патч до продукту, наприклад, якщо тестування показало, що виправлення певної вразливості порушить щось у системі. Проте це має бути винятком, а не правилом.
Найкращою практикою завжди є якнайшвидше усунення вразливості та автоматичне повторне тестування, щоб переконатися, що проблема справді зникла. Це займає більше часу, ніж просте блокування, але є значно надійнішим.
Нюанси застосування патчів
Застосування патча до стороннього ПЗ може здатися легшим, ніж виправлення власного коду, оскільки хтось інший вже виконав усю роботу і залишається лише застосувати патч. Але навіть якщо він доступний, може бути застосований та нічого не порушить, це не завжди означає, що вразливість усунено.
Особливо у випадку з поширеними та серйозними вразливостями зазвичай є ціла послідовність патчів (MOVEit випустив три лише за перший місяць). Окрім неповних виправлень, зроблених поспіхом, це також може бути результатом підвищеної уваги. Оскільки після того, як стає відомо про вразливість продукту, він раптово починає активно досліджуватися третіми сторонами, у тому числі зловмисниками. Як результат, часто знаходяться нові вразливості або шляхи атак, що призводить до купи нових патчів.
Кожен патч має бути протестований перед застосуванням у продакшні, і спочатку треба з’ясувати, чи потрібно його розгортати. Щоб розуміти, чи вразлива компанія до певного CVE, в ідеалі треба мати спосіб швидко протестувати все середовище. Це слід робити незалежно від перевірки та розгортання патчів, не кажучи вже про інвентаризацію продуктів і залежностей.
Відповідальність за неефективні виправлення
У 2023 році відбулося кілька резонансних випадків притягнення CISO (керівників відділів IT-безпеки) до юридичної відповідальності за порушення безпеки. Попри особливості кожного кейсу, це служить нагадуванням про важливість точної інформації про безпеку для CISO. Якщо все вказувало на те, що вразливість було виправлено, то чому компанію все одно зламали? Патч був неефективним? Чи повідомлення про його застосування було помилковим? Його застосовували всюди, крім одного місця? Чи він все ще стояв у черзі на виправлення, коли зловмисники змогли обійти брандмауер?
Кібербезпека може бути складною, і коли справа доходить до суду, стає ще більше зрозуміла значущість якісних процесів і рішень.
Важливість тестування та автоматизації
Перевірки на вразливості за допомогою ефективного інструменту DAST є невід’ємною частиною будь-якої успішної програми безпеки додатків. Завдяки автоматизованому тестуванню, інтегрованому в пайплайн розробки, можна відстежувати поточний стан безпеки, а також проводити перевірки перед продакшном. Інструмент також дозволяє автоматично тестувати внутрішні виправлення, щоб додатково запевнитися у їх надійності. Таким чином, можна виявляти експлойти до того, як вони створять проблеми для організації.
