HBGary. RSA. Comodo. Кто следующий? Когда продукты безопасности становятся мишенью, тебе нужно провести серьезное исследование, прежде чем внедрить их в свою сеть. Что происходит, когда те самые продукты, которые предназначены для обеспечения безопасности, содержат в себе уязвимости? Насколько мы поняли по недавним атакам на HBGary, RSA и Comodo, даже такие продукты могут стать жертвой уязвимостей, таких как переполнение буфера и обход каталога.
Легко предположить, что средства безопасности сами по своей сути являются безопасными. Но на самом деле, продукты безопасности не отличаются от приложений для наших настольных компьютеров, страдающих от уязвимостей нулевого дня - все они написаны программистами, которые тоже люди и иногда допускают ошибки, приводящие к уязвимостям.
Суровая реальность заключается в том, что продуктам безопасности необходимо пройти такую же проверку, как и любому другому программному обеспечению или устройству, предполагаемому к внедрению.
Предприятия не должны слепо внедрять обновления в безопасности. Подобно тому, как они делают это с продуктами, не связанными с обеспечением безопасности, ИТ-отделы должны оценивать риск, связанный с новым инструментом безопасности, определять испытывался ли код безопасности в ходе его разработки, и проводить проверку на проникновение в тестовом окружении.
Первым шагом является оценка рисков, позволяющая убедиться, что размещение устройства или установка ПО не окажет негативного эффекта на безопасность. Важные вопросы, на которые нужно ответить: Что произойдет, если атакующий воспользуется уязвимостью в устанавливаемом продукте? Что атакующий сможет сломать или украсть, получив доступ к системе?
В конце 2006 червь "Big Yellow" дал несколько пугающие ответы на эти вопросы. Атакующие могли получить полный удаленный доступ с правами администратора к системе под управлением Windows с уязвимой версией антивируса Symantec. Затем червь подключал систему к ботнету, позволяя злоумышленникам удаленно контролировать зараженный компьютер.
Будь проведена оценка рисков, организации могли бы больше знать о том, как лучше заблокировать продукт от воздействия извне. Порты, использовавшиеся для удаленного контроля системы, могли быть привязаны исключительно с серверам управления, что значительно снизило бы эффект от вируса.
Многие предприятия просто забывают поинтересоваться у своих поставщиков средств защиты, следуют ли они практикам безопасного кодирования. Есть ли у них цикл разработки ПО (software development lifecycle, SDLC), который включает тестирование безопасности системы? Скорее всего представитель по телефону скажет, что есть, так что давите на них и просите больше информации. Проводят ли они проверки исходного кода? Что насчет анализа 3-ей стороной и тестирования на проникновение?
Конечно, в этом случае вам придется поверить поставщику на слово. Но все же, обсуждение и изучение процесса разработки (учитывая, что вам его откроют) более обнадеживает. И в случае возникновения проблем эта тема может быть поднята ещё раз – как поставщик пропустил уязвимость и что будет сделано для улучшения ситуации?
Испытание на проникновение ещё на этапе оценки продукта, или же в небольшой тестовой инсталляции, - также может выявить проблемы безопасности, которые могли быть пропущены на этапе оценки рисков. Установка продукта может потребовать изменений в управлении правами доступа, которые в итоге приведут к ослаблению текущего окружения. Или же продукт может содержать уязвимости, которые могут быть найдены с помощью сканера, фаззинга или других проверок.
Сейчас многие решения по безопасности предоставляют веб-интерфейс для управления, который также может стать причиной бреши. Компрометация интерфейса управления может подвергнуть атаке всю систему. Интерфейс может быть подвержен межсайтовому скриптингу (XSS), подделке запросов (CSRF), SQL-инъекциям, или неавторизированному удаленному запуску команд – все это уязвимости, которые вы не будете рады видеть в веб-интерфесе продукта по обеспечению безопасности (как и в любом другом вашем веб-приложении).
Иногда причиной уязвимости является внутренний веб-сервер, идущий в комплекте с продуктом обеспечения безопасности. Два примера приходят в голову: В одном случае, поставщик использовал устаревшую версию Tomcat, компрометация которой привела к публикации нескольких сотен тысяч записей пациентов. Будучи в целом интересной на будущее, ситуация была весьма неприятна для клиента. И её можно было избежать, если бы продукт был проверен перед использованием.
Второй случай – обнаружение похожей уязвимости в сервере JBOSS. Тестирование на проникновение показало, что сервер содержит ошибку, дающую полный удаленный доступ к Windows машине с запущенной уязвимой версией JBOSS. В этом случае клиент перед покупкой передал поставщику информацию о том, как проблему можно исправить.
Никто не ожидает, что продукт, обеспечивающий безопасность, будет содержать уязвимости, но такое случается. Оценка рисков, правильно заданные вопросы и тестирование на проникновение могут помочь уменьшить, если не предотвратить, огромный урон от уязвимости. Запомните, вы платите деньги за продукт, который должен помочь обезопасить ваше окружение, а не наоборот. Примите соответствующие меры предосторожности и убедитесь, что он справляется со своей задачей.
