понедельник, 24 апреля 2017 г.

ИБ. НПА. Анализ уязвимостей ГИС


Продолжаем рассматривать недавние изменения в приказ ФСТЭК России №17. В этот раз – анализ уязвимостей ГИС.
Теперь анализ уязвимостей ГИС требуется проводить на 3 из 6 этапах жизненного цикла системы защиты ГИС: формирования требований, внедрения и аттестации.

1. На этапе анализа угроз безопасности информации ГИС, необходимо провести анализ возможных уязвимостей ИС, используя при этом БДУ ФСТЭК России, а также иные источники данных об уязвимостях в качестве исходных данных. В модель угроз нужно включить описание возможных уязвимостей ИС.
Основное отличие от других этапов кроется в слове “возможных”. Не фактических, а именно возможных. А при наличие хорошей фантазии, у нас будет возможно всё. На сколько я понимаю, тут нужна некая классификация всех возможных уязвимостей и исключение неподходящих типов уязвимостей по определенным причинам (отсутствие объекта воздействия, определенные структурные характеристики, неиспользуемые ИТ). 
Проблема в том, что в БДУ ФСТЭК в разделе Уязвимости отсутствует подобная классификация уязвимостей. Кроме того, разделе Уязвимости приведены только фактические уязвимости ПО. А как же уязвимости ГИС в целом? Недостатки орг. мер?
На самом деле, перечень таких возможных уязвимостей скрывается в неструктурированном виде в тексте угроз БДУ ФСТЭК: “Данная угроза обусловлена уязвимостями некоторых системных (материнских) плат – наличием механизмов аппаратного сброса паролей, установленных в BIOS/UEFI” или “Данная угроза обусловлена слабостями механизмов фильтрации сетевого трафика и антивирусного контроля на уровне организации”.

2. На этапе внедрения системы защиты информации требуется провести уже фактический анализ уязвимостей.
“При анализе уязвимостей информационной системы проверяется отсутствие известных уязвимостей средств защиты информации, технических средств и программного обеспечения, в том числе с учетом информации, имеющейся у разработчиков и полученной из других общедоступных источников, правильность установки и настройки средств защиты информации, технических средств и программного обеспечения, а также корректность работы средств защиты информации при их взаимодействии с техническими средствами и программным обеспечением.
По результатам анализа уязвимостей должно быть подтверждено, что в информационной системе отсутствуют уязвимости, содержащиеся в банке данных угроз безопасности информации ФСТЭК России, а также в иных источниках, или их использование (эксплуатация) нарушителем невозможно.”
Тут уже речь о других уязвимостях – известных или фактических уязвимостях. При этом нужно проверить как минимум все уязвимости из БДУ. Выгружаем в XLS . И ставим + - напротив уязвимостей J


Но хорошо, что уязвимости имеют такие поля как Производитель, Наименование ПО, Версия ПО. Составив заранее полный перечень ПО, можно сделать выборку нужных уязвимостей. Но что делать с результатами? Например, для Windows 8.1 – 247 уязвимостей в БДУ. Далее нужно в каждой пройти по ссылке на внешние источники и проверить что там предлагалось для устранения уязвимостей, проверить наличие установленных обновлений для данных уязвимостей.

