Уральский форум: предварительная отчетность по инцидентам

С отчетность по инцидентам вышла промашка; очередная. Я уже в прошлом году высказывался по поводу того, что мне не совсем понятно, зачем ДНПС собирает 203-ю форму отчетности, если он не публикует никаких ее сводных результатов. А все, что он публикует (о сумма похищенных средств с карт и из ДБО), - это не более чем PR и игра на публику; большого смысла эти цифры не имеют и в деятельности банковских служб ИБ не помогают. Меня мало волнуют как таковые суммы украденных средств - гораздо интересней, как и почему это происходит. Но вот именно эти данные ДНПС и скрывает (или не не знает, как их интерпретировать, или просто так и не обработал за все эти годы).

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

Реальные и предотвращенные хищения в ДБО

Хищения по картам

На вопрос, а как тогда получать информацию о том, где и как злоумышленники чаще всего творят свои темные дела, представители ЦБ отправили всех в FinCERT, который рассылает, если не статистику, то уведомления об атаках злоумышленников. По статистике FinCERT за первые месяцы его работы распределение атак по типам выглядит следующим образом:

Не густо, если учитывать, сколько информации заполняется в 203-й и 258-й формах по инцидентам. Но, видимо, не судьба...

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

Подробнее…

Правительство утвердило дорожную карту по переводу финансовых услуг в электронный вид

Пока США отменяют часть финансовых и ИТ санкций в отношении Крыма, а Минпромторг с Минкомсвязью спорят о том, что считать отечественным оборудованием, Правительство утвердило план ("дорожную карту") с комплексом мер по совершенствованию механизмов электронного взаимодействия на финансовом рынке и по переходу на электронный документооборот всех участников рынка, их клиентов, федеральных органов исполнительной власти и Банка России. Среди целей плана:

• повышение прозрачности и безопасности операций в сфере предоставления розничных финансовых услуг;
• повышение эффективности мер по противодействию легализации (отмыванию) доходов, полученных преступным путем, и финансированию терроризма путем реализации риск-ориентированного подхода к вопросам идентификации.

Согласно проведенному исследованию текущий уровень доверия к безопасности пользователей электронных технологий и сервисов, в долях на финансовом рынке составляет 25%. Задача поднять это значение в 2016-м году до 40%, а в 2018-м - до 60%.

Как же Банк России, Минкомсвязь России, Минфин России, Минэкономразвития России, ФСБ России, МФЦ планируют достичь данных показателей? Дорожная карта предусматривает несколько шагов:

1. Регулирование вопросов, связанных с применением различных видов ЭП на финансовом рынке, в том числе с учетом зарубежного опыта и международных стандартов.
• Неужели признают западные алгоритмы электронной подписи для финансовых транзакций? С учетом планов по оснащению НСПК отечественной криптографии коллизия выглядит интересно.
2. Проведение анализа действующих документов Банка России в области стандартизации, входящих в состав комплекса "Обеспечение информационной безопасности организаций банковской системы Российской Федерации", для определения возможности их использования в качестве основы при проведении работ по стандартизации обеспечения информационной безопасности организаций финансового рынка.
• Анализ уже проведен.
3. Определение направлений работ по разработке новых документов в области стандартизации, отсутствующих в составе комплекса "Обеспечение информационной безопасности организаций банковской системы Российской Федерации", для цели стандартизации обеспечения информационной безопасности организаций финансового рынка
• Эти планы уже озвучены были на ТК122.
4. Разработка и ввод в действие документов Банка России в области стандартизации информационной безопасности организаций финансового рынка, реализуемые по результатам выполнения подпунктов 2 и 3, в том числе разработка проекта стандарта организации "Обеспечение информационной безопасности организаций - участников финансового рынка"
• Тут все понятно - СТО будут на "подведомственные" ФСФР организации распространять.
5. Обеспечение нормативно-правового регулирования защиты информации для участников финансового рынка, адаптированного к их бизнес-процессам (в соответствии с внутренним планом-графиком Банка России)
• План было бы интересно посмотреть, но основные моменты озвучены были в Магнитогорске и на Межотраслевом форуме директоров по ИБ.
6. Разработка механизмов оперативного взаимодействия Банка России, участников финансового рынка, КО, правоохранительных органов в части обмена информацией по направлениям противодействия правонарушениям: определение целей и задач, состава и содержания информации, разработка регламентов оперативного взаимодействия и организация и автоматизация оперативного взаимодействия (в соответствии с внутренним планом-графиком Банка России)
• Это FinCERT, о котором пока достоверно известно мало что, кроме того, что он должен заработать с 1-го июля.

