понедельник, 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, которые не заставляют пользователей разрабатывать инструкции, но содержит в себе перечень действий в нештатных ситуациях, которые необходимо выполнять.




четверг, 23 ноября 2017 г.

ИТ. Норма ИТ и ИБ специалистов в гос. учреждениях

Несколько коллег недавно просили подсказать какие-то нормы или статистику по РФ, сколько ИТ и ИБ специалистов должно быть в организации на такое-то количество техники. Ниже то что удалось найти (в том числе с вашей помощью), возможно будет полезным.

1.       Из адекватной статистики удалось обнаружить только глобальные цифры:
a.       700 тыс. ИТ специалистов в РФ
b.       2% населения РФ заняты ИКТ
c.       ВУЗами выпускается примерно 7 (семь) ИТ специалистов в год на 10000 чел. населения

2.       Перечень типовых отраслевых (межотраслевых) норм труда, утвержденных нормативными правовыми актами Российской Федерации и СССР 

В этом перечне пропущены некоторые более свежие нормы, например, как эта от Минздравсоцразвития за 2011 г.

Приведенные документы содержат нормы времени на конкретные микро-работы на одну единицу объекта обслуживания, а также периодичность этих работ.
Для того чтобы на основании этих данных рассчитать необходимую численность персонала ИТ, необходимо, во-первых, зафиксировать перечень задач ИТ подразделения, во-вторых определить количество обслуживаемых объектов (АРМ, ОС, серверов, СУБД, ППО, …). Пример расчета можно брать из Постановления Минтруда РФ от 23.07.98 № 28, хотя сами работы там порядком устарели.

3.       На работы по ИБ или ЗИ подобных публичных норм нет. Но у меня в блоге есть пример экспертной оценки количества ИБ специалистов, необходимых в соответствии с законодательством об обработке и защите ПДн (без учета какой-либо автоматизации или оптимизации). Разработанные по аналогии с нормами из 1-ого пункта, исходя из типовых работ, их периодичности и типовых трудозатрат. 

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

5.       РС БР ИББС-2.7-2015 «Ресурсное обеспечение информационной безопасности». Рекомендуется зафиксировать задачи и функции возложенные на службу ИБ, сделать прогноз по расширению перечня задач в соответствии с планами повышения уровня зрелости. Необходимую численность необходимо определять исходя из трудозатрат на выполнение задач, количества процессов СОИБ, количества объектов защиты (филиалов, АБС, работников).  

Из вышеприведенных примеров (1,2,5) видно, что требуемое количество ИТ и ИБ специалистов необходимо рассчитывать в индивидуальном порядке, исходя из задач конкретной организации. И это логично.

Но что, если у нас типовое гос. учреждение, такое как ВУЗ, школа, поликлиника, МФЦ, типовой муниципальный орган.  Задачи и функции ИТ и ИБ в таких учреждениях абсолютно идентичны. Для них можно было бы сделать точные расчеты на уровне РФ или субъекта федерации и распространять такие нормы как рекомендации.

Действительно, подобные расчеты есть, но носят они, к сожалению, кусочный и несистематический характер. Примеры:
6.       Методических рекомендаций по расчету штатных нормативов специалистов по применению в медицинских учреждениях компьютерных информационных технологий. Приказ Министерства здравоохранения РеспубликиТатарстан от 26 ноября 2001 г. N 1095.    
Например, на 100 АРМ – 2,4 программиста и 1,6 электроник. Про ИБ нет.

7.       Постановление правительства Красноярского края от 17 февраля 2017 года N 97-п «Об утверждении нормативов штатной численности краевых государственных учреждений социального обслуживания».
от 0.5 до 4 инженеров-программистов / инженеров по ЗИ в зависимости от количества “коек”

8.       Приказ Министерства образования Московскойобласти от 07 ноября 2011 года № 2866. “Об утверждении типовых штатных расписаний государственных образовательных учреждений начального профессионального и среднего профессионального образования Московской области, подведомственных Министерству образования Московской области”
1 программист при наличии ЛВС, доступа в интернет и сайта. 1 инженер кабинета информатики при наличии более 31 АРМ. Про ИБ нет.



 Хотелось бы подобных методик по РФ либо по всем субъектам РФ. И чтобы про ИБ там было.... 

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

ИБ. Классификация для пользователей ГИС

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

Очевидно, что такие рабочие места необходимо защищать. Но по каким требованиям? То с чем я сталкивался – полный разброд и шатание. Одни защищают такие АРМ как собственную ИСПДн. Другие классифицируют как ГИС причем с уровнем защищенности от К1 до К3. Давайте разберемся какой порядок работы всё-таки правильный и какие сейчас есть сложности с ним.