Вручную - сложно. Хотелось бы, чтобы сканнеры уязвимостей могли работать с БДУ и делать всё за нас. Давайте посмотрим…
RedCheck от Алтекс-Софт : “RedCheck производит поиск уязвимостей по нашей базе ovaldb которая синхронизируется с БД угроз безопасности информации ФСТЭК России! Список уязвимостей Вы можете посмотреть на сайте базы данных https://ovaldb.altx-soft.ru/Definitions.aspx?refsource=FSTEC .”
Вроде ок. (UPDATE) за 2017 г. в базе RedCheck уже 372 уязвимости из БДУ ФСТЭК.
Ревизор Сети 3.0 от ЦБИ: “Ревизор Сети изначально осуществляет поиск включенных в БДУ ФСТЭК России (http://bdu.fstec.ru) уязвимостей, содержащихся в операционных системах Windows и функционирующих в них приложениях и средствах защиты информации, в том числе российской разработки. Помимо поиска уязвимостей из базы данных уязвимостей ФСТЭК России Сетевой сканер «Ревизор Сети» версии 3.0 осуществляет поиск уязвимостей, содержащихся в таких источниках, как cve.mitre.org, ovaldb.altx-soft.ru, microsoft.com и других источниках. ”
XSpider от Positive Technologies “Обязательно такая возможность будет. В июне в рамках пересертификации XSpider будет передана в испытательную лабораторию ФСТЭК сборка уже с таким функционалом ”.
Сканер-ВС от Эшелон “Сканер-ВС поддерживает поиск уязвимостей по БДУ ФСТЭК России”. Правда опыт показал, что текущая, сертифицированная версия – не поддерживает.
Итого, в перспективе возможно за нас всё будут делать сканеры, но в данный момент готового отчета, подтверждающего отсутствие уязвимостей из БДУ ФСТЭК я не обнаружил. С актуальностью баз остаются вопросы – возможно придется проверять результаты и последние уязвимости просматривать вручную.
Кроме того, не забываем, что в анализ уязвимостей входит ещё анализ настройки СЗИ, ПО и ТС и анализ корректности работы СЗИ.

3. На этапе аттестации требуется провести следующие испытания “анализ уязвимостей информационной системы, в том числе вызванных неправильной настройкой (конфигурированием) программного обеспечения и средств защиты информации” при этом в качестве исходных данных используются “результаты анализа уязвимостей информационной системы”. Это как вообще?
Просто повторяем то что делали на этапе внедрения? С учетом последних требований к разделению аттестаторов и внедренцев, видимо тут расчет на выборочный независимый дублирующий анализ.  


четверг, 13 апреля 2017 г.

ИБ. Почему старая методика угроз не подходит для моделирования угроз ГИС?


Как вы, наверное, знаете, недавно в приказ ФСТЭК №17 “Требования о защите информации, не содержащей государственную тайну, содержащуюся в государственных информационных системах” были внесены неоднозначные изменения, по которым есть вопросы и проблемы с их применением.  Сегодня давайте обсудим одну из таких проблем:  
теперь при моделировании угроз необходимо использовать “новую” БДУ ФСТЭК России, а новой методики моделирования угроз не предвидится.  Далее подробно …

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

По сути это две отдельных работы, требования к каждой из которых детализируются в пункте 14.3 приказа:
I. Определение угроз
“14.3. Угрозы безопасности информации определяются по результатам оценки возможностей (потенциала) внешних и внутренних нарушителей, анализа возможных уязвимостей информационной системы, возможных способов реализации угроз безопасности информации и последствий от нарушения свойств безопасности информации (конфиденциальности, целостности, доступности).
В качестве исходных данных для определения угроз безопасности информации используется банк данных угроз безопасности информации (bdu.fstec.ru) …”
II. Разработка модели угроз
“Модель угроз безопасности информации должна содержать описание информационной системы и ее структурно-функциональных характеристик, а также описание угроз безопасности информации, включающее описание возможностей нарушителей (модель нарушителя), возможных уязвимостей информационной системы, способов реализации угроз безопасности информации и последствий от нарушения свойств безопасности информации”
Можно ли использовать при этом произвольные методики? Нет…        
“Для определения угроз безопасности информации и разработки модели угроз безопасности информации применяются методические документы, разработанные и утвержденные ФСТЭК России

III. Давайте разбираться, какой же методический документ надо использовать? В соответствии с каким документом должен требовать государственный орган проведение работ от подрядчика?

Единственный утвержденный и опубликованный методический документ ФСТЭК России в части моделирования угроз - это “Методика определения актуальных угроз безопасности персональных данных при их обработке в информационных системах персональных данных. ФСТЭК России, 2008 год”. Условно назовем её “старая методика”. (Есть ещё утвержденный, но не опубликованный документ - "Методика определения актуальных угроз безопасности информации в ключевых системах информационной инфраструктуры", утв. ФСТЭК России в 18.05.2007, но его мы не будем рассматривать) .

По неформальной информации, “новой” методики для ГИС ожидать в ближайшее время не стоит. Тогда надо определиться со “старой” методикой. Нужно ли и можно ли её использовать? Есть несколько причин против использования методики:

Первая: “старая” методика предназначена только для определения угроз ПДн и ИСПДн. Мы же рассматриваем Государственные информационные системы, которые не всегда могут являться ПДн. Требования Приказа применяются и для иной информации в ГИС, в том числе для общедоступной информации и информации подлежащей обязательному опубликованию.

Вторая: “старая” методика разработана на основании Постановления правительства №781, которое уже отменено.  Вместе с этим в юридической практике применяется следующее общее правило “Признание основного нормативного правового акта утратившим юридическую силу означает утрату юридической силы производных и вспомогательных нормативных правовых актов, если не установлено иное”.  То есть – утратила юридическую силу.

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

Четвертая: Методический документ должен охватывать и вторую часть работ – а именно описывать, как разрабатывается документ под названием Модель угроз.  В старой методике об этом ни слова.

Пятая: В соответствии с Приказом угрозы должны определяться в зависимости от одного набора характеристик. Примерно же набор характеристик применяется в БДУ ФСТЭК. А в “старой” методике, определяются в зависимости от другого набора. Подробнее на рисунке.



С одной стороны, все выводы указывают на тот факт, что это не подходящая для ГИС методика.  С другой стороны, есть один весомый аргумент за её использование – это единственная утвержденная и опубликованная методика ФСТЭК России в области моделирования угроз.

PS: На самом деле, все указанные аргументы против использования “старой” методики, можно было бы устранить внеся небольшие “косметические” обновления в методику. Поменять термины, ИСПДн на ИС, ПДн на информацию и т.п. + добавить некоторые описательные разделы из проекта “новой” методики + немного актуализировать таблицу для расчета исходной защищенности.  А все формулы для расчета актуальности угроз можно было оставлять без изменений – они себя хорошо показали за время, прошедшее с 2008 года.  

 Думаю, что на такую небольшую актуализацию методики моделирования угроз, месяца было бы вполне достаточно. А вот три года, это уже перебор. 

воскресенье, 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 г.

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


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


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

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


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

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



пятница, 10 февраля 2017 г.

ИБ. НПА. Новые требования к лицензиатам ФСТЭК - мониторинг

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




Рассмотрение самого термина вынес в приложение. А в начале мы рассмотрим варианты мониторинга на практике:
1 вариант. SOC. Тут у нас комплекс средств, персонала и процессов, которые собирают информацию, анализируют и реагируют. Как правило для автоматизации и формализации процессов SOC, а также для красивого представления этой информации заказчику – используется дополнительное web приложение, BI.  Видимо регулятор думал только про этот вариант мониторинга ИБ, когда готовил Перечень оборудования необходимого лицензиатам. 
2 вариант. SIEM.  В данном случае тоже оказывается услуга мониторинга и реагирования, но не применяется никаких надстроек, только коробочный SIEM, в который поставщик услуги не может вносить изменения. Никаких публичных сервисов не применяется. Отчет заказчику на бумаге раз в месяц. Один оператор в одной консоли управления.  
3 вариант. Узконаправленный мониторинг. Например, есть федеральная защищенная сеть и поставщик услуги должен мониторить только криптошлюзы. Например, криптошлюзы vipnet и система их мониторинга statewatcher. Никаких публичных сервисов не применяется. Отчет заказчику на бумаге раз в месяц. Один оператор в одной консоли управления.  (аналогично возможен узконаправленный мониторинг других типов СЗИ в своих специализированных консолях – не SIEM).
4 вариант.  Ручной или полу-ручной мониторинг. Фактически любой аутсорсер регулярно производит хотя бы минимальный мониторинг ИБ: просматривает журналы антивируса или журналы ОС. Зачастую это приходящий админ, который просматривает журналы на местах. Иногда это автоматический сбор журналов в хранилище с последующим ручным анализом. В общем случае это надо рассматривать как взаимодействие АРМ поставщика услуг и управляемого узла заказчика. Многие региональные компании / учреждения и не могут позволить себе более крутого мониторинга.
Причем, если представителей первого варианта от 4 до 15. То остальным мониторингом Иб занимается, наверное, половина текущих лицензиатов ФСТЭК, а это около 1000.

Давайте теперь посмотрим на требуемый к 1 июля 2017 года Перечень оборудования для этих лицензиатов:
А) Межсетевой экран уровня веб-сервера. Контроль и фильтрация в соответствии с заданными правилами информационных потоков по протоколу передачи гипертекста, проходящих через него. Применяется на сервере, обслуживающем сайты, веб-службы и веб-приложения, или на физической границе сегмента таких серверов (сервера). Должен иметь сертификат ФСТЭК России, удостоверяющий его соответствие Требованиям к межсетевым экранам, утверждённым приказом ФСТЭК России от 9 февраля 2016 г. N 9, не ниже чем по 4 классу защиты
Как я специально отмечал, в вариантах 2-4 нет никаких web серверов и публичных сервисов. Данное средство не применимо. Избыточное требование.

