вторник, 24 декабря 2013 г.

СЗПДн. Анализ. Зимний пакет изменений 152-ФЗ

Сегодня зарегистрирован очередной законопроект о внесении изменений в 152-ФЗ.

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

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

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

Советую всем интересующимся самостоятельно прочитать законопроект и пояснительную записку к нему.

PS: Так-же можно почитать впечатления Михаила Емельянникова, который участвовал в разработке данного законопроекта.  

понедельник, 23 декабря 2013 г.

СОИБ. Анализ. Модель угроз SAP

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

Изначально мне надо было подобрать комплекс технических решений по защите SAP, потом возникло желание протестировать применение приказов 17, 21 и недавнего проекта методического документа ФСТЭК Р на практике.

Для начала зафиксируем характеристики ИС, на основе которых в дальнейшем будем делать выбор мер защиты. Так как регулятор нам не дал нам необходимого перечня – придется придумывать самому.






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

В предыдущих заметках (тут и тут) я приводил результаты моделирования угроз /экспресс-анализа рисков в виде таблицы.

В этот раз я решил выполнить модель угроз в виде графической схемы .  А почему бы и нет, если методические документы ФСТЭК нам не говорят что такое моделирование угроз?


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

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



Отличительные особенности модели угроз ИС на платформе SAP: наиболее ценная информация хранится в БД, но на серверах приложений реализуется большое количество обработки (бизнес-логики) и они так-же относятся к наиболее критичным, а вот на АРМ пользователей объемы информации минимальны и угрозы для них получаются неактуальными, на общем фоне. Ещё одна особенность - большой масштаб приложений SAP и как следствие в них, почти наверняка, будут уязвимости; кроме этого в каждой организации разрабатывается надстройки на ABAP или Java, которые уникальны для организации, но так-же могут содержать уязвимости.

В следующей статье продолжу непосредственно про выбор мер защиты ИС на платформе SAPи способов их реализации.

PS: Другие полезные материалы по теме угроз SAP – от DSec и PTsecurity





пятница, 20 декабря 2013 г.

СОИБ. Анализ. Что может выбирать оператор / эксперт

Последнее время от многих экспертов слышу: чем меньше обязательных правил / требований -> тем больше свобода выбора  -> тем лучше систему обеспечения ИБ можно построить.
А зачем организации вообще обращаются к каким-то стандартам, методикам, design guide-ам или другим лучшим практикам?  Если эти ограничения делают систему хуже, зачем тогда появились все эти серии документов от ISO, NIST, SANS, OWASP, СТО БР ИББС, ГОСТ ИСО/МЭК?
Пожалуй, потому, что с ним СОИБ приобретает ряд полезных свойств:
·        Накопление и передача знаний. Даже если человек занимается безопасностью всю жизнь, он не может быть экспертом во всех областях (не касается Алексея Лукацкого)
·        Системность подхода. В информационной безопасности самые опасные инциденты начинаются с самого слабого звена, поэтому надо не забыть рассмотреть все звенья
·        Независимость системы от одного ответственного за ИБ. Если система построена полностью на базе знаний и суждений одного человека, то с его уходом  систему придется создавать заново.
·        Защита от ошибок эксперта. К сожалению, всем людям свойственно ошибаться. Обнаружив противоречие своих суждений и стандарта можно хотя-бы ещё раз внимательно подумать/перепроверить.
·        Удобство коллективной работы. Как я уже писал ранее, во время жизненного цикла СОИБ на неё оказывают влияние следующие типы лиц: Оператор, Обработчики, Подрядчики – проектировщики, Подрядчики – поставщики, Подрядчики – аутсорсеры, Производители средств защиты информации, Аудиторы, Регуляторы. Они должны взаимодействовать на одном языке (термины), одинаково понимать требования, понимать решения и аргументы другой стороны. Сколько раз сталкивался с ситуацией, что после нескольких первых этапов меняется подрядчик, говорит что всё раньше было сделано неправильно и надо переделывать с нуля. Или приходит регулятор со своим списком проверяемых документов и его не волнует что у вас документ называется “Акт установления уровня защищенности”. Если у вас нет “акта классификации” значит требования законодательства не выполняются.
Теперь посмотрим только на методики. Среди основных показателей эффективности методики можно выделить:
·        Точность в достижении цели. Следуя указаниям методики пользователь должен получать результат соответствующий целям методики.

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

