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



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