Б) Межсетевой экран уровня сети. Контроль и фильтрация в соответствии с заданными правилами информационных потоков, проходящих через него. Применяется на физической границе (периметре) информационной системы или между физическими границами сегментов информационной системы. Должен иметь сертификат ФСТЭК России, удостоверяющий его соответствие Требованиям к межсетевым экранам, утверждённым приказом ФСТЭК России от 9 февраля 2016 г. N 9, не ниже чем по 4 классу защиты
Так как во всех вариантах предполагается удаленное взаимодействие поставщика услуги с заказчиком (как минимум удаленное управление), то требование логичное. Не должен быть сапожник без сапог.

В) Средство (средства) антивирусной защиты, предназначенное (предназначенные) для применения на серверах и автоматизированных рабочих местах информационных систем, и средство (средства) их централизованного администрирования. Должно (должны) иметь сертификат (сертификаты) ФСТЭК России, удостоверяющий (удостоверяющие) соответствие средства (средств) Требованиям к средствам антивирусной защиты, утверждённым приказом ФСТЭК России от 20 марта 2012 г. N 28, не ниже чем по 4 классу защиты.
Также логичное требование. На узлах оператора услуги используем антивирус.

Г) Система обнаружения вторжений.  Автоматизированное обнаружение (за счет сбора и анализа данных сетевого трафика) в информационных системах действий, направленных на несанкционированный доступ к информации, специальные воздействия на неё (носители информации, средства вычислительной техники), и реагирование на них. Должна иметь сертификат ФСТЭК России, удостоверяющий соответствие средства Требованиям к системам обнаружения вторжений, утверждённым приказом ФСТЭК России от 6 декабря 2011 г. N 638, не ниже чем по 4 классу защиты
Обнаруживать вторжения откуда? D вариантах 2-4, у оператора нет никаких web серверов и публичных сервисов. А внутри сети несколько доверенных пользователей. Данное средство не применимо. Избыточное требование.