Во-первых, кто может и должен классифицировать клиентские места ГИС? В соответствии с пунктом 14 приказа ФСТЭК №17 классификацию ГИС осуществляет обладатель информации в ГИС (заказчик ГИС –орган который создает или заказывает ГИС по гос. контракту). Учреждение с клиентским местом не создает ГИС и соответственно не может проводить классификацию.

Во-вторых, может быть клиентские места ГИС вообще не нужно защищать? Нужно. В соответствии с пунктом 4 приказа ФСТЭК №17 “Лицо, обрабатывающее информацию, являющуюся государственным информационным ресурсом, по поручению обладателя информации (заказчика) или оператора .... (далее - уполномоченное лицо), обеспечивает защиту информации в соответствии с законодательством Российской Федерации …”
Как как, как правило разработаны документы (ФЗ, положения, приказы о работе системы) которые предусматривают различных пользователей системы, их обязанности и функции в системе. По сути эти документы и являются поручением.  Но в соответствии с какими требованиями обеспечивать безопасность? В 90% случаев, документация на ГИС, которая передается пользователю не содержит требований по защите информации.   

В-третьих, пункт 4 приказа ФСТЭК №17 и пункт 9 статьи 14 №149-ФЗ говорят, что именно Заказчики ГИС (обладатели информации в ГИС) несут ответственность за защиту информации и именно они должны устанавливать требования по защите информации для уполномоченных лиц.  
Так получается всем пользователям надо запрашивать перечень класс ГИС и требования к защите с владельцев ГИС (готовы к шквалу запросов)? Запрашивали выборочно. Пока что широкий диапазон “мы вообще не включали клиентские места в область защиты” до “у нас для всей системы включая клиентские места один класс – К1”.  Бывает так что предусмотрена классификация для федеральных и региональных серверных сегментов, но про пользовательские места опять забыли.  

В-четвертых, а имеет вообще смысл “парится”? Могут ли у клиентских мест быть классы ГИС отличные от ГИС в целом? Могут. В соответствии с пунктом 14.2 приказа ФСТЭК №17 класс защищенности может определятся для отдельных сегментов (составных частей) ГИС. И это вполне логично, так как значимость информации на отдельном клиентском месте существенно меньше чем на серверах в ЦОД где эти данные консолидированы. Отдельный большой вопрос как определять масштаб для составной части ГИС?

Итого приходим к следующему единственно правильному сценарию:
1.       Владелец ГИС при создании системы предусматривает классификацию сегментов пользователей ГИС
2.       Владелец ГИС разрабатывает (это его обязанность) требования по защите информации для пользователей ГИС
3.       Пользователю ГИС до момента его подключения к системе доводятся требования по защите информации
4.       До подключения, после подключения или периодически во время работы пользователя с ГИС, владелец ГИС запрашивает с пользователя свидетельства того, что требования по защите информации выполняются (так как обеспечения защиты информации - это в первую очередь обязанность владельца ГИС)


Пока по нему не работают ни старые ГИС типа zakupki.gov.ru, ГИС ГМП ни новые, такие как cabinets.fss.ru

пятница, 10 ноября 2017 г.

ИБ. ФСТЭК и уязвимость Intel ME

ИБ сообщество почти не обратило внимания на недавнее информационное сообщение ФСТЭК России об уязвимости Intel Management Engine. А между тем значение оно имеет существенное значение для защиты ГИС и ИСПДн (compliance).

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

 В-третьих, требуется в обязательном порядке обновить микропроцессорное ПО. Но сейчас такое обновление от Intel ещё отсутствует. А если судить по времени реакции конечных вендоров на предыдущуюуязвимость Intel ME, то это может затянуться ещё на + 6 месяцев. Кроме того, такие обновления необходимо устанавливать локально. Что ещё больше увеличит время установки обновления.
На время отсутствия обновления необходимо принять компенсирующие меры, в том числе:
·         Обеспечить защиту физического доступа к ТС
·         Отключить Intel ATM, а это достаточно сложная процедура и не всё будет работать корректно
·         Опечатывание USB и других средств ввода-вывода
·         Настройка изолированной среды на средствах зыщиты от НСД, что довольно трудоемкая и мешающая обычной работе процедура.


С другой стороны, по этой уязвимости много вопросов:
·         В БДУ ФСТЭК России нет информации о затронутых систем, платформ, нет описания, нет степени критичности, нет вектора атаки или другой подробной информации об уязвимости
·         В качестве источника информации об уязвимости приведена ссылка на Хабр, который не является специализированным ресурсом для публикации и долговременного хранения информации об уязвимостях. В любой момент администраторы ресурса могут скрыть статью, убрать в песочницу и т.п.
·         В статье на Хабре также фактически отсутствуют какие то подробности об уязвимости и приводится приглашение на вебинар и анонс того что подробности об уязвимости будут раскрыты на Black Hat Europe.
·         На вебинаре по Intel ME также не было никакой информации об указанной уязвимости, за исключением нескольких подсказок и намеков секции вопросов и ответов.
·         Остается только наедятся на Black Hat. Но ведь доклад там может и не состоятся: отзовут визу, докладчика не выпустят из-за доступа к ГТ, либо из-за неоплаченных штрафов, а ещё докладчик может заболеть.
·         Не подставляется ли ФСТЭК России, публикуя такое серьезное информационное сообщение, не имеющее под собой никаких фактических оснований?  


