среда, 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: Кстати не мешало бы в новых НПА использовать какие-то одинаковые формулировки требований к документации: "документировать" "утверждать"

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

ПДн. Эксплуатация. Перечни ФИО или должностей сотрудников?

Ранее эта проблема уже обсуждалась, но всё ещё остается актуальной. Итак. Статьей 88 ТК РФ, Постановлением правительства №687, Постановлением правительства №1119, Постановлением правительства №211, приказом ФСБ №378 требуется установить и утвердить перечень лиц, допущенных к обработке ПДн.

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

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

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

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

Было интересно, какая существует практика утверждения “перечня лиц” в областях не связанных с ПДн. Беглый просмотр около 100 последних публичных приказов и распоряжений об утверждении “перечня лиц” показал, что в более 90% случаев перечни содержат ФИО (примеры 1, 2, 3) но встречаются и варианты только с должностями (пример 4, 5).  

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



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

А что вы думаете по поводу перечней лиц, ответственных/допущенных к .. ПДн?

среда, 9 августа 2017 г.

ПДн. НПА. Рекомендации Роскомнадзора по составлению политики обработки ПДн

Недавно Роскомнадзор подготовил и опубликовал на сайте Рекомендации по составлению документа, определяющего политику оператора в отношении обработки персональных данных, в порядке, установленном Федеральным законом от 27 июля 2006 года № 152-ФЗ «О персональных данных».


У меня в целом положительное отношение к данным рекомендациям. Объясню почему: зачастую Операторы ПДн относятся к публичной политике ПДн как к типовой декларации на одну страницу – туда попадают какие-то типовые вещи, а все подробности остаются во внутренних документах Оператора. Но пользователю/клиенту этой типовой декларации может быть недостаточно для принятия решения о том, стоит ли пользоваться услугой и насколько она безопасна.

Роскомнадзор порекомендовал указывать в политике некоторые сведения, которые операторы уже обязаны указывать в уведомлении Роскомнадзору. Всё равно эти сведения доступны через реестр операторов ПДн, так зачем заставлять клиента ходить за сведениями на внешние ресурсы, если можно указать это в политики. Роскомнадзор порекомендовал указывать дополнительную информацию о передаче ПДн третьим лицам, которая свидетельствует о том, что оператор соблюдает основные принципы обработки ПДн. Рекомендовали описать регламент взаимодействия с субъектом ПДн и привести в примере формы – это будет полезно клиентам, решившим обратится к Оператору ПДн.

В общем то приведенные рекомендации соответствуют и подходам к политике обработки ПДн, принятым в евросоюзе: пример 1, пример 2.

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

Чтобы немного сгладить последнюю оплошность привожу ниже пример политики обработки ПДн блога (в соответствии с частью 2 статьи 1 152-ФЗ на обработку ПДн физическими лицами для личных нужд не распространяются требования, но мы предположим, что на месте sborisov.blogspot.ru был бы какой-то корпоративный блог) имеющего форму обратной связи (недавняя шумиха с наказанием РКН сайтов, имеющих форму обратной связи, но не имеющих политики ПДн)



Альтернативная ссылка на случай если вариант выше недоступен.

четверг, 13 июля 2017 г.

ИБ. Защита бесконтактных банковских карт и эмуляций

Раз уж от бесконтактных банковских карт (на карте совмещены чип и NFC) не скрыться и добрались они даже до массовых зарплатных проектов, стоит ждать роста количества атак на них (скрытые списания, копирования, клонирования).  Давайте посмотрим какие у нас есть варианты более безопасного использования их:



