воскресенье, 26 марта 2017 г.

ИБ. Некоторые моменты создания ведомственных и корпоративных центров ГосСОПКА

Недавно прошел двухсерийный вебинар Positive Technologies посвященный их опыту создания центров ГосСОПКА. С видео и основными тезисами из вебинара можно ознакомится по ссылке

Тут же хотелось бы обсудить некоторые интересные цитаты и идеи.
1. На вебинаре ФСТЭК и ФСБ показаны как противопоставляющие и дополняющие друг друга.
·         ФСТЭК дает базовые требования. ФСБ дает дополнительные требования”
·         ФСТЭК требует защиты критических систем – ГИС. ФСБ требует защищенности объекта в целом
·         ФСТЭК наказывает за формальное несоблюдение требований. ФСБ наказывает за пропущенные атаки и инциденты
Может быть это такое желание у PT, но на практике мы не сталкиваемся с подобным. За инциденты никто не наказывается. Проверок ИБ со стороны ФСТЭК и ФСБ фактически не проводится, а если проводится, то и тот и другой регулятор выделяют в нарушения - только обязательные требования.
И при правильном подходе, требования ФСТЭК к ГИС – это не базовые меры. Если мы правильно подошли к моделированию угроз, выбору мер защиты, выбору мер усиления – то в итоге получили все необходимые меры защиты.  
Те требования, которые приходят с ГосСОПКА скорее связаны с обменом информацией в области ИБ и исходят из аксиомы, что сообщество или группа служб ИБ смогут более эффективно обеспечивать защиту чем одна отдельная служба ИБ.  

2. В качестве одной из обязательных функций центра ГосСОПКА называется анализ угроз. Давайте посмотрим, что PT подразумевает под этим:
·         Что может делать нарушитель
·         Какие следы он может оставить
·         Как обнаружить эти следы
·         Что делать если обнаружили
·         Чем можем пожертвовать
·         Кто может помочь
Согласитесь, что довольно странный анализ угроз. Наверное, ЭТО надо было назвать «планированием реагирования на атаки» или чем-то другим?

3. “Корпоративный или ведомственный центр ГосСОПКА работает не на ФСБ России, он работает на свое ведомство или корпорацию и решает их задачи”
Этот ответ на вопросы слушателей неоднократно повторялся на вебинаре. Все так. Только напомню, что основная идея ГосСОПКА – обмен информацией и коллективное более эффективное противодействие атакам.

4. Предлагается персонал центра ГосСОПКА разделить на 3 линии.
·         Первая линия –взаимодействие с пользователями, прием заявок, регистрация инцидентов, типовые действия по инструкции
·         Вторая линия – квалифицированные, но типовые действия по реагированию
·         Третья линия – руководство и эксперты
Откуда ведомству или корпорации взять персонал. Предлагается не набирать 1-2 линию в Москве - большие запросы по зарплате, ведомства ограничены в окладах, толковых спецов быстро перекупят конкуренты.
PT говорят, что центр ГосСОПКА территориально не привязан к объектам защиты.  Предлагают набирать 1-2 линию в регионах, в которых есть хорошие ВУЗы, выпускающие ИБ специалистов, такие как Екатеринбург, Челябинск и другие.
Так что, центры ГосСОПКА - добро пожаловать в Краснодар. Тут несколько ВУЗов выпускают ИБшников.  
Экспертов предлагают на первое время брать на аутсорсинг во внешней организации, например, в том же PT. А своего достаточно иметь только Руководителя центра ГосСОПКА.

5. На этом вебинаре PT публично упомянули новое решение – PT Ведомственный (Корпоративный) Центр. В результате создается впечатление что именно по материалам PT были разработаны недавние требования ФСТЭК к оборудованию SOC.



вторник, 14 марта 2017 г.

ИБ. Ещё один WAF

Полторы недели назад Код Безопасности неожиданно объявил о выпуске межсетевого экрана для web приложений (web application firewall) «Континент WAF». А на прошлой неделе на вебинаре КБ раскрыли подробности нового продукта и сказали, что он уже доступен для продажи и тестирования.

Как так? Без предварительных анонсов и спойлеров? Без упоминания в прошлогодних планах? Просто взяли и выпустили технологически сложный продукт. Ответ вы узнаете чуть позже, а пока кратко пройдемся по истории.

