пятница, 19 октября 2018 г.

КИИ. Подключение к ГосСОПКА


В последнее время сталкиваюсь с большим количеством вопросов типа “у нас обычная организация, нет SOC-а, как нам технически подключится к ГосСОПКА?”. Так как раньше возможности такого подключения были описаны только в ДСП-шных документах, которые мог получить только лицензиат, то приходилось отправлять их либо в коммерческий центр ГосСОПКА, либо за получением лицензии.
Но наконец, по материалам одной из недавних конференций информация появилась и в публичных источниках. Ей и спешу свами поделиться. Озвучено было 3 варианта подключения к технической инфратструктуре ГосСОПКА:
1.       Купить новое клиентское ПО VipNet Client КС3. Подключить его в сеть НКЦКИ. Цена вопроса – до 10 тыс. рублей

2.       Купить новый шлюз VipNet Coordinator или HW. Подключить его в сеть НКЦКИ. Цена вопроса – 60-200 тыс. рублей в зависимости от шлюза

3.       Связать уже имеющуюся у вас сеть VipNet с сетью НКЦКИ с помощью межсетевого. Без доп. затрат  

Как видно из выдержки презентации, подключившись к технической инфраструктуре ГосСОПКА, мы сможем работать в личном кабинете по адресу portal.cert.local и вносить данные через web. Также вероятно будет возможность импортировать инцидент из файла. И ещё один способ взаимодействия: связать систему учета инцидентов организации и систему учета инцидентов НКЦКИ через API.
Кроме того, в приказах ФСБ России №367 и 368 озвучивается возможность, при отсутствии технического подключения к НКЦКИ, передавать информацию в ГосСОПКА посредством почтовой, факсимильной или электронной связи на адреса (телефонные номера) НКЦКИ, указанные на сайте http://cert.gov.ru. Сейчас там указаны: телефон +7 (916) 901-07-42 и почта gov-cert@gov-cert.ru
Кроме того есть web-форма для сообщения об инциденте http://cert.gov.ru/abuse/index.html Но состав полей этой web формы не совпадает с составом информации, которую нужно предоставлять в ГосСОПКА в соответствии с приказом ФСБ №.

Собрал все возможные варианты (без участия сторонних SOC) передачи сведений в ГосСОПКА на одной картинке:


PS: под вопросом пока остается минимальный или рекомендованный набор данных об инциденте или атаке, которые достаточно передавать в НКЦКИ, а также форматы файлов. Надеюсь по нему также будут публичные разъяснения. 


пятница, 12 октября 2018 г.

КИИ. Обязательные документы


При планировании мероприятий по обеспечению безопасности значимых объектов критической информационной инфраструктуры важно понимать какие процессы обеспечения безопасности необходимо создать/изменить, а также в каких документах они должны быть определены и описаны.
Я провел полный анализ действующих НПА в области КИИ на предмет требований в которых какие-либо документы упоминаются в явном виде, либо имеются требования к мерам необходимость документирования которых очевидна и неоспорима.   
Для владельцев незначимых объектов КИИ получился примерно следующий перечень


Для владельцев значимых объектов КИИ перечень существенно больше
В хорошем качестве можно скачать PDF 

Получилось 18 политик, 8 порядков, 4 приказа, 3 журнала, 2 положения. Но это как минимум.


Есть ещё ряд процессов обеспечения ИБ, которые требуется выполнять, но требований по документированию которых не приводится – тут документы могут разрабатываться на усмотрение субъекта КИИ. Также для многих процессов, может быть недостаточно политики и порядка – могут понадобится дополнительные инструкции или документы, возникающие в результате процесса.
Пока получается что в области КИИ требования к организационным мерам и документированию более сильные чем в других сферах.    

Но конечно возможна и оптимизация. Можно объединять документы в более крупные, делать документы сразу по нескольким темам, но это вопрос уже других статей.  

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


понедельник, 3 сентября 2018 г.

ПДн. Обезличивать не надо защищать



До недавнего времени, интерес к обезличиванию ПДн был не большой, как со стороны законодателей, так и со стороны операторов.