Посмотрим теперь методический документ ФСТЭК России версии 1.3 “Меры защиты информации в государственных информационных системах”.
Цели его применения:
“Методический документ применяется для выбора и реализации в соответствии с пунктом 21 Требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах, утвержденных приказом ФСТЭК России от 11 февраля 2013 г. № 17, организационных и (или) технических мер защиты информации в информационных системах, направленных на исключение:
неправомерных доступа, копирования, предоставления или распространения информации (обеспечение конфиденциальности информации);
неправомерных уничтожения или модифицирования информации (обеспечение целостности информации);
неправомерного блокирования информации (обеспечение доступности информации).”
Как я писал в предыдущих заметках, документ не помогает в выборе мер. Разделы связанные с выбором – просто скопированы из Приказа ФСТЭК России. Следующие связи отсутствуют: характеристики ИС-меры, цели обработки – меры, угрозы – меры, объекты защиты – меры.
То есть, не факт что пользователь данной методики сможет выбрать меры. А значит цели не достигаются.
Повторяемость результатов.  По сути в документе приводится только последовательность блоков действий: определение базового набора, адаптация, уточнение, дополнение. Что и как делать на каждом этапе по сути не написано.
Поэтому 10 пользователей методики взяв одну и ту же систему получат 10 разных результатов.  У одного эксперта перечень мер будет составлять пустое множество. У другого - это будет базовый набор мер. Третий подумает, что может выбирать меры по своему усмотрению. Четвертый будет пытаться обосновать каждую используемую меру актуальной угрозой. Пятый подумает, что надо обосновать каждую неиспользуемую меру. Шестой решит, что может самостоятельно определить класс системы. Седьмой подумает что это должно следовать из модели угроз. Восьмой решит что все меры должны быть регламентированы. Девятый посчитает достаточным, чтобы средства защиты имелись и лампочки горели. Регулятор в любом случае будет искать нарушения.

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



понедельник, 9 декабря 2013 г.

СОИБ. Анализ. Серия 2. предложения к Методическим рекомендациям ФСТЭК по защите ГИС

Проект методического документа ФСТЭК России “Меры защиты информации в государственных информационных системах”.
Продолжаю замечания и предложения:

1.      Опять СЗИ или не СЗИ?
Приказ 17 ФСТЭК требует:
"11. Для обеспечения защиты информации, содержащейся в информационной системе, применяются средства защиты информации, прошедшие оценку соответствия в форме обязательной сертификации на соответствие требованиям по безопасности информации"

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

Это не было сделано в постановлении правительства 1119. Не было сделано в приказе 17 и 21 ФСТЭК. Казалось бы,  если не в методическом документе, то где?

Посмотрим на проблему в конкретной ситуации:

Например, в ИАФ.1 есть требование
"Пользователи информационной системы должны однозначно идентифицироваться и аутентифицироваться для всех видов доступа..."

Мне не повезло, у меня в организации нет SSO.

В начале работы с ИС я включаю АРМ, прохожу аутентификацию в Электронном замке (прикладываю таблетку), потом в ОС Linux (ввожу пароль), потом в службе каталогов LDAP (пароль), потом захожу в службу терминалов Citrix (пароль), там запускаю приложение  SAP (пароль), в ходе работы с ИС периодически захожу ещё в различные сервисы (например, выкладываю файлы на FTP и т.п.)
Даже для пользователя 1 ИС у нас набирается  порядка 10 доступов.

Во всех доступах я должен применить меру защиты информации "ИАФ.1".
В соответствии с приказом 17 я буду обязан сертифицировать все эти 10 сервисов доступа (только для одной ИАФ.1 десять сертификаций !!!)

Ведь ни где не указывается что достаточно одного сертифицированного средства защиты информации.

Придется сертифицировать всё. В том числе SAP.

А если у меня ИС 1 и 2 класса, то придется этот SAP ещё и по 4 уровню НДВ сертифицировать. А это астрономические суммы и сроки.

Я не верю что регулятор так и планировал. Скорее просто недодумал с какими проблемами столкнутся операторы.

Предложение (Вариант 1):  Ввести определение, которое бы ограничивало множество “средства защиты информации”

Предложение (Вариант 2):  Совместно с группой экспертов подготовить перечень типов средств защиты информации, которые сертифицированы или могут быть сертифицированы в ближайший год. Явно написать, что требуется сертификация для средств защиты информации  приведенных типов. Можно так-же привести в подразделах “требования к реализации мер защиты информации”, что если применяются средства защиты информации таких то типов, то требуется их сертификация.