Д) Средство автоматизированного реагирования на инциденты информационной безопасности. Автоматизированное выявление инцидентов информационной безопасности по заданным индикаторам, идентификация типовых инцидентов и их локализация.
Посмотрите определения в приложении. Автоматическое реагирование не входит в понятие мониторинг ИБ ни в одном из них!!  Заказчику не всегда нужно реагирование. Если это критический объект, автоматическое реагирование может быть вообще запрещено.  Избыточное требование.

Е) Замкнутая система (среда) предварительного выполнения программ (обращения к объектам файловой системы). Изолированная информационная система (её сегмент), представляющая собой среду безопасного выполнения программ (обращения к объектам файловой системы) в целях анализа влияния указанных программ (объектов файловой системы) на безопасность информации
Это такое хитрое название для песочницы. Но в вариантах 2-4 она не применима. Песочницы и проверка подозрительных файлов, это как правило отдельная услуга, заказываемая независимо от мониторинга ИБ.  

Ж) Система управления информацией об угрозах безопасности информации. Сбор и управление информацией, поступающей из различных источников, об угрозах безопасности информации, оповещение операторов информационной системы, предназначенной для мониторинга информационной безопасности, а также операторов средств и систем информатизации, в отношении которых осуществляется мониторинг информационной безопасности, об актуальных угрозах безопасности информации
Быть в курсе актуальных угроз ИБ и уведомлять о них заказчиков, это нормально для любого лицензиата ТЗКИ. Но зачем для этого отдельная Система? Посмотрите на ГосСОПКА и FinCERT – обмен идет по электронной почте. Никакой специальной системы для этого не требуется. 
Почему сбор информации именно из разных источников?   Если источник хороший, то достаточно и одного.
И каким может быть подтверждение наличия у заказчика такой системы?  Лицензия, патент, приказ? В общем – под большим вопросом

З) Система управления событиями безопасности информации. SIEM Автоматизированное обнаружение (за счет сбора и анализа данных о событиях безопасности, регистрируемых программными и программно-техническими средствами) в средствах и системах информатизации признаков несанкционированного доступа к информации и специального воздействия на неё (носители информации, средства вычислительной техники). Должна иметь сертификат соответствия ФСТЭК России
Для варианта 1-2 применимо. Для вариантов 3-4 SIEM не применим и не нужен. Избыточное требование.
Опять же, на соответствие каким требованиям должна быть сертификация. Достаточно ли, например, сертификации на требования к МЭ или САВЗ? Ведь там сертифицирован программный комплекс, включающий в том числе систему управления, которая умеет собирать события безопасности.  Тогда формально корпоративного антивируса в минимальной комплектации с системой управления будет достаточно для этого пункта.

