воскресенье, 11 февраля 2018 г.

ИБ. Требования ФСБ к средствам защиты КИИ

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

Но недавно опубликованный проект приказа ФСБ России «Об утверждении Требований к средствам, предназначенным для обнаружения, предупреждения и ликвидации последствий компьютерных атак и реагирования на компьютерные инциденты» наконец разъяснил, что мы должны увидеть на значимых объектах КИИ для подключения к ГосСОПКА.

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

Как обычно я немного упростил формулировки требований и отобразил в виде майнд-карт, для того чтобы можно было быстро, одним взглядом окинуть новые требования ФСБ России.
Средства обнаружения компьютерных атак – под этим ФСБ России подразумевает не IDS, не IPS и не какие-то “сенсоры”. Тут требуется сбор, обработка, автоматический анализ событий ИБ и выявление инцидентов – традиционно такие средства называют SIEM (security information and event management). Тут нет никаких требований по передачи информации в НКЦКИ. Миллионы “сырых” событий ИБ – это не интересно.  

Средства предупреждения компьютерных атак – одна часть требований связанна со сбором информации об инфраструктуре, сбором информации об уязвимостях и недостатках в настройке. Эти функции как правило реализуются сканнерами защищенности. Вторая часть требований связана с получением так называемой справочной информации (базы репутаций IP, адреса серверов бот-сетей и т.п.), а также с получение информации об угрозах безопасности информации – как правило такие функции выполняются отдельными средствами или сервисами предоставление актуальной информации об угрозах.   Тут хочу отдельно отметить требования выгружать в НКЦКИ обобщенную информацию об уязвимостях и автоматически обмениваться с НКЦКИ информацией об угрозах – поэтому не подойдут имеющиеся на рынке готовые решения, должны появится новые решения, заточенные под ГосСОПКА.  

 От средств реагирования на компьютерные инциденты требуется иметь возможность обогатить информацию об инциденте данными из других систем (репутации, угрозы, уязвимости, доступные сервисы) и получить в итоге консолидированную информацию которая поможет оперативно отреагировать на инцидент. И именно такая консолидированная информация уже более ценна для НКЦКИ. Тут требуется обеспечить автоматизированный обмен информацией, причем с соблюдением системы идентификации НКЦКИ. Так что потребуются средства, специально разработанные под ГосСОПКА.    

Для СКЗИ одно требование – они должны быть сертифицированными.  
Также в документе приводятся общие требования к средствам. Наиболее интересные из них – возможность модернизации и технической поддержки силами исключительно российских компаний. Это фактически исключает возможность использовать иностранные решения для защиты критических объектов КИИ.

Ниже общая схема взаимодействия указанных средств.  



Ещё недавно мы возмущались объемным требованиям к лицензиатам ФСТЭК оказывающим услуги по мониторингу (SOC-и). Сейчас мы пришли к ситуации, когда всем владельцам значимых объектов КИИ (а их может быть тысячи) придется создавать собственные SOC-и в обязательном порядке. Ведь указанные типы средств и функций составляют основу центров мониторинга и реагирования на инциденты.    


PS: Напоследок несколько замечаний к документу:
·         В приказе ФСБ России, в отличие от документов ФСТЭК, приводятся конкретные детальные требования к средствам, но не предусмотрено какой-либо системы оценки средств, указанным требованиям.
Как конечному пользователю узнать, соответствует ли его набор средств указанным требованиям? Запрашивать официальные письма у производителя? Проводить собственные испытания?  
Или в соответствии с другим приказом ФСБ России отправлять перечень предполагаемых средств на согласование с КНЦКИ и в таком случае положительный ответ будет подтверждением соответствия указанных средств требованиям.  Тогда надо запасаться временем на несколько попыток (по 45 календарных дней каждая)
·         Не совсем понятно, как подтвердить возможность осуществления модернизации средств силами исключительно российских компаний? Заранее проводить опрос среди интеграторов? Открытый конкурс на модернизацию?
·         Как можно проверить и подтвердить отсутствие НДВ кроме сертификации?  
·         Не совсем понятно, подойдет ли в свете указанного ПО с открытым исходным кодом (под требования ФСТЭК к лицензиатам вполне подходили gosint, spiderfoot)? Если субъект КИИ самостоятельно будет оказывать себе поддержу ПО, проводить модернизацию, сам оформит для себя формуляр и руководство администратора?
·         Некоторые требования к средствам представляются избыточными. Например, задавая себе вопрос, “действительно ли указанная функция необходима для эффективного обнаружения, предотвращения и реагирования на атаки?” не для всех функций можно ответить положительно. Некоторые – скорее для удобства или для некоторых исключительных ситуаций.  Например, настройка и контроль SLA по реагированию на инциденты или расчет прогнозов на основе ретроспективного анализа данных.