Предложение (Вариант 3):  Уточнить что при дублировании мер безопасности различными средствами защиты, обязательна сертификация одного из них.

2.      Используемые термины.

Цитирую ИАФ.1
“3) в информационной системе должна обеспечиваться многофакторная (двухфакторная) аутентификация для сетевого (с использованием сети связи общего пользования, в том числе сеть Интернет) доступа в систему с правами непривилегированных учетных записей (пользователей);
5) в информационной системе должна обеспечиваться многофакторная (двухфакторная) аутентификация для локального (без использования информационно-телекоммуникационной сети) доступа в систему с правами непривилегированных учетных записей (пользователей);”

Первый раз вижу чтобы “удаленный доступ” обозвали “сетевым доступом”.
Позвольте, а куда попадает доступ к ИС через локальную вычислительную сеть (ЛВС)?

ЛВС – это информационно-телекоммуникационная сеть; смотрим 149-ФЗ.

Но ЛВС – это не сеть связи общего пользования; смотрим  126-ФЗ.

Разработчики забыли про ЛВС? В этом же документе есть мера “УПД.13 Реализация защищенного удаленного доступа субъектов доступа к объектам доступа через внешние информационно-телекоммуникационные сети”

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

Предложение 2:  определить корректный, не противоречащие законодательству РФ базовый набор структурно-функциональных  характеристик ИС (как я предлагал в предыдущей серии). Далее, в описании всех мер, использовать единые наименования характеристик ИС.

четверг, 5 декабря 2013 г.

СОИБ. Анализ. Мои предложения к Методическим рекомендациям ФСТЭК по защите ГИС.


Замечания и предложения:
1.      Мерам защиты – короткие и запоминающиеся имена.
Разработчики документов ФСТЭК загнали себя в терминологическую ловушку. По закону они должны были разработать состав и содержание мер защиты. По логике они должны были для начала придумать понятные и удобные наименования для мер защиты. Они попытались это совместить. Вышло неудачно.

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

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

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

Кроме того, ГИС – это только одна из множества ИС Организации. (например, 10%). ИСПДн – это тоже одна из множества ИС Организации (например, 10%). Остальные системы Организация тоже хочет защищать и наверняка будет использовать для этого какие-то стандарты: ИСО серии 27000, Cobit, NIST.

Для того чтобы оператор мог сопоставлять стандарты и использовать сходные меры для защиты всех ИС, необходимо использовать обще-употребимые наименования.

Кстати, ранее я уже делал сопоставление мер из Top 20 от NIST и мер защиты из приказа 21 ФСТЭК. Но лучше если такое сопоставление будет идти от группы экспертов и регулятора.

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

Пример:
Условное обозначение и номер меры
Наименование Меры защиты информации в информационных системах
Определение Меры защиты информации в информационных системах
ИАФ.1
Идентификация и аутентификация пользователей
Identification and Authentication (Organizational Users)
Идентификация и аутентификация пользователей, являющихся работниками оператора
ИАФ.2
Идентификация и аутентификация устройств
Device Identification and Authentication
Идентификация и аутентификация устройств, в том числе стационарных, мобильных и портативных
ИАФ.3
Управление идентификаторами
Identifier Management
Управление идентификаторами, в том числе создание, присвоение, уничтожение идентификаторов
ИАФ.4
Управление аутентификацией
Authentificator   Management
Управление средствами аутентификации, в том числе хранение выдача, инициализация, блокирование средств аутентификации и принятие мер в случае утраты и (или) компрометации средств аутентификации

Предложение 2. Разработать в качестве приложения к методическому документу – таблицу соответствия базовых мер защиты и мер из стандартов ИСО серии 27000, Cobit, NIST.

2.      Адаптации – дефиницию!!!

В разделе 2.3 б) не определено как именно учитываются цели, задачи и перечень мероприятий.
“2.3 б)
При адаптации базового набора мер защиты информации учитываются:
цели и задачи защиты информации в информационной системе;
перечень мероприятий проводимых оператором по обеспечению безопасности в рамках организации в целом;”

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

Предложение 3. Необходимо привести базовый набор “целей” и “задач защиты информации в ИС”, типы “мероприятий по обеспечению безопасности в рамках организации в целом”. Дать целям и задачам идентификаторы.
Необходимо для каждой базовой меры защиты информации определить, каким целям и задачам она соответствует. А так-же провести связь между “мероприятиями по ... в целом” и базовыми мерами защиты информации. В каких случаях мероприятие может исключать меры защиты?

