понедельник, 3 июня 2019 г.

Замена SMS и PUSH-уведомления при реализации требований 683-П и 684-П ЦБ РФ


Чем же заменить SMS и PUSH-уведомления при реализации кредитными и некредитными финансовыми организациями требований 683-П и 684-П ЦБ РФ?

Рассмотрим в рамках статьи два схожих и наиболее обсуждаемых пункта, опубликованных в один день на прошлой неделе  положений ЦБ РФ - 683-П и 684-П, оба от 17.04.2019.

Полностью эти положения называются так:

683-П: "Об установлении обязательных для кредитных организаций требований к обеспечению защиты информации при осуществлении банковской деятельности в целях противодействия осуществлению переводов денежных средств без согласия клиента".

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

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

Далее по тексту будем пользоваться следующими сокращениями:
  • ЭД – электронный документ
  • ЭП – электронная подпись
  • ПЭП – простая электронная подпись
  • НЭП – неквалифицированная электронная подпись
  • КЭП – квалифицированная электронная подпись
  • НПА – нормативный правовой акт
  • ФЗ – федеральный закон
Рассмотрим наиболее значимые пукнты: в 683-П –  пункт 5.1, а в 684-П – пункт 10. 

683-П: "5.1. Кредитные организации должны обеспечивать подписание электронных сообщений способом, позволяющим обеспечить целостность и подтвердить составление указанного электронного сообщения уполномоченным на это лицом.

Признание электронных сообщений, подписанных электронной подписью, равнозначными документам на бумажном носителе, подписанным собственноручной подписью, должно осуществляться в соответствии со ст. 6, 63-ФЗ "Об электронной подписи".

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

Признание электронных сообщений, подписанных электронной подписью, равнозначными документам на бумажном носителе, подписанным собственноручной подписью, должно осуществляться в соответствии со статьей 6, 63-ФЗ «Об электронной подписи".

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

В настоящее время наибольшее количество дискуссий вызывает первый абзац рассматриваемого пункта. Экспертное сообщество по сути разделилось на два лагеря – одни эксперты говорят, что теперь финансовым организациям вместо использования уже привычных SMS и PUSH-уведомлений необходимо будет в обязательном порядке искать альтернативы, способные обеспечить целостность и авторство отправляемых электронных сообщений. Другие говорят, что можно будет остаться на SMS и PUSH, ограничившись небольшими доработками. Центральный банк пока же воздерживается от официальных комментариев по этому поводу.

Мы же, со своей стороны, не дожидаясь комментариев ЦБ РФ, предположим в нашей статье, что в соответствии с 683/684-П или по каким-то иным причинам, финансовым организациям придется искать альтернативу SMS и PUSH-уведомлениям.

Далее перейдем к анализу второго абзаца. Для этого обратимся к указанной в нем ст.6, 63-ФЗ (рассмотрим только пункты, относящиеся к обсуждаемому вопросу).

"Статья 6. Условия признания электронных документов (далее – ЭД), подписанных ЭП, равнозначными документам на бумажном носителе, подписанным собственноручной подписью
  1. Информация в электронной форме, подписанная КЭП признается ЭД, равнозначным документу на бумажном носителе, подписанному собственноручной подписью, и может применяться в любых правоотношениях в соответствии с законодательством РФ, кроме случая, если ФЗ или принимаемыми в соответствии с ними НПА установлено требование о необходимости составления документа исключительно на бумажном носителе.
  2. Информация в электронной форме, подписанная ПЭП или НЭП, признается ЭД, равнозначным документу на бумажном носителе, подписанному собственноручной подписью, в случаях, установленных ФЗ, принимаемыми в соответствии с ними НПА или соглашением между участниками электронного взаимодействия. НПА и соглашения между участниками электронного взаимодействия, устанавливающие случаи признания ЭД, подписанных НЭП, равнозначными документам на бумажных носителях, подписанным собственноручной подписью, должны предусматривать порядок проверки электронной подписи. НПА и соглашения между участниками электронного взаимодействия, устанавливающие случаи признания ЭД, подписанных ПЭП, равнозначными документам на бумажных носителях, подписанным собственноручной подписью, должны соответствовать требованиям статьи 9 настоящего ФЗ".