вторник, 30 января 2018 г.

ИБ. Рекомендации Банка России к ЧМ 2018

Мероприятия / соревнования мирового уровня традиционно привлекают к себе особое не только внимание общественности и зрителей, но и киберпреступников и злоумышленников всех мастей. Как во время проведения зимних олимпийских игр 2014 в г. Сочи было зафиксировано большое количество кибератак, так и во время проведения Чемпионата мира по футболу 2018 стоит ожидать повышения интенсивности атак на инфраструктуру и все связанные с ЧМ сервисы.
Видимо в связи с этим ФинЦЕРТ Банка России недавно опубликовал рекомендации по безопасности во время проведения Чемпионата мира по футболу 2018. Рекомендации даются по 4 направлениям:
·         Для магазинов и организаций сферы услуг позащите POS-терминалов икассовых решений
·         Для банков по защите банкоматов
·         Для организаций кредитно-финансовой сферы позащите информационной инфраструктуры

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

Так, например, гражданам советуют отдавать предпочтение банкоматам, установленным в безопасных местах, под наблюдением охранных служб и не использовать банковские карты для прохода в помещения.

Владельцам POS-терминалов – опечатывать терминалы, ставить на учет, лепить наклейки с инвентарными номерами, обязать сотрудников периодически проверять терминалы на наличие накладных устройств и целостность защитных наклеек.

Банкам рекомендуют сократить использование устройств, требующих провести банковской картой для входа в помещение с банкоматом; размещение банкоматов в хорошо освещенных местах; в дополнение к камерам, направленным на пользователя банкомата, размещать ещё и дополнительные камеры, фиксирующие подходящих и уходящих людей; настройка BIOS, обновления ОС, зашифрованный канал взаимодействия с диспенсером, VPN, персональный МЭ, антивирус, белые списки USB устройств и ПО, системы удаленного мониторинга состояния банкоматов.

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

Это были краткие выдержки, советую вам почитать и первоисточник. Также было бы интересно увидеть рекомендации Роскомнадзора, ФСТЭК России и ФСБ России.  


четверг, 18 января 2018 г.

ПДн. Изменения в законодательстве РФ за 2017 г.



Недавно для учреждений здравоохранения делал краткий обзор изменений законодательства РФ за 2017 год. Презентация выступления ниже, возможно кому-то будет полезной.



Отдельно хочу обратить внимание на подборку изменений в федеральных законах где так или иначе упоминаются персональные данных.

Нажмите чтобы увидеть все 20 ФЗ с изменениями



Я всегда считал, что с регулированием обработки персональных данных план примерно следующий: 152-ФЗ определяет и регламентирует общие нормы, применяемые по-умолчанию / в общем случае / всегда; а отдельные ФЗ, связанные с определенными отраслями или видами деятельности должны регламентировать особенности того, как обрабатываются персональные данные в данном виде деятельности (сколько должны хранится, кому передаваться, где консолидироваться и т.п.).   

Об этом говорится в части 1 статьи 4 152-ФЗ. А также во многих других статьях 152-ФЗ. “.. если срок хранения персональных данных не установлен федеральным законом”, “..если иное не предусмотрено федеральным законом”, “обработка персональных данных необходима для достижения целей, предусмотренных … законом, для осуществления и выполнения возложенных законодательством Российской Федерации на оператора функций, полномочий и обязанностей”, “не распространять персональные данные без согласия субъекта персональных данных, если иное не предусмотрено федеральным законом”.

Ожидалось что во многих ФЗ будут отдельные разделы, посвященные обработке ПДн. В небольшой части федеральных законов так и делается (242-ФЗ, 482-ФЗ).