И) Система управления инцидентами информационной безопасности. Централизованная регистрация событий (инцидентов) информационной безопасности средств и систем информатизации, регистрация обращений операторов средств и систем информатизации, в отношении которых осуществляется мониторинг информационной безопасности, оповещение уполномоченных пользователей об инцидентах информационной безопасности, о возможных мерах по их нейтрализации и контроль обработки (нейтрализации) инцидентов информационной безопасности средств и систем информатизации, координация действий участников процесса нейтрализации инцидентов информационной безопасности, формирование и модификация шаблонов инцидентов информационной безопасности, в том числе инструкций по их нейтрализации
Мониторинг ИБ и управление инцидентами ИБ – это несвязанные друг с другом термины. В приказах ФСТЭК – это разные блоки мер защиты. Заказчику мониторинга в вариантах 2-4 зачастую этого не требуется. Избыточное требование.

К) Средство (средства) защиты каналов передачи данных. Должно (должны) обеспечивать конфиденциальность и целостность данных, передаваемых по каналам связи между информационной системой, предназначенной для управления информационной безопасностью, и средствами, и системами информатизации, в отношении которых осуществляется мониторинг. Должно (должны) иметь сертификат (сертификаты) соответствия ФСБ России
С одной стороны, защита каналов связи между клиентом и заказчиком – это логичное требование. С другой стороны, требовать предъявить СКЗИ на этапе получения лицензии – глупо. На российском рынке более 30 вендоров СКЗИ и все они не совместимы между собой. Либо оператору услуги придется покупать все возможные варианты заранее, либо, что более вероятно, получать нужный вариант в момент заключения договора или контракта
К тому же, что даст ФСТЭК России формальное предъявление лицензиатом 1 сертифицированного vipnet клиента? Этого будет достаточно?
Гораздо логичнее добавить в 17 и 21 приказы требования того, что необходима защита событий безопасности, удаленного управления, результатов мониторинга ИБ и т.п. Чтобы заказчик услуги потом требовал это от оператора услуги.

Л) Информационная система, предназначенная для мониторинга информационной безопасности. Информационная система, предназначенная для оказания услуг по мониторингу информационной безопасности средств и систем информатизации, в состав которой входят средства и системы (или их компоненты), содержащиеся в настоящем перечне под NN 27-32, и в которой приняты меры по защите информации для первого класса защищенности государственных информационных систем в соответствии с Требованиями о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах, утвержденными приказом ФСТЭК России от 11 февраля 2013 г. N 17. Должна располагаться по адресу осуществления лицензируемого вида деятельности
Требованием маловыполнимое в вариантах мониторинга 2-3, когда используются некоторые коробочные решения без собственной разработки.
В конце концов требование защиты по ГИС класса К1 (а также СЗИ 4 класса защищенности) не логично, если осуществляется мониторинг ИСПДн, например, класса УЗ4. Получается, что система мониторинга на стороне оператора будет стоить гораздо дороже системы мониторинга на стороне Заказчика. А единственная причина почему аутсорсинг и услуги по мониторингу ИБ развиваются хоть какими-то вялыми темпами заключается в небольшой экономии.  
Необходимо сформулировать требование так, чтобы в системе мониторинга выполнялись меры защиты, соответствующие классу / уровню защищаемой информационной системы.

Вывод в целом. В Перечне ФСТЭК России с оборудованием необходимым лицензиатам для оказания услуг, имеются некорректные и избыточные требования, которые не могут быть выполнены иными лицензиатами, кроме операторов 1 вариант – SOC. В связи с тем, что услуги SOC (как и ГосСОПКа) дорогие и рассчитаны исключительно на крупные корпорации и федеральные ведомства (по словам владельцев SOC с SOC-forum) - деятельность многих других лицензиатов ФСТЭК окажется вне закона, а региональные   компании, гос. органы и учреждения полностью лишатся возможности мониторинга ИБ.