Из того что пока мне удалось узнать об уязвимости (но это не точно): процессоры Skylake (а такие в продаже в РФ с конца 2015 года), используется технология аппаратной отладки (JTAG) через локальное подключение к USB порту по технологии Intel Direct Connect Interface (DCI)…..

пятница, 6 октября 2017 г.

ПДн. ТОП характеристик обработки ПДн

В предыдущих частях 1 и 2 мы начали рассматривать реестр операторов ПДн. Сегодня продолжим с с рассмотрения наиболее популярных характеристик обработки ПДн сообщаемых операторами.

К сожалению, в реестре не ведется анализ отраслей, к которым относятся операторы ПДн, что не позволяет проводить сравнение со статистикой общего количества организаций, действующих в определенных отраслях. Сопоставление целей, оснований и категорий субъектов ПДн позволяет проводить хотя бы косвенный анализ. Например, что из примерно 100 тыс. образовательных организаций РФ, в реестре зарегистрированы 45-69 тыс.  

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

Цели обработки ПДн


Основания обработки ПДн

Категории субъектов ПДн

Категории ПДн

Выше приведена статистика, так как она есть – что вносили операторы ПДн, без анализа корректности и уместности той или иной информации.

Хотя анализировать там есть что. Например, одни и те же категории собственных работников одни называют “сотрудниками”, другие “работниками”, а третьи – “лицами, состоящими в трудовых отношениях”. При том что в принципе для РКН нет особого смысла собирать информацию о типовой обработке ПДн работников, так как она характерна для 100% операторов ПДн. Зачем тогда такая информация РКН?

Опять же, какой смысл от ТК РФ, 152-ФЗ и уставных документов в основаниях обработки ПДн? Этим и так руководствуются 100% операторов.  Гораздо полезнее было бы, если бы оператор рассказывал про какую-то нестандартную обработку ПДн и указывал что нет никаких оснований кроме договора с клиентом / согласия. В таком случае и клиенту и РКН было бы удобнее – именно в таких случаях можно не давать согласие или отзывать его. Именно в таких случаях встречается передача третьим лицам без согласия.


А там, где обработка в соответствии с ФЗ, должно проходить как нечто типовое и пред заполненное. 

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

ПДн. Нарушители в Реестре операторов ПДн?

В предыдущей части мы начали рассматривать реестр операторов ПДн. Сегодня продолжим с нарушителями законодательства о ПДн, которых можно выявить, едва взглянув на Реестр.

1. В связи с изменениями в № 152-ФЗ, внесенными от 25.07.2011 № 261-ФЗ, каждому оператору необходимо было определить лицо, ответственное за организацию обработки ПДн, принять дополнительные меры, определенные статьей 18.1 152-ФЗ и уведомить РКН о назначенном лице и принятых мерах.

Как видно по результатам анализа, в Реестре имеется 113 931 (на момент анализа) операторов, нарушающих это требование. И далее несколько примеров таких операторов:




 2. В связи с изменениями в № 152-ФЗ, внесенными от 21.07.2014 № 242-ФЗ и в ступившему в силу 1 сентября 2015 г. требовалось перенести все БД в РФ и уведомить Роскомнадзор о местах нахождения БД с ПДн.  

Как видно по результатам анализа, 267 306 (на момент анализа) операторов нарушает это требование и всё ещё не сообщила о месте нахождения БД с ПДн. Не помог даже комментарий РКН о необходимости предоставления этих сведений

глядя на предыдущие примеры, наверное, вы могли подумать, что нарушают требования исключительно небольшие операторы с потенциально низкой квалификацией в ЗПДн? Посмотрим на крупных операторов, располагающихся рядом с РКН

(На момент моего анализа только 7 из 21 федеральных министерств РФ вообще подали Уведомление. МЧС, Минюст, Минкультуры, Минпромторг и другие – где вы? Субъектам ПДн интересно какие ПДн вы обрабатываете …)



Только 2 министерства (Минобороны и Минэнерго) из 7, а также только 49 из 263 федеральных учреждений подали информацию о местонахождении БД с ПДн. Примеры тех кто забыл:



Такая вот получилась занимательная статистика. Далее следует продолжение анализа по характеристикам обработки ПДн … возможно будет полезным 

ПДн. Зачем Реестр операторов ПДн?

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