Подробнее…

Новые требования Банка России по защите от вредоносного кода

ЦБ в лице г-на Симановского, первого зампреда Банка России, выпустил новое письмо 49-Т от 24 марта 2014-го года "О рекомендациях по организации применения средств защиты от вредоносного кода при осуществлении банковской деятельности". Если мне не изменяет память, слухи об этом документе ходили достаточно давно (чуть ли не с конца 2012-го года), но тогда он по разным причинам так и не увидел свет. И вот сейчас свершилось - 16 страниц разъяснений тех требований, которым в СТО БР ИББС и 382-П было отведено совсем немного места.

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

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

С технической точки зрения требуется применять:

• терминальный доступ
• анализа защищенности
• контроль состава и целостности ПО и железа
• сегментацию
• инвентаризацию ПО и железа
• резервирование и восстановление из резервных копий
• меры по локализации эпидемий вредоносного кода.

Помимо антивирусов 49-Т требует использования:

• средств контроля использования съемных носителей
• автоматизированных средств обобщения и анализа информации, фиксируемой в журналах протоколирования работы защитного ПО (если я правильно понял эту формулировку, то речь идет о SIEM)
• средств анализа наличия на средствах вычислительной техники и объектах защиты неустраненных недостатков системного и прикладного ПО в части защиты от вредоносного кода (если я правильно понял эту заумную фразу, то авторы хотели прописать сюда сканеры SAST/DAST/IAST).

Хотя есть и нестыковки в 49-Т и 382-П. Например, классический вопрос - сколько разных производителей антивируса должно быть в банке? В п.2.7.3 382-П говорится об использовании средств защиты от вредоносного кода разных производителей при наличии технической возможности. В 49-Т (а надзор будет считать это письмо не рекомендацией, а обязательным документом) такой приписки уже нет - там говорится просто о раздельной установке антивирусов различных производителей (п.2.1.10).

П.2.1.17 меня "убил". Он требует выделить независимый ПК, изолированный от сети, в т.ч. и Интернет, на котором с помощью загрузочного диска будут проверяться все съемные машинные носители информации перед их использованием в банке. Я так себе и представил очередь к этому ПК :-) А писанины по этому письму сколько требуется... Жуть просто. На каждый пункт нужен свой регламент.

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

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

Последний раздел касается требований к провайдерам связи. Тут и SLA, и требование к провайдеру защищать банк от вирусов, и согласование внутренних документов по борьбе с вредоносным кодом с провайдерами, и т.д.

В целом у меня сложилось впечатление (наверное неверное), что 49-Т - это переложение 382-П понятным языком и в контексте борьбы с вредоносным кодом. Учтены почти все 15 разделов 382-го положения; кроме отчетности и криптографии :-)

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

1. Высокоуровневые требования федерального законодательства
2. Требования ведомственных приказов, определяющих "что" надо делать
3. Требования методических документов, определяющих "как" надо делать.

По такому принципу сейчас строятся документы ФСТЭК. Видимо и в ЦБ решили последовать этому примеру.

Интересно, если требования этого документа в полном объеме не выполнить (наряду с другими мелкими огрехами), не станет ли это основанием для отзыва лицензии у банка за невыполнение требований Банка России?.. Кто знает, кто знает...

ЗЫ. Кстати, когда читал документ, с ходу транслировал его требования к решениям Cisco Sourcefire Advanced Malware Protection (AMP). Выполнить можно многое из требуемого на техническом уровне :-)

Подробнее…

Уральский форум. Часть 2. Экономика ИБ или торговля страхом

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