Но в 2017 году больше преобладала тенденция включать вместо этого в федеральные законы заглушки типа “в рамках … деятельности обработка персональных данных осуществляется в соответствии с законодательством о персональных данных / в соответствии c требованиями Федерального закона от 27 июля 2006 года N 152-ФЗ “О персональных данных”.

Также непонятно, зачем добавляют все больше исключений в часть 1 статьи 6, когда можно аналогичные поправки вносить в ФЗ соответствующие затронутым видам деятельности (исполнение судебных актов / государственная охрана).  

Было бы интересно услышать ваше мнение по этому поводу.


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

КИИ. Требования ФСТЭК по ОБ значимых объектов КИИ

На официальном портале размещен проект приказа ФСТЭК России “Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации”.

В отличие от предыдущего приказа по системе безопасности ЗО КИИ, данный приказ является более классическим и уже привычным нам. Сделал обзор в виде майд-карт его основных требований в сравнении с приказом ФСТЭК №31, которому он должен был стать логической заменой (как пророчили эксперты). 

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

2. Этап Разработки мер защиты
Из интересного тут можно отметить разрешение оценивать в основном только угрозы, связанные с компьютерными атаками. Уточнили что модель угроз может быть одна на несколько объектов, но только если они однотипные.
В документе в явном виде не сказано, на каком этапе и после каких мероприятий должен производится выбор мер защиты информации, но логически можно сделать вывод что это должен быть этап разработки мер защиты, после моделирования угроз.
В явном виде указана необходимость разработки обоснования, в случае если меры промышленной безопасности, физической безопасности или иные компенсирующие меры заменяют меры из базового набора мер защиты.
3. Этап внедрения мер защиты
Из интересного: потребовали выполнения эксплуатационной документации на СЗИ (а я в блоге регулярно обращаю внимание на сложности в реализации некоторых требований в ЭД и о том, что большинство пользователей игнорируют ограничения ЭД).
Также интересна детализация способов выявления узявимостей: тут и анализ перечней установленного ПО и сканирование по сети и пентесты.

4. На этапе эксплуатации и выводе из эксплуатации
Тут все аналогично приказу ФСТЭК России №31.

5. Состав мерам защиты
Для того чтобы оценить существенность изменений сделал сравнение мер из текущего документа и приказа ФСТЭК №31.
Отмечу что в новом приказе существенно сократили наименования мер защиты. (например, “Управление средствами аутентификации, в том числе хранение, выдача, инициализация, блокирование средств аутентификации и принятие мер в случае утраты и (или) компрометации средств аутентификации” -> “ Управление аутентификаторами”). Об этом ФСТЭК уже много раз просили и вот свершилось. Короткие наименования мер защиты гораздо удобнее использовать в проектной документации, при обсуждении, согласовании и другой коллективной работе. Аналогичные короткие имена применяются в NIST
А для того чтобы разъяснить что скрывается под короткими наименованиями мер защиты, ФСТЭК России планирует ещё выпустить методический документ с содержанием и правилами реализации мер защиты КИИ.
В составе мер защиты также произошло много изменений - в основном они касались смены условного обозначения мер защиты и переносу меры в другую группу. Также появилось несколько новых мер защиты и рядом мер были расширены базовые наборы (новые +).
Также были удалены 4 блока мер защиты: АНЗ, ЗСВ, ОБР и УБИ.