Предложение 4.
Необходимо определить базовый набор структурно-функциональных  характеристик. Дать им идентификаторы.
Необходимо привести зависимость между базовыми мерами защиты и структурно-функциональными характеристиками. В каких случаях наличие определенных характеристик может исключать меры защиты?  Это все можно привести в описании меры защиты.

3.      Потеряна связь между угрозами и мерами защиты
“2.3
Меры защиты информации, выбираемые для реализации в информационной системе, должны обеспечивать блокирование одной или совокупности нескольких актуальных угроз безопасности информации, включенных в модель угроз безопасности информации.”
2.3 в)
При уточнении адаптированного базового набора мер защиты информации для каждой угрозы безопасности информации, включенной в модель угроз, из адаптированного базового набора мер защиты информации сопоставляется мера защиты информации, обеспечивающая блокирование этой угрозы безопасности или снижающая вероятность ее реализации исходя из условий функционирования информационной системы.”

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

4.      Отсутствуют метрики и процедуры для оценки меры.
В соответствии с приказом 17 ФСТЭК в рамках внедрения мы должны проверять работоспособность системы защиты информации, в рамках аттестации – оценивать и в рамках эксплуатации СОИБ регулярно анализировать и оценивать СОИБ:
“16.4. Предварительные испытания системы защиты информации информационной системы ... включают проверку работоспособности системы защиты информации информационной системы,  ...
18.14 В ходе контроля (мониторинга) за обеспечением уровня защищенности информации, содержащейся в информационной системе, осуществляются:
анализ и оценка функционирования системы защиты информации информационной системы, включая выявление, анализ и устранение недостатков в функционировании системы защиты информации информационной системы;
принятие решения по результатам контроля (мониторинга) за обеспечением уровня защищенности информации о доработке (модернизации) системы защиты информации информационной системы, повторной аттестации информационной системы или проведении дополнительных аттестационных испытаний.”

В описании базовых мер защиты отсутствует описание метрик и процедур оценки работоспособности базовых мер защиты или обеспечения ими уровня защищенности. Данное упущение может стать проблемой или даже коррупциогенным фактором при внешнем аудите или проверке Регулятора, так как разные специалисты будут трактовать работоспособность меры по-своему.
Предложение 6. Для каждой базовой меры защиты определить метрики и процедуры анализа работоспособности. Например, можно использовать одну из лучших мировых практик «Critical Controls for Effective Cyber Defence» от SANS.

PS:
Так и не успел добраться до замечаний к самим мерам. Об этом в следующей заметке.

В данной заметке только замечания. Значит ли это, что у меня негативное отношение к документу? Вовсе нет. Я благодарен ФСТЭК и группе экспертов разработчиков за то что документ в принципе появился на свет. А он мог и не появится. 

Но от этих же лиц зависит, будет ли этот документ валятся в пыли или активно использоваться при создании систем защиты информации. А если будет использоваться, то в 5% или в 50% работ?
Хотелось бы вариант документа, которым буду пользоваться регулярно при создании и эксплуатации СОИБ, а иначе зачем вообще всё это затеяно?

Ну а чтобы этот методический документ приобрел статус "лучшей практики" есть следующее: 
Предложение 7. В информационном письме или пояснительной записке к документу привести следующую информацию:
·        кто (какие эксперты или организации) разрабатывал данный документ?
·        как осуществлялся отбор лиц для участия в разработке документа?
·        на какой основе эти лица участвовали в разработке? Платно или бесплатно? Если платно, то по какому конкурсу, тендеру?

PSS: Также комментарии и замечания (но пока без предложений) к данному документу можно почитать у Алексея Лукацкого и Андрея Прозорова.

вторник, 3 декабря 2013 г.

Общее. Конференция Antifraud Russia 2013


На днях прошла четвертая международная конференция Antifraud Russia 2013 посвященная борьбе с мошенничеством в сфере высоких технологий, а особенно в банковской сфере, телекоммуникациях, ритейле, электронной торговле.


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

Основные тезисы с пленарного заседания подробно представлены в обзоре на banki.ru.