Первый прочитал Павел Головлев, член комитета по банковской безопасности АРБ. Он рассказывал про модели угроз для систем ДБО и систем платежных карт. Взяв за основу статистику Банка России по совокупному объему платежей, числу инцидентов и их сумме, была определена удельная величина риска в системах ДБО. Она составила 1 копейку на 1000 рублей. Иными словами банк теряет 1 копейку на 1000 рублей, пропущенных через ДБО. Для индустрии платежных карт (PCI) эта величина вырастает до 15 копеек на 1000 рублей.

Дальше все просто - достаточно определить сумму транзакций для конкретного банка и вычислить величину риска для него. Сумму транзакций можно примерно определить по той же статистике ЦБ. Вспоминаем цифры, приведенные мной год назад в теме про бессмысленность использования хакерами дыр в приложениях для мобильного банкинга. У Паши в презентации фигурирует валовый объем платежей в 1 триллион рублей. Для такого объема величина риска составит всего 10 миллионов рублей. А если взять только цифры мобильного банкинга (8 миллиардов рублей), то величина риска составляет всего... 80 тысяч рублей. И это на всю отрасль мобильного банкинга. Смешные цифры. И в обозримом будущем ситуация останется такой, что эта тема будет интересна только тем, кто занимается сугубо технической работой, не понимая экономики процесса.

Значит ли это, что хакерам совсем неинтересен мобильный банкинг? Разумеется, нет. На эту тему выступал Дмитрий Волков из Group-IB. Его мастер-класс был посвящен мобильным бот-сетям и нарастающим тенденциям "по ту сторону баррикад". Но Group-IB, не занимаясь непривязанными к реальной безопасности исследованиями, имеет дело с практикой, которую Дмитрий и демонстрировал. По версии Group-IB гораздо проще, чем искать дырки в банковских приложениях, написать троянца для мобильного устройства, который будет просто перехватывать SMS-подтверждения, приходящие на мобильное устройство, скрывать их от владельца смартфона, и передавать владельцу бот-сети, который вручную или в автоматическом режиме сможет давать распоряжения на перевод денежных средств от имени владельца мобильного устройства. Пока такие бот-сети насчитывают не так уж и много устройств, но Group-IB предсказывает рост их числа в ближайшее время.

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

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

Еще один, не самый удачный на мой взгляд, пример приводился в докладе компании Fortinet. Они, по неведомой мне причине, решили представить для банков свои услуги Managed Security Services. Причем совершенно неадаптированные под российский рынок - неаттестованый ЦОД, деятельность без лицензии, ЦОД за пределами России... И это для консервативных банков :-) На вопрос о финансовых гарантиях за взлом подзащитной организации ответа от Fortinet не последовало. И его, наверное, и не могло последовать - массовых случаев финансовых гарантий по облачным услугам и услугам аутсорсинга я что-то не припомню в мировой практике. Без четкого ответа остался вопрос Fprtinet'у и про SLA. Правда, SLA - это не нечто универсальное и для каждого заказчика его показатели могут меняться. Кстати, с SLA возникла интересная ситуация на мастер-классе Лаборатории Касперского. В процессе блиц-сессии вопросов и ответов, выступающие ЛК проговорились, что позиционируют они свой AntiDDoS продукт как сервис, а продают как программное обеспечение, т.е. по модели "as is". Иными словами, никакого SLA у данного "сервиса" нет :-(

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

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

Подробнее…

Кому нужно ломать приложения для мобильного банкинга? Никому!

Не смог не запостить еще и сюда ;-) Идет в LinkedIn дискуссия. Одна из многих. Местами жаркая. Обсуждаем, как водится, технический подход к ИБ и бизнес-подход. Доходит дело до отчета Digital Security о безопасности приложений для мобильного банкинга. И Илья Медведовский делает такое заявление: "Что касается мобилок, то в самих мобильных банкингах масса проблем и их актуальность на практике мне очевидна. Сидя в чужой WiFi сети, делаешь перевод Васе, а деньги уходят Пети и всего делов - и никакой конопли не нужно :). И никакого тут FUDа впомине нет. Потому что мобильный банкинг набирает ход по полной и при этом пока абсолютно дырявый на практике. И надо помочь обратить на это внимание."

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

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

