Оценка защищенности информационных систем: обзор подходов

Не проходит дня, чтобы в российских СМИ или Интернете не промелькнула новость о том, что та или иная компания пострадала от рук хакеров — то украдут данные, то выведут сайт из строя, то зашифруют важные файлы. И нет-нет да и задаст нам генеральный директор, с которым мы столкнулись в лифте, вопрос: «А с нами такого не случится?» Если вы думаете, что новости о взломах проходят мимо больших боссов и такой вопрос они вам не зададут, то будьте готовы к другому, интересующему всегда: «А мы защищены?» И если мы, придя на инвестиционный комитет или на собрание совета директоров, отвечаем утвердительно, то следующий вопрос, который мы услышим, будет как из нашего детства: «А чем докажешь?» Парадокс, но руководство компании мало волнует, как мы защищаемся от хакеров. Их волнует доказуемый результат нашей деятельности. Мне хотелось бы в статье рассмотреть шесть различных подходов к оценке защищенности информационных систем, указав их особенности применения в той или иной ситуации.

Но сначала давайте попробуем определиться с тем, что и ради чего мы может оценивать? Несмотря на очевидный и лежащий на поверхности ответ, ситуация не столь проста. С одной стороны, мы делаем это, чтобы улучшить состояние безопасности и найти слабые места прежде, чем это сделают хакеры, способные реализовать недопустимые события, несущие катастрофические последствия для бизнеса (от кражи денег на счете организации и срыва контрактных обязательств до нанесения вреда жизни и здоровью людей или экологической катастрофы). С другой — оценка защищенности требует ресурсов, которые могли бы помочь решать существующие проблемы с ИБ, а не выискивать новые.

Поэтому перед выбором подхода к оценке защищенности необходимо определиться с ее целью. Одно дело — протестировать защищенность нового самописного веб-приложения, которое позволит компании лучше удовлетворять потребности клиентов (а в противном случае потерять их или их лояльность, а следовательно, и снизить средний чек от них), и совсем другое — анализировать периметр компании, чтобы недопустить проникновения в нее «плохих парней», способных украсть ценную информацию, например, персональные данные, что может повлечь получение штрафа в размере 1% или 4% от оборота компании, ставшей причиной утечки персданных. С одной стороны, мы можем захотеть найти и устранить все уязвимости в приложениях (сразу скажу, это тупиковая затея), а с другой — выявить все сценарии, позволяющие злоумышленникам реализовать недопустимые события. Наконец, вы можете захотеть продемонстрировать свой уровень защищенности и отношение к безопасности партнерам и клиентам или вы обязаны выполнить требования законодательства (например, ФСТЭК или Банка России).

Сканирование уязвимостей

Это, пожалуй, самый популярный метод оценки защищенности, который используется для повышения своей ситуационной осведомленности в отношении имеющихся уязвимостей приложений, системного ПО, сетевой инфраструктуры и т. п. Кроме того, подобная защитная мера является обязательной согласно требованиям ФСТЭК и ЦБ для государственных и муниципальных организаций, субъектов КИИ, финансовых организаций, владельцев АСУ ТП, операторов персональных данных и т. п.

Будучи полностью автоматизированным, этот метод, к сожалению, имеет и существенные недостатки. Во-первых, он позволяет найти только известные уязвимости, заложенные производителем в свой сканер уязвимостей (а потому так важно регулярно обновлять его базу знаний). Во-вторых, работа сканера может повлечь за собой нарушение работоспособности отдельных компонентов инфраструктуры, не очень хорошо спроектированных или не способных выдержать массовую проверку уязвимостей и выходящих из строя (такое бывает с некоторыми элементами АСУ ТП). В-третьих, обычно сканеры безопасности выявляют атомарные, единичные уязвимости, не учитывая их взаимосвязи с другими, и цепочки уязвимостей, которые применяются хакерами в реальной жизни. Наконец, этот метод находит известные ему дыры в инфраструктуре, но не подтверждает возможность их использования, в отличие от пентестов или решений класса BAS.

Запускаться такие решения могут как самой компанией, так и внешними подрядчиками. В ряде случаев последнее требуется законодательством, например, стандартом PCI DSS или положениями Банка России.

Динамический анализ приложений (DAST)

