Как говорят медики, абсолютно здоровых людей практически нет, есть недообследованные. То же можно сказать и об информационных системах: практически у каждой из них есть дыры и прорехи в информационной безопасности, которыми могут воспользоваться злоумышленники. Впрочем, при определенных обстоятельствах уязвимости «выстреливают» и без их вмешательства, и какими в этом случае окажутся последствия, можно только гадать...

Что можно противопоставить уязвимостям, как их выявлять и как от них защищаться? «Мы применяем собственные методики обнаружения и снижения рисков, — рассказывает Дмитрий Костров, директор по проектам департамента ИБ компании «МТС». — Также мы используем опыт наших ИТ-партнеров и активно работаем с производителями программных продуктов — они периодически публикуют списки уязвимостей и рекомендации по их устранению и минимизации ущерба от них».

Сергей Коношенко, директор департамента ИБ компании «Кабест» (входит в группу «Астерос»), в качестве методической основы для комплексного управления уязвимостями рекомендует применять стандарт ISO 27001.

В случае если информационные системы организации подпадают под действие государственных регуляторов, необходимо учитывать и их требования. «Многие регуляторы предписывают вести постоянный мониторинг и конт­роль информационных систем на предмет поиска и устранения уязвимостей в них», — поясняет Коношенко.

Компаниям следует учитывать и требования международных стандартов. Например, тем, кто сталкивается с обработкой банковских карт, необходимо выполнять требования PCI DSS (Payment Card Industry Data Security Standard) и внимательно относиться к предписаниям регулирующего органа в этой сфере — PCI Security Standards Council, напоминает Игорь Антонов, начальник отдела аудита и консалтинга компании «Андэк».

Ранжируем уязвимости

По мнению Кострова, можно использовать различные типы классификации уязвимостей. Например, можно разделять уязвимости, появившиеся при проектировании разрабатываемой системы, при вводе ее в эксплуатацию, а также те, что появились на этапе эксплуатации и при модернизации. «Однако более правильной, на мой взгляд, является классификация в зависимости от критичности уязвимостей», — считает он.

Коношенко полагает, что при классификации уязвимостей стоит отталкиваться от результатов исследования угроз и рисков, представляющих опасность для данной организации в области защиты информации. Антонов рекомендует опираться на классификацию CVSS (Common Vulnerability Scoring System), поскольку именно эта общепризнанная классификация используется в отраслевых стандартах (в частности, в PCI DSS) и поддерживается большинством инструментов, предназначенных для выявления уязвимостей.

Наибольшую вероятность срабатывания имеют уязвимости, связанные с ошибками при установке «заплаток» (патчей), отмечает Костров: «Информация о взломе системы из-за ошибок разработчиков ПО распространяется с огромной скоростью. Сложный процесс установки нового ПО (использование тестовых зон, проверка работоспособности всех приложений после установки нового пакета обновлений и пр.) позволяет злоумышленникам воспользоваться информацией о возможности взлома. «Бюрократизация» ИТ дает им временной лаг».

К наиболее опасным по масштабам возможного ущерба Костров относит уже обнаруженные уязвимости, «заплатки» к которым еще не выпущены. Большую опасность представляют и бреши, связанные с неправильной конфигурацией систем и средств защиты, внедрением программных модулей, целью которых является сбор, анализ информации конфиденциального характера и пересылка этой информации вовне, а также уязвимости, связанные с ошибками в коде при разработке программных продуктов.

«Самые вероятные уязвимости — те, что были обнародованы, — соглашается Николай Федотов, главный аналитик компании InfoWatch. — Во всем мире подавляющее большинство инцидентов ИБ, в том числе заражений вредоносными программами, происходит именно через такие уязвимости. Для их нейтрализации чаще всего либо уже имеется «заплатка», либо известен способ временного «прикрытия». Гораздо более интересны необнародованные (0-day) уязвимости — о них чаще говорят, но в статистике инцидентов ИБ они встречаются гораздо реже. Что касается размера убытков, то он зависит лишь от данных и систем, до которых злоумышленник может добраться, ну и, конечно, от его замысла».

По мнению Антонова, степень опасности уязвимостей сильно зависит от особенностей конкретной системы: «Если для нее критично время простоя, то наиболее опасны уязвимости, связанные с отказом в обслуживании, если же более всего критична конфиденциальность хранимой информации, следует обратить первоочередное внимание на уязвимости, позволяющие получить доступ к данным (например, посредством SQL-инъекции)».