Пойдем теперь по цепочке и рассмотрим пункты ст.9, 63-ФЗ, относящиеся к обсуждаемому вопросу:

"Статья 9. Использование ПЭП
  1. ЭД считается подписанным ПЭП при выполнении в том числе одного из следующих условий:
  2. 1) ПЭП содержится в самом ЭД;
    2) ключ ПЭП применяется в соответствии с правилами, установленными оператором ИС, с использованием которой осуществляются создание и (или) отправка ЭД, и в созданном и (или) отправленном ЭД содержится информация, указывающая на лицо, от имени которого был создан и (или) отправлен ЭД.
  3. НПА и (или) соглашения между участниками электронного взаимодействия, устанавливающие случаи признания ЭД, подписанных ПЭП, равнозначными документам на бумажных носителях, подписанным собственноручной подписью, должны предусматривать, в частности:
  4. 1) правила определения лица, подписывающего ЭД, по его ПЭП;
    2) обязанность лица, создающего и (или) использующего ключ ПЭП, соблюдать его конфиденциальность".
И наконец, обратимся к определениям ПЭП, НЭП, КЭП в 63-ФЗ:

ПЭП является ЭП, которая посредством использования кодов, паролей или иных средств подтверждает факт формирования ЭП определенным лицом.

НЭП является ЭП, которая:

1) получена в результате криптографического преобразования информации с использованием ключа ЭП;
2) позволяет определить лицо, подписавшее ЭД;
3) позволяет обнаружить факт внесения изменений в ЭД после момента его подписания;
4) создается с использованием средств ЭП.

КЭП является ЭП, которая соответствует всем признакам НЭП и следующим дополнительным признакам:

1) ключ проверки ЭП указан в квалифицированном сертификате;
2) для создания и проверки ЭП используются средства ЭП, имеющие подтверждение соответствия требованиям, установленным в соответствии с настоящим ФЗ.

