С наступающим Новым годом и Рождеством!

Все пытался сформулировать какие-то пожелания и подвести какие-то персональные итоги, но понял, что в 2016-м уже все написал. Почти все, что я сказал тогда, я могу повторить и сегодня. Поэтому не буду повторяться и просто поздравлю всех читателей с наступающим Новым Годом! Пусть он пройдет у вас под четырьмя "З". Чтобы был у вас ЗАДОР на все ваши идеи и начинания! Чтобы было у вас ЗДОРОВЬЕ на реализацию всех ваших идей и начинаний! Чтобы вы могли ЗАЩИТИТЬ все ваши идеи и начинания! И чтобы при этом у вас всегда находилось время на получение новых ЗНАНИЙ! Ура!

ЗЫ. Вся команда блога (для тех, кто думает, что я его веду не один) уходит на новогодние каникулы и вернется 9-го января :-)

Мой краткий локальный прогноз на год мыши (под коньяк)

В прошлой заметке я описал некие тенденции на поле нормативной брани деятельности, которые я отметил за прошедших 2,5 с половиной года, но совершенно забыл сделать некоторый прогноз на ближайшее время. Исправляюсь...

Я уже не раз признавался, что мне нравится то, как действует ФСТЭК и как она пытается регулировать отрасль ИБ в условиях имеющихся ограничений, сдержек и противовесов. Но в последнее время у меня все меньше поводов для оптимизма :-( При этом регулярно слыша критику в адрес регулятора, я иногда встаю на его защиту, так как вижу немного больше того, что видно снаружи. Вот, например, одно из последних критических замечаний коснулось планируемой методики моделирования угроз, которую, по словам коллег, "ФСТЭК не может уже 4 года принять" (на самом деле даже больше).

И вот в канун Нового года у меня в рамках одного неформального мероприятия, после ряда алкогольных возлияний и вдыхания коньячных паров, у меня состоялась короткая беседа на тему будущего ИБ в России. А о чем еще говорить под бокал коньяка в среде специалистов :-) Хотя началась она забавно.

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

Потом еще долго длилась душещипательная беседа, выводы из которой я попробую кратко сформулировать. В октябре 2015-го года Президент Путин дал ряд поручений по вопросу совершенствования защиты информации, сформулированных в соответствующем непубличном документе Пр-2172. К счастью, далеко не все из них были реализованы (хотя соответствующие законопроекты и были разработаны). Спустя два года, тоже в октябре, но уже 2017-го года, Президент Путин вновь сформулировал ряд поручений по развитию ИБ в России. Их можно выделить 5:

• импортозамещение
• суверенный Интернет
• усиление защиты госорганов
• развитие ГосСОПКА
• международное сотрудничество (но немного не в том смысле, как это понимается обывателем).

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

И, как мне кажется, именно этим объясняется все, что сейчас происходит в отрасли ИБ в России. И импортозапрещение (запретить просто и можно на уровне ФСБ или ФСТЭК, в отличие от развития отечественной отрасли ИТ/ИБ), и "засекречивание" документов ФСТЭК и ФСБ, и усиление требований к иностранным вендорам, и снижение числа контактов с "иностранцами". Иногда это доходит до маразма - достаточно вспомнить пресловутый приказ Миинобразования, жестко ограничивающий контакты ВУЗов и научных организаций с сотрудниками иностранных компаний (правда, потом было устное разъяснение от Минобразования, что приказ можно игнорировать, так как он не зарегистрирован в Минюсте, но кто посмеет ослушаться подписанного министром приказа). У наших отраслевых регуляторов до такого еще не дошло, но определение охлаждение отношений с иностранными вендорами чувствуется :-(

Поэтому регуляторы, возможно, и хотели бы быть более открытыми, динамичными и учитывающими современные тенденции, но увы, они скованы вышестоящими властными структурами и государственными интересами, которые, как известно, отличаются от интересов бизнеса, общества и граждан (я про это уже писал в 2013-м году и позже). Но оправдывать их этим, конечно, можно, но результат мы видим перед глазами и он печален. Тенденции именно таковы, это все не случайно. Поэтому в год мыши вряд ли что-то изменится в лучшую (по моему мнению) сторону. Побуду совсем пессимистом и предположу, что этот курс сохранится как минимум до 2024 года, а если разговоры об объединении России и Беларуси к этому моменту воплотятся в реальность (за чем последует изменение Конституции и обнуление сроков президентства Путина), то этот курс может сохраниться и на последующие 12 лет, до 2036-го года.

Кстати, по поводу маразма. На Медузе была статья пару дней назад о том, что в МИРЭА читается курс по национальной системе информационной безопасности, созданный бывшим преподавателем Высшей школы КГБ.

В рамках этого курса, судя по слайдам в Твиттере, рассказывается о скрепах, духовных войнах, пси-лучах, боевых мемах и т.п.

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

Вот такой апокалиптический прогноз получился в канун Нового года. Остается только надеяться, что это результат коньячных паров и отсутствие солнца в Москве уже на протяжении нескольких недель :-)

ЗЫ. А пока я писал эту заметку наткнулся на две новости - в МИД создан департамент международной информационной безопасности и Генассамблея ООН приняла российскую резолюцию по борьбе с киберпреступностью. Это как раз показывает один из пяти трендов, о которых я написал выше.

Нормативка по ИБ. Что изменилось за 2,5 года?

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

Последний раз я читал его в 2017-м году и сейчас, когда я его обновлял (то еще приключение) по прошествии двух лет, я сделал несколько интересных наблюдений, касающихся нормативного регулирования ИБ в России:

1. Несмотря на то, что ФСТЭК провозгласила своим основным приоритетом защиту информации в госорганах, новых НПА для них почти и не появилось. Есть 17-й приказ и... и все. Куча остальных НПА (приказы 390, 149, 120, 104, 470, 221 и 190 Минкомсвязи, совместный приказ ФСТЭК и ФСБ, приказы Минэкономразвития и ФСО и т.п.) как были, так и остались и никто их не трогал, чтобы привести в соответствие (разве, что есть частные разъяснения Минкомсвязи по поводу своих приказов и их соотнесению с 17-м приказом ФСТЭК). Отчасти это хорошо - госам не надо отслеживать кучу новых и постоянно меняющихся нормативных актов, как тем же финансовым организациям.
2. За два года сильно разрослась ветка регулирования безопасности критической информационной инфраструктуры. Но это и понятно - совершенно новое регулирование, требующее своей нормативной базы.
3. Финансовая сфера оказалась самой зарегулированной. Чуть ли не половина курса (как минимум, его треть) посвящена нормативке Банка России - куча положений и указаний, ГОСТы, СТО и РС. Жалко "банкиров". Когда они успевают с реальными угрозами бороться непонятно :-(
4. По защите ПДн за два года тоже ничего не произошло, кроме косметических правок в 21-й приказ. Зато усиливается карающая сторона законодательства - законопроектов по штрафам появилось не меньше пяти и часть из них уже принята. А вот законопроекты по внесению изменений в ФЗ-152 как-то буксуют. Я уже молчу про "наш" законопроект "Гаттарова-Матвиенко", который мы писали лет пять назад и который должен был помочь разъяснить некоторые неочевидные конструкции законодательства о персональных данных.
5. "Операторский" блок охарактеризовался уходом от направления ИБ в сторону суверенного Интернета - число нормативных актов по этой части в разы превышает число приказов Минкомсвязи именно по защите информации у операторов связи. Но это и понятно в современной геополитической ситуации.
6. Интересно, что наши регуляторы активно нарушают правила принятия обязательных НПА. Я про это еще отдельно напишу в следующем году. Там есть интересные следствия, например, в части требований по сертификации средств защиты информации.
7. Интересно смотреть было на презентации ФСТЭК, где из года в год указываются планы по выпуску различных требований к средствам защиты или методических документов (по защите информации в Wi-Fi, по защите информации на беспроводных устройствах, по ЦОДам и т.п.), но потом эти планы так и не воплощались в жизнь.
8. Кстати, еще одна тенденция - "засекречивание" нормативных актов ФСТЭК и ФСБ. Но если от второго регулятора это видеть привычно (хотя закрытие многих документов НКЦКИ и выглядит странно), то ФСТЭК раньше была более открытой. При этом своей цели такое "засекречивание" не достигает, а вот удобства становится явно меньше.
9. Наконец, интересная ситуация сложилась с ГОСТами по ИБ, которые продвигает Банк России, называя их обязательными к исполнению. Так вот это не так очевидно, как об этом говорит регулятор. Но об этом я тоже напишу отдельно в следующем году.
10. Ужесточилась позиция регуляторов в отношении сертификации средств защиты информации, несмотря на отсутствие нормативных актов, которые бы к этому вели. Ни одного нового Указа, Федерального закона или Постановления Правительства в этой части принято не было, но почему-то отдельные регуляторы стали считать, что они могут требовать обязательной сертификации.

Вот таких десять наблюдений, которые характеризуют изменения нормативного поля ИБ за 2 с лишним последних года. Не буду давать им оценку, - это просто наблюдения. Но объем курса вырос на 250 слайдов и с трудом укладывается теперь в два дня по 8 часов :-)