Эльман Бейбутов, руководитель направления безопасности баз данных и корпоративных центров управления событиями ИБ компании «Инфосистемы Джет», наиболее значимыми с точки зрения реализации атак считает приложения на базе веб-технологий: «Использование злоумышленниками уязвимостей веб-приложений часто становится причиной реализации угроз и получения доступа к конфиденциальной информации. Например, более 80% всех атак на веб-сервисы реализуются с помощью всего трех методов: внедрение SQL-кода, подделка межсайтовых запросов и выполнение команд операционной системы. Причем атаки в этих случаях могут быть нацелены не только на конфиденциальность и целостность, но и на доступность информации, что особенно актуально для систем, работающих в режиме 24х7».

Поиск и обнаружение

К поиску и обнаружению уязвимостей следует привлекать и сотрудников, отвечающих за ИБ, и специалистов по ИТ, поскольку те хорошо знают отдельные ИТ-компоненты и подсистемы, развернутые на предприятии. По мнению Кострова, для поиска уязвимостей эффективно привлекать группу быстрого реагирования на инциденты ИБ (Computer Security Incident Responce Team, CSIRT), если таковая есть в данной отрасли, или хотя бы центр управления событиями информационной безопасности предприятия (Security Operations Center, SOC).

Эффективным организационным инструментом для выявления уязвимостей является аудит систем. Стандарт ISO 27001 рекомендует переходить к непрерывному внутреннему аудиту ИБ, а плановые внешние аудиты проводить не реже раза в год, напоминает Коношенко.

Методики поиска уязвимостей, отмечает Костров, сводятся к двум основным направлениям: постоянный мониторинг предоставляемой ИТ-производителями информации о выявленных уязвимостях их продуктов и сканирование систем с использованием специальных инструментов — сканеров уязвимостей. Периодическое сканирование на наличие уязвимостей, сравнивание полученных результатов с предыдущими (лучше в автоматическом режиме) — вот простейший рецепт выявления брешей. Костров советует также отслеживать публикации и дискуссии на различных интернет-форумах специалистов по ИБ.

«Для начала нужно организовать отслеживание обнародованных уязвимостей и выпускаемых «заплаток», — рекомендует Федотов. — Бреши в ИБ надо закрывать как можно быстрее. Персонал следует материально заинтересовать как в количестве, так и в быстроте их закрытия. Кроме того, важно с большим вниманием относиться к обращениям (в том числе извне) по поводу уязвимостей и инцидентов, причинами которых могут стать дыры в системах. Еще одна мера по снижению числа уязвимостей связана с выбором ПО: к процессу необходимо привлекать службу ИБ, причем с правом решающего голоса. Лучше отдавать предпочтение менее «красивому», но более защищенному ПО».

Для поиска уязвимостей в уже установленных системах могут использоваться как автоматизированные проверки (сканирование), так и ручные (тест на проникновение, технический аудит и пр.), делится своими рекомендациями Антонов. Периодичность их проведения, а следовательно, и стоимость напрямую зависят от стоимости информации, содержащейся в информационной системе, и критичности информационной системы для бизнеса.

Что касается веб-приложений, то, по словам Бейбутова, уязвимости в них можно выявлять двумя основными способами: посредством анализа безопасности кода приложений и путем регулярного сканирования уязвимостей. При этом корректировкой кода рекомендуется заниматься в ходе разработки приложения. Устранять выявленные уязвимости в уже используемых приложениях необходимо с максимальной оперативностью. Хорошие результаты по минимизации рисков, связанных с уязвимостями в уже установленных веб-приложениях, обеспечивают межсетевые экраны с функцией virtual patching, позволяющие быстро блокировать атаки и автоматически предотвращать эксплуатацию еще не выявленных уязвимостей.

Регулярно ставим «заплатки»

Своевременная установка «заплаток» и пакетов сервисных обновлений позволяет эффективно бороться с уязвимостями используемого ПО, уверен Антонов, но вместе с тем она никак не влияет на уязвимости, связанные с ошибками в конфигурировании.

«Если ставить все выпущенные заплатки в течение 12 часов после их выхода, вы можете со спокойной совестью принять оставшиеся риски, — считает Федотов. — Правда, кроме брешей, закрытых «заплатками», есть уязвимости, которые появляются в ходе разработки ПО собственными силами или из-за нестандартного конфигурирования тиражируемых систем. Такие уязвимости придется выявлять и устранять самим».

По мнению Кострова, работа по установке обновлений представляет собой палку о двух концах: если обновление вышло, его надо срочно ставить, однако же установка «заплатки» без ее проверки в тестовой зоне может привести к плачевным результатам — есть риск, что эти обновления станут причиной сбоя одного из ключевых бизнес-приложений и, как результат, потери денег.

Не стоит полагать, что установка «заплаток», выпускаемых вендорами, решит все проблемы, связанные с уязвимостями. Впрочем, вообще не нужно питать иллюзий относительно отсутствия брешей в информационной системе — они будут в ней присутствовать, пока их не устранят.