НПА РФ касающиеся обезличивания ПДн:
·         Федеральный закон 152-ФЗ “О персональных данных”
требования по обезличиванию в редких случаях
·         Приказ Роскомнадзора от 05.09.2013 N 996 "Об утверждении требований и методов по обезличиванию персональных данных"
описаны возможные методы, но требования фактически отсутствуют
·         КОАП РФ
есть штраф за нарушение требований и методов обезличивания, но мизерный и только для должностных лиц гос. органов

Появилось несколько свежих отраслевых НПА, устанавливающих требования обезличивать ПДн:
·         Приказ Министерства здравоохранения РФ от 14 июня 2018 г. N 341н "Об утверждении Порядка обезличивания сведений о лицах, которым оказывается медицинская помощь, а также о лицах, в отношении которых проводятся медицинские экспертизы, медицинские осмотры и медицинские освидетельствования"
касается всех Мед. организаций, но обезличивание происходит автоматически через специальный модуль ЕГИСЗ
·         Поправки федеральный закон от 05.04.2013 N 44-ФЗ "О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд”
при закупке лекарственных препаратов требование публиковать обезличенные решения врачебных комиссий
·         Приказ Росстата от 17.04.2018 N 179 "Об утверждении порядка сбора сведений о населении в электронной форме, определяющего требования к программному обеспечению, техническим средствам, включая носители информации, каналам связи, средствам защиты и форматам представления данных в электронной форме"
требования обезличивать данные переписи населения

Минкомсвязи выдвинул 2 законопроекта:
1.       Изменения в 152-ФЗ: 
a.       добавить обязанность проводить обезличивание в случаях, когда это требуется законодательством РФ (ну это и так вроде очевидно)
b.       всем операторам добавили обязанность разрабатывать правила работы с обезличенными данными, в случае применения обезличивания
раньше такие правила требовались только для гос. органов
2.       Изменения в КОАП РФ
Теперь штрафы для всех операторов и распространяются на физ лиц, должностных лиц и юр. лиц. До 30 тыс.
Заключение:
Начало появляться больше НПА, обязывающие операторов проводить обезличивание ПДн в определенных случаях. Сейчас эти случаи:
·         обезличивать или уничтожать по достижению целей обработки ПДн
·         обработка ПДн в статистических или исследовательских целях
·         обработка ПДн при оказании мед. услуг
·         публикация решений врачебный комиссий при проведении закупок лекарственных препаратов
·         при переписи населения
Скорее всего число таких случаев, где обезличивание требуется в явном виде, будет только увеличиваться. Поэтому очевидно, что за невыполнение требований должно быть предусмотрено хоть какое-то наказание. Так кто ожидаемы поправки в КоАП
Для всех случаев обработки ПДн, операторам нужно будет определять, будет ли в них применяться обезличивание или нет. Если будет то определить способ обезличивания, реализовать автоматизированные механизмы или назначить ответственных лиц, при обезличивании в ручную и действительно внедрить выбранные способы на практике.  
Вероятно, во многих массовых ИС/ГИС (также как в ЕГИСЗ) должны появляться встроенные возможности по обезличиванию данных.

PS: Также рекомендую обзор законопроектов по обезличиванию ПДн от Михаила Емельянникова – рассмотрел проблему с другой стороны

PPS:Нажмите чтобы посмотреть цитаты из НПА и планируемые изменения

пятница, 24 августа 2018 г.

ИБ. Новое положение ФСТЭК о системе сертификации СЗИ


Коллеги, информирую. С 1 августа 2018 года вступило в силу новое Положение о системе сертификации средств защиты информации, утвержденное приказом ФСТЭК России N 55 от 3 апреля 2018 г. 
В основном оно рассчитано на разработчиков СЗИ. Но есть некоторые новые ньюансы, интересные пользователям и лицензиатам:

·         теперь официально разрешено применять СЗИ после окончания срока действия сертификата ФСТЭК (сертификат был, но срок закончился), до того момента пока производитель оказывает техническую поддержку СЗИ или ФСТЭК явно не отзовет сертификат

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

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

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

·         официально прописано что это обязанность заявителя на сертификацию/разработчика - устранение багов, подготовка обновлений ПО, предоставление пользователю обновлений ПО, а также изменений эксплуатационной документации. По сути пользователям разрешено устанавливать обновления, устраняющие уязвимость, до окончания инспекционного контроля со стороны ФСТЭК

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