У средств динамического анализа приложений (dynamic application security testing, DAST) схожее со сканерами безопасности целеполагание, особенности и ограничения, однако в отличие от них решения класса DAST фокусируются не на инфраструктуре, а на отдельных приложениях или пробелах в защитных механизмах, реализованных межсетевыми экранами для веб-приложений (Web Application Firewall, WAF) или решениями класса RASP (Runtime Application Self-Protection). К описанным для сканеров уязвимостей особенностям можно добавить еще одну — требование квалифицированного персонала, ориентированного на защиту приложений (application security). В противоположность сканерам безопасности, способным работать в полностью автоматическом режиме, решения класса DAST предусматривают вовлечение персонала в его работу.

Эмуляция атак (BAS)

Что может произойти, если кто-то воспользуется найденными уязвимостями? Именно на этот вопрос отвечают решения по симуляции атак (Breach & Attack Simulation, BAS), которые эмулируют работу реальных хакеров, осуществляющих набор взаимоувязанных между собой действий для достижения своей цели. С помощью BAS, которые в последнее время иногда подменяют собой сканеры уязвимостей или простые тесты на проникновение, можно определять, насколько способны имеющиеся средства защиты выявлять и блокировать методы злоумышленников. При условии постоянно пополнения и обновления базы хакерских симуляций, данный класс решений можно использовать в непрерывном режиме, позволяющем также непрерывно мониторить эффективность системы ИБ предприятия без привлечения внешних компаний (но можно и с их помощью).

Тесты на проникновение

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

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

Команды Red Team

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

Bug Bounty

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

Решением может стать платформа/провайдер Bug Bounty, который объединяет усилия тех, кто хочет продать свои услуги в области оценки защищенности, и тех, кто хочет их купить. Это некая биржа, где компании размещают свои приложения или информационные системы, которые надо проверить на прочность, а легальные хакеры, чье число практически ничем не ограничено, тестируют их, получая деньги в зависимости от серьезности найденных слабых мест. Например, группа компаний VK за три месяца использования отечественной платформы Standoff 365 Bug Bounty, на которые «выставила» 19 своих сервисов («ВКонтакте», «Одноклассники», Skillbox и т. п.), выплатила более 3 млн рублей пяти с лишним десяткам исследователей. Размер выплат составил от 3 тысяч до 750 тысяч рублей в зависимости от критичности уязвимости.

Однако у подхода Bug Bounty есть серьезный недостаток. И дело не в деньгах, которые мы платим тем, кто найдет уязвимости в наших приложениях и инфраструктуре (мы бы их все равно заплатили внешним пентестерам или своим же специалистам). Чтобы публично воспользоваться услугами внешних специалистов надо обладать определенной смелостью признать, что ваша ИБ может содержать пробелы, а это означает очень высокий уровень зрелости. Наверное, поэтому подобным методом оценки защищенности пока пользуется в России не так много компаний — помимо уже упомянутой VK, это Rambler, «Азбука вкуса», «Авито» и другие.

Какой подход выбрать?

Я не уверен, что существует алгоритм выбора однозначного и единственно верного подхода к оценке защищенности, поскольку на этот выбор будет влиять множество факторов:

• Цель оценки, которую мы уже обсудили выше. Одно дело искать уязвимости или проверять способность команды ИБ выявлять действия хакеров, и совсем другое — оценивать сценарии возможного проникновения и возможность хакеров реализовывать недопустимые события.

• Соответствие требованиям регуляторов, которые могут не только определять сам способ оценки, но и предъявлять к нему особые требования. Например, Банк России обязывает, чтобы оценка защищенности финансовых приложений проводилась только внешними организациями, а ФСТЭК — чтобы такие организации обладали лицензиями на деятельность по технической защите конфиденциальной информации.

• Толерантность к сбоям. Некоторые тесты, например, в производственной сети в отношении компонентов АСУ ТП, могут привести к сбою и нарушению технологических, производственных или бизнес-процессов. Насколько для нас это критично?

• Сроки, в течение которых необходимо провести оценку.

• Стоимость, которая может быть как незначительной (например, в случае использования бесплатных, open source сканеров уязвимостей) или достаточно высокой (например, в случае приглашения Red Team, которая будет скупать уязвимости или писать вредоносное ПО специально под заказчика).

Подводя итоги

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

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

• Оценка защищенности не должна быть проходным и разовым мероприятием — в организации должна существовать соответствующая стратегия, описывающая разные подходы к оценке защищенности и ситуации, когда они должны применяться в организации (регулярно, перед запуском бизнес-приложения в промышленную эксплуатацию, после «удачного» взлома и т. п.).

• Оценка не должна быть повсеместной (это дорого и избыточно) — надо фокусироваться на тех системах и приложениях, взлом которых повлечет за собой катастрофические для компании последствия. Это позволит сфокусироваться на главном.

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