Предлагаю исключить из перечня избыточные требования к деятельности по мониторингу ИБ, либо определять в официальных документах, что данные требования распространяются только на особый вид мониторинга ИБ, на базе центров оперативного управления ИБ.   Часть требований к оборудованию перенести в приказы ФСТЭК №17, 21, 31 как требования к процессам мониторинга.


ПРИЛОЖЕНИЕ
ГОСТ Р 53114-2008
“А.19 мониторинг: Систематическое или непрерывное наблюдение за объектом с обеспечением контроля и/или измерения его параметров, а также проведение анализа с целью предсказания изменчивости параметров и принятия решения о необходимости и составе корректирующих и предупреждающих действий.
3.5.2 мониторинг информационной безопасности организации; мониторинг ИБ организации: Постоянное наблюдение за процессом обеспечения информационной безопасности в организации с целью установить его соответствие требованиям по информационной безопасности.”
ГОСТ Р 50922-2006
“2.8.7 мониторинг безопасности информации: Постоянное наблюдение за процессом обеспечения безопасности информации в информационной системе с целью установить его соответствие требованиям безопасности информации.”
ГОСТ Р ИСО/МЭК 27001—2006
“А.10.10 Мониторинг - Цель: Обнаруживать несанкционированные действия, связанные с обработкой информации
A.10.10.1 (Ведение журналов аудита) Должны быть обеспечены ведение и хранение в течение определенного периода времени журналов аудита, регистрирующих действия пользователей, нештатные ситуации и события информационной безопасности, в целях помощи в будущих расследованиях и проведении мониторинга контроля доступа
A.10.10.2 (Мониторинг использования средств обработки информации) Должны быть установлены процедуры, позволяющие вести мониторинг и регулярный анализ результатов мониторинга использования средств обработки информации
A.10.10.3 (Защита информации журналов регистрации) Средства регистрации и информация журналов регистрации должны быть защищены от вмешательства и несанкционированного доступа
A.10.10.4 (Журналы регистрации действий администратора и оператора) Действия системного администратора и системного оператора должны быть регистрируемыми
A.10.10.5 (Регистрация неисправностей) Неисправности должны быть зарегистрированы, проанализированы и устранены
A.10.10.6 (Синхронизация часов) Часы всех соответствующих систем обработки информации в пределах организации или охраняемой зоны должны быть синхронизированы с помощью единого источника точного времени”
Приказ ФСТЭК №31
“16.8. В ходе контроля (мониторинга) за обеспечением уровня защищенности автоматизированной системы управления осуществляются:
контроль за событиями безопасности и действиями персонала в автоматизированной системе управления;
контроль (анализ) защищенности информации, обрабатываемой в автоматизированной системе управления, с учетом особенностей ее функционирования;
анализ и оценка функционирования системы защиты автоматизированной системы управления, включая выявление, анализ и устранение недостатков в функционировании системы защиты автоматизированной системы управления;
документирование процедур и результатов контроля (мониторинга) за обеспечением уровня защищенности автоматизированной системы управления;
принятие решения по результатам контроля (мониторинга) за обеспечением уровня защищенности автоматизированной системы управления о необходимости пересмотра требований к защите информации в автоматизированной системе управления и доработке (модернизации) ее системы защиты.
Регистрация событий безопасности РСБ.5 - Мониторинг (просмотр, анализ) результатов регистрации событий безопасности и реагирование на них”


PS: Другие комментарии к новым требованиям можно почитать у Алексея Лукацкого и Андрея Прозорова




среда, 8 февраля 2017 г.

ИБ. НПА. Новые требования к лицензиатам ФСТЭК - пентестеры


Постановления Правительства РФ от15.06.2016 N 541 внесло изменения в Постановление Правительства РФ от 3 февраля 2012 г. N 79 «о лицензировании деятельности по технической защите конфиденциальной информации»

Изменения вступают в силу 17.06.2017.

Давайте вспомним что изменилось:
1) виды работ и услуг:
В ряде случаев вместо “работ и услуг” стало применяться только “услуг по”.
Убрали сертификационные испытания и добавили услуги по мониторингу
- в) сертификационные испытания на соответствие требованиям по безопасности информации продукции …;
+ в) услуги по мониторингу информационной безопасности средств и систем информатизации;