1.       Экранирующий чехол с защитой RFID / NFC. Но покупать и использовать чехольчик для каждой отдельной карты – неудобно. Скорее уж при обновлении кошелька, выбирать сразу с RFID защитой.  
2.       Задать лимит на списание средств без ПИН-кода? Упс. Тут уже постарались без нас. По РФ действует лимит - до 1000 руб. в сутки можно оплачивать без ПИН. Поменять сумму невозможно
3.       Отключить возможность бесконтактной оплаты, оставив возможность обычной чиповой карты? Упс. Такой возможности нет. Ни со стороны банка, ни со стороны клиента.  
4.       Скопировать свою карту в телефон/смарт часы/браслет/кольцо с поддержкой NFC (в приложение Apple pay, Samsung pay, android pay, microsoft wallet и другое ПО). Выложить все бесконтактные карты дома.
5.       Не забывать про классические меры безопасности с вязанные с банковскими картами (SMS информирование, доверенные получатели, иметь под рукой номер для оперативной блокировки карты, помнить кодовое слово для разблокировки и т.п.)

Далее посмотрим какие варианты есть в случае если все ваши банковские карты сохранены на телефоне:
1.       Экранирующий чехол с защитой RFID / NFC
2.       Вывести кнопку управления беспроводного интерфейса NFC на быстрый доступ. По умолчанию держать выключенным.  При необходимости быстро включать одним нажатием

3.       Отключить возможность проведения платежа пока телефон заблокирован
iOS: Settings -> Touch ID & Passcode -> Allow access when locked: wallet – off
Android Pay и Samsung Pay:  это уже сделано по умолчанию.


4.       Настроить один из вариантов авторизации платежа (Pattern, PIN, or Password)

5.       Включить уведомления о платежах в телефоне. По умолчанию включено.
iOS: Settings -> Wallet & Apple Pay-> Card Notifications
Android:  это уже сделано по умолчанию.
Settings > Applications > Application Manager > Android Pay > Notifications
Samsung Pay -> Settings -> Notifications


6.       Не отдавайте надолго разблокированный телефон. Не допускайте установки вредоносного ПО на мобильное устройство – хотя на нем и хранятся виртуальные токены вместо данных пластиковых карт, но клонирование устройства с виртуальной картой в ряде случаев возможно.


четверг, 22 июня 2017 г.

ИБ. НПА. Изменения в 17 приказе по защите ГИС и согласования



Недавние изменения в 17 приказ ФСТЭК России, были небольшими, но породили множество вопросов. По самым важным я задал вопросы органу гос. контроля. Обещали подобную информацию, разместить в информационном письме на сайте ФСТЭК России, но для самых нетерпеливых привожу ответы здесь …

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



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


3. В соответствии с ч. 5 ст. 19 Федерального Закона от 27 июля 2006 г. "О персональных данных" №152-ФЗ (далее - 152-ФЗ) Федеральные органы исполнительной власти, осуществляющие функции по выработке государственной политики и нормативно-правовому регулированию в установленной сфере деятельности, органы государственной власти субъектов Российской Федерации, Банк России, органы государственных внебюджетных фондов, иные государственные органы в пределах своих полномочий принимают нормативные правовые акты, в которых определяют угрозы безопасности персональных данных, актуальные при обработке персональных данных в информационных системах персональных данных, эксплуатируемых при осуществлении соответствующих видов деятельности, с учетом содержания персональных данных, характера и способов их обработки (т. е. Модели угроз).
В соответствии с ч. 7 ст. 19 152-ФЗ проекты нормативных правовых актов (моделей угроз), указанных в ч. 5 ст. 19 152-ФЗ подлежат согласованию с федеральным органом исполнительной власти, уполномоченным в области обеспечения безопасности, и федеральным органом исполнительной власти, уполномоченным в области противодействия техническим разведкам и технической защиты информации, т.е. с ФСТЭК России.
Прошу уточнить, необходимо ли согласование с ФСТЭК России моделей угроз, разрабатываемых Департаментом информационных технологий, Министерством здравоохранения или иными гос. органами субъектов Российской Федерации и пояснить порядок такого согласования.

В дополнение к 3-ему ответу, сегодня на конференции Будни информационной безопасности в г. Кургане представитель управления ФСТЭК России по УФО анонсировал новый приказ ФСТЭК России №105 от 05 июня 2017 г. в котором определен порядок рассмотрения и согласования моделей угроз и технических заданий на создание ГИС, в частности указывающий отправлять документы по федеральным ГИС в московский ФСТЭК, документы по региональным ГИС и МИС в управления ФСТЭК по федеральным округам.



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