С этим на самом деле большая проблема - большая часть производителей МЭ не получила сертификаты на соответствие их новым РД ФСТЭК. Например, из анализа Алексея Комарова видно что сейчас есть только 1 ! межсетевой экран уровня хоста. Тут просто монополия.   Также проблема с выбором СЗИ сертифицированных по новым РД, если нам нужен МЭ + СОВ. Выбор очень мал.

А если учесть, что в соответствии с новым Положением, сложность получения производителями сертификатов только возрастет (будет проверятся процесс исправлений и обновлений), то как бы количество сертифицированных СЗИ ещё не уменьшилось.

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


среда, 8 августа 2018 г.

ИБ. Облачные хранилища файлов и документов


Все большее количество организаций используют облачные хранилища для обмена большими документами, файлами или для совместной работы над документом.  Поднимать свой FTP сервере или медиа сервис уже не модно.  Даже в корпоративной среде часто используются google disk, yandex disk, microsoft onedrive. А в малом бизнесе и небольших государственных учреждениях эти облачные сервисы используются повсеместно.

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

Но данный способ поделиться документом влечет за собой серьезные угрозы безопасности. После того как вы отправили ссылку на файл коллегам или партнерам, далее вы теряете контроль над информацией. Эти лица, могут также пересылать ссылку своим друзьям, знакомым, а также публиковать её в соц. сетях, в чатах, на форумах; а могут скопировать файл себе в хранилище и делиться ссылками уже на свою копию файла. Ссылка, попав в общедоступные источники будет проиндексирована поисковиками и информация фактически становится общедоступной.  Также из-за сбоев в работе некоторых сервисов, связанных с поисковыми системами, ссылка может быть проиндексирована, например, из вашей переписки.

Давайте посмотрим на несколько примеров которые выдают нам поисковики

Сравните документы, которые доступны на Google Docs через поисковые системы Yandex и Google: разница в 2000 документов говорит о том, что недавняя шумиха про утечку документов через yandex была не спроста.




Или по другим ключевым словам


Например, можно найти паспортные данные клиентов учебного центра




или планы и архив доставок курьерской службы с фио, телефонами, суммами и заказами


списки детей, зачисленных в детские сады


списки молодых семей, запросивших льготу, с членами семей и информацией о недвижимости


списки учеников, их родителей, с адресами и телефонами

 Сомневаюсь, что в указанных случаях есть законные основания для публикации персональных данных (фактически оператор сделал их общедоступными – доступ по ссылке + публикация или утечка ссылки).


Также повсеместно осуществляется сбор ПДн с использованием google формы, расположенные не в РФ:




ПДн собранные с помощью форм консолидируются в таблицы, к которым также открывают доступ по ссылке для того чтобы работать совместно с коллегами.



Как следствие, нарушение законодательства РФ, утечки ценной информации, недовольство клиентов и т.п.

Что делать?
·         Внимательно оценивайте информацию и документы, которыми планируете поделиться через облачный сервис

·         Собирать ПДн через google формы не рекомендую в любом случае – это нарушает требования законодательства о хранении БД ПДн на территории РФ
·         Если нужно поделиться с коллегами ценной информацией – делайте это не через доступ по ссылке, а открывайте доступ пользователям поименно (в яндекс диске персональный доступ можно давать только для Папок)


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

·         Для владельцев G Suite – запретите возможность делиться файлами с несотрудниками организации или разрешите делится только с пользователями из белого списка доменов (партнеры, постоянные контрагенты).
На главной странице консоли администратора выберите Приложения -> G Suite -> Google Диск и Документы -> Настройки доступа

·         Если у вас крупная компания или гос. орган: сделайте для пользователей инструкцию, какие типы документов можно выкладывать в облачные хранилища и как лучше открывать доступ к таким файлам. Назначьте ответственных за публикацию файлов в интернете (в общий доступ), которые понимают ценность информации и возможность её опубликования. Давайте доступ на публикацию материалов только для этих сотрудников
·         Проведите ревизию ранее опубликованных файлов. В персональном аккаунте, обратите внимание на значок рабочей группы, сигнализирующий что кому-то был предоставлен доступ к файлу (по ссылке или персонально)