В случае с мобильными клиентами ДБО применимы все три случая. Попробую это показать в цифрах. Во-первых, надо развенчать мнение, что мобильный банкинг - это наше все и у него большое будущее. Как показало исследование рынка ДБО, проведенное AnalyticResearchGroup, мобильный банкинг в России встречается крайне редко. И то преимущественно в крупных городах. В регионах, по мнению специалистов АnalyticResearchGroup, даже кризис не подтолкнул жителей небольших городов к использованию дистанционных банковских услуг; обычных, не говоря уже о мобильных. При этом три четверти россиян не только не пользуются мобильным и интернет-банкингом, но даже не знают о существовании таких услуг. Об этом свидетельствуют результаты опроса, проведенного Фондом «Общественное мнение» (ФОМ). Постоянными пользователями услуг мобильного банкинга является всего 3% россиян. Но это же может быть именно те 3%, которым принадлежат все богатства страны?! Может. Поэтому посмотрим на распространенность мобильного банкинга применительно к объемам денежных средств, которые там циркулируют.

Работающие на российском рынке кредитные организации ориентированы, в большей степени, на корпоративный рынок. Только 30,4% из них используют системы дистанционного обслуживания физических лиц. Системы типа мобильный банк установлены только в 6,8% банков. Почему? Потому, что деньги в мобильном банкинге смешные. Всего 8.1 млрд. рублей в 2012-м году по данным J’son & Partners Consulting. Это все деньги. Из них доля денежных переводов составляет всего 30%. Т.е. на денежные переводы, о перехвате и подмене которых указывается в отчете, как основной угрозе, приходится всего 2.7 млрд.рублей. К слову, объем рынка электронных платежных систем в России в 2012-м году по оценкам J’son & Partners Consulting составляет 1811 млрд.рублей. Т.е. мобильные переводы денежных средств - это всего 0.14%. Ну если взять все платежи через мобильный банкинг (т.е. + оплата услуг и товаров), то получится около 0.45%. Это в рамках статистической погрешности ;-) И не надо забывать, что электронные платежные системы - это тоже копейки в общем объеме денежных переводов.

Я не смог быстро найти в открытом доступе объем банковских платежей, совершенных юридическими лицами с использованием платежных поручений, переданных в банк электронным способом, за 2012-й год. Нашел только за 1-е полугодие 2010 года. Это значение превысило 101 трлн руб. (из них 51 трлн руб. - платежи со счетов, обслуживаемых через системы интернет-банкинга). Я не буду прикидывать, сколько этот объем составлял в 2012-м году. Допустим столько же (хотя по всем оценкам он должен быть больше). Но сделаем допущение, что столько же, т.е. 200 триллионов рублей в год. А дальше посмотрим, какова доля мобильного банкинга на фоне переводов денежных средств юрлицами через системы ДБО. 0.0013%!

Доля мобильного банкинга (а им пользуются только физики) в объеме рынка ДБО для юриков - 0.0013%! И после этого кто-то будет рассказывать о значительной угрозе мобильных приложений? Какой смысл ломать физика через мобильный телефон, когда ломая юрика можно получить на порядок-другой больше денег? Я не понимаю. Только гики будут ломать таким образом физиков со смартфонами, гоняясь за их копейками. "Нормальная" киберпреступность, входящая в состав оргпреступности, будут работать по-крупному - т.е. на рынке ДБО для юридических лиц. И эта тенденция еще долго не будет переломлена.

Т.е. число мобильных платежей будет очевидно расти. И расти оно может быть даже быстрее, чем объемы средств, переводимых через ДБО для юриков. Но беря соотношение денег в обоих сегментах злоумышленнику по всем законам выгоднее ломать юридических лиц. Тем более, что если примут 9-ю статью ФЗ-161 в нынешней редакции и внесут поправки в ГК РФ, то мошенникам даже ломать ничего не надо - достаточно просто заявить в банк, что платеж проведен не по распоряжению клиента и банк должен будет вернуть деньги. И зачем при таком "узаконенном мошенничестве" заниматься поиском дыр и их использованием, получая дополнительные риски по ст.272 УК РФ? Никакого резона.

