- PVSM.RU - https://www.pvsm.ru -
Классический подход российского бизнеса сегодня — это установка файрволла, затем после первых попыток направленных атак — системы защиты от вторжений. И дальше спать спокойно. На практике это даёт хороший уровень защиты только против скрипткидди, при любой более-менее серьёзной угрозе (например, от конкурентов или атаке от недоброжелателей, либо направленной атаке от иностранной группы промшипонажа) нужно что-то дополнительное, помимо классических средств.
Я уже писал про профиль типовой направленной атаки [1] на российское гражданское предприятие. Теперь расскажу о том, как меняется стратегия защиты в целом в нашей стране в последние годы, в частности, в связи со смещением векторов атак на 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.
Примеры таких аудитов есть вот здесь [2] у нас. Но перейдём к проблемам и игре «найди знакомого».
Как правило, большая часть проблем для ИБ крупного бизнеса больше не технические, а «бытовые», на уровне организации:
Скриншот Gigamon GigaVUE-HC2
• системы класса 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).
Аттестованная сеть
В одном из крупных государственных ведомств было решено провести оценку защищенности аттестованного сегмента сети, предназначенного для обработки конфиденциальной информации. В частности, пользователям этого сегмента категорически запрещался доступ в Интернет. Нашлось вот что:
В целом, вы наверняка видели такие изолированные сети в армии, когда бойцы штаба сидят на сайтах знакомств. Здесь ситуация была несколько серьёзнее.
Сетевой периметр коммерческого банка
Нужно было оценить защищённость периметра. Обычно такую работу проводят в рамках тестирования на проникновение, но в данном случае заказчику было интереснее посмотреть, что он сможет сделать самостоятельно изнутри. Для этого серверы и телекоммуникационное оборудования внешних демилитаризованных зон просканировали системой MaxPatrol в режимах Audit и Compliance, после чего проанализировали отчеты. Первое, что бросилось в глаза — определенное количество уязвимостей, связанных, как обычно, с устаревшим софтом или отсутствием обновлений безопасности (старые версии ОС, отсутствие патчей на большинстве серверов и т.п.), но это не самое страшное: к большинству таких уязвимостей нет доступных хакерам эксплойтов. Но встретились и сюрпризы. На паре периметровых маршрутизаторах отсутствовали ACL (как выяснилось, их временно отключили при диагностике проблем связи между подразделениями, и забыли включить), так что снаружи было доступно гораздо больше узлов, чем представляли администраторы. В большой Интернет мордой наружу смотрела боевая СУБД. Вместо SSH использовался TELNET на ряде узлов. На ряде боевых серверов не поменяли настройки RDP после конфигурирования (RDP-трафик закрывался типовым ключом). Нашлись герои, не поменявшие дефольные пароли с момента начала работы в компании. К счастью, снаружи это не успели заметить, поэтому всё удалось оперативно закрыть почти без жертв в составе ИТ-отдела.
P.S. Если у вас вопрос не для комментариев, моя почта — PLutsik@croc.ru.
Автор: plutsik
Источник [3]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/rossiya/86711
Ссылки в тексте:
[1] типовой направленной атаки: http://habrahabr.ru/company/croc/blog/236411/
[2] вот здесь: http://www.croc.ru/insafety/
[3] Источник: http://habrahabr.ru/post/253835/
Нажмите здесь для печати.