пятница, 16 июня 2017 г.

СКЗИ. НПА. Ещё больше вопросов по применению криптографии

В рамках предыдущей статьи мы определили, что в обеспечении безопасности информации ограниченного доступа с использованием СКЗИ участвуют как минимум 2 лица: ОКЗИ лицензиата ФСБ России и обладатель информации (если он не лицензиат).


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

Естественно, что, когда 2 лица задействованы в одном процессе, хорошо бы распределить их зоны и регламентировать взаимодействие. Для этого и применяется инструкция ФАПСИ №152. В некотором приближении все мероприятия в Инструкции можно разделить на 3 блока:
·         внутренние требования к ОКЗИ (требования, которые лицензиат должен выполнить на своей стороне – помещения, персонал, свои документы)
·         требования, к мерам, которые ОКЗИ должны принять совместно с обладателем КИ на объектах обладателя КИ
·         требования к пользователям СКЗИ

Рекомендую всем ознакомится с Инструкцией и составить свое мнение. Но нам всё-таки показались недостаточно четко расписанными взаимоотношения ОКЗИ и обладателя информации, в связи с чем были написаны вопросы в ФСБ, отправлены по частям, получены ответы, которыми я и хочу поделиться далее. Скорее всего будут полезны для ОКЗИ, но и обладателям информации будет не лишним ознакомится.

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

2. Ещё одна из проблем, с которой мы часто сталкивались – изначально ОКЗИ обслуживает только одно СКЗИ, следует ли из этого автоматически что ОКЗИ отвечает за все СКЗИ у Заказчика? В приказе ФАПСИ 152 недостаточно четко описан этот момент – создается впечатление что как только Лицензиат назначает ОКЗИ для заказчика, ОКЗИ автоматом отвечаем за всё и все СКЗИ. Что не очень логично
Вопрос к ФСБ: В случае если у Покупателя используются различные СКЗИ, например, КриптоПро CSP, АПКШ Континент и Покупатель дополнительно приобретает СКЗИ VipNet HW 1000, может ли ОКЗИ лицензиата ФСБ России обслуживать только часть СКЗИ Покупателя, например только защищенную сеть VipNet и не контролировать иные СКЗИ?
Как следствие, может ли у Покупателя быть одновременно несколько ОКЗИ для разных СКЗИ?
Ответ от ФСБ: Количество ОКЗИ для организации не регламентировано. У покупателя может быть несколько ОКЗИ для разных СКЗИ.   

3. Много раз мы сталкивались с ситуацией, когда изначально были подготовлены корректные документы по ОКЗИ, вся необходимая информация учтена в журналах, пломбы, хранилища, помещения – всё как положено. Но через месяц у заказчика все поменялось, часть документов стали неактуальны, часть мер перестали выполняться. Но каждый день выходить к Заказчику и контролировать чтобы он чего-то не поменял, ОКЗИ не может (либо это обойдется слишком дорого). Лучше раз в квартал, а то и раз в год. Из приказа ФАПСИ 152 непонятно, возможна ли периодическая работа ОКЗИ. Периодичность в приказе нигде не упоминается.
Вопрос к ФСБ: Приказом ФАПСИ №152 требуется контроль соблюдения правил эксплуатации СКЗИ со стороны ОКЗИ. В связи с тем, что представители ОКЗИ не могут постоянно находится на территории Заказчика и не могут контролировать пользователей Заказчика и актуальность документации непрерывно, допускается ли проведение такого контроля с определенной периодичностью, например, раз в неделю, месяц, квартал, год?
Ответ от ФСБ: Периодичность контроля соблюдения Заказчиком правил эксплуатации СКЗИ может устанавливаться ОКЗИ самостоятельно.

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

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


PS: Кстати, кроме Инструкции, много вопросов вызывают также и обязанность по выполнению требований формуляра и эксплуатационной документации на СКЗИ.