Ну и напоследок несколько замечаний и вопросов к проекту приказа:
·         В части КИИ у ФСТЭК есть 3 набора требований: требования по обеспечению безопасности на стадиях жизненного цикла ЗО КИИ, требования к созданию системы обеспечения безопасности ЗО КИИ и требования к мерам ОБ.
Не увидел четкого и логичного разделения между этими требованиями. Сейчас какая-то каша и много дублирований. Было бы логичнее перенести требования к ОБ на различных этапах – в приказ по системе ОБ; а в этом приказе оставить какие-то общие требования, перенести требования к процессам ОБ.   
·         В пункте 13.6 есть невыполнимое требование “По результатам анализа уязвимостей должно быть подтверждено, что в значимом объекте, как минимум, отсутствуют уязвимости, содержащиеся …, а также в иных источниках …”. Так множество источников не ограничено, то даже минимума мы никогда не достигнем…
·         В пункте 19 требуется обеспечить нейтрализацию угроз, актуальных на каждом уровне ЗО. При этом ни в БДУ ни в самом документе эти уровни больше нигде не упоминаются. Что хотят от нас? Принимать меры защиты на каждом уровне? При анализе угроз разбивать все угрозы по уровням?
·         В пункте 16 говорится что “Безопасность ЗО обеспечивается принятием организационных мер и применением средств защиты информации, обеспечивающих блокирование (нейтрализацию) угроз безопасности информации, последствиями которых может быть прекращение или нарушение функционирования значимого объекта”. Значит ли это что угрозы с иными последствиями меры защиты не нужны – их можно сразу отбрасывать?
·         Требования в пункте 22 звучат так, что в случае если у меня объект 1 категории, то я должен считать, что для меня актуальны все угрозы связанные с нарушителем высокого потенциала, а значит актуальны все угрозы.
Либо имелось в виду что для меня должен быть установлен актуальным нарушитель с высоким потенциалом? Почему бы так и не написать…
·         Там же в 22 пункте ещё одна нестыковка: “нарушителя с потенциалом не ниже базового повышенного уровня”… при этом в БДУ ФСТЭК у нас только 3 типа: высокий, средний, низкий.  Что за “повышенный”?
·         В составе мер: ЗИС.17 (защита от утечек информации) включает в себя ЗТС.1 (защита от утечек информации по ТК). Надо переформулировать


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

Общее. Wi-fi wardriving на службе у Роскомнадзора


Последние два месяца территориальные отделения РКН готовили и многие уже выложили планы деятельности на 2018 год. Но месяц назад заместитель Роскомнадзора О.И. Иванов разослал поручение включить в планы мероприятий контроль за Wi-Fi.

В результате в планы деятельности управлений пополнились серьезным количеством проверок публичных wi-fi точек доступа. Пример тут 

Чем заканчивается подобный мониторинг? Примерно следующим.

 

Кто попадает под проверки? Кафе, рестораны, гостиницы, крупные торговые и бизнес-центры, публичные мероприятия/выставки, развлекательные и спортивные центры, автосалоны, аэропорты и жд вокзалы и т.п.   В принципе попасть может любая организация, использующая публичный wi-fi для доступа в сеть Интернет.  

Даже если вход в здание строго ограничен, но wifi доступен с улицы – этого достаточно. Получаем ip -> Проверка Whois/whoami -> если диапазон за интернет провайдером, официальный запрос за какой организацией числится данный публичный ip-адрес.   





Как же удастся территориальным отделениям РКН провести более 500 выездных проверок Wi-Fi точек доступа? Для сравнения, проверок по персональным данным в плане на порядки меньше: 10-15.

Дело в том, что на помощь РКН приходит Wi-Fi WarDriving, технология за десятки лет, отработанная любителями открытого интернета: авто + заряженный ноутбук + хорошая антенна + скрипты для автоматического подключения на недетские и запрещенные сайты. Этого достаточно для того чтобы за пару дней выявить сотню нарушителей. Да и заниматься этим гораздо интереснее, чем проверять бумажки по ПДн 

А ещё и энтузиасты помогают. Вот и получается у РКН, большой объём проверок малыми средствами. 




Организациям, предоставляющим wi-fi для посетителей и сотрудников,  рекомендую проверить как обстоят дела с ограничением доступа в данный момент, подписаться/внедрить на сервисы идентификации клиентов, подписаться на сервисы фильтрации запрещенного и недетского контента (есть и бесплатные), настроить оборудование на использование этих сервисов.  


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

КИИ. Требования ФСТЭК к системам ОБ КИИ

На официальном портале размещен проект приказа ФСТЭК России “Об утверждении Требований к созданию систем безопасности значимых объектов критической информационной инфраструктуры Российской Федерации и обеспечению их функционирования”.

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

Не считая общих положений документ содержит 4 группы требований к системе безопасности значимых объектов критической информационной инфраструктуры Российской Федерации (СБ):
  