·         В корпоративных аккаунтах, от учетки администратора G Suite проверьте файлы переданные доступные не сотрудникам
·         Если обнаружите, что ранее с кем-то делились ценной информацией / персональными данными “по ссылке”, проверьте не доступны ли аналогичные файлы с вашими данными через поисковые системы  



понедельник, 2 июля 2018 г.

КИИ. Категорирование объектов, часть 3


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

3. Определение объектов КИИ
Продолжаем начатое на прошлых этапах (а можно и совместить 1-3) общение с руководителями подразделений. Спрашиваем какие ИС или АСУ обрабатывают информацию, необходимую для обеспечения выявленных критических процессов, и (или) осуществляют управление, контроль или мониторинг критических процессов.
Отдельно в ИТ подразделении получаем полный перечень ИС (он должен был готовится в рамках мероприятий по ПДн) и АСУ, совместно с ИТ выкидываем из перечня ИС, не связанные с критическими процессами (как правило, кадровые, бухгалтерские, отчетность, банк-клиенты).
В результате, того, что данные об ИС и АСУ получены не из одного источника, гарантируется его большая адекватность и актуальность.
(UPDATE) При формировании перечня АСУ, обращайте внимание на определение АСУ, данное в 187-ФЗ. Возможно придется вычеркнуть некоторые АСУ не подходящие под определение. Например, если в составе его нет программных средств, или если это АСУ управляется не технологическим или производственным оборудованием.    
Далее к перечню объектов КИИ необходимо добавить информационно-телекоммуникационные сети. Тут нет особого смысла дробить на маленькие кусочки. Указываем одним пунктом – корпоративная сеть организации. Внешние защищенные сети, такие как Защищенная сеть Минздрава РФ, Защищенная сеть Минздрава КК, Защищенная сеть ТФОМС – не указываем, так как не являемся владельцами данных сетей.

3.а. Получившийся, предварительный, но ещё не утвержденный, перечень объектов КИИ отправляем вышестоящему гос. органу (Минздрав субъекта РФ). По-хорошему, отраслевые регуляторы должны публиковать порядок согласования с ними перечней, но пока такого не замечено. Поэтому просто пишем письмо  
“В соответствии с требованиями пункта 15 Правил категорирования объектов критической информационной инфраструктуры Российской Федерации, утвержденных Постановлением Правительства РФ от 8 февраля 2018 г. № 127 направляем Вам на согласование предварительный перечень объектов критической информационной инфраструктуры нашей организации.”
и прикладываем перечень объектов КИИ.

3.б. Минздрав субъекта РФ, посмотрит не забыли ли вы указать какую-то систему, которую указали коллеги до вас. По-хорошему, они могли бы предложить убрать системы, которые точно не будут критическими. Но в ближайшее время этого делать никто не будет, так как информации недостаточно. И уже озвучиваются вопросы типа “вдруг мы вычеркнем систему, а потом произойдет инцидент и окажется что не надо было её вычеркивать”.

4. Утверждение перечня объектов КИИ
После согласования перечня с отраслевым регулятором, готовим формальный документ с перечнем объектов и отдаем его руководителю на утверждение. Одновременно с ним нужно подготовить письмо на начальника 2 управления ФСТЭК России (копию на руководителя Управления ФСТЭК России по вашему федеральному округу), приложением к которому необходимо приложить перечень объектов КИИ.
И хотя форма перечня объектов КИИ формально не утверждена, но на семинарах, в письмах и заседаниях ФСТЭК России приводит различные “рекомендованные форматы”
например, такой



или такой


Если обобщать, то в целом получается такая форма перечня (примеры объектов КИИ)
Наименование организации
Сфера деятельности
Наименование объекта КИИ
Планируемый срок категорирования
Адрес и контакты организации
ККБ №0
Здравоохранение
ИС:
"Электронная очередь"
"СОЦ-Лаборатория"
"Льготные рецепты"
"М-Аптека"
МИС "Самсон"
"Медкомтех"
"03"
"Экспресс-здоровье"
"Скрининг новорожденных"
"Высокозатратные нозологии"
"Регистр больных сахарным диабетом"
АРМ ПЦ ЛЛО
СК ИПРА
АСУ:
Автоматизированная система оперативного управления диспетчерской службой скорой медицинской помощи
АСУ пожаротушением
АСУ рентген аппаратами
АСУ томографом
АСУ лучевой терапия
ИТС:
Корпоративная сеть ККБ №0
1 января 2019 г.
Руководитель – Иванов И.И.