С 2003 года, а может быть и ранее в РФ наиболее популярным вариантом защиты web приложений был опенсорсный modsecurity. Несмотря на сложности в настройке, он был и, пожалуй, остается одним из наиболее эффективных решений. Но корпоративным заказчикам было неудобно с ним работать. В связи с этим стало появляться много коммерческих продуктов которые взяли за основу modsecurity, сигнатуры или работали по схожему принципу.

Примерно в 2008 году на рынке корпоративного ИБ РФ начало продвигаться западное решение в области специализированных межсетевых экранов для защиты web приложений - imperva securesphere web application firewall.  Позже продвигались и другие западные решения Fortigate Web, Barracuda WAF, Cisco ACE, но это были скорее разовые проекты.

Временем серьезной популярности WAF в РФ можно считать с 2011 года, когда Imperva получили сертификат ФСТЭК на свое решение и его можно было внедрять ещё и в гос. органах. С этого момента популярность WAF только увеличивалась, что не удивительно, ведь область применения – все компании имеющие важные web приложения (их количество стремится к 100% со временем) сочетались с гибкой ценовой политикой (по стоимости доступны были не только крупным, но и средним компаниям. по стоимости сравнимы с IPS). Но кризис 2014 серьезно подкосил imperva в РФ. Цены выросли в несколько раз (что существенно сокращало область применения до крупных корпораций), потом задержки с поставками, потом санкции и т.п.

Параллельно с этим, примерно в 2013 -2014 году с резкой критикой существующих WAF решений выступили многие российские исследователи / пентестеры. Закончилось это появлением собственных решений сначала wallarm, потом Positive Technologies Application Firewall и Solidlab WAF. В отличие от западных вендоров, которые черпали идеи в открытых сообществах типа OWASP, наши разработчики опирались на собственный опыт пентестов, bugbounty и соревнований CTF. Это позволило им создать WAF нового поколения.

 Wallarm изначально был больше применим для малого бизнеса и западных компаний (ведь безопасники крупных российских компаний не спешили доверять облакам). PT AF наоборот позиционировался для крупных компаний и гос. Solidwall же не был особо известен на корпоративном рынке ИБ, по крайне мере я не слышал о нем до сего дня. А чтобы помочь донести WAF до средних компаний, Infowatch включили Wallarm в состав своей группы решений под названием Attack Killer.

В конце 2016 года событий, связанных с WAF в РФ стало ещё больше: появились новые требования ФСТЭК к межсетевым экранам, в том числе WAF были вынесены в отдельный тип, появились обязательные требования к наличию WAF у лицензиатов ФСТЭК, в конце 2016 года Pentest.IT выпустили Nemesida WAF (бюджетный облачный WAF с планами по сертификации в ФСТЭК).



И вот на прошлой неделе Континент WAF. Расскажу самое интересное с вебинара:
·         Планируют получить сертификат ФСТЭК по 4 классу по новым требованиям уже этим летом
·         Запускаться будет на стандартных платформах Континент 400, 1000, 3000 (система управления на континент 100)
·         Производительность гарантируют в 1000 RPS для Континент 1000
·         В функциях кроме стандартных сигнатур для WEB и фильтрации HTTP есть ещё и автоматическое профилирование приложения, и анализ профилирование поведения пользователя – а это уже позиционирование рядом с Imperva
·         Решение сделали не самостоятельно, а в партнерстве с Solidlab (думаю партнерство аналогичное тому как КБ раньше работали с ESET и Agnitum)
(UPDATE)А Solidlab разрабатывают решение с 2014 года. А до этого команда разработчиков из Solidlab несколько лет участвовала в CTF и наверняка ещё тогда начали готовить какие-то утилиты для защиты Web приложений. Так что можно считать, что у Континент WAF долгая история.
Да и в Коде безопасности по всей видимости уже долго шла подготовка к выпуску продукта, готовили прайс-листы, проводили интеграцию, готовили маркетинговые материалы. 




Что нас ждет дальше? Бум разработки WAF от отечественных производителей (Searchinform windows actual firewall?) или на этом успокоимся?