Стратегия CISO по модели 3-3-4-5

Вот представьте, что сегодня вы едете на работе в лифте, открываются двер, заходит генеральный директор и вдруг, ни с того, ни с сего спрашивает вас: "А какая у вас, мил человек, стратегия по ИБ?" Вы начинаете хватаеть воздух ртом, пытаясь сформулировать за несколько секунд, а какая же у вас стратегия в ИБ и есть ли она вообще? Так вот вам вариант, который я стащил у Рафика Римана и который перевел на русский язык и чуть-чуть подправил.

Рафик назвал ее стратегией 3-3-4-5, так как она состоит из 3 компонентов, каждый из которых состоит из 3, 4 и 5 частей соответственно. Выглядит она следующим образом:

Первый компонент помогает ответить на вопрос: "Чего я хочу достичь?". Вспоминая все, что я уже писал и посмотрев на название блога в шапке, мы ставим на первое место содействие бизнесу, его задачам, целям и приоритетам. На второе место мы ставим более близкое ИБ, но сформулированное на понятном бизнесу языке - управление рисками на приемлемом уровне. Третье место мы отдаем вопросам взаимодействия - справа-налево или с востока на запад, то есть между ИТ, ИБ и бизнесом, и сверху-вниз или с севера на юг, то есть между руководством, CISO и командой ИБ.

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

Любая стратегия должна помогать нам ответить не только на вопрос "Что", но и "Как", поэтому третьим компонентом нашей стратегии ИБ будет "Как я хочу это сделать?". Рафик берет за основу фреймворк NIST Cybersecurity Framework и его пять компонентов (Identify, Protect, Detect, Respond, Recovery). Можно наверное использовать и серию стандартов ISO 2700x, и ISF, и CoBIT, но это уж как кому нравится. NIST CSF на мой взгляд более практичный, более простой и более проработанный инструмент, чем остальные. Увы, но в России фреймворков по ИБ так и не появилось. Ни ГОСТы ЦБ, ни серия приказов ФСТЭК не дотягивают до полноценного фреймворка.

Да ну, фигня, какая-то, - скажите вы. Нам что-нибудь попроще и поконкретнее. Да, пожалуйста. Вот вам чеклист CISO, который я презентовал в январе 2019-го года и который ставил 11 задач, которые можно было решать в течение всего года, тратя на них по одному месяцу (один в резерве). Его можно повторить и в 2020-м году - он не теряет своей актуальности.

В любом случае, теперь, если вы вновь столкнетесь с генеральным в лифте, вы знаете, что ему ответить. Знаете же?

Новая аббревиатура по ИБ - SASE (произносится как "СОСИ")

На последнем SOC Forum, под влиянием просмотра множества выступлений, родилось у меня четверостишье:

SOAR, SIEM, CASB и TIP

ГосСОПКА, ФСТЭК и IRP

Ты сокращенья должен знать

Иди учи их. Не тупи!

Не так давно Gartner порадовал нас новой, столь ласкающей слух русского человека, аббревиатурой - UEBA (User Entity Behavior Analytics) и многие отечественные производители ринулись осваивать новую нишу. И вот новый сюрприз от Gartner - они вводят в обиход новое сокращение - SASE (произносится как "sassy"), расшифровывающееся как Secure Access Service Edge. Однако в данном случае эта аббревиатура врядли станет распространенной в России, так как стоящие за ней технологии малоприменимы в российских реалиях, где государство думает о суверенном Интернете, а регуляторы блокируют применение облачных решений по ИБ. Зато Gartner угадал с русскоязычным произношением этой технологии, которая не будет применяться в России. Но чтобы не заканчивать на этой пессимистичной ноте, я все-таки расскажу что такое SASE и куда движется мысль прогрессивной ИБ.

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

Есть сценарии, когда весь внешний трафик заворачивается на корпоративный периметр, где и контролируется традиционными средствами ИБ - МСЭ, IPS, DLP и т.п. Но работает он далеко не всегда и в какой-то момент начинает мешать бизнес-процессам, который не может мириться со сложностью и задержками, вносимыми ИБ-решениями, неспособными подстроиться под дивный чудный мир без границ. Возникает идея объединить средства сетевой безопасности с сетевыми решениями и вынести их в облако, объединив концепции Network-as-a-Service и Network Security-as-a-Service.

Это и есть концепция SASE, которая объединяет SD-WAN и МСЭ, оптимизацию WAN и CASB, CDN и мониторинг DNS, управление полосой пропускания и SWG (Secure Web Gateway), маршрутизатор и VPN, Zero Trust и удаленную изоляцию браузеров. По сути речь идет о решении класса Secure Internet Gateway или SIG (да-да, еще одна аббревиатура), но наделенного расширенными сетевыми возможностями. Иногда, можно встретить и термин Firewall-as-a-Service, который применялся до очередного творческого порыва Gartner (а может быть будет применяться и после, так как более понятен). Но если посмотреть на картинку ниже становится понятно, почему FWaaS неполно отражает суть SASE - в последней гораздо больше разных защитных функций, чем даже в самых навороченных NGFW или UTM. И все это из облака и прозрачно для пользователя. Удобно.

Чтобы эта схема заработала в полную силу, точки присутствия SASE должны быть размещены по всему миру, ну или, в случае с нами, по всей России. Тогда можно будет говорить о низких задержках и повсеместном защищенном доступе. Учитывая наш телекоммуникационный рынок такое можно развернуть только на площадках нескольких операторов - Ростелеком, Orange и, может быть, у большой тройки мобильных операторов. Либо надо строить решение самостоятельно на базе различных IaaS-провайдеров, что будет непросто. Поэтому Gartner дает сдержанные прогнозы по применению SASE - в 2018-м году только 1% предприятий использовал подход SASE, а спустя 5 лет таких должно стать около 40% (это немного на фоне остальных прогнозов).

Однако если немного дистанцироваться от SASE, то почти все аналитики сходятся во мнении, что будущее сетевой безопасности - это облака, которые дают по сравнению с традиционной моделью сетевой ИБ много преимуществ:

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

Жаль, что в России это будущее пока туманно...

Кибербезопасность "утопающих" дело рук самих "утопающих"

Как-то в Фейсбуке, устав от совершенно дурацкой рекламы, я задался целью настроить показ рекламы таким образом, чтобы получить хоть какую-то пользу. Но результат оказался нулевым -  это как борьба с ветряными мельницами. Зато мне стали показывать мошенническую рекламу, которая крутилась вокруг трех тем:

• "платформа Дурова", которая помогает за день заработать столько, сколько за месяц,
• Сбербанк, который платит деньги за прохождение опросов,
• выплаты от государства "по закону".

Масштаб такого мошенничества в ФБ, конечно, поражает. За три недели под сотню показов и все совершенно разные, но эксплуатирующую вполне конкретную тему - мы поможем быстро заработать или получить много денег.

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

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

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