Вот и получается, что не умаляя технических достоинств отчета Digital Security, даже с точки зрения злоумышленников ломать приложения мобильного банкинга смысла нет. Разумеется в массовом порядке (если взломать конкретного человека, то ему будет очень неприятно). А если это угроза незначительная, то зачем вкладываться в ее нейтрализацию? Этого не будет делать разработчик ДБО (если ему на навяжут эти требования), этого не будет делать банк-покупатель таких решений (бизнес там копеечный и запускается, как правило, ради имиджа, а не заработка).

Резюмируя: с точки зрения технической тема интересная и с ней можно попробовать даже выступить на каком-нибудь Blackhat. С точки зрения бизнеса тема не стоит и выеденного яйца и в ближайшие годы ситуация не изменится. В этом и есть разница в подходах к ИБ с точки зрения технического и бизнес-взглядов.

Подробнее…

Обновление программы курса по защите информации в НПС

Обновил программу курса по НПС. В текущей версии 1.6 добавлены следующие темы:

• Требования ДИС Банка России по защите информации в системах ДБО
• Все нормативные требования по защите информации в системах ДБО (ФСТЭК, ФСБ, Банк России)
• Обновление списка операторов платежных систем
• Список операторов электронных денежных средств
• Планы развития СТО БР ИББС на 2013 год
• Планы развития требования по защите информации в НПС на 2013 год
• Рекомендации НП НПС о порядке использования электронных средств платежа
• Деятельность НП НПС в части уточнения работы с 382-П, 2831-У и ПДн в рамках НПС

Подробнее…

Какие нормативы регулируют защиту ДБО?

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

Сегодня требований по безопасности систем ДБО пруд пруди:

• раздел 7.6 СТО БР ИББС, за который отвечает ГУБиЗИ Банка России
• Положение 382-П, за которое отвечает ДРР Банка России
• упомянутые вчера требования по защите ДБО, разработанные ДИС Банка России вместе с Российской Академией Наук
• требования ФСТЭК по защите персональных данных, т.к. до сих пор так никто ответа и не дал, как же защищать персданные при осуществлении денежных переводов - по 161-ФЗ или по 152-ФЗ
• требования ФСБ по применению СКЗИ, в т.ч. и для ДБО
• рекомендации НП НПС и АРБ по реагированию на инциденты в ДБО
• Письмо 60-Т от 27.04.2007 "Об особенностях обслуживания кредитными организациями клиентов с использованием технологии дистанционного доступа к банковскому счету клиента (включая интернет-банкинг)"
• Письмо 197-Т от 7.12.2007 "О рисках при дистанционном банковском обслуживании"
• Письмо 36-Т от 31.03.2008 "О Рекомендациях по организации управления рисками, возникающими при осуществлении кредитными организациями операций с применением систем интернет-банкинга"
• Письмо 11-Т от 30.01.2009 "О рекомендациях для кредитных организаций по дополнительным мерам информационной безопасности при использовании систем интернет-банкинга"
• Письмо 141-Т от 26.10.2010 "О Рекомендациях по подходам кредитных организаций к выбору провайдеров и взаимодействию с ними при осуществлении дистанционного банковского обслуживания".

Визуально это выглядит так:

Внушительный список. Где-то это обязательные требования, где-то рекомендации. Но вопрос, которым задаются банки, в другом. Почему нет требований к разработчикам АБС и систем ДБО? Почему регулируют только банки? Потому что у них есть деньги? Или потому что у них есть отраслевой регулятор, а у разработчиков ДБО нет?

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

Но ни преступников, ни клиентов особо не трогают, концентрируя весь набор требований на банках. Оно и понятно - проще. Это вам не внесение изменений в Уголовно-процессуальный кодекс. И не написание разъяснений для судей и следователей. И не регулярное их обучение. И не поиск баланс в 9-й статьей ФЗ-161. На все это требуется время и усилия по продвижению изменений. А выпустить требования по защите гораздо проще. Только вот в какой-то момент должно произойти переполнение чаши терпения. И вот тогда я даже не берусь предсказывать, к чему это все может привести...

Подробнее…

Как взломали один банк...

UPDATE : Вопрос частично разрулили. Служба ИБ банка отработала сигнал оперативно. Деньги должны вернуть!

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

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