Про Требования к силам обеспечения безопасности объекта критической информационной инфраструктуры (ОБ КИИ) можно отметить требования к образованию лиц ответственных за ОБ КИИ, в том числе переподготовку раз в 5 лет – такое раньше было только для лицензиатов. Про недопустимость назначения на ответственного за ОБ КИИ функций, не связанных с ИБ хорошая новость. И требования к повышению осведомленности пользователей – тоже весьма актуально.

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

Про требования к документам по ОБ КИИ – тут весь раздел можно отнести к новинкам. В Требованиях от ФСТЭК раньше таких подробных требований к документам ИБ мы не видели. Требования в общем то все здравые, избыточного не заметил. Я бы наоборот добавил ещё нужных документов.

Про требования к организации работ по ОБ КИИ. Если под организацией работ понимать управление ИБ, то получается классический цикл деминга PDCA. Из интересного – это ежегодный контроль состояния безопасности, по сравнению с 3х летним по ПДн, ГИС.

  
 Ну и напоследок несколько замечаний и вопросов к проекту приказа:
·         Не смотря на название документа, в нем очень мало про “создание” систем. Какие этапы? Что на каком этапе делаем? Например, нужно ли проектирование? Применяется ли ГОСТ на создание АС в защищенном исполнении?
·         Предложения по совершенствованию документов СБ упоминаются отдельно, хотя входят в предложения по совершенствованию функционирования СБ
·         Не совсем понятно, что такое уровень безопасности объектов КИИ, как его определить и повышать?
·         Не совсем понятно, зачем в 17 пункте приведены некоторые типы СЗИ. Это СЗИ которые обязательно должны быть или просто примеры возможных вариантов?
·         Пятый раздел с требованиями к организации работ ОБ КИИ представляется наименее проработанным. В нем фактически нет требований, которые обязывали бы иметь какие-либо свидетельства. Детализация низка…. На этапе контроля осуществляется контроль. На этапе совершенствования – совершенствование.  Как потом проверить, было оно или нет?
·         Нет требований, зависящих от категории значимости объекта КИИ. Хотя логичнее было бы возложение дополнительных требований на наиболее значимые объекты КИИ.

    

среда, 29 ноября 2017 г.

ИБ. Как криптография помогает пожарным

Как вы, наверное, знаете при использовании СКЗИ для защиты информации ограниченного доступа (ПДн) должны соблюдаться требования эксплуатационной документации.  
ПКЗ 2005 46. СКЗИ эксплуатируются в соответствии с правилами пользования ими.”
Приказ ФСБ 378 “4. Эксплуатация СКЗИ должна осуществляться в соответствии с документацией на СКЗИ”.

В правилах пользования на достаточно популярные СКЗИ VipNet Client и Coordinator указано “На случай пожара, аварии или стихийного бедствия должны быть разработаны специальные инструкции, утвержденные руководством учреждения, в которых предусматривается порядок вызова администрации, должностных лиц, вскрытие помещений, очередность и порядок эвакуации конфиденциальных документов и дальнейшего их хранения.”
Аналогичные требования есть правилах пользования старых версий КриптоПро CSP, блоках СКЗИ для тахографов (НКМ-1, НКМ-2, НКМ-К), а также во многих приказах, регламентах гос. органов, СМЭВ.

Во время проверок ФСБ России отсутствие инструкции на случай чрезвычайных ситуаций, в которых предусмотрен порядок вызова должностных лиц, вскрытие помещений, очередность и порядок эвакуации конфиденциальных документов и дальнейшего их хранения рассматривается как нарушение правил эксплуатации СКЗИ и наказывается.



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

Единственным выходом в такой ситуации мне представляется разработка частной инструкции/порядка по действиям с СКЗИ в помещении с СКЗИ при чрезвычайных ситуациях. В случае если в организации будет разработан общий порядок действий, данная инструкция будет его уточнять. А в случае если общего порядка нет, будет формальным выполнением требований эксплуатационной документации.

Если вам интересен пример, что писать, можно обратится к правилам пользования на последние версии КриптоПро CSP 3.9, 4.0, КриптоАРМ, JINN-Client, которые не заставляют пользователей разрабатывать инструкции, но содержит в себе перечень действий в нештатных ситуациях, которые необходимо выполнять.