Отмечу те моменты, которые понравились лично мне. (В течении конференции публиковал их в твиттере с тегом #antifraudrussia)

Как всегда, было интересно послушать Илью Сачкова из Group-IB. Он приводил основные моменты из отчета своей компании “Рынок преступлений в области высокихтехнологий: состояние и тенденции 2013 года”. Аналогичный доклад Илья уже делал на нескольких конференциях в этом году, но для того, кто не читал полную версию отчета, послушать было интересно. По расчетам Group-IB получилось, что объем рынка киберпреступности уменьшился.  Остальные участники конференции говорили о росте.

Илья отметил новые тренды – целевые атаки на сотрудников  банков, заражение и подмена POS-терминалов. Например в прошлом году было зафиксировано 23 заражения АРМ-а операциониста банка, с которого в дальнейшем осуществлялся несанкционированный доступ.

Также Илья обратил особое внимание на теневой интернет, такой как сеть Tor и неконтролируемую валюту - bitcoin. По его словам, там в открытую продают оружие, наркотики и базы данных пластиковых карт.  Выявлялись прецеденты, когда человек заказывал наркотики, которые доставлялись ему службой “Почта России”.

Илья призвал бороться с такими сетями. Так как обычной фильтрацией по iP-адресам и URL не обойтись (так как сети децентрализованные, нет одного узла который достаточно будет  запретить) то необходимо использовать технологии типа DPI.

Евгений Балезин из MasterCard привел интересную статистику Trustwerse и собственную. По их статистике основной целью атак были магазины электронной коммерции и точки продаж (магазины). Прокомментировал, что заражать вредоносным кодом POS-терминалы сложно, а вот подменить POS-терминал можно легко, в сговоре с персоналом магазина.



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


Стоянов Руслан из Лаборатории Касперского рассказал про “темный путь”: от неофита до киберпреступника, а так-же предложил бороться с киберпреступниками как с педофилами. А именно выпустить законы о запрете данного контента, определить характеристики, фильтровать информационные хакерские ресурсы, фильтровать сервисное облако, придумать уголовные статьи, по которым пройдут владельцы сервисного облака для киберпреступников.


На круглом столе «Как защитить интересы банков и клиентов в рамках законодательства о Национальной платежной системе» мы не увидели заявленных Руслана Гаттарова из СФ РФ , Олега Иванова из АРБ, Дмитрия Фролова из ЦБ РФ. Дмитрий Волков из Group-IB и  Ильдар Мингазов из Управления "К" держались немного в стороне от общего обсуждения. Они рассказали свою часть про проблемы и успехи в поимке киберпреступников и в остальном обсуждении фактически не участвовали.


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

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

В остальном, обсуждение на круглом столе свелось к констатации проблем с ст. 9 161-ФЗ:
·        банки не имеют юридической возможности приостанавливать платежи, даже если знают что это мошенничество.
·        банки не имеют права проводить расследование преступлений.
·        нет механизма для черных списков, хотя все (банки) понимают что они нужны

Общее мнение круглого стола - изменения в 9 статье 161-AP с нового года вступают в силу, а банки к ним не готовы,  законодательство надо совершенствовать и срочно. Как кто и когда должен начать изменение законодательства - не понятно. Явно не хватало отсутствующих участников от ЦБ РФ, СФ РФ и АРБ для разъяснения этого вопроса.

А в кулуарах Евгений Безгодов, из Дейтерия рассказал как PCI DSS выпустила кривой перевод стандарта на русский язык. Рабочая группа в течении года его корректировала. Сейчас на финальной стадии они с Евгением Бартовым из Альянс-PRO допиливают и PCI DSS в ближайшее время опубликует.

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


Алексей Сизов из Джет-а, рассказывал как антифрод системы “тормозят”. Мобильные платежи обрабатываются в доли секунды, а антифрод системы выполняют кучу аналитики и не успевают за платежными системами даже если запускаются параллельно. Выходы – либо запускать антифрод раньше чем обработку платежей (предсказания?) либо внедрять возможность мобильного блокирования и отзыва мобильных платежей.

Дмитрий Костров, выступал как независимый эксперт и сделал обзор всех нормативных документов в области СОРМ. Особо отметил новые документы. Выходят ещё одни технические требования по СОРМ - теперь будет присоска ФСБ напрямую к базам данных абонентов. Так-же планируются поправки - малых операторов освободить от СОРМ, если их трафик проходит через СОРМ крупных операторов.

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


К числу высказанных и опровергнутых в итоге могу отнести:
·        “Шилов (Бифит): любой нормальный разработчик по- умолчанию  занимается безопасностью продукта. Никакая стимуляция ему не нужна.”
Соучастники стола опровергли это фактами, что в ПО (в том числе банковском ПО) регулярно находят критические уязвимости, тем что любой бизнес идет по пути минимизации затрат.
·        “(Представители банков): мы готовы платить за безопасность банковского ПО, если разработчик будет отвечать финансово за любой ущерб связанный с ошибками в ПО”. Юридически будет очень сложно доказать что преступление совершено из-за наличия уязвимости в ПО. Тем боле что уязвимость может быть одновременно в ОС, СУБД и прикладном ПО. МВД подтвердили что в уголовных делах разработчики не фигурируют, только банк, клиент и нарушитель. А если проводить аналогию – то придется с производителей дверей  требовать компенсацию за квартирные кражи. Но этого никто не делает. Потому что есть некие продукты. Покупатель сравнивает характеристики и выбирает себе подходящий. Далее он может сам проверить его на прочность, а может провести независимую экспертизу. Так-же независимую экспертизу может провести и группа покупателей.
·        “(Представители разработчиков): Мионбразования виновато в плохой подготовке студентов”.
В результате обсуждения выяснили, что студентов врядли удастся ещё в ВУЗе заставить делать безопасный код. Для этого надо следовать большому количеству строгих правил и стандартов, для чего у студентов нет никакого стимула. Если кто-то идет по пути программирования, то он хочет творить, создавать, делать что-то новое. Зато Талантливого программиста Разработчик может отправить на специальные курсы (Рустэм обещал такие организовать) плюс применять корпоративные правила безопасной разработки и превратить его в Безопасного Программиста.
·        “(Представители разработчиков): Банки хотят безопасность, а сами не готовы платить за безопасность”.  
В ходе обсуждения выяснилось что за безопасное ПО банки готовы доплачивать разумный процент. За это требовать от разработчика SLA или другие гарантии.
·        “(Представители банков): В ТЗ мы указываем только функциональные требования к банковскому ПО. То что оно должно быть безопасным мы подразумеваем по умолчанию. Этим должен заниматься разработчик”.
Разработчик делает только то что требуется. Его задача в минимальные сроки и за минимальные затраты выполнить требования. А вкладывать в продукт всё о чем мог подразумевать заказчик (котики?) он не будет. Требования по безопасности обязан выдвинуть банк – заказчик.
·        “(Представители разработчиков): Программисты не любят пентестеров, вы ломаете нам код. Обламываете крылья”.  
Соблюдать требования ИБ некомфортно, это вызывает дополнительные трудозатраты, но приучить себя можно, перетерпеть. Ему ведь за это платят деньги. Это в том случае если будет спрос на безопасность. У Microsoft он возник 4-5 лет назад и они внедрили SDL.
·        “(ВСЕ): Так как всем нужен стимул чтобы заниматься ИБ, хорошо если ктото большой и сильный обяжет всех это делать”.  
Сычев из ЦБ ответил: можете даже не рассчитывать на такой сценарий. В планы ЦБ не входят обязательные требования, проверки, сертификации банковского ПО.

Высказывания с которыми большинство согласилось:
·        “Бешков (Microsft): если разработчика не мотивировать кнутом, то ничего делать не будет”.
Поэтому Microsoft выстроили свой анализатор кода в Visual Studio по умолчанию. Поэтому разработчику кто-то должен предъявить жесткие требования по ИБ, заключить SLA. И разработчику должно быть что терять (репутация, деньги) – только тогда он будет заниматься ИБ. Поэтому банкам надо публиковать информацию об инцидентах, связанных ошибками в банковском ПО.
·        “Рустем (Appercut): лечить надо то что болит. У многих ИТ директоров дыры в ПО - не болят. А вот стабильная работа ДБО их больше волнует”.  
Большинство согласилось, что если заказчик (банк) не заинтересован в безопасности (а заинтересован в чем-то другом), то ни разработчик ни аудитор ни поставщики решений безопасности его не убедят заниматься безопасностью.
·        “Медведовский (DSec): разработчики живут на другой планете. Мы обнаруживаем огромное количество критичных уязвимостей в банковском ПО. Зарегистрировано много инцидентов связанное со слабостью защитных механизмов ДБО”
·        “Шилов (Бифит): за прошлый год только 7 из 400 заказчиков-банков обратилось с информацией об уязвимостях. И то ошибки были в окружении - ОС и Вебсервере”
·        “Сычев (ЦБ): Требования к безопасности банковского ПО может выдвигать только заказчик. Чтобы требования были адекватными и комплексными, можете объединяться и делать сообща”

PS: Питание и организация мероприятия на отлично. А в процессе написания статьи ни одной кружки-термоса не пострадало.