В упомянутом выше взломе мошенники действовали просто - первую сумму они сняли в 23.59, а вторую в 00.01. Формально требование суточного лимита соблюдено - 23.59 и 00.01 - это два разных дня. Правда идея суточного лимита все-таки относится к астрономическим, а не календарным суткам. Поэтому банкам стоит настраивать свои системы именно на 24-хчасовой интервал межжу транзакциями, а не на на учет календарных суток. А клиентам уточнять при оформлении данной услуги - как банк учитывает сутки, календарно или астрономически?

Дальше больше. Мошенники на двукратном снятии денег не остановились и пошли в соседний банкомат другого банка. И что же? Они с успехом сняли деньги и там, т.к. суточное ограничение на снятие наличных действовало только для собственной банкоматной сети и не было (почему-то) привязано к самому счету. И вновь совет банкам - привязывать суточные лимиты к счету или даже клиенту целиком, а никак не к банкомату или собственной банкоматной сети. Клиентам же стоит также интересоваться, ограничение действует только в "своих" банкоматах или распространяется на все банки без исключения. Причем обе рекомендации легко проверить на практике.

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

Что могу сказать? Все правы и неправы, если посмотреть на упоминаемый мной взлом. Клиенту стоило бы знать, какие вопросы задавать банку при оформлении услуги "суточный лимит". А помочь ему в этом могли бы ролики повышения осведомленности. Но роликов недостаточно. Нужны были разъяснения и требования со стороны регулятора (скорее всего именно ЦБ), как должна была быть реализована данная услуга по суточному лимиту. Простой формулировки как в вышеупомянутой методичке ДИС явно недостаточно. А помимо требований в методику контроля (надзора) должен был быть вставлен соответствующий пункт (что и как проверять). Ну а преступников конечно ловить надо в любом случае. Только вот непросто это в таких кейсах.

Подробнее…

Новая методичка Банка России по безопасности ДБО

Те немногочисленные посетители последней секции вчерашнего Инфофорума, посвященной защите дистанционного банковского обслуживания (ДБО), помнят доклад Андрея Щербакова, советника ДИС Банка России. Он анонсировал методические рекомендации по безопасности ДБО, разработанные ДИСом и Российской Академией Наук. Это было не только ново, но и неожиданно. Раньше ДИС не был замечен в этой области. Да и вопрос компетенции тоже сразу возник; все-таки это скорее тема ГУБиЗИ, чем ДИСа. Но оставим в стороне этот вопрос и посмотрим на сами требования, которые были любезны присланы по моей просьбе.

Разработчики рекомендаций выделяют 9 групп требований:

1. Требования по идентификации и аутентификации клиентов
2. Требования по идентификации и аутентификации клиента и удаленного банка
3. Требования по аутентификации и регистрации операций
4. Требования по защите транзакций
5. Требования к криптографической подсистеме
6. Требования по хранению ключей
7. Требования по безопасности программного окружения
8. Требования к журналам и аудиту
9. Технологические требования. 

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

 
По заявлениям Щербакова данный документ был направлен в 8-й центр ФСБ и получил положительную оценку. Правда, повторюсь, статус этого документа - рекомендации. Судьба тоже пока неочевидна - оно и понятно - они только анонсированы. Если их примут в ГУБиЗИ и ДРР и вставят либо в состав СТО, либо в обновляемое 382-П, либо в готовящийся документ по защите переводов с помощью электронных средств платежа, то будет неплохо. Хотя определенная конкуренция между департаментами внутри ЦБ всегда существовала и существует и это может помешать принять этот документ на вооружение. Посмотрим...

Подробнее…

Что декабрь нам готовит?

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

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

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

К 3-му декабря должно завершиться обсуждение переводов стандарта PCI DSS, подготовленного Банком России вместе с НП АБИСС.

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

Подробнее…

Как ФСБ дураком меня назвала - часть вторая

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

Первое, что меня удивило - это отвечающая сторона. Это Минпромторг. С какого перепугу отвечал мне не аппарат Правительства и не орган исполнительной власти, ответственный в России за персданные (Минкомсвязь), я так и не понял. Но факт остается фактом.

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