PS:
Отдельно связался с solidlab и попросил немного рассказать про их решение:
·        "SolidWall "WAF" и "Континент" WAF это два параллельно живущих решения"
·         "Продукт построен на платформе Linux и имеет собственную уникальную архитектуру и набор функциональных модулей за исключением системы захвата трафика на основе NGinx (активный режим) или Suricata (пассивный режим), а также сигнатурного анализатора ModSecurity (сделано для обеспечения совместимости с открытым форматом сигнатур)"
·         "Про сигнатуры... Ответов на этот вопрос много. Дело в том, что наш WAF состоит из целого набора модулей, которые работают на различных уровнях абстракции веб-приложения и на основе различных методах. Пройдемся по порядку: Первый уровень абстракции - это уровень протокола HTTP. На этом уровне осуществляется протокольная валидация, которая позволяет исключить атаки на уровень парсера веб-сервера, фреймворка или избежать неприятных вещей типа Http Parameter Contamination (HPC). Соответственно, понятие сигнатуры тут - это правила в терминах RFC о протоколе HTTP. Есть базовый набор правил, который по желанию можно расширить: запретить определенные заголовки или, например, HPP, если приложение не использует одноименные параметры. Как видно, на этом уровне сплетаются два способа задания правильного и нежелательного: black-listing и модель нормального поведения. Второй уровень абстракции - это атаки, синтаксиса входных параметров в домене веб-приложения. Здесь также мы используем два варианта описания: black-listing для обнаружения injection-атак и автоматическое или ручное формирование синтаксических моделей параметров веб-приложения. Для модуля black-listing'а синтаксических атак на самом нижнем уровне используется mod_security, который обвешан различными дополнениями: интеллектуально подавление ложных срабатываний, автоматическое обновление через подписки от TrustWave или ручное создание собственных сигнатур. На самом деле, основной упор делается на модуль автоматического вывода синтаксических форм параметров веб-приложений, так как такой подход позволяет избежать injection-атак в подавляющем большинстве случаев by design. Остаются только различные сложные варианты типа File Upload. Третий уровень абстракции - это все, что связано с семантикой параметров: время жизни сессий, атаки на авторизацию и аутентификацию, манипуляции с CSRF-токеном, переборные атаки, нарушение последовательностей действий и т.п. Здесь сигнатурой опять же является мета-правило более высокого порядка, которое формулируется в терминах не синтаксиса параметров, но действий и их атрибутов. Это если кратко. Технологически, конечно, все намного сложнее."
·         "Про основу - у нас почти все написано на Питоне и есть модули на Си. целевая система – Ubuntu. Соответственно для модулей на Си есть Питоновские обертки. Идея нашего слоеной модульности в т.ч. чтобы избежать лаборатории с выпуском новых сигнатур для блеклистинга эксплойтов ибо известно, что это во-первых, операционно дорого, а во вторых плохо работает в мире веба потому ставка на позитивные модели для каждый бизнес-действий"

Пару слов про Nemesida от Pentest.IT
·        " WAF наша собственная разработка, выполнен в виде модуля для nginx
·         Сигнатуры:
 * анализ security trackers;
 * отдел аудита и тестирования на проникновение, собственные исследования;
 * собственная лаборатория lab.pentestit.ru с количеством участников
   15.000 со всего мира и "чистыми" логами атак по 50-60 Гб в день в
   первые две недели запуска;
 * защищаемые сайты;
·         Сертификацией ФСТЭК активно занимаемся в данный момент"


пятница, 3 марта 2017 г.

ПДн. Использование мер защиты транспортной безопасности для защиты ПДн


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


Вполне резонный вопрос таких организаций – как мы можем использовать уже полностью реализованные меры ТБ для защиты ПДн и выполнения требований ПДн?  

Был проведен анализ требований ТБ на предмет соответствия требованиям ПДн. К слову сказать, система НПА в области транспортной безопасности достаточно разветвленная и зависит от видов транспорта.  Не буду её всю здесь приводить, отмечу только что хотя и детальные требования для разных видов транспорта определяются отдельными ПП РФ и приказами регуляторов, но во многом они совпадают.  Приведу результаты сравнения требований на примере морского и речного транспорта:


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

Но хотя и меры ПДн напрямую не пересекаются с мерами ТБ, последние могут оказать значительное влияние на СЗПДн:
·         На этапе моделирования нарушителя – хорошо реализованные меры ТБ позволяют фактически исключить внутреннего нарушителя
·         На этапе моделирования угроз – исключить большую часть угроз, связанных с локальным воздействием на ИС, а также угроз, связанных с внутренним нарушителем
·         На этапе выбора мер защиты – исключить из базового набора мер защиты ПДн, меры необходимые для нейтрализации исключенных ранее угроз