Классический подход российского бизнеса сегодня — это установка файрволла, затем после первых попыток направленных атак — системы защиты от вторжений. И дальше спать спокойно. На практике это даёт хороший уровень защиты только против скрипткидди, при любой более-менее серьёзной угрозе (например, от конкурентов или атаке от недоброжелателей, либо направленной атаке от иностранной группы промшпионажа) нужно что-то дополнительное, помимо классических средств.
Я уже писал про профиль типовой направленной атаки на российское гражданское предприятие. Теперь расскажу о том, как меняется стратегия защиты в целом в нашей стране в последние годы, в частности, в связи со смещением векторов атак на 0-day и связанные с этим внедрения статических анализаторов кода прямо в IDE.
Плюс пара примеров на сладкое — вы узнаете, что может твориться в полностью изолированной от Интернета сети и на периметре банка.
Развитие
За последние два года на рынке крупных enterprise-решений началось достаточно сильное движение. Сначала была достаточно хорошая активность по защите от DDoS — как раз тогда атаки подешевели. Пока средний бизнес знакомился с IT по вопросам «почему у нас лежит сайт и не работают кассы в магазинах», крупный перестраивал оборону в сторону защиты от нестандартных атак. Напомню, большая часть направленных угроз реализуется через связку 0-day и социнжиниринга. Поэтому логичным шагом стало внедрение анализаторов кода ещё на стадии разработки ПО для компании.
Проверка до коммита
Одной из самых эффективных мер стала организация процесса так, что ни один коммит не проходит без статического анализа кода, и не один релиз не выходит на боевые сервера, пока не будет пройден динамический анализ. Причём эта динамика делается в «песочницах» виртуальных машин, идеально соответствующих различным серверам, машинам пользователей с разными профилями и так далее. То есть код «раскачивается» в реальном окружении со всей цепочкой взаимодействий.
Самый хардор, конечно, интеграция анализаторов с IDE. Написал функцию — и ни шагу дальше, пока не уберёшь все предупреждения анализатора. При этом для полного счастья безопасник видит логи того, что происходило, и ему дублируется каждое предупреждение. Как говорят коллеги, на Западе это оказалось очень действенным инструментом, чтобы код сразу писался нормально.
Пример решения — HP Fortify Software Security center.
Сторонний код
При имплементации стороннего кода ИБ крупного бизнеса часто настаивает на статическом анализе кода. Когда речь про опенсорс — ситуация очень простая и понятная, просто прогон через анализатор и «подавление» от сотни до тысячи предупреждений. Когда код коммерческий, и заказчик не готов предоставить исходники своей подсистемы, наступает более интересная итерация.
Если исходники не дают, но читать в офисе разработчика их можно, на место выезжает представители ИТ-отдела и ИБ-отдела, где они вместе запускают статический анализатор. Если же и так нельзя, то от кода либо отказываются, либо, реже, назначают усиленную «раскачку» в динамике.
Кроме автоматических методов часто приглашается пентестер: это либо сотрудник ИБ/ИТ-отдела с профильным образованием, либо, чаще — сторонний специалист у компании-партнёра.
Старый код
При обнаружении проблем с legacy-кодом, да ещё и скомпилированным для подсистемы аж в 1996 году (был такой реальный случай), естественно, переписать его бывает достаточно сложно. В этом случае на файрволле прописывается правило, описывающее тип эксплуатации уязвимости (фактически — сигнатуры пакетов эксплоита), либо же на одной из промежуточных систем (про них ниже) прописывается отсечка всего того, что не является нормальным пакетом для конечной системы. Своего рода DPI, но для закрытия уязвимости, обвязка уровнем выше.
Внутренние обходы
Совсем крупный бизнес имеет ещё одну характерную проблему — количество изменений в живой инфраструктуре такое, что даже крупному отделу не под силу уследить за всеми движениями в сети. Поэтому те же банки, розница и страховые используют специализированные средства вроде HP Webinspect или MaxPatrol от наших соотечественников Positive Technologies. Эти системы позволяют проверять самые разные компоненты инфраструктуры, включая то, что накатывается на микроконтроллеры слаботочных систем.
Очень распространились системы профилирования трафика. Строится типичный профиль обращений к каждому узлу на базе данных с коммутаторов и маршрутизаторов, затем выстраивается корреляция пользователей и систем, к которым они обращаются. Получается матрица взаимодействия, где видно какая служба на какого пользователя генерит трафик. Небольшие отклонения попадают в виде уведомления безопасникам, серьёзные — сразу блокируются. При попадании в сеть зловреда видны характерные множественные следы, всё критичное «замораживается» и начинается разбор логов.
При этом настройка идёт в виде «приложение-пользователь-сервер» в виде GUI прямо самим безопасником без участия IT-отдела. Как это ни странно, нравятся такие системы в том числе и админам — у меня был пример, когда приложение Вконтакте начало генерировать 90% трафика в полосе, и админ это очень легко заметил.
Пример системы поиска сетевых аномалий — StealthWatch.
При комплексном анализе защищённости обычно делается три процедуры:
- Анализ на уровне «чёрного ящика» без привилегий пользователей, то есть просто заход снаружи. Это свободные порты, анализ всего что смотрит наружу из служб, попытки использовать собранные уязвимости и пройти DMZ. Стандартный пентест, как правило.
- Аудит с учётки админа или привилегированного пользователя. Предполагается, что злоумышленник как-то «намутил» доступы (например, средствами социнжинринга), и атака развивается с этого момента. В рамках этого же аудита делается обход по всему изнутри сети. Проверяются настройки, конфигурационные файлы, корректность обновления систем, контрольные суммы каждого пакета и файла, оцениваются версии ПО и их известные уязвимости (например, чтобы винда на пользовательских машинах была правильно обновлена из сертифицированного источника). Пример пакета — RedCheck.
- Третий режим — соответствие требованиям определённого стандарта. Это расширенный обход сети в соответствии с шаблоном, например, модели обработки персональных данных по классам. У наших вендоров есть преднастроенные шаблоны под Россию — у иностранных, как правило, в лучшем случае дальше PCI DSS дело уходит редко.
Примеры таких аудитов есть вот здесь у нас. Но перейдём к проблемам и игре «найди знакомого».
Типичные проблемы
Как правило, большая часть проблем для ИБ крупного бизнеса больше не технические, а «бытовые», на уровне организации:
- Устаревшее оборудование и ПО. Часто в крупном бизнесе нужны сертифицированные решения, а они стремительно отстают от новинок. Многие просто не могут позволить себе поставить новое ПО или новую крутую железку, а ставят нечто с заведомо известными дырами или отсутствующим нужной функциональностью и забивают костыли, чтобы как-то решить вопрос. Нередка ситуация, когда банк ставит решение, которое только проходит сертификацию, и, по факту, месяц-два работает на свой страх и риск без полного соответствия требованиям регуляторов. Альтернатива — иметь дыру размером с лошадь в ИБ, но при этом пытаться закрыть её бумажкой, что всё соответствует стандарту и требованиям.
- Следствие — один ящик замыкает на себя всю сеть. Проблема совершенно безумная со стороны, но часто вся внутренняя сеть небольшого банка может упираться в одно устройство, которое лет на 5 отстало от флагмана, но зато работает под сертификатом. При выходе из строя этой железки падает всё до решения вопроса. Естественно, более современные решения умеют байпассы на подсистемы, параллельность, резервирование — но реальность немного отличается от идеальной схемы архитектуры сети.
- Или другой вариант. Есть, в целом, всё что нужно. Но DLP и антибот нельзя активировать, часто бывают проблемы с обновлением базы сигнатур антибота (запрещено обновлять), проблемы с драйверами (была ситуация — поставили сертифицированное оборудование, а оно не сошлось с RAID-массивом — к счастью, через несколько дней вышла новая сертифицированная версия).
- «Хардкод». Разным устройствам нужен разный тип трафика, и при внедрении новых железных решений часто делается болезненная и долгая перекоммутация. Тесты одного защитного средства могут идти недели просто из-за этого. На практике же достаточно поставить современное решение, которое позволит работать на уровне канала. Что позволяет, например, ставить IPS под этот канал до файрволла или после (что очень сказывается на производительности).
Gigamon GigaVUE-HC2
- Разное железо под защиту. Это не проблема на самом деле, просто тенденция такова, что большая часть вендоров пришла к тому, что все решения по обеспечению периметра укладываются в одно устройство UTM. Дело в том, что каждое решение представляет собой ПАК в виде «чёрного ящика». Современный вариант — одинаковая x86-архитектура, и возможность обновлять функциональность не выбрасывая железо раз в два года. Например, есть устройство, где внутри уже файрволл, потоковый антивирус, антибот-система и так далее. При этом оно сертифицировано целиком и в железной части состоит из x86-машины, разбитой на виртуальные программные блейды на уровне ПО. При необходимости туда доставляется софт, доплачивается за лицензию — и оно продолжает молотить по-новому.
- Сложная интеграция зоопарка систем. Опять же, следствие предыдущего пункта. Много разного плохо состыкованного железа — это проблема проброски данных из одной части ИБ-системы в другую. К примеру, давно уже стало нормой, что IPS чётко связана с антиботнет-системой. Уверен, что далеко не во всех банках это так — потому что, опять же, либо сложно делать интеграционную механику, либо нет единой железки с блейдами как я описал выше. Кстати, последнее поколение ещё и умеет «расщеплять мозг», чтобы сканировать само себя на предмет соответствия конфигурации тому же PCI DSS. Ранее это делалось отдельными внешними системами.
- Анализ инфраструктуры на соответствие стандартам не учитывает русские реалии. Упрощая, у вас будет идеальные наборы «утилит-обходчиков» для проверки соответствия PCI DSS. Но только малая часть решений умеет № 152-ФЗ «О персональных данных». К примеру, за это (ну и не только) отечественный MaxPatrol «гоняется» в Лукойле, Норникеле, Вымпелкоме, Газпроме и так далее.
- Внезапные изменения. Это вообще за гранью добра и зла, но так случается. Частый случай — IT-специалист что-то делает и устанавливает новое правило на уровне инфраструктуры, которое через месяц-другой внезапно обнаруживает безопасник (часто — не сам, а с подсказки, программы поиска багов, пентеста или реальной атаки) и впадает в панику. Затем устраивает всем разнос. Например, на одной из наших интеграций была ситуация, когда нам надо было ускорить на неделю внедрение тяжелого сервера-молотилки. При внедрении, не зная всех деталей ИТ-кухни заказчика, мы разрешили гонять определенный тип трафика прямо до него. А потом отчитались об успехе. В ответ на это безопасники инициировали служебное расследование, в результате которого нам самим чуть не досталось по шапке. Так вот, правильно ставить систему, когда IT-спец внедряет что-то на сети, но правило не проаппрувится, пока его не подтвердит безопасник. Было бы так, наши коллеги получили бы премии, потому что проблема была не в разрешении на трафик, а том, что это прошло мимо ИБ-отдела.
- Недоверенные источники. Во многих корпоративных средах на уровне приклада часто бывают проблемы с тем, что конечные пользовательские устройства — это цирк пополам со зверинцем вирусов. Например, одно дело, когда страховой агент едет на место, фотографирует вмятину на машине на свою камеру, потом приезжает домой, фотошопит на более сильные повреждения и отправляет. Другое дело, когда фотография приходит из корпоративного приложения (под сертификатом) по защищённому каналу и с нерутированного устройства. Можно доверять размеру вмятины. Более серьёзный случай — резкое снижение доверия к VPN в одной из компаний, где в итоге из-за вирусов у удалённых сотрудников к злоумышленникам попадали все доступы. Решили вопрос виртуальным JAVA апплетом в браузере, который обеспечивает защищенную доверенную среду при VPN доступе.
Защитные средства, примеры
• системы класса NG FW (Check Point, Stonesoft, HP Tipping Point);
• система обнаружения потенциально опасных файлов (песочница) (Check Point, McAfee, FireEye);
• специализированные средства защиты web-приложений (WAF) (Imperva SecureSphere WAF, Radware AppWall, Fortinet Fortiweb);
• Интеллектуальный центр (ByPass узел) для подключения средств ИБ (Gigamon GigaVUE-HC2).
• системы обнаружения аномалий в сетевом трафике (StealthWatch, RSA NetWitness, Solera Networks);
• Анализ защищенности и соответствия (MaxPatrol, HP Webinspect)
• аудит безопасности кода (HP Fortify, Digital Security ERPScan CheckCode, IBM AppScan Source);
• система защиты от DDoS (железо — Radware DefensePRO, ARBOR PRAVAIL, Check Point DDoS Protector; сервис — Kaspersky DDoS Prevention, QRATOR HLL).
Примеры на десерт
Аттестованная сеть
В одном из крупных государственных ведомств было решено провести оценку защищенности аттестованного сегмента сети, предназначенного для обработки конфиденциальной информации. В частности, пользователям этого сегмента категорически запрещался доступ в Интернет. Нашлось вот что:
- Следы подключения USB-модемов.
- Один из ноутбуков был подключен одновременно ко внешней сети и публичной.
- Нашлось довольно много мессенджеров и игр.
В целом, вы наверняка видели такие изолированные сети в армии, когда бойцы штаба сидят на сайтах знакомств. Здесь ситуация была несколько серьёзнее.
Сетевой периметр коммерческого банка
Нужно было оценить защищённость периметра. Обычно такую работу проводят в рамках тестирования на проникновение, но в данном случае заказчику было интереснее посмотреть, что он сможет сделать самостоятельно изнутри. Для этого серверы и телекоммуникационное оборудования внешних демилитаризованных зон просканировали системой MaxPatrol в режимах Audit и Compliance, после чего проанализировали отчеты. Первое, что бросилось в глаза — определенное количество уязвимостей, связанных, как обычно, с устаревшим софтом или отсутствием обновлений безопасности (старые версии ОС, отсутствие патчей на большинстве серверов и т.п.), но это не самое страшное: к большинству таких уязвимостей нет доступных хакерам эксплойтов. Но встретились и сюрпризы. На паре периметровых маршрутизаторах отсутствовали ACL (как выяснилось, их временно отключили при диагностике проблем связи между подразделениями, и забыли включить), так что снаружи было доступно гораздо больше узлов, чем представляли администраторы. В большой Интернет мордой наружу смотрела боевая СУБД. Вместо SSH использовался TELNET на ряде узлов. На ряде боевых серверов не поменяли настройки RDP после конфигурирования (RDP-трафик закрывался типовым ключом). Нашлись герои, не поменявшие дефольные пароли с момента начала работы в компании. К счастью, снаружи это не успели заметить, поэтому всё удалось оперативно закрыть почти без жертв в составе ИТ-отдела.
P.S. Если у вас вопрос не для комментариев, моя почта — PLutsik@croc.ru.