Подводя итоги, посмотрим, смогут ли все-таки финансовые организации продолжить использование SMS и PUSH уведомлений (по сути являющихся реализацией ПЭП. Из определения ПЭП и положений ст.9, 63-ФЗ следует, что это маловероятно. Если факт составления указанного электронного сообщения уполномоченным на это лицом (авторство) еще можно как-то доказать, прописав в соответствующих соглашениях, то обеспечить целостность средствами ПЭП без применения криптографических средств, практически невозможно. Даже по определению ПЭП – обеспечение целостности не ее задача.

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

Если же организация захочет замахнуться на КЭП для решения обсуждаемой задачи, то в этом случае ей потребуется либо аккредитовать свой УЦ, либо воспользоваться услугами стороннего коммерческого аккредитованного УЦ для получения квалифицированных сертификатов.

При этом и в случае с НЭП и в случае с КЭП - в качестве технических средств ЭП для решения поставленной задачи можно использовать, например, решение КриптоПро myDSS, которое представляет собой совместную разработку компаний КРИПТО-ПРО и SafeTech на базе программно-аппаратного комплекса облачной электронной подписи (ЭП) КриптоПро DSS и системы подтверждения электронных транзакций PayControl. На данный момент КриптоПро myDSS является единственным на рынке сертифицированным ФСБ решением, способным решить поставленную задачу. Подробнее о решении можно почитать тут.

Ну, и в заключение не очень приятный сюрприз. 683-П и 684-П официально опубликованы 21 мая и оба вступают в силу через 10 дней после опубликования, т.е. 1 июня 2019 года (за исключением некоторых пунктов, к которым п. 5.1 и п.10, соответственно, не относятся). Т.е. принимать соответствующие решения и переходить к реализации требований финансовым организациям формально нужно уже сейчас.

пятница, 17 мая 2019 г.

Ждать ли новый WannaCry через RDP или почему стоит серьезно отнестись к защите от критической уязвимости в RDS?





Суть уязвимости
14 мая 2019 года (ровно через 2 года и 2 дня с момента массового распространения WannaCry) Microsoft сообщила о наличии критической уязвимости CVE-2019-0708 в реализации Remote Desktop Services (RDS – службы удаленного рабочего стола) в Windows, которая позволяет атакующему через протокол RDP удаленно выполнить произвольный код на целевой системе. Уязвимости подвержены старые версии Windows – от Windows XP (Windows Server 2003) до Windows 7 (Windows Server 2008 R2).
Для эксплуатации уязвимости необходим только сетевой доступ к хосту и наличие на нем включенной службы RDS (не заблокированной межсетевым экраном). Т.е. если ваш Windows хост доступен из интернета через RDP, то уязвимость может быть эксплуатирована кем угодно. Уязвимость реализуется за счет отправки специального запроса к RDS через RDP, без аутентификации. После реализации уязвимости атакующий может удаленно выполнить произвольный код на целевой системе с правами SYSTEM.
Microsoft отмечает, что есть весьма высокая вероятность появления автоматических червей, которые будут использовать уязвимость в RDS для распространения в локальных сетях. Вполне возможно, что распространение будет иметь масштабы, близкие к WannaCry.

Как от нее защититься?
Для защиты от уязвимости Microsoft рекомендует временно или на постоянной основе (если RDP не требуется) отключить RDP-доступ к хостам и отключить службу RDS. Кроме этого рекомендуется как можно быстрее установить необходимые обновления безопасности, даже если вы планируете оставить на своих хостах службу RDS отключенной.
Если же отключить на хостах RDP доступ и службу RDS по каким-то причинам нельзя, то до момента установки необходимых обновлений, Microsoft рекомендует:
  • Включить поддержку Network Level Authentication (NLA проверку подлинности на уровне сети – в настройках RDP на хостах). При включенной NLA для реализации уязвимости атакующему сначала нужно аутентифицироваться в службе.
либо
  • Заблокировать внешний доступ по RDP на периметровом FW и отключить проброс RDP порта (TCP 3389) в локальную сеть. Это позволит защитить хосты от эксплуатации уязвимости атакующими из-за пределов внутренней сети, однако хосты по-прежнему останутся уязвимыми из пределов внутренней сети.

Если использование RDP для удаленных подключений нужно и важно для вас и вы не готовы отказаться от него, то для исключения риска реализации уязвимости из-за пределов внутренней сети, RDP-подключения достаточно защитить с помощью средств VPN – и тут отлично подойдет TLS-шлюз удаленного доступа и VPN - КриптоПро NGate. Почитать о нем можно тут и тут
В этом случае:
  1. Отпадает необходимость отключения RDP-доступа и RDS-службы на хостах. При этом пользователи продолжают пользоваться RDP как и раньше;
  2. Не требуется включение поддержки NLA;
  3. Не требуется блокирование внешнего доступа по RDP на периметровом FW и отключение проброса RDP порта в локальную сеть, т.к. использование VPN-шлюза не подразумевает публикацию RDP наружу.
При этом установка обновлений безопасности на хосты потребуется для исключения риска реализации уязвимости из пределов внутренней сети. 

Почему это так важно?
О том, что стоит уделить особое внимание вопросам нейтрализации рассматриваемой уязвимости, свидетельствует, в частности, то, что Microsoft выпустила обновления для всех ОС Windows, подверженных рассматриваемой уязвимости, включая устаревшие и уже не поддерживаемые ОС Windows XP и Windows Server 2003 – это говорит о серьезности найденной уязвимости и высоком риске ее массовой эксплуатации.

вторник, 5 марта 2019 г.

Особенности выбора средств удаленной идентификации в ЕБС




Решил оправдать название своего блога и начать писать не только про КИИ, но и про другие темы по ИБ. Остановимся в этот раз на одном довольно специфическом вопросе, касающемся выбора средств удаленной идентификации клиентов Банков в рамках функционирования Единой Биометрической системы (ЕБС). И Банкам, подключающимся к ЕБС, важно не забыть про этот момент.
Как обычно обратимся сначала за исходными данными к первоисточникам: к 482-ФЗ от 31.12.2017 "О внесении изменений в отдельные зак.акты РФ" и к  Методическим рекомендациям ЦБ по нейтрализации актуальных угроз безопасности при обработке БПДн (4-МР от 14.02.2019), названным с легкой руки некоторых экспертов «Валентинкой». 

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

4-МР:
3.1. В целях обеспечения ИБ на технологическом участке удаленной идентификации клиента банкам (ФЛ) рекомендуется следующее.
3.1.3. Для обеспечения конфиденциальности передаваемой информации при взаимодействии с клиентом рекомендуется применять СКЗИ класса не ниже КС1 на стороне клиента и рекомендуется применять СКЗИ класса не ниже КС3 на стороне банка.
 Из полученных исходных данных делаем простые промежуточные выводы:
  1. Независимо от того, с какого устройства ФЛ собирается провести удаленную идентификацию, оно должно иметь возможность использовать для этого сертифицированное СКЗИ (п.19, 482-ФЗ), причем сертифицированное по классу не ниже КС1, а Банк на своей стороне должен использовать СКЗИ, сертифицированное по классу не ниже КС3 (п. 3.1.3 4-МР).
  2. Если для удаленной идентификации ФЛ использует мобильник, смартфон или планшет, то он обязан (т.е. не имеет право, а именно обязан) использовать СКЗИ, сертифицированное по классу не ниже КС1. Иначе Банк должен будет отказать ему в удаленной идентификации.
  3. Если для удаленной идентификации ФЛ использует иное устройство (например, ПК с браузером) и при этом отказывается от использования сертифицированных СКЗИ, то у ФЛ должна быть возможность (а Банк со своей стороны, соответственно, должен обеспечить для ФЛ такую возможность) использовать несертифицированные СКЗИ (в том числе не ГОСТовые).
Из промежуточных выводов вытекает основной вывод для Банков:
Для обеспечения удаленной идентификации ФЛ на технологическом участке удаленной идентификации Банк обязан одновременно обеспечить на своей стороне поддержку как ГОСТового TLS, так и зарубежного TLS. При этом СКЗИ, реализующее на стороне Банка ГОСТовый TLS, должно быть сертифицировано по классу не ниже КС3. Это в свою очередь накладывает серьезные ограничения на перечень технических средств, удовлетворяющих указанным требованиям и которые можно использовать для решения поставленной задачи. Так, например, одновременная поддержка ГОСТового и не ГОСТового TLS в настоящее время реализована в продуктах КриптоПро и уже даже несколько месяцев обеспечивается при доступе к сайту cryptopro.ru (можно попробовать самостоятельно, предварительно установив на свое устройство КриптоПро CSP 4.0 и, например, Яндекс.Браузер). Новость об этом можно почитать тут. В частности, решение КриптоПро NGate, сертифицированное по классу КС3, способно решить поставленную задачу по идентификации ФЛ с соблюдением всех необходимых требований.

воскресенье, 30 декабря 2018 г.

Проект изменений в 127-ПП "Об утверждении правил категорирования ОКИИ..."



29.12.2018 на публичное обсуждение был выложен проект 01/01/12-18/00087406 "Проект ПП РФ «О внесении изменений в ПП РФ от 8 февраля 2018 г. № 127»".

Обсуждение продлится по 11.01.2019.

Ознакомиться с размещенным проектом, а также высказать по нему свое мнение можно тут.
 

Отразил (пока без анализа) предлагаемые проектом изменения в исходной версии 127-ПП в режиме правки для более удобного изучения и анализа. Посмотреть и скачать получившийся документ можно тут.

вторник, 4 декабря 2018 г.

Все ли Банки являются субъектами КИИ? Большой вопрос!




Банки и банковская сфера в целом имеют особый статус в законодательстве о КИИ. Для этой сферы в законодательстве выделен дополнительный регулятор (ЦБ РФ), существует отраслевой аналог ГосСОПКА (Финцерт), а применимый к Организациям банковской сферы показатель критериев категорирования в 127-ПП распространяется только на определенные Организации.
Неоднократно, с разных трибун представителями ЦБ озвучивалась позиция о том, что все Банки в РФ являются субъектами КИИ без каких-либо дополнительных условий. И это формально следует из определения Субъекта КИИ в 187-ФЗ.
Вот один из последних случаев, когда ЦБ в лице А.М. Сычева была озвучена такая позиция: (SOC-Форум, секция «Диалог с регулятором», смотреть начиная с 1:27:25): https://youtu.be/GCKcGfoZwjI
Но давайте попробуем выстроить логическую цепочку и разобраться - действительно ли все Банки являются субъектами КИИ и соответственно подпадают под действие 187-ФЗ? Опираться будем на мнения ФСТЭК и ЦБ, которые могут расходиться с мнением ФСБ.


В качестве исходных данных рассмотрим следующие утверждения:
  1. По мнению ФСТЭК: Объектами КИИ являются только те ИС/АСУ/ИТКС субъекта, которые подлежат категорированию и попадают в Перечень объектов КИИ, подлежащих категорированию. Остальные ИС/АСУ/ИТКС субъекта объектами КИИ не являются. Писал об этом тут.
  2. По мнению ФСТЭК: Ели Организация функционирует в одной из сфер, указанных в 187-ФЗ, у нее есть ИС/АСУ/ИТС, но нет объектов КИИ, подлежащих категорированию (критические процессы не автоматизированы), то организация тоже не подпадает под определение субъекта КИИ. Писал об этом там же.
  3. Согласно п.5б, 127-ПП критические процессы должны рассматриваться в рамках основной деятельности, в нашем случае банковской. Т.е. остальные процессы, не связанные с иной деятельностью в процессе категорирования не рассматриваются.
  4. Согласно п.5б, 127-ПП процесс становится критическим, если его нарушение может привести к негативным социальным, экономическим,... последствиям. По мнению ФСТЭК: речь идет о соответствующих последствиях, определяемых показателями критериев значимости в 127-ПП. Если указанные в показателях критериев значимости негативные последствия нарушения процесса возможны, то его необходимо считать критическим, даже если по своему масштабу последствия не дотягивают до 3-й категории значимости. Писал об этом тут.
  5. По устно озвученному мнению ЦБ: 10-й показатель экономического критерия значимости 127-ПП, применим не к любому Банку, а только к системно значимой кредитной организации, оператору услуг платежной инфраструктуры системно и (или) социально значимых платежных систем или системно значимой инфраструктурной организацией финансового рынка.


Какие можно сделать выводы на основе приведенных выше исходных данных:
  1. Рассматривая п.4 остается открытым вопрос - необходимо ли считать процесс критическим, если сам показатель, к которому соотносится нарушение процесса, не применим к субъекту? Если ответ «Да», то остальные выводы можно не читать, любой Банк является субъектом КИИ, а по результатам категорирования в перечень объектов КИИ, подлежащих категорирования попадут банковские системы, которые не окажутся значимыми ОКИИ. Если ответ «Нет», то переходим к следующим выводам.
  2. Банк, не подпадающий под п.5, не может иметь критических процессов, нарушение которых может привести к указанным в п.4  последствиям, т.к. ни один процесс в таком Банке даже не подпадает под 10-й показатель (процессы не в рамках банковской деятельности при этом не рассматриваются, согласно п.3).
  3. Значит у такого Банка нет ни одной ИС/АСУ/ИТКС, которая обеспечивает критические процессы, т.к. самих критических процессов нет.
  4. Значит у такого Банка нет ни одной ИС/АСУ/ИТКС, подлежащих категорированию
  5. Значит у такого Банка нет объектов КИИ (согласно п.1)
  6. Значит такой Банк не является субъектом КИИ (согласно п.2)

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