В область лицензирования попала наладка СЗИ.  В СКЗИ-шном лицензировании “наладка” всегда упоминалась. Теперь вот и в ТЗКИ. Когда мы говорится про наладку программного обеспечения очевидно имеется в ввиду его настройка.
- е) установка, монтаж, испытания, ремонт средств защиты информации (технических средств защиты информации, защищенных технических средств обработки информации, технических средств контроля эффективности мер защиты информации, программных (программно-технических) средств защиты информации, защищенных программных (программно-технических) средств обработки информации, программных (программно-технических) средств контроля защищенности информации).
+ е) услуги по установке, монтажу, наладке, испытаниям, ремонту средств защиты информации (технических средств защиты информации, защищенных технических средств обработки информации, технических средств контроля эффективности мер защиты информации, программных (программно-технических) средств защиты информации, защищенных программных (программно-технических) средств обработки информации, программных (программно-технических) средств контроля эффективности защиты информации).

Сменили термин “Средства контроля защищенности” -> “средства контроля эффективности защиты”.
                Первый был в приказах ФСТЭК
“18.8. Меры по контролю (анализу) защищенности информации должны обеспечивать контроль уровня защищенности автоматизированной системы управления путем проведения мероприятий по выявлению и анализу уязвимостей, контролю установки обновлений программного обеспечения, состава программного обеспечения и технических средств и правильности функционирования средств защиты информации”
Второй из ГОСТ Р 50922-2006
“2.7.3 средство контроля эффективности защиты информации: Средство защиты информации, предназначенное или используемое для контроля эффективности защиты информации.
2.9.1 эффективность защиты информации: Степень соответствия результатов защиты информации цели защиты информации.”

2) От требования к наличию специалистов с образованием -> наличие руководителя с образованием (переподготовкой) и опытом + не менее 2х технических работников с образованием (переподготовкой) + стаж.
Теперь требуется повышать квалификацию (замечу, что минимально допустимый срок повышения квалификации – 16 часов, но среди программ согласованных с ФСТЭК скорее всего придется выбирать от 72 часов) указанных лиц не реже одного раза в 5 лет.  Раньше же лицензиаты вполне могли обходится сотрудниками, получившими высшее образование 10-15 лет назад.

3) Убрали требования к наличию лицензионных ОС, СУБД и другого ПО
4) Вместо наличия средств контроля защищенности -> теперь требуются средства контроля эффективности + средства контроля исходных текстов программного обеспечения

Ну а дальше перейдем к самому нашумевшему – утвержденному директором ФСТЭК России 16 декабря 2016 г. «Перечень контрольно-измерительного и испытательного оборудования, средств контроля защищенности, необходимых для выполнения работ и оказания услуг, установленных Положением о лицензировании деятельности по технической защите конфиденциальной информации, утвержденным постановлением Правительства Российской Федерации от 3 февраля 2012 г. N 79»

Для начала формальные ошибки:
·         ПП №79 в новом варианте требует средства контроля эффективности защиты, а в Перечне – средства контроля защищенности
·         ПП №79 в новом варианте требует средства контроля исходных текстов ПО, а в перечне о нем ни слова

Далее про пентестеров:  на SOС–forum ФСТЭК говорил что эта деятельность входит в лицензируемую “б) услуги по контролю защищенности конфиденциальной информации от несанкционированного доступа и ее модификации в средствах и системах информатизации”

Из планируемых изменений в 17 приказ ФСТЭК следовало что пентесты входят и в деятельность по аттестации.

А из Перечня следует, что “Средства, предназначенные для осуществления тестирования на проникновение” применяются в деятельности б, в, г.1, д.1. (контроль защищенности, мониторинг ИБ, аттестация, установка СЗИ). 

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

Посмотрим какие средства требуются именно пентестерам (услуги по контролю защищенности КИ от НСД) для получения лицензии.
Программные средства формирования и контроля полномочий доступа в информационных (автоматизированных) системах
Должны иметь сертификат соответствия ФСТЭК России
Средства контроля эффективности применения средств защиты информации
Должны иметь сертификаты соответствия ФСТЭК России
Программное средство контроля целостности программ и программных комплексов
Должно иметь сертификат соответствия ФСТЭК России
Система контроля (анализа) защищенности информационных систем
Должна иметь сертификат соответствия ФСТЭК России
Средства, предназначенные для осуществления тестирования на проникновение

На первый взгляд ничего страшного нет. Классический набор + новые средства тестирования на проникновения, под которые пока не требуется сертификат и подойдет пачка опенсорсных утилит с функциями: 

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


В следующий раз про мониторинг.