Второй интересный вывод приведен в конце письма. Т.к. Интернет-пользователи не являются частью ИСПДн сайта Правительства, то и беспокоиться о защите их ПДн в процессе передачи по Интернет не надо. Логично, правда ведь. Могу теперь представить, как могут рассуждать банки, оказывающие услуги ДБО своим клиентам. Если клиент-физлицо не является частью системы ДБО, то и защищать канал до него не требуется. А значит и СКЗИ покупать не надо. И лицензию ФСБ получать тоже. Бинго!

Подробнее…

Обновление курса по управлению инцидентами

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

Последние внесенные в программу изменения (в первую очередь с ориентацией на участников НПС):

• Нормативные документы, требующие управлять инцидентами СТО БР ИББС, КСИИ, НПС
• Рекомендации АРБ и НП НПС
• Рекомендации Group-IB
• Определение «инцидента» по СовБезу
• Обязательность отчетности об инцидентах
• Обязательность формы отчетности об инцидентах
• Форма отчетности по 2831-У
• Частота отчетности об инцидентах
• Российские CERT
• Жизненный цикл инцидента
• Проект стандарта ISO 27037
• Признаки инцидентов в системах ДБО
• Больше специфики ДБО при расследовании инцидентов
• Визуализация неотложных действий при инциденте в ДБО
• Базы данных инцидентов
• Обновлен раздел о взаимодействии с правоохранительными органами
• Добавлен список ПО для создания копий носителей и сетевого трафика, необходимых для расследований
• Уточнение процедуры расследования инцидента.

Программа стала еще более насыщенной. Как говорили слушатели - огромный объем информации, который не всегда легко воспринимать. Видимо надо рассматривать вопрос о расширении программы на 2 дня. В этом случае планирую добавить в программу темы детального анализа процедура расследования конкретных видов инцидентов - с сетевым оборудованием, с WiFi, с e-mail, с DDoS и т.д.

Подробнее…

Говоря о ДБО, о какой ДБО мы говорим?

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

 Защищая только транзакционную часть мы рискуем все равно попасть на нарушения нормативных требований. Например, по новому ФЗ-161 необходимо уведомлять клиента о каждой транзакции. А если уведомления не было? Кто будет виноват? Правильно, банк. Поэтому защищая ДБО необходимо не забывать по обе составляющие.

 Допустим, не забыли. Но опять, говоря о защите транзакционной ДБО, что конкретно мы имеем ввиду? Защиту Интернет-банкинга? Защиту мобильного банкинга? Возможно. А что насчет телефонного банкинга? У меня в банке, например, реализована система телефонного банкинга через IVR (Interactive Voice Response). Защищен ли доступ к ДБО через этот, не самый распространенный способ дистанционного доступа к своему счету? Был несколько лет назад такой прецедент в России - один крупный банк, столкнувшись с ростом мошенничеств в своей системе Интернет-банкинга, усилил меры защиты. и ввел одноразовые коды подтверждения каждой транзакции. Но только в Интернет - телефонный банкинг был забыт, чем и не преминули воспользоваться злоумышленники.

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

Подробнее…

Требования к разработчикам ДБО

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

Но Россия тут не пионер. Одним из первых к этой теме обратился PCI SSC, который выработал определенные требования к разработке платежных приложений - стандарт PA DSS. Правда, подпадают под него далеко не все приложения, которые обрабатывают финансовые потоки. В т.ч. под него спокойно могут не попасть многие системы ДБО, особенно для юридических лиц, т.к. они не обрабатывают данные платежных карт. Но как основа для формирования собственных требований данный стандарт подходит достаочно неплохо.

Еще один интересный документ был опубликован совсем недавно - в январе этого года. Речь идет о Software Assurance Framework от BITS - подразделения по разработке технологических политик Financial Services Roundtable. Этот 53-хстраничный документ, который описывает целую программу защищенной разработки ПО для финансовых институтов. 8 частей этого документа охватывают все необходимые темы при разработке защищенных приложений:

