Неустраненные пробелы в безопасности могут привести к успешной атаке с большим количеством последствий. От неэффективных исправлений уязвимостей до отсроченных патчей, многое может пойти не так, ставя под угрозу защищенность организации.
Точно знать, исправлен ли недостаток, важно для принятия решений. Независимо от того, речь идет о критической уязвимости, которая задерживает выпуск нового релиза, zero-day в продакшне или о какой-то давней проблеме. Для этого необходимо проводить точное и регулярное тестирование, которое дает достоверную информацию о статусе уязвимостей.
Чтобы быть уверенным в устранении проблемы, нужно понимать, что нужно исправить, и как проверить, что уязвимостей действительно больше нет. Независимо от того, это применение патча к постороннему продукту, или исправление собственного кода, путь к устранению недостатков имеет много подводных камней.
Частичного исправления недостаточно
Часто исправление делается, например, чтобы просто закрыть тикет и продолжить работу, а не устранить первопричины уязвимостей. В идеале исправлению должно уделяться большое внимание QA. Но есть нюанс, ведь тестирование безопасности отличается от других видов тестирований, требует специальных навыков для выполнения вручную и инструментов для автоматизации.
К примеру, поверхностным исправлением на основе отчета об уязвимости «SQLi на странице X» может быть фильтрация входных данных формы с учетом символов, относящихся к SQL. Может показаться, что теперь можно закрыть тикет и забыть об этом, но есть много других способов внедрить SQL в тот же параметр, к тому же на странице могут быть и другие уязвимые параметры. Более того, исправление на скорую руку может даже способствовать возникновению других уязвимостей.
Единственный способ быть уверенным в качестве исправлений – выполнение автоматизированных тестирований безопасности и предотвращение попадания кода в продакшн без его проверки.
Злоупотребление временными мерами
В случае с системами продакшна, исправление часто начинается и завершается использованием брандмауэра для веб-приложений (WAF). В идеале это должно быть лишь временной мерой до полного устранения уязвимости. Однако очень часто на этом все и заканчивается, несмотря на то, что она все еще может быть эксплуатирована другим типом атаки, который не блокирует брандмауэр.
Блокировка – это лишь поверхностное исправление, представляющее большой риск. Обход правил брандмауэра является фундаментальным навыком как пентестеров, так и злонамеренных хакеров, поэтому весьма вероятно, что рано или поздно уязвимость все же смогут эксплуатировать. Конечно, бывают ситуации, когда не удается полностью исправить или применить патч к продукту, например, если тестирование показало, что исправление конкретной уязвимости нарушит что-то в системе. Однако это должно быть исключением, а не правилом.
Лучшей практикой всегда является оперативное устранение уязвимости и автоматическое повторное тестирование, чтобы убедиться, что проблема действительно исчезла. Это занимает больше времени, чем простая блокировка, но при этом гораздо надежнее.
Нюансы применения патчей
Применение патча к постороннему ПО может казаться легче, чем исправление собственного кода, поскольку кто-то другой уже выполнил всю работу и остается только применить патч. Но даже если он доступен, может быть применен и ничего не нарушит, это не всегда означает, что уязвимость устранена.
Особенно в случае с распространенными и серьезными уязвимостями, обычно есть целая последовательность патчей (MOVEit выпустил три только за первый месяц). Кроме неполных исправлений, сделанных наспех, это также может быть результатом повышенного внимания. Поскольку после того, как становится известно об уязвимости продукта, он внезапно начинает активно исследоваться третьими сторонами, в том числе злоумышленниками. Как следствие, часто находятся новые уязвимости или пути атак, что приводит к куче новых патчей.
Каждый патч должен быть протестирован перед применением в продакшне, и сначала нужно выяснить, надо ли его разворачивать. Чтобы понимать, уязвима ли компания к определенному CVE, в идеале нужно иметь способ быстро протестировать всю среду. Это следует делать независимо от проверки и развертывания патчей, не говоря уже об инвентаризации продуктов и зависимостей.
Ответственность за неэффективные исправления
В 2023 году произошло несколько резонансных случаев привлечения CISO (руководителей отделов IT-безопасности) к юридической ответственности за нарушение безопасности. Несмотря на особенности каждого кейса, это служит напоминанием о важности точной информации о безопасности для CISO. Если все указывало на то, что уязвимость была исправлена, почему компанию все равно взломали? Патч был неэффективным? Было ли уведомление о его применении ошибочным? Его применили везде, кроме одного места? Или он все еще стоял в очереди на исправление, когда злоумышленники смогли обойти брандмауэр?
Кибербезопасность может быть сложной, и когда дело доходит до суда, становится еще более понятна значимость качественных процессов и решений.
Важность тестирования и автоматизации
Проверки на уязвимости с помощью эффективного инструмента DAST является неотъемлемой частью любой успешной программы безопасности приложений. Благодаря автоматизированному тестированию, интегрированному в пайплайн разработки, можно отслеживать текущее состояние безопасности, а также проводить проверки перед продакшном. Инструмент также позволяет автоматически тестировать внутренние исправления, чтобы дополнительно удостовериться в их надежности. Таким образом можно обнаруживать эксплойты до того, как они создадут проблемы для организации.