(861)2790001

г. Краснодар, ул. Красная 1.

Несмотря, на то, что в ПП 127 не установлены сроки на утверждение перечня объектов КИИ, есть решение Коллегии ФСТЭК России от 24.04.2018 №59, в котором озвучены сроки, которые в свою очередь доносятся на заседаниях по защите информации во всех субъектах РФ.

Пример протокола такого заседания можно посмотреть тут.
Срок на утверждение перечня объектов КИИ – до 1 августа 2018 г.
Срок на проведение категорирования объектов КИИ – до 1 января 2019 г.

пятница, 29 июня 2018 г.

ИБ. Как не нужно моделировать угрозы ИБ


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

Зачастую отдельные территориальные органы предъявляют специфические требования к моделям угроз.  И сегодня хотелось бы обсудить такое требование, как указание в модели угроз перечня уязвимостей из БДУ ФСТЭК России.  
Но идею использовать базу уязвимостей из БДУ ФСТЭК при моделировании угроз я встречал не только у регулятора, но и у некоторых продвинутых специалистов операторов. Что в общем не удивительно – раз уж есть база, почему бы её не использовать?

Предлагается использовать уязвимости из БДУ следующим образом: определять перечень используемого в ИС программного обеспечения, а потом выбирать все уязвимости, соответствующие версиям используемого ПО. 

Например, если у нас используется ОС Window 7, то мы должны привести перечень всех 306 уязвимостей, связанных с данной ОС


Если MS office 2007 – ещё 135 
MS Adobe Flash Player 11 – ещё 646.

Таким образом, в достаточно большой ИС, с разным прикладным и системным ПО, мы выберем из БДУ ФСТЭК, например, половину всех уязвимостей. Порядка 9000. И что дальше? Зачем нам эта информация на этапе моделирования угроз? На этапе, когда самой ИС ещё нет, а только формируются требования к ней?
    
Для чего нам вообще моделирование угроз? Для того чтобы на этапе создания системы защиты мы могли выбрать правильные меры и средства защиты. Как нам поможет этот перечень гипотетических уязвимостей, которые могут быть, а могут и не быть в итоговой системе.  Ведь для нейтрализации угроз, связанных с эксплуатацией публично известных уязвимостей, существует всего 2-3 меры:
·         установка патчей и патч-менеджмент
·         виртуальный “патчинг”, для тех случаев, когда мы не можем быстро установить обновление
·         изолирование уязвимого узла на уровне сети

А что если у нас новая версия ПО и в БДУ ФСТЭК на него пока не зарегистрированы уязвимости? Исходя из этого мы можем не включить в нашу систему защиты меры по регулярному обновлению ПО? Нет. Меры по регулярному анализу уязвимостей и установке обновлений ПО и так уже прописаны как обязательные в 17 и 239. Лучше сразу исходить из концепции что в нашем системном и прикладном ПО могут быть уязвимости, просто пока мы не о всех знаем.

Но нам же надо моделировать… от нас требуют анализировать уязвимости при моделировании угроз – скажете Вы.  
Посмотрите, как классифицировались угрозы по типам уязвимостей в базовой модели угроз ФСТЭК от 2008 г. – там нужно было ответить, могут ли у нас быть уязвимости на разных уровнях: в системном ПО, прикладном ПО, сетевых протоколах, СЗИ, наличие аппаратных закладок, технических каналов утечки, недостатки мер защиты. 7 уязвимостей.
Посмотрите в текст угроз из БДУ ФСТЭК, как там описаны уязвимости, которые могут быть использованы при реализации угроз. Это совсем не те уязвимости.
 


Да, они плохо структурированы, они не типизированы, но их хотя бы 200, а не 18000 как в соседней ветке. С 200 уже можно работать.  Но ещё лучше структурировать уязвимости, упомянутые в тексте угроз из БДУ и привести их к 7-30 типам, по которым необходимо будет принять обоснованное решение – могут у нас быть такие уязвимости или нет.

Хотите ещё пример, как можно описывать и классифицировать уязвимости в рамках моделирования угроз? Ну вот хотя бы ГОС ИСО/МЭК 27005-2010 Менеджмент риска ИБ