• Обучение и тренинги разработчиков
• SDLC. Тема SDLC становится достаточно популярной в последнее время. И я про нее писал в блоге и в отдельной статье в "ИТ Менеджере". Эта же тема освещается и на специализированной конференции в России - SECR.
• Моделирование угроз. BITS упоминает Microsoft STRIDE, хотя таких стандартов и рекомендаций существует десятки (я их рассматриваю в курсе по моделированию угроз). И писал про это недавно.
• Лучшие практики программирования. Интересно, что BITS не выдумывает ничего своего, а отсылает к уже существующим практикам - OWASP Secure Coding Practices Guide, Department of Homeland Security Build Security In Portal, CERT Secure Coding, MSDN Security Developer Center и т.д.
• Тестирование безопасности. Этот кусок очень неплохо расписан - упомянуты различные программные продукты, виды анализа кода и т.д.
• Практика предварительного внедрения
• Документирование. Раздел подробно описывает, какие документы должны сопровождать разработку и тестирование программного обеспечения.
• Контроль пост-внедрения.

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

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

Подробнее…

Магнитогорские впечатления (часть 3)

Продолжаем...

Дистанционное банковское обслуживание

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

Артем Сычев (Россельхозбанк) начал с того, что привел цифры. Средняя сумма покушения составляет около 400 тысяч рублей (для юриков). Стоимость же организации самой атаки - всего 30 тысяч рублей. В итоге злоумышленники всегда в выигрыше. Специализированные банковские ботнеты имеют средний улов в 20-40 тысяч аккаунтов ДБО, что позволило сделать о том, что проституция, наркотики и терроризм "отдыхают" по сравнению с хищениями в ДБО (то ли еще будет).


При этом действующее законодательство находится на стороне преступников, а вступающий в силу ФЗ-161 "О национальной платежной системе" ситуацию только усугбляет, не только формируя ощущение безнаказанности у преступников, но и по сути узаконивая мошенничество. В пресловутой 9-й статье ФЗ-161 говорится о том, что по завялению клиента банк сначала обязан возместить ему потери, а потом уже доказывать, что виноват клиент. Представляете себе каким буйным цветом расцветет мошенничество в России? Пока действующее законодательство тоже не сильно помогает банкам. Например, хищения, как правило, происходят не там, где выводятся деньги. А по УПК дело возбуждается по месту вывода денег, а не их хищения. Это дает возможность следственным органам перекидывать дела между собой, что убийственно сказывается на результате действий банковских служб безопасности. Ведь деньги выводятся мобильно - за 2-3 часа. Судебное решение получить за это время нереально; как и осуществить коммуникации с коллегами. При этом атаки осуществляются преимущественно из регионов с большим количеством "зон". Деньги уходят в тюрьмы, в теневой бизнес, и вернуть их оттуда почти невозможно.

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

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


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

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

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

Ситуацию осложняет то, что часто вывод денег осуществляется через мобильных операторов и системы мгновенных платежей (например, Юнистрим), с которыми тоже нужно взаимодействовать. А пока, как было сказано на конференции, из большой тройки только Билайн и МТС озабочены данной проблемой и пытаются бороться с ней.

Как сказал председатель Нацбанка Башкирии Марданов Р.Х., основная причина хищений - недостаточная защищенность ДБО. Причем подвержены атакам и уязвимостям все типы ДБО - и "тонкие" и "толстые" клиенты. Об этом говорят и последнее исследование Digital Security и webinar'ы Positive Technologies. Производители же ДБО игнорируют эту проблему и считают, что их это не касается. Им пора уже задуматься! Сейчас формируются стандарты и требования для разработчиков платежных приложений в части ИБ, которые позволят унифицировать рекомендации не только в части повышения защищенности ДБО, но и сформируют единый набор требований к системе сбора доказательств, которые должны будут фиксировать системы ДБО.


3 главных угрозы ДБО - кража ключей электронной подписи, удаленное управление пользовательским компьютером без ведома владельца и подмена/модификация платежных поручений.Для нейтрализации этих угроз на конференции представлены были различные решения - TrustScreen, MAC-токены, QR-мидлеты и LiveCD/LiveUSB. "Актив", Аладдин Р.Д., VASCO, Бифит, С-Терра представляли все из них. Интересно, что о TrustScreen'ах - доверенных средствах отображения подписываемых платежных документов заговорили на прошлогодней конференции и вот уже сейчас рабочие решения были представлены потребителям.

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

Вот так примерно выглядел третий день деловой программы конференции.

ЗЫ. Завтра поговорим о мобильных устройствах и облаках в банковской деятельности.

Подробнее…