Я решил исправить этот недочет. Выгрузил пару месяцев назад данные реестра с открытых данных, провел анализ и хочу поделится с вами некоторыми интересными результатами.

1. В текущем виде реестр представляет из себя некую хаотическую массу информации. Вроде поля у всех одинаковые, но каждый может писать в них всё что заблагорассудится, без какой-либо типизации. Плюс со временем менялись рекомендации, но к уже ранее внесенной информации они никак не применялись. В результате имеем не фактически не поддающиеся анализу и сравнению данные
Сравните, например, данные оператора с рег. номером 08-0000106 и 77-17-005506. Они различаются по объему в десятки раз, пользовательская нумерация внутри одного поля, разные символы для разделения логических блоков; по-разному ссылаются на ФЗ и многое другое.  
Не удивительно, что мы давно не видели аналитики от РКН. Реестр в таком виде не подходит для аналитики …

2. Операторы действуют не вечно. Юридическое лицо может быть ликвидировано, поглощено, преобразовано либо прекратить деятельность, связанную с обработкой ПДн. Для этого операторы отправляют письма с просьбой исключить из реестра. В реестре операторов добавляется пометка “исключен”, а все данные остаются на месте J
Ниже статистика “исключенных” операторов. Их 14454



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

1.



2. 




3.




То есть, реестр полон “мертвых душ”. И если говорить в терминах ПДн, возможно тут хранение избыточных данных, когда цели обработки уже достигнуты?

3. Частью 7 статьи 22 152-ФЗ предусмотрена необходимость уведомления РКН при изменении любых сведений, указанных в части 3 статьи 22 (сведений в реестре операторов ПДн). По результатам анализа видно, что большая часть операторов подавали уведомление только раз и не разу не уведомляли РКН об изменениях.
То есть, реестр полон потенциальных нарушителей. Это повод для того чтобы продолжать анализ и разобраться поподробнее. Продолжение следует …


PS: по вопросам методике анализа обращайтесь лично   

вторник, 19 сентября 2017 г.

ПДн. СКЗИ. Перечни, журналы и другие записи в электронной форме

В предыдущей заметке мы обсудили спорные моменты, связанные с ведением “перечней лиц” в ИБ. В комментариях в блоге, facebook высказывались противоположные версии о необходимости ФИО. РКН по всей видимости пока решили никого не трогать, так как есть более значимые, с их точки зрения нарушения.

Взглянем на проблему чуть шире. В обязательных требованиях по ПДн и СКЗИ, помимо необходимости утверждения перечней лиц, есть ещё необходимость сохранения некоторых других свидетельств выполнения требуемых мероприятий: журналов, актов, ...

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

Разработчики же нормативных актов стараются максимально затруднить нам переход в цифровую эпоху: не учитывают нюансы электронного документооборота, используются разные формулировки для требований к документации, что вносит некоторую путаницу и ограничения:  
·         издание оператором документов (152-ФЗ)
·         утверждение руководителем оператора документ (ПП 1119, ПП 211, приказ ФСБ №378)
·         перечень … устанавливается оператором (ПП 687)
·         определить места …, установить перечень .. (ПП 687)
·         утверждение перечня … (приказ ФСБ №378)
·         осуществлять поэкземплярный учет … ведением журнала (приказ ФСБ №378)
·         формирования и утверждения руководителем оператора … (приказ ФСБ №378)
·         разработку … документации / разработку документов .. (приказ ФСТЭК №17)
·         отражаются в документации / вносятся в документацию (приказ ФСТЭК №17)
·         результаты оформляются актом .. (приказ ФСТЭК №17)
·         документирование действий / документирование процедур / документирование результатов (приказ ФСТЭК №17)
·         разработку схемы … схему утверждает (приказ ФАПСИ №152)
·         перечню … утверждаемому обладателем КИ (приказ ФАПСИ №152)
·         заключение, составленное комиссией (приказ ФАПСИ №152)
·         журналы ведут (приказ ФАПСИ №152)
·         правила устанавливает (приказ ФАПСИ №152)

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

Когда упоминается термин “документ”, обычным файлом уже не обойтись. Нужно добавлять реквизиты и вводить систему идентификации электронных документов (электронный документооборот) (ГОСТ Р 7.0.8-2013, №63-ФЗ)

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

Конечно было интересно узнать мнения регуляторов (особенно ФСБ России, которые уже так привыкли к бумажным журналам регистрации) по данному вопросу, поэтому я спросил, допустимо ли вести требуемую документацию в электронной форме? Нужна ли электронная подпись? Если нужна, то какая?
Ответ Минкомсвязи (только суть, общие слова как в предыдущей статье)


Ответ ФСБ России

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



 PS: Кстати не мешало бы в новых НПА использовать какие-то одинаковые формулировки требований к документации: "документировать" "утверждать"