Эти данные продаются или их можно найти самостоятельно с помощью специализированных поисковиков. Предлагаются даже специальные программы, которые сканируют Интернет и пытаются подбирать пароли к камерам. В данном случае, виноваты в этом сами пользователи, которые забывают поменять заданные на камерах по умолчанию пароли или ставят легко угадываемые пароли. Но можно ли винить их в этом? Лишь отчасти. А вот соцсети могли бы более пристально следить за этим, выявляя группы, каналы и чаты, в которых идет бойкая торговля (и недорого) доступа к камерам и архивам с них. А это прямое вторжение в личную жизнь, что подпадает под действие Уголовного Кодекса. Но с этим никто не борется и правоохранительные органы как-то несильно заморачиваются по этому поводу :-(

А самое неприятное, что не совсем понятно, как взрослые, а именно на 99% являются заинтересованной стороной, узнают, что им надо делать для повышения своей безопасности? Инструкции к купленным камерам на этом акцент не делают. Курсы? Так их нет (почти) и в любом случае еще надо подумать, чтобы на них пойти. Общая культура ИБ в стране? Так ее тоже  нет и регуляторам в целом наплевать на нее (попытка создать Основы госполитики в области формирования культуры в России провалилась).

Наконец, третья тема, которая показывает нежелание или неумение правоохранительных органов бороться с ней - телефонный терроризм. У меня старшего сына на прошлой неделе трижды эвакуировали из школы. Младшую дочь - один раз. И судя по комментариям в Фейсбуке, с этой проблемой сталкиваются многие родители. Да, Минкомсвязь и ЦБ вроде договорились о том, чтобы бороться с подменой CallerID для защиты от мошеннических звонков. Но что делать в случае с телефонным терроризмом? Кто будет защищать детей и их родителей? Вопрос риторический, но напрямую касающийся кибербезопасности.

Если сложить эти три кейса вместе, то получается, что огромный пласт пользователей у нас абсолютно не защищен от современных киберугроз, которых, в условиях цифровой трансформации, становится все больше. Бежать куда-то? Некуда. Заявление направить? Некому, да и результат предсказуем. Самому научиться? Где? Отказаться от Интернет и гаджетов? Уже невозможно. Тупик...

Банк России разъясняет. СПФС, СТО, ФЗ-161 ии др.

Ответы Банка России на оставшиеся разные вопросы, поступившие от отрасли.

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

Ответ: Контроль (мониторинг) использования технических средств защиты информации закреплен п. 2.14.5 действующей редакции положения 382-П за службой информационной безопасности ОПДС и ОУПИ. В отношении СПФС порядок оказания услуг регламентируется Указанием Банка России от 20.09.2019 № 5263-У, а остальные требования защиты определяются Договором на оказание услуг.

2. Необходимо ли в данный момент выполнять требования СТО Банка России? Если нет, то какова процедура отсоединения от данного стандарта? Необходимо ли уведомлять об отсоединении Банк России? Если да, то необходимо ли и дальше присылать результаты оценки соответствия наряду с отчетностью по 382-П и 57580.2?

Ответ: Требования стандартов Банка России носят рекомендательный характер. В связи с принятием Положения Банка России от 17.04.2019 № 683-П «Об установлении обязательных для кредитных организаций требований к обеспечению защиты информации при осуществлении банковской деятельности в целях противодействия осуществлению переводов денежных средств без согласия клиента» требования, установленные национальным стандартом Российской Федерации ГОСТ Р 57580.1-2017 «Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый состав организационных и технических мер», утвержденным приказом Федерального агентства по техническому регулированию и метрологии от 8 августа 2017 года № 822-ст «Об утверждении национального стандарта» (далее - ГОСТ Р 57580.1-2017), являются обязательными.

3. Что понимается под «незамедлительным уведомлением при списании средств» согласно 161-ФЗ и 5039-У? В СТО 1.5, а также в 4926-У говорится о том, что в случае владения незначимыми объектами КИИ уведомление осуществляется в течение 24 часов. Не будет ли направление уведомления в течение 24-х часов рассматриваться как нарушение требования незамедлительности?

Ответ: На основании части 11.1 статьи 9 Федерального закона от 27.06.2011 № 161-ФЗ «О национальной платежной системе» (далее – Федеральный закон № 161-ФЗ) при получении от клиента - юридического лица уведомления, указанного в части 11 статьи 9 Федерального закона № 161-ФЗ, после осуществления списания денежных средств с банковского счета клиента оператор по переводу денежных средств, обслуживающий плательщика, обязан незамедлительно направить оператору по переводу денежных средств, обслуживающему получателя средств, уведомление о приостановлении зачисления денежных средств на банковский счет получателя средств или увеличения остатка электронных денежных средств получателя средств (далее - уведомление о приостановлении) по форме и в порядке, которые установлены нормативным актом Банка России.

Согласно пункту 1 Указания № 5039-У оператор по переводу денежных средств, обслуживающий плательщика, при получении от клиента - юридического лица уведомления об утрате электронного средства платежа и (или) о его использовании без согласия клиента должен незамедлительно направить оператору по переводу денежных средств, обслуживающему получателя, уведомление о приостановлении в виде электронного сообщения, позволяющего воспроизвести его на бумажном носителе.

В соответствии с пунктом 1.4 Указания № 4926-У оператор по переводу денежных средств, обслуживающий плательщика, оператор услуг платежной инфраструктуры - субъекты критической информационной инфраструктуры, которым на праве собственности, аренды или ином законном основании принадлежат значимые объекты критической информационной инфраструктуры, определяемые в соответствии с Федеральным законом от 26 июля 2017 года № 187-ФЗ "О безопасности критической информационной инфраструктуры Российской Федерации", должны направить в Банк России первичное уведомление в течение трех часов с момента наступления событий, указанных в абзацах четвертом и шестом пункта 1.3 Указания № 4926-У, и в течение одного рабочего дня, следующего за днем наступления событий, указанных в абзацах втором, третьем и пятом пункта 1.3 Указания № 4926-У.

Иные операторы по переводу денежных средств, обслуживающие плательщика, операторы услуг платежной инфраструктуры должны направить в Банк России информацию о переводах без согласия клиента по форме первичного уведомления:

• в случаях, указанных в абзацах четвертом и шестом пункта 1.3 Указания № 4926-У, - в течение 24 часов с момента наступления событий, указанных в пункте 1.3 Указания № 4926-У;
• в случаях, указанных в абзацах втором, третьем и пятом пункта 1.3 Указания № 4926-У, - в течение одного рабочего дня, следующего за днем наступления событий, указанных в пункте 1.3 Указания № 4926-У.

Таким образом, в указанных нормах Федерального закона № 161-ФЗ, Указании № 5039-У указано требование о незамедлительном направлении операторами по переводу денежных средств друг другу уведомлений о приостановлении. Сроки, содержащиеся в Указании № 4926-У, относятся к направлению в Банк России уведомлений о случаях и попытках осуществления переводов денежных средств без согласия клиента. Следовательно, указанные сроки не могут рассматриваться в качестве тождественных.

Между тем полагаем, что незамедлительное направление уведомлений о приостановлении означает направление без промедления, при первой возможности. Допустимость направления уведомлений о приостановлении в течение 24 часов будет рассматриваться в каждом конкретном случае, принимая во внимание обстоятельства, характеризующие возможность направления оператором по переводу денежных средств указанных уведомлений.

4. Согласно 161-ФЗ «оператор по переводу денежных средств, обслуживающий плательщика, должен незамедлительно направить оператору по переводу денежных средств, обслуживающему получателя» в случае несанкционированного списания средств. Согласно 5039-У для такого уведомления должна использоваться техническая инфраструктура Банка России, то есть ФинЦЕРТ. Получается, что мы направляем уведомление не оператору, обслуживающему получателя, а Банку России. Не нарушаем ли мы тем самым законодательство?

Ответ: На основании части 11.1 статьи 9 Федерального закона № 161-ФЗ при получении от клиента - юридического лица уведомления, указанного в части 11 статьи 9 Федерального закона № 161-ФЗ, после осуществления списания денежных средств с банковского счета клиента оператор по переводу денежных средств, обслуживающий плательщика, обязан незамедлительно направить оператору по переводу денежных средств, обслуживающему получателя средств, уведомление о приостановлении по форме и в порядке, которые установлены нормативным актом Банка России.

Согласно пункту 3 Указания № 5029-У оператор плательщика, оператор получателя (далее при совместном упоминании - операторы) должны направлять уведомление о приостановлении, уведомление о невозможности приостановления (далее при совместном упоминании - уведомления) с использованием технической инфраструктуры (автоматизированной системы) Банка России, указанной в пункте 1.2 Указания № 4926-У.

Таким образом, уведомления направляются операторами друг другу, техническая инфраструктура (АСОИ ФинЦЕРТ) является каналом взаимодействия.

5. Планируются ли к разработке и, если да, то когда, нормативные акты Банка России, регулирующие вопросы защиты информации в проектах по цифровому профилю, Мастерчейне и финансовом маркетплейсе?

Ответ: Банк России участвует в рассмотрении проектов федеральных законов в сфере инновационных финансовых технологий (например, проект федерального закона № 419059-7 «О цифровых финансовых активах», проект федерального закона № 617867-7 «О совершении сделок с использованием электронной платформы»).

Так, Банком России инициированы изменения в указанные проекты федеральных законов в части требований к защите информации, относящихся к новым видам деятельности некредитных финансовых организаций.

Проект федерального закона № 747513-7 «О внесении изменений в отдельные законодательные акты (в части уточнения процедур идентификации и аутентификации)» (законопроект о «цифровом профиле») содержит вопросы, относящиеся к компетенции уполномоченных органов государственной власти, устанавливающих требования к защите информации в отношении государственных информационных систем.

Банк России разъясняет. 684-П

Ответы Банка России на вопросы по 684-П, поступившие от отрасли.

1. При выполнении банковских операций в кредитной организации должно применяться 683-П. Какое положение должно применяться в кредитных организациях, в отношении депозитарной деятельности и деятельности профессионального участника рынка ценных бумаг? 684-П? Или оно действует только на некредитные или небанковские кредитные организации?

Ответ: В соответствии со статьей 6 Федерального закона от 02.12.1990 № 395-1 «О банках и банковской деятельности» кредитная организация имеет право осуществлять профессиональную деятельность на рынке ценных бумаг в соответствии с федеральными законами.

Согласно статьи 39 Федерального закона от 22.04.1996 № 39-ФЗ «О рынке ценных бумаг» кредитные организации осуществляют профессиональную деятельность на рынке ценных бумаг в порядке, установленном указанным федеральным законом и иными федеральными законами, а также принятыми в соответствии с ними нормативными правовыми актами Российской Федерации для профессиональных участников рынка ценных бумаг.

На основании пункта 1 части 7 статьи 44 Федерального закона от 29.11.2001 № 156-ФЗ «Об инвестиционных фондах» деятельность специализированного депозитария может совмещаться с деятельностью кредитной организации.

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

Таким образом, кредитная организация, осуществляющая деятельность профессионального участника рынка ценных бумаг, а также деятельность специализированного депозитария, должна применять:

• при осуществлении банковской деятельности - Положение Банка России от 17.04.2019 № 683-П «Об установлении обязательных для кредитных организаций требований к обеспечению защиты информации при осуществлении банковской деятельности в целях противодействия осуществлению переводов денежных средств без согласия клиента» (далее – Положение № 683-П);
• при осуществлении профессиональной деятельности на рынке ценных бумаг и деятельности специализированного депозитария - Положение Банка России от 17.04.2019 № 684-П «Об установлении обязательных для некредитных финансовых организаций требований к обеспечению защиты информации при осуществлении деятельности в сфере финансовых рынков в целях противодействия осуществлению незаконных финансовых операций» (далее – Положение № 684-П). 

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

2. Распространяется ли 684-П на ломбарды и микрофинансовые организации? Если да, то какой уровень защиты по ГОСТ 57580.1 должен быть для них выбран? Минимальный? 

Ответ: Ломбарды, микрофинансовые организации не указаны в Положении № 684-П в качестве организаций, реализующих усиленный или стандартный уровни защиты информации в соответствии с национальным стандартом Российской Федерации ГОСТ Р 57580.1-2017 «Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый состав организационных и технических мер», утвержденным приказом Федерального агентства по техническому регулированию и метрологии от 08.08.2017 № 822-ст «Об утверждении национального стандарта» (далее – ГОСТ Р 57580.1-2017).

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

Таким образом, ломбарды, микрофинансовые организации вправе самостоятельно определять реализацию уровней защиты информации в соответствии с ГОСТ Р 57580.1-2017; обязанность реализации уровней защиты информации в соответствии с ГОСТ Р 57580.1-2017 в отношении ломбардов, микрофинансовых организаций Положением № 684-П не установлена.

Осталась последняя порция разъяснений, которые касаются разных аспектов ИБ в финансовых организациях (СПФС, СТО, ФЗ-161 и т.п.).

Банк России разъясняет. ГОСТ 57580.1

Ответы Банка России на вопросы по ГОСТ 57580.1, поступившие от отрасли.

1. Можно ли рассматривать в качестве средства защиты от вредоносного кода межсетевые экраны нового поколения (NGFW), системы обнаружения вторжений или иные схожие средства защиты информации, в которых есть функционал для борьбы с вредоносным кодом, например, для блокирования возможностей взаимодействия с командными серверами, загрузки обновлений, утечки информации и т.п.? 

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

Примечание от меня: неожиданно. ФСТЭК только антивирусы сертифицирует и то, только те, которые поданы на сертификацию, то есть обычно коммерческие решения.

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

Ответ: Примером реализации меры СМЭ.14 может служить организация выделенных VLAN на уровне L2.

3. Возможно, в содержании меры СМЭ.15 вместо фразы «не выше» должно было быть написано «не ниже»? Можно назвать примеры типов средств, которые могут реализовать данную меру? 

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

4. Можно ли в качестве средства реализации меры СМЭ.16 использовать коммутаторы и маршрутизаторы, которые могут фильтровать трафик не только на сетевом уровне?

Ответ: Можно. Все зависит от конкретных средств и задач, и данный вид реализации можно считать частным.

5. По тексту стандарта часто используется термин «межсетевое экранирование». Надо ли его трактовать буквально и для его реализации применять только специализированные межсетевые экраны или возможно применение любых технических средств, которые могут обеспечить разграничение доступа на сетевом уровне? 

Ответ: В ГОСТе не указан тип техники, который обязателен к использованию. Если коммутаторы и маршрутизаторы имеют возможность фильтровать трафик, то их использование допустимо. Возможности применения средства защиты информации подтверждаются сертификацией уполномоченным органом государственной власти (ФСТЭК).

Примечание от меня: опять смена позиции регулятора. При принятии ГОСТа со стороны ЦБ (а также в сентябре) прямо звучало, что сертификация не является обязательной и ее можно заменить компенсирующими мерами (не говоря уже о том, что ГОСТ 57580.1 - это каталог защитных мер, из которых я беру то, что считаю нужным для защищаемой системы в соответствие с принятой системой управления рисками).

6. Можно ли в качестве средства реализации меры СМЭ.2 использовать коммутаторы и маршрутизаторы, которые могут фильтровать трафик на сетевом уровне? Или обязательно использовать только отдельно стоящие межсетевые экраны, что во внутренней коммутируемой сети может быть затруднительно? 

Ответ: В ГОСТе не указан тип техники, который обязателен к использованию. Если коммутаторы и маршрутизаторы имеют возможность фильтровать трафик, то их использование допустимо. Возможности применения средства защиты информации подтверждаются сертификацией уполномоченным органом государственной власти (ФСТЭК).

7. Согласно п.6.4 с учетом экономической целесообразности можно отказаться от каких-либо защитных мер, заменив их компенсирующими мерами. Возможно ли использование решение open source в качестве компенсирующей меры для замены дорогостоящих средств защиты их аналогами?

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

8. Оценка соответствия по ГОСТ 57580.1 для участка АБС, который является также и участком ЕБС, должна проводиться один раз в два года, как написано в 683-П, или один раз в год, как написано в 321-м приказе Минкомсвязи?

Ответ: Проведение оценки соответствия по ГОСТ 57580.1 должно осуществляться ежегодно для сегмента, на котором осуществляется обработка биометрических персональных данных в соответствии с 321 приказом Минкомсвязи. Проведение оценки соответствия не реже одного раза в два года осуществляется по требованиям Положений 683-П и 672-П применительно к соответствующим объектам информационной инфраструктуры (не пересекающихся с участком ЕБС).

Завтра будут ответы по 684-П.

Банк России разъясняет. 672-П

Ответы Банка России на вопросы по 672-П, поступившие от отрасли.

Вопрос № 1. Какая область действия у 672-П? Пункт 2 указывает, что требования распространяются на все средства, применяемые для обработки защищаемой информации, перечисленные в пункте 2.1 382-П, а пункт 2.1 очень обширный, в т.ч. информация ограниченного доступа, подлежащая обязательной защите в соответствии с законодательством. 

Ответ: Положение № 672-П устанавливает требования к защите информации в платежной системе Банка России и распространяется на участников платежной системы Банка России, являющиеся кредитными организациями (их филиалами), имеющими доступ к услугам по переводу денежных средств с использованием распоряжений в электронном виде, предусмотренный пунктом 3.7 Положения Банка России от 06.07.2017 № 595-П «О платежной системе Банка России», а также операционный центр, платежный клиринговый центр другой платежной системы при предоставлении операционных услуг и услуг платежного клиринга при переводе денежных средств с использованием сервиса быстрых платежей.

Требования Положения 672-П распространяются на объекты информационной инфраструктуры, эксплуатация и использование которых обеспечиваются кредитной организацией при осуществлении переводов денежных средств в соответствии с пунктами 3, 4 Положения 672-П. 

Вопрос № 2. Что такое контур формирования электронных сообщений и контур контроля реквизитов электронных сообщений? Как их реализовывать в существующих АБС с учётом того, что все электронные сообщения хранятся в одной базе данных АБС?

Ответ: Контур формирования ЭС – это подсистема (компонент) автоматизированной системы кредитной организации, реализующая формирование исходящего ЭС на основе первичного документа, предназначенного для направления в платежную систему Банка России, его контроль и подписание электронной подписью в соответствии с подпунктом 1.3 пункта 1 приложения к Положению 672-П.

Контур контроля ЭС – это подсистема (компонент) автоматизированной системы кредитной организации, реализующая прием исходящего ЭС из контура формирования, его контроль и подписание электронной подписью в соответствии с подпунктом 1.4 пункта 1 приложения к Положению 672-П.

Техническая реализация указанных подсистем осуществляется кредитной организацией с учетом требований, указанных в подпунктах 1.1 и 1.2 пункта 1 приложения к Положению 672-П.

Вопрос № 3. Какие планируются изменения в отчётности по обеспечению защиты информации 2831-У, с учётом того, что предоставлять отчётность по 2831-У нужно и по соответствию требованиям 382-П и по соответствии требованиям 672-П?

Ответ: Отчетность по 2831-У в соответствии с требованием, указанном в пункте 18 Положения 672-П направляется в части анализа обеспечения в платежной системе Банка России защиты информации при осуществлении переводов денежных средств кредитной организацией, являющейся участником ССНП и СБП. Об изменениях в отчетности 2831-У будет сообщено дополнительно.

Вопрос № 4. С чем связано то, что сроки реализации требований ГОСТ 57580.1 и проведения оценки соответствия ГОСТ 57580.1 разные в 683-П и в 672- П?

Ответ: Это связано с оптимизацией сроков вступления в силу по требованиям Положения 672-П в части реализации технологических мер защиты информации в платежной системе Банка России. В соответствии с Положением 683-П сроки проведения оценки по ГОСТ установлены для кредитных организаций. Положение № 672-П распространяется на иные субъекты, кроме КО (ОЦ, ПЦ).

Вопрос № 5. Нужно ли проводить оценку соответствия требованиям ГОСТ 57580.1 согласно 683-П, 672-П и приказа Минкомсвязи от 25.06.2018 №321 отдельно или можно их совместить для оптимизации расходов? 

Ответ: Оценку соответствия требованиям ГОСТ 57580.1 можно совместить для оптимизации расходов, с учетом покрытия области действия нормативных документов, в рамках которых выполняется оценка.

Вопрос № 6. Кто должен осуществлять анализ защищенности и контроль встраивания СКЗИ для АРМ КБР-Н? Кредитная организация или Банк России? Планируется ли сертификация АРМ КБР-Н по требованиям ФСТЭК? 

Ответ: Контроль встраивания СКЗИ для АРМ-КБР-Н осуществляется Банком России. Сертификация АРМ-КБР-Н по требованиям ФСТЭК не планируется.

Вопрос № 7. 672-П требует исполнения ГОСТ 57580.1, который построен на свободе выбора защитных мер. Также 672-П требует исполнения 382-П, который описывает закрытый перечень защитных мер, которые должны быть обязательно реализованы. Как одновременно реализовывать два набора защитных мер, которые могут отличаться от друг от друга? В чем смысл руководствоваться ГОСТ 57580.1, если все равно необходимо выполнять полный набор защитных мер из 382-П?

Ответ: В соответствии с частью 9 статьи 20 Федерального закона № 161-ФЗ правила платежной системы Банка России определяются нормативными актами Банка России. Таким образом, Положение № 672-П является частью правил платежной системы Банка России.

При проведении оценки соответствия участники платежной системы Банка России должны учитывать не только требования Положения № 382-П, но также особенности, определенные пунктом 20 Положения № 672-П, то есть с применением национального стандарта Российской Федерации ГОСТ Р 57580.2-2018 «Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Методика оценки соответствия», утвержденного приказом Федерального агентства по техническому регулированию и метрологии от 28.03.2018 № 156-ст «Об утверждении национального стандарта» (далее – ГОСТ Р 57580.2-2018).

Участники иных платежных систем проводят оценку соответствия, основываясь на Положении № 382-П.

Вместе с тем необходимо обратить внимание, что кредитные организации независимо от того, участниками какой платежной системы они являются, должны проводить оценку соответствия в соответствии с Положением № 683-П, а именно с учетом ГОСТ Р 57580.2-2018.

Реализация защитных мер в рамках Положения 672-П направлена на защиту информации в платежной системе Банка России. Все требования Положения 382-П входят в состав мер, указанных в ГОСТ 57580.1. Требования по защите информационной инфраструктуры через применение мер ГОСТ 57580.1 планируется реализовать в Положении 382-П.

Вопрос № 8. Помимо прямого исполнения требований 672-П кредитным организациям также необходимо руководствоваться формуляром на СКЗИ «Сигнатура», который требует применения МСЭ, сертифицированного по требованиям ФСБ. Таких решений на рынке практически нет (у части решений сертификаты прекратят действие в ближайшее время и их производители не планируют их продлять). Как выполнить это требование в условиях отсутствия на рынке соответствующих решений? Возможно ли его замена на МСЭ, сертифицированный по требованиям ФСТЭК, как это указано в руководстве по обеспечению ИБ АРМ КБР-Н?

Ответ: В соответствии с формуляром на СКАД «Сигнатура», для передачи информации, поступающей от криптосредства и на криптосредство, допускается использование выходящих за пределы контролируемой зоны каналов связи, относящихся к корпоративной сети и оснащенных межсетевыми экранами, сертифицированными по требованиям ФСБ России не ниже 4 класса защиты для обеспечения конфиденциальности передаваемой информации. В настоящее время в перечень средств защиты информации, сертифицированных ФСБ России, содержится информация об одиннадцати межсетевых экранах, позволяющих выполнить данное требование. 

Примечание от меня: вот тут ЦБ, конечно, постоянно меняет свою позицию :-( Еще в сентябре звучала другая позиция по поводу этих МСЭ. Да и практика региональных проверок тоже местами отличается от данного ответа.

Вопрос № 9. С 01.07.2021 согласно 672-П требуется сертификация СКЗИ. Необходимо ли проводить контроль встраивания СКЗИ на каждый релиз ПО, участвующего в платежной системе Банка России?

Ответ: Требуется уточнение, о каком именно требовании 672-П идет речь. Изменения в 672-П, вступающие в силу с 01.07.2021 в пп. 14.2, 14.3, касаются применения СЗИ, реализующих двухстороннюю аутентификацию и шифрование информации на уровне звена данных или сетевом уровне, прошедших процедуру оценки соответствия требованиям, установленным федеральным органом исполнительной власти в области обеспечения безопасности. Контроль встраивания на уровне звена данных или сетевом уровне производится при установке СЗИ и не зависит от изменений ПО на прикладном уровне.

Завтра будут ответы по ГОСТ 57580.1.

Банк России разъясняет. 683-П

Летом этого года, спустя несколько месяцев после выхода новых положений и указаний Банка России (683-П, 684-П и т.п.), на разных мероприятиях стала формироваться целая волна вопросов по новым нормативным актам, которые оставались безответными, что приводило к тому, что поднадзорные ЦБ финансовые организации не всегда знали, как им поступать. Когда накопилась некая критическая масса, я через канал банковских безопасников в Telegram собрал вопросы и отправил их в Департамент информационной безопасности. И вот, наконец, я получил ответы на все вопросы, которые в течение этой недели и буду публиковать в блоге (не все сразу, так как там очень много). Первая часть будет касаться 683-П.

Но прежде чем публиковать ответы, хочу сказать спасибо руководство ДИБ ЦБ и тем, кто готовил ответы на вопросы отрасли. Такая обратная связь очень нужна и важна!

1. В чем отличия 683-П и 382-П?

Ответ: Предметы регулирования Положения Банка России от 17.04.2019 № 683-П «Об установлении обязательных для кредитных организаций требований к обеспечению защиты информации при осуществлении банковской деятельности в целях противодействия осуществлению переводов денежных средств без согласия клиента» (далее – Положение № 683-П), Положения Банка России от 09.06.2012 № 382-П «О требованиях к обеспечению защиты информации при осуществлении переводов денежных средств и о порядке осуществления Банком России контроля за соблюдением требований к обеспечению защиты информации при осуществлении переводов денежных средств» (далее – Положение № 382-П) разные.

Область применения Положения № 683-П шире области применения Положения № 382-П с точки зрения распространения Положения № 683-П на все банковские операции, связанные с осуществлением перевода денежных средств, и распространения Положения № 382-П только на один вид банковских операций – перевод денежных средств.

В то же время Положение № 382-П устанавливает требования к защите информации не только кредитных организаций, являющихся операторами по переводу денежных средств, но и иных субъектов национальной платежной системы, указанных в части 3 статьи 27 Федерального закона № 161-ФЗ.

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

Примечание от меня: пока готовился ответ ситуация немного поменялась - ЦБ выложил проект новой редакции 382-П (и пояснительная записка), у которого немного иная сфера применения.

2. Положение вводит обязательное для банков требование о «получении от клиента подтверждения совершенной банковской операции», которое не содержит никаких исключений. Однако в настоящее время, в соответствии с правилами международных платежных систем и внутренними политиками банка, операции на суммы меньше 1000 рублей не требуют подтверждения клиентом, к ним относятся операции по оплате покупок через сеть «Интернет», например, электронных книг в litres.ru, а также операции совершаемые с помощью NFC карт, которые могут проводится на POS-терминалах, не оборудованных устройствами для ввода PIN-кода, например в метро и другом городском транспорте. В связи с вышеизложенным просим предоставить разъяснения, следует ли банкам после вступления в силу Положения требовать подтверждения операции клиентом во всех без исключения случаях.

Ответ: Выбор способа получения от клиента подтверждения совершенной банковской операции, предусмотренного абзацем десятым подпункта 5.2.1 Положения № 683-П, осуществляется кредитной организацией в соответствии с принятой в организации политикой управления рисками. Подтверждение совершенной банковской операции может быть получено от клиента любым способом, позволяющим установить, что данное подтверждение предоставляется клиентом. Данные требования распространяются на все банковские операции, регулируемые Положением № 683-П. 

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

Ответ: Согласно пункту 5.2.1 Положения № 683-П технология обработки защищаемой информации, применяемая на технологическом участке, указанном в абзаце четвертом подпункта 5.2 настоящего пункта, дополнительно должна обеспечивать:

• подписание клиентом электронных сообщений способом, указанным в подпункте 5.1 настоящего пункта;
• получение от клиента подтверждения совершенной банковской операции.

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

Таким образом, подписание распоряжение на совершение банковской операции само по себе не является подтверждением совершенной операции. Понятия «распоряжение на совершение банковской операции» и собственно «совершенная банковская операция» разделены.

Выбор способа получения от клиента подтверждения совершенной банковской операции, предусмотренного абзацем десятым подпункта 5.2.1 Положения № 683-П, осуществляется кредитной организацией в соответствии с принятой в организации политикой управления рисками. Подтверждение совершенной банковской операции может быть получено от клиента любым способом, позволяющим установить, что данное подтверждение предоставляется клиентом. Данные требования распространяются на все банковские операции, регулируемые Положением № 683-П. 

4. Подпунктом 5.1 Положения устанавливается требование «обеспечивать подписание электронных сообщений способом, позволяющим обеспечить целостность и подтвердить составление указанного электронного сообщения уполномоченным на это лицом», из этой формулировки следует, что возможно не только исключительное использование усиленной электронной подписи для подписания сообщения, но и использование иных аналогов собственноручной подписи (в т.ч. и иных видов электронной подписи), позволяющих в сочетании с соответствующими программными и техническими средствами обеспечить целостность сообщения и подтвердить факт его составления уполномоченным лицом. В связи с вышеизложенным просим предоставить разъяснения кто и по каким критериям будет принимать решение о соответствии используемого банком способа подписания электронных сообщений требованиям подпункта 5.1 при проведении надзорными подразделениями Банка России проверок в кредитной организации.

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

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

Реализация требований, предусмотренных пунктом 5.1 Положения Банка России № 683-П, возлагается на кредитные организации и определяется ими самостоятельно.

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

5. Просьба разъяснить, соответствует ли по мнению ДИБ Банка России требованиям подпункта 5.1 Положения применяемая в настоящее время технология подтверждения карточных операций путем ввода клиентом PIN-кода карты в терминальном устройстве (банкомате или POS-терминале, в том числе, не поддерживающих EMV стандарт).

Ответ: Выбор способа получения от клиента подтверждения совершенной банковской операции, предусмотренного абзацем десятым подпункта 5.2.1 Положения № 683-П, осуществляется кредитной организацией в соответствии с принятой в организации политикой управления рисками. Подтверждение совершенной банковской операции может быть получено от клиента любым способом, позволяющим установить, что данное подтверждение предоставляется клиентом. Данные требования распространяются на все банковские операции, регулируемые Положением № 683-П. Таким, образом, соответствует.

6. В настоящее время для подтверждения операций, совершаемых с использованием сети «Интернет» широко используется технология, в которой подтверждение клиентом операции осуществляется путем ввода клиентом направленного ему в SMS сообщении одноразового кода, случайным образом сгенерированного банком и однозначно соответствующим подтверждаемой операции. Просьба пояснить, соответствует ли по мнению ДИБ Банка России данная технология требованиям подпункта 5.1 Положения.

Ответ: Да, соответствует.

7. Просьба пояснить, возможно ли по мнению ДИБ Банка России в принципе соответствовать требованиям подпункта 5.1 Положения технология подтверждения операций направляемыми клиенту в SMS сообщении кодами и если да, то при соблюдении каких обязательных условий. 

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

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

Реализация требований, предусмотренных пунктом 5.1 Положения Банка России № 683-П, возлагается на кредитные организации и определяется ими самостоятельно.

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

8. В пункте 5.2.1 на технологическом участке «удостоверения права клиентов распоряжаться денежными средствами» должно быть обеспечено «получение от клиента подтверждения совершенной банковской операции». Что имеется (может иметься) ввиду, например, в случае классического Интернет-банка с усиленной электронной подписью (без использования СМС для подтверждения платежа)?

Ответ: Выбор способа получения от клиента подтверждения совершенной банковской операции, предусмотренного абзацем десятым подпункта 5.2.1 Положения № 683-П, осуществляется кредитной организацией в соответствии с принятой в организации политикой управления рисками. Подтверждение совершенной банковской операции может быть получено от клиента любым способом, позволяющим установить, что данное подтверждение предоставляется клиентом. Данные требования распространяются на все банковские операции, регулируемые Положением № 683-П.

9. Не ведет ли использование рабочих мест сегмента технологического участка сбора биометрических персональных данных для одновременной работы с АБС (вместо выделения отдельных рабочих мест для работы с ЕБС) к распространению требований ГОСТ 57580.1 на весь сегмент АБС? Если да, тогда и оценку соответствия нужно проводить для всего сегмента АБС. 

Ответ: Согласно пункту 3.1 Положения № 683-П кредитные организации должны обеспечить реализацию уровней защиты информации для объектов информационной инфраструктуры, используемых для обработки, передачи, хранения защищаемой информации в целях осуществления банковских операций, определенных национальным стандартом Российской Федерации ГОСТ Р 57580.1-2017 "Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый состав организационных и технических мер", утвержденным приказом Федерального агентства по техническому регулированию и метрологии от 8 августа 2017 года № 822-ст "Об утверждении национального стандарта" (далее - ГОСТ Р 57580.1-2017).

Пунктом 2.1.1 Методических рекомендаций по нейтрализации банками угроз безопасности, актуальных при обработке, включая сбор и хранение, биометрических персональных данных, их проверке и передаче информации о степени их соответствия предоставленным биометрическим персональным данным гражданина Российской Федерации, утв. Банком России 14.02.2019 № 4-МР (далее - Методические рекомендации № 4-МР), банкам рекомендуется размещать объекты информационной инфраструктуры, используемые на технологическом участке сбора, в выделенных (отдельных) сегментах (группах сегментов) вычислительных сетей.

Согласно пункту 2.1.2 Методических рекомендаций № 4-МР для объектов информационной инфраструктуры в пределах сегмента (группы сегментов) вычислительных сетей рекомендуется применять меры защиты информации, реализующие стандартный уровень (уровень 2) защиты информации, определенный ГОСТ Р 57580.1-2017.

Таким образом, объекты информационной инфраструктуры, которые используются в целях осуществления банковских операций, в обязательном порядке должны соответствовать требованиям ГОСТ Р 57580.1-2017.

Относительно требований к автоматизированным системам, используемым в целях сбора биометрических персональных данных для единой биометрической системы, положения Методических рекомендаций № 4-МР носят рекомендательный характер.

10. Какое именно программное обеспечение имеется ввиду в п. 4.1 683-П – «программное обеспечение, обрабатывающее защищаемую информацию на участках, используемых для приема электронных сообщений, к исполнению в автоматизированных системах и приложениях с использованием информационно-телекоммуникационной сети "Интернет"»? Не лишняя ли запятая перед словом «к исполнению" (может имеется ввиду «прием к исполнению»)? 

Ответ: Да, верно, запятая лишняя.

11. Можно ли прямо сейчас проводить этот анализ уязвимостей по ОУД4, или нужно ждать появления методических документов (профиля защиты, если я правильно понимаю) от регулятора? 

Ответ: Да, проводить можно. Банком России завершена разработка методического документа, содержащего профиль защиты, который в настоящее время проходит согласование в ТК122. Рассматривается возможность по увеличению сроков реализации данного требования в связи с разработкой профиля защиты, путем рассылки информационного письма Банка России. 

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

Ответ: В соответствии с пунктом 4.2 Положения № 683-П для проведения анализа уязвимостей в прикладном программном обеспечении автоматизированных систем и приложений кредитные организации должны привлекать организации, имеющие лицензию на осуществление деятельности по технической защите конфиденциальной информации на проведение работ и услуг, предусмотренных подпунктами "б", "д" или "е" пункта 4 Положения о лицензировании деятельности по технической защите конфиденциальной информации, утвержденного постановлением Правительства Российской Федерации от 3 февраля 2012 года N 79 "О лицензировании деятельности по технической защите конфиденциальной информации" (далее – Положение о лицензировании).

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

13. Может ли вендор ДБО проводить анализ уязвимостей своего же софта, если у него имеется лицензия ФСТЭК?

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

14. Специфика АБС в частных обновлениях версий. Доработки выходят еженедельно, масштабные обновления - ежемесячно. Учитывая сроки выполнения процедур сертификации, продукт, прошедший её, давно уже устареет и даже законодательству перестанет соответствовать. Банки пользоваться сертифицированным продуктом физически не будут никогда. С анализом уязвимостей ситуация не легче, да и вряд ли в стране есть достаточно испытательной мощностей для этого. Хоть кто-нибудь эту тупиковую проблему имеет ввиду? 

Ответ: В отношении прикладного программного обеспечения, в которое часто вносятся изменения, целесообразно вместо сертификации проводить анализ уязвимостей. Для оценки анализа уязвимостей необходима лицензия ФСТЭК. Порядок проведения анализа уязвимостей, в том числе сроки и особенности процедур анализа, документами Банка России не регламентирован.

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

Ответ: Сообщаем, что Банком России осуществляется разработка методического документа, содержащего профиль защиты прикладного программного обеспечения автоматизированных систем и приложений кредитных организаций и некредитных финансовых организаций, в целях детализации и уточнения требований к оценочному уровню доверия не ниже ОУД 4 в соответствии с ГОСТ Р ИСО/МЭК 15408-3-2013 «Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 3. Компоненты доверия к безопасности» в части анализа уязвимостей в прикладном программном обеспечении автоматизированных систем и приложений. В данный момент указанный документ проходит публичные слушания в подкомитете №1 Технического комитета №122 и подлежит официальному опубликованию после завершения процедур согласования и утверждения.

16. Достаточно ли отчета о проведенном анализе защищенности, представленным лицензиатом ФСТЭК, в качестве подтверждения проведения анализа защищенности, или требуется еще что-то?

Ответ: Подтверждающим документом о проведенном анализе защищенности, например, может быть сертификат ФСТЭК (в случае проведения анализа по требованиям ФСТЭК) или заключение лицензиата ФСТЭК (в случае проведения анализа по ОУД 4).

17. О чем говорит принципиальная расхождение формулировках 382-П и 683-П (при всей их схожести)? Если 382-П не конкретизирует ПО, которое должно подвергаться подтверждению безопасности, то в 683-П это явно указано. Может быть, Банк России и по 382-П уточнил бы, что нужно не всю АБС сертифицировать/анализировать уязвимости, а только её «транспортный конец», грубо говоря АРМ КБР-Н. Банк России его сертифицировала бы и вся проблема «конца света» 01.01.2020 была бы решена.

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

18. Каковы предполагаемые последствия в случае неисполнение оператором по переводу денежных средств или кредитной организации положений 382-П и 683-П с 01.01.2020? В положениях отсутствуют какие-либо указания на этот счёт, что, видимо, означает, что эти организации должны будут прекратить операции, обеспечиваемые с применением несертифицированного/не прошедшего анализ уязвимостей ПО?

Ответ: Банк России вправе применить меры, предусмотренные статьей 74 Федерального закона № 86-ФЗ, в части выполнения кредитными организациями требований Положения № 683-П.

19. Как вы полагаете, если разработчик АБС получит лицензию ФСТЭК, указанную в положениях, правильно ли будет, если он сам будет выполнять анализ уязвимости собственных продуктов?

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

20. Отчет об отсутствии уязвимостей в ПО, попадающем под соответствующие требования (например, ДБО), требуется на каждый релиз, используемый кредитной организацией?

Ответ: В этом случае анализ уязвимости ПО применяется для всего процесса разработки ПО и не для каждого обновления, а для релизов, которые затрагивают существенные изменения в части функционирования ядра, обеспечения информационной безопасности. И не менее 1 раза в год в соответствии с ГОСТ Р 57580.1-2017 (п 9.7 ЖЦ.20).

21. Есть ли у Банка России рекомендации по тому, как проводить анализ защищенности приложений в условиях Agile-разработки, когда в день кредитная организация выпускает несколько десятков релизов ПО?

Ответ: В этом случае анализ уязвимости ПО применяется для всего процесса разработки ПО и не для каждого обновления, а для релизов, которые затрагивают существенные изменения в части функционирования ядра, обеспечения информационной безопасности. И не менее 1 раза в год в соответствии с ГОСТ Р 57580.1-2017 (п 9.7 ЖЦ.20).

22. Каким образом должно быть организовано подтверждение клиентом уже совершенной операции, требуемое согласно 10-му абзацу п.5.2.1? Первое, что приходит в голову (по тексту требования) обзванивать клиентов и просить их подтвердить, что совершенная операция была действительно инициирована ими, как например происходит, когда срабатывает антифрод. Возможно есть иные способы? 

Ответ: Выбор способа получения от клиента подтверждения совершенной банковской операции, предусмотренного абзацем десятым подпункта 5.2.1 Положения № 683-П, осуществляется кредитной организацией в соответствии с принятой в организации политикой управления рисками. Подтверждение совершенной банковской операции может быть получено от клиента любым способом, позволяющим установить, что данное подтверждение предоставляется клиентом. Способ получения подтверждения, описанный в обращении, не противоречит требованиям абзаца десятого подпункта 5.2.1 Положения № 683-П. В качестве возможного варианта исполнения требований – направление коротких текстовых сообщений с кодом подтверждения.

Завтра будут разъяснения по 672-П.

Обнаружение атак двадцать лет спустя

Почти  двадцать лет спустя я написал свою первую книжку по обнаружению атак, которая, до сих пор используется в учебном процессе ряда ВУЗов. При этом ее часто даже сейчас воспринимают как догму, забывая, что за двадцать лет технологии обнаружения атак сильно поменялись, а возможности решений по обнаружению атак не ограничены только классическими IDSами (хотя регуляторы, присвоив аббревиатуры СОВ и СОА вполне конкретным типам решений, сильно подпортили картину).

В одном из недавних проектов по аудиту SOC я столкнулся с этой проблемой. Заказчик в ТЗ на построение системы защиты указал, что необходимо, среди прочего, построить систему обнаружения атак, а проектировщик не долго думая, просто прописал в проекте кучу сенсоров сетевой системы обнаружения атак и все. В рамках аудита, мы выясняли, причину такого решения, и почему проектант даже имеющийся у заказчика Stealthwatch (решение класса Network Traffic Analytics, NTA) не включил в список технологий обнаружения. Разумеется, все остальные варианты обнаружения вредоносной активности также не были рассмотрены проектироващиком, который почему-то посчитал, что обнаружение атак - это только классические сетевые СОВы (СОА), которые появились в то время, когда основным источником при обнаружении атак был сетевой трафик и, иногда, системные логи.

С тех пор ситуация сильно поменялась и к источникам, по которым можно обнаруживать проявления вредоносной активности, добавилось куча всего другого - файлы, Web-трафик, Netflow (и вообще flow-протоколы), URL, домены, активность пользователя и активность приложений. И это еще не полный перечень.

Другая проблема в обнаружении атак в том, что эти решения обычно ставят на периметра корпоративной или ведомственной сети, в то время как они сегодня давно не ограничены одной площадкой или одним выходом в Интернет. У вас есть внутренняя сеть и куча способов проникновения в нее, минуя периметр. У вас есть Wi-Fi, у вас есть АСУ ТП, у вас есть облака, у вас есть 4G и еще куча точек и отрезков контроля. Обратите внимание, что я специально упомянул не только точки, которые можно контролировать на предмет вредоносной активности, но и отрезки, на которых это можно сделать.

В итоге, если попробовать уйти от устаревшего толкования термина "обнаружение атак" и наполнить его новым смыслом, лучше отражающем реалии современной ИБ, чем далекие от идеала и почти всегда запаздывающие нормативные документы, то у нас получается вот такая матрица, где крестик означает возможность мониторинга чего-то плохого и скрытого в файлах, DNS-запросах, URL, мета-данных Web-трафика, почтовых сообщениях и т.п.

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

Да ну, фигня это все, можете сказать вы. У меня есть МСЭ, СОВ и антивирус, да еще и сертифицированный VPN; зачем мне еще что-то? Они прекрасно справляются со своими задачами. Ну еще WAF куплю в 2020-м. Как вообще вышеприведенную матрицу транслировать в приоритезированный список технологий обнаружения атак, которые надо внедрять в организации? Я бы начал с матрицы MITRE ATT@CK, которая описывает самые распространенные тактики, техники и процедуры киберпреступников. Существует маппинг TTP из нее с источниками данных, позволяющих выявлять плохих парней. Обратите внимание, что на первом месте у нас мониторинг процессов, файлов, параметров командной строки, API, реестра и сетевого трафика. Сетевой трафик вообще на последнем месте в Топ7 источников.

Для упрощения можно посмотреть Топ10 источников данных для мониторинга от Red Canary и посмотреть, что из этого вы мониторите, после чего уже принимать взвешенное решение о том, какие источники данных у вас не охвачены и какие технологии нужны для их охвата.

Тенденции киберугроз (презентация)

Вчера выступал на московском "Код ИБ. Итоги", где сначала модерировал пленарную секцию, а потом выступал в секции "Угрозы" с обзором тенденций по киберугрозам. Выкладываю презентацию с нее.

Тенденции киберугроз. Что необходимо знать? from Aleksey Lukatskiy

Экономика решений по инспекции DNS

Вчера наткнулся на интересное исследование по экономической ценности решений по инспекции DNS, которые пока незаслуженно не нашли своего места в портфолио служб ИБ. Может быть дело в том, что для таких решений нет требований у регуляторов?

А проблема при этом есть. Как обычно работает вредоносный код? Сначала пользователь заманивается на фишинговый ресурс или легальный, но зараженный сайт (например, evil.example.com), откуда скачивается инсталлятор вредоносного ПО, который в свою очередь соединяется с другим сайтом (например, bigevil.example.net) и подгружает с него основной функционал в виде различных модулей, коих может быть много. При этом вредоносный код может коммуницировать с командным сервером, расположенным на третьем сайте, например, cc.example.org.

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

По данным Cisco, 92% всех вредоносов используют DNS как канал для получения обновлений, коммуникаций с командными серверами и т.п. Авторы исследования пошли дальше и проанализировали базу Verizon DBIR за 5 лет, содержащую 11079 подтвержденных взломов.  Оказалось, что в трети из них (в 3668) смогли бы помочь средства инспекции DNS и не допустить совершения инцидента. Дальше авторы попробовали оценить сумму предотвращенных потерь и их результаты показывают, что эта сумма составляет около 10 миллиардов долларов США за 5 лет по известным инцидентам. Если посмотреть на общую картину по киберпреступлениям, то согласно оценкам, в 2018 в мире ущерб от них составил от 445 до 600 миллиардов долларов. Дальше авторы делают очень интересное предположение, что средства инспекции DNS могут помочь бороться с третью всех этих киберпреступлений, то есть они могут спасти от 115 до 200 миллиардов долларов в год.

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

И возвращаясь к теме экономической ценности, которая упомянута в названии отчета. Увы. Отчет про эту тему говорит достаточно мало, приравнивая к эффективности стоимость потенциально предотвращенных потерь в целом по рынку, что далеко от того